Beginnen Sie mit Aufgaben und einer schlanken Informationsarchitektur
Informationsarchitektur beschreibt, wie Inhalte und Funktionen gruppiert, benannt und verbunden sind. Listen Sie Besucheraufgaben auf und kartieren Sie für jede Aufgabe die Startseite, die nächste Seite und den erfolgreichen Endzustand. So erkennen Sie, ob ein Menüpunkt nützlich ist oder ein internes Label, das Besucher erst entschlüsseln müssen. Halten Sie die primäre Navigation auf die Abschnitte konzentriert, die diese Aufgaben starten.
Navigation ist kein Sitemap. GOV.UK empfiehlt, nützliche Top‑Level‑Bereiche aufzulisten, statt jeden Teil eines Dienstes. Wenn eine Ablauffolge erforderlich ist, zeigen Sie sie im Inhalt oder als Aufgabenliste, anstatt die Nutzer aus einem globalen Menü ableiten zu lassen.
Fassen Sie Seiten zusammen, wenn Besucher dieselbe Antwort oder Aufgabe erwarten, nicht weil ein Team sie verwaltet.
Nutzen Sie Landingpages und kontextuelle Links für Details statt eines überfrachteten Headers.
Verwenden Sie Bezeichnungen, die das Ziel vorhersagen
Ein Label ist ein Versprechen für das Folgende. Bevorzugen Sie vertraute Bezeichnungen wie „Preise“, „Dokumentation“, „Support“ oder „Konto verwalten“, wenn sie dem Ziel entsprechen. Vermeiden Sie vage Bezeichnungen wie „Ressourcen“ oder „Entdecken“, es sei denn, Besucher können den Inhalt vorhersagen. Halten Sie Wortwahl und Reihenfolge konsistent.
Google empfiehlt prägnanten, relevanten Linktext, der auch im Kontext verständlich ist. Generische „klicken Sie hier“-Links und mit Keywords vollgestopfte Links tun das nicht. Geben Sie einem nur als Icon dargestellten Steuerelement einen zugänglichen Namen, der seine Aktion beschreibt.
Verwenden Sie „Tarife anzeigen“ statt „Mehr erfahren“, wenn das Ziel Tarife sind.
Markieren Sie das aktive Ziel visuell und programmatisch; W3C beschreibt aria-current=page für die angezeigte Seite.
Machen Sie Ziele crawlbar und strukturell klar
Ein Navigationsziel sollte normalerweise ein HTML‑Anker mit einem href sein, das auf eine echte Webadresse verweist. Google sagt, dass es diese Form in der Regel crawlen kann, einschließlich dynamisch eingefügter Anker, wenn das gerenderte Markup diese Struktur beibehält. Ein reiner Klick‑Handler oder ein benutzerdefiniertes Attribut ist kein verlässlicher Ersatz. Untersuchen Sie das gerenderte Ergebnis, nicht nur den Framework‑Quellcode.
Verwenden Sie semantische Struktur um die Hauptnavigation. W3C empfiehlt ein nav‑Element und für gewöhnliche Seitennavigation eine Liste. Hat eine Seite mehrere Navigationsbereiche, beschriften Sie jeden, damit Screenreader‑Nutzer primäre Navigation von Footer‑ oder lokaler Navigation unterscheiden können.
Bestätigen Sie, dass wichtige Desktop‑ und Mobile‑Ziele nach clientseitigem Rendering Anker und href‑Werte haben.
Die URL‑Inspektion liefert Informationen zu Crawling, Indexierung und Auslieferung durch Google; sie beweist nicht, dass Besucher eine Seite finden können.
Gestalten Sie das mobile Menü als vollständige Interaktion
Responsive Navigation darf einklappen, aber Ziele, die erhalten bleiben, sollten auf allen Bildschirmgrößen dieselbe Wortwahl, Reihenfolge und Ziel‑URL behalten. W3C erlaubt das Einklappen oder Verbergen von Elementen in Subnavigation, fordert jedoch Konsistenz. Machen Sie keinen kritischen Pfad nur auf dem Desktop verfügbar, weil der Header überfüllt ist; verschieben Sie weniger wichtige Inhalte oder überdenken Sie die Hierarchie.
Für ein Ein-/Ausblendmenü verwenden Sie einen Button, der die Linkgruppe steuert und kommuniziert, ob sie geöffnet ist. W3C’s disclosure‑navigation‑Beispiel verwendet aria‑expanded und aria‑controls und beschreibt Tab, Shift+Tab und Escape. Es dient der Anleitung – testen Sie Ihre Komponente mit den Kombinationen, die Ihr Publikum nutzt.
Wenn sowohl die Elternseite als auch ihre untergeordneten Links benötigt werden, unterscheiden Sie den Seitenlink von der Steuerung, die ihn aufklappt.
Alles, was durch Pointer‑Hover sichtbar wird, muss auch per Tastaturfokus und Touch auffindbar sein.
Unterstützen Sie Orientierung und Tastaturnavigation
Tastaturzugang ist kein Feinschliff. WCAG 2.1 Erfolgskriterium 2.1.1 verlangt, dass Funktionalität über eine Tastaturschnittstelle bedienbar ist, außer bei pfadabhängigen Eingaben. Im Header sollten Besucher per Tab durch Steuerungen navigieren können, den Fokus sehen, Links und Buttons aktivieren und sich ohne Falle wegbewegen können.
Wiederholte Header‑Links können das Durchqueren von Seiten verlangsamen. Ein Skip‑Link nahe dem Seitenanfang bietet Tastaturnutzern eine Route zum Hauptinhalt. GOV.UK erklärt, dass er visuell verborgen ist, bis die Tastaturnutzung ihn aktiviert. Testen Sie, dass er ein sinnvolles Ziel erreicht.
Entfernen Sie den Browser‑Fokusindikator nicht ohne klare Alternative, die beim Zoomen sichtbar bleibt.
Verwenden Sie Tab, Shift+Tab, Enter, Leertaste und Escape vom Header bis zur Zielseite.
Testen Sie die Auffindbarkeit vor und nach der Veröffentlichung
Bitten Sie repräsentative Personen, eine realistische Aufgabe zu erledigen, z. B. Kündigungsinformationen zu finden oder Tarife zu vergleichen. Beobachten Sie, wohin sie zu gehen erwarten, welche Bezeichnungen sie fehlinterpretieren und ob sie die Suche nutzen, weil die Navigation versagt hat. Leiten Sie sie nicht zum vorgesehenen Label. Protokollieren Sie jede Barriere und die kleinste Änderung, die sie wahrscheinlich beseitigt.
Kombinieren Sie Aufgabentests mit technischen Prüfungen. W3C’s Easy Checks empfiehlt Tests ohne Maus, inklusive Sichtbarkeit des Fokus, Tab‑Reihenfolge, Tastaturfallen und Dropdowns. Wiederholen Sie Kernaufgaben bei schmalen Breiten und vergrößerter Schrift. Automatisierte Prüfungen können Markup‑Probleme melden, aber nicht beweisen, dass ein Label sinnvoll ist.
Notieren Sie vor dem Testen das beabsichtigte Endziel und die unterstützten Geräte bzw. Eingabemethoden.
Testen Sie die alte und neue Route mit denselben Aufgaben, statt sich auf Stakeholder‑Vorlieben zu verlassen.
Behandeln Sie Navigationsänderungen als verfügbarkeitskritische Releases
Ein Header kann laden, während ein kritischer Pfad effektiv nicht verfügbar ist: Checkout, Login, Support‑Route oder eine Dokumentationsseite können hinter einem fehlerhaften Zustand, veralteten Link oder falschen Redirect liegen. Vor der Veröffentlichung inventarisieren Sie kritische Ziele, testen Desktop‑ und Mobile‑Routen und bestätigen, dass gerenderte Links die beabsichtigte Seite erreichen. Verwenden Sie autorisierte Umgebungen für authentifizierte oder regionale Pfade.
Die Rolle von SIU ist proaktive Behebung: Führen Sie eine Vorabprüfung (preflight) durch, verifizieren Sie essenzielle Pfade nach der Bereitstellung und machen Sie Korrekturen reversibel. Bewahren Sie eine versionierte Menükonfiguration, benennen Sie die Person, die sie wiederherstellen kann, und validieren Sie die wiederhergestellten Pfade. Das begrenzt den Release‑Einfluss; es ersetzt weder Usability‑Forschung noch Live‑Status‑Monitoring.
Blockieren Sie die Veröffentlichung, wenn ein kritisches Ziel fehlt, falsch ist oder nicht per Tastatur und Touch erreichbar ist.
Dokumentieren Sie die vorherige Konfiguration, den Besitzer, Auslöser und Validierungsschritte vor einer Umstrukturierung.