Ein Web Accessibility Check prüft bei der Fokusführung, ob Tastaturnutzer jederzeit erkennen können, welches Element gerade den Fokus hat, ob die Reihenfolge der fokussierbaren Elemente logisch und vorhersehbar ist und ob der Fokus nicht in Bereichen gefangen bleibt oder unbemerkt springt. Diese Aspekte sind für Menschen, die keine Maus verwenden können, grundlegend für die Bedienbarkeit einer Website. Die folgenden Abschnitte beantworten die wichtigsten Fragen rund um Fokusführung im Accessibility-Test.
Welche Elemente der Fokusführung werden bei einem Accessibility Check geprüft?
Ein Web Accessibility Check prüft bei der Fokusführung drei Kernbereiche: die Sichtbarkeit des Fokusindikators, die logische Reihenfolge fokussierbarer Elemente und das Verhalten des Fokus bei interaktiven Komponenten wie Dialogen oder Menüs. Ziel ist es, festzustellen, ob Tastaturnutzer eine Website vollständig und vorhersehbar bedienen können.
Konkret untersucht ein automatisierter Barrierefreiheitstest folgende Punkte:
- Fokusindikator: Ist der sichtbare Fokusrahmen vorhanden und ausreichend kontrastreich?
- Tab-Reihenfolge: Folgt die Reihenfolge, in der Elemente per Tabulator angesteuert werden, einer logischen Leserichtung?
- Fokus-Fallen: Gibt es Bereiche, aus denen Tastaturnutzer nicht mehr herausnavigieren können?
- Fokus-Management bei Dialogen: Wird der Fokus beim Öffnen eines Modals korrekt hinein- und beim Schließen wieder zurückgeführt?
- Skip-Links: Existieren Mechanismen, mit denen Nutzer wiederkehrende Navigationsbereiche überspringen können?
Automatisierte Tools können einen Teil dieser Prüfpunkte zuverlässig abdecken, insbesondere HTML-basierte Fehler. Andere Aspekte, etwa ob die Tab-Reihenfolge inhaltlich sinnvoll wirkt, erfordern eine manuelle Prüfung.
Was ist ein sichtbarer Fokusindikator und warum prüfen Tools ihn?
Ein sichtbarer Fokusindikator ist eine visuelle Markierung, die anzeigt, welches interaktive Element auf einer Website gerade den Tastaturfokus hat. Typischerweise erscheint er als farbiger Rahmen oder Umriss um Schaltflächen, Links oder Formularfelder. Accessibility-Tools prüfen ihn, weil sein Fehlen Tastaturnutzer und Screenreader-Nutzer effektiv von der Bedienung ausschließt.
Viele Websites entfernen den Standard-Fokusrahmen des Browsers per CSS mit der Regel outline: none, ohne einen gleichwertigen Ersatz zu schaffen. Für Menschen, die auf Tastaturnavigation angewiesen sind, etwa Menschen mit motorischen Einschränkungen oder blinde Nutzer, die einen Screenreader kombiniert mit Tastatur einsetzen, bedeutet das: Sie wissen nicht, wo sie sich auf der Seite befinden.
Automatisierte Tests prüfen unter anderem, ob der Fokusindikator einen ausreichenden Farbkontrast zum Hintergrund aufweist. WCAG 2.2 hat mit dem Erfolgskriterium 2.4.11 (Focus Appearance) die Anforderungen an den Fokusindikator konkretisiert: Mindestgröße und Kontrastverhältnis des Fokusrahmens werden nun explizit definiert. Ein barrierefrei testender Scanner kann prüfen, ob ein Fokusindikator grundsätzlich vorhanden ist und ob er die Kontrastanforderungen erfüllt.
Wie erkennt ein Accessibility Check eine fehlerhafte Tab-Reihenfolge?
Ein Accessibility Check erkennt eine fehlerhafte Tab-Reihenfolge vor allem durch die Analyse positiver tabindex-Werte im HTML-Code. Positive Werte wie tabindex=“2″ oder tabindex=“5″ reißen Elemente aus der natürlichen DOM-Reihenfolge heraus und erzeugen häufig eine Navigationsabfolge, die für Tastaturnutzer verwirrend oder unlogisch wirkt.
Tools wie axe-core, auf die sich professionelle Barrierefreiheits-Software stützt, markieren solche Konstrukte als potenzielles Problem. Darüber hinaus prüfen sie, ob interaktive Elemente überhaupt fokussierbar sind, also ob Links, Buttons und Formularfelder im Tastaturfokus erreichbar sind und nicht durch tabindex=“-1″ ohne funktionalen Grund ausgeschlossen wurden.
Was ein automatisierter WCAG-Test nicht beurteilen kann, ist die inhaltliche Logik der Reihenfolge: Ob der Fokus erst auf die Hauptnavigation, dann auf den Seiteninhalt und zuletzt auf die Fußzeile wandert, lässt sich nur durch manuelle Tastaturnavigation überprüfen. Ein automatischer Scan liefert hier Hinweise, ersetzt aber keine vollständige manuelle Prüfung.
Welche Fokusführungs-Probleme kann ein automatischer Check nicht erkennen?
Ein automatischer Accessibility Check kann mehrere Kategorien von Fokusführungs-Problemen nicht zuverlässig erkennen. Dazu gehören die inhaltliche Sinnhaftigkeit der Tab-Reihenfolge, das korrekte Fokus-Management in dynamischen Komponenten und die tatsächliche Nutzbarkeit von Skip-Links im Kontext der Seite. Schätzungen aus der Forschung gehen davon aus, dass automatisierte Tests etwa 30 bis 50 Prozent aller Barrierefreiheitsprobleme abdecken.
Konkret bleiben folgende Fokusführungs-Probleme typischerweise unsichtbar für automatische Tools:
- Logische Lesereihenfolge: Ob die Tab-Reihenfolge dem inhaltlichen Aufbau der Seite entspricht, lässt sich nur durch manuelles Durchtabben beurteilen.
- Fokus-Management in Single-Page-Anwendungen: Wenn JavaScript neue Inhalte lädt, ohne den Fokus zu setzen, bemerkt ein statischer HTML-Scan das nicht.
- Modale Dialoge und Overlays: Ob der Fokus beim Öffnen eines Dialogs korrekt ins Modal wandert und beim Schließen zurückkehrt, erfordert eine Interaktion, die automatisierte Scans meist nicht simulieren.
- Fokus-Fallen in bestimmten Widget-Typen: Komplexe ARIA-Widgets wie Karussells oder benutzerdefinierte Dropdowns können Fallen erzeugen, die nur durch aktive Bedienung sichtbar werden.
- Wirksamkeit von Skip-Links: Ein Skip-Link kann im HTML vorhanden und für den Scanner sichtbar sein, aber beim Aktivieren auf ein nicht fokussierbares Ziel verweisen.
Aus diesem Grund empfiehlt sich nach einem automatischen Barrierefreiheitstest stets eine ergänzende manuelle Prüfung, insbesondere mit Tastatur und einem Screenreader.
Welchen WCAG-Kriterien ordnet ein Check die Fokusführungs-Befunde zu?
Ein Accessibility Check ordnet Fokusführungs-Befunde hauptsächlich den WCAG-Erfolgskriterien aus dem Bereich Bedienbar (Prinzip 2) zu. Die relevantesten Kriterien sind 2.1.1 (Tastatur), 2.1.2 (Keine Tastaturfalle), 2.4.3 (Fokus-Reihenfolge), 2.4.7 (Fokus sichtbar) sowie 2.4.11 und 2.4.12 aus WCAG 2.2 zur Darstellung des Fokusindikators.
Im Einzelnen bedeuten diese Kriterien:
- 2.1.1 Tastatur (Level A): Alle Funktionen der Website müssen per Tastatur erreichbar und bedienbar sein.
- 2.1.2 Keine Tastaturfalle (Level A): Nutzer dürfen nicht in einem Bereich der Seite gefangen werden, aus dem sie per Tastatur nicht mehr herausgelangen.
- 2.4.3 Fokus-Reihenfolge (Level A): Fokussierbare Komponenten müssen in einer Reihenfolge navigierbar sein, die Bedeutung und Bedienbarkeit erhält.
- 2.4.7 Fokus sichtbar (Level AA): Jede über Tastatur bedienbare Benutzeroberfläche muss einen sichtbaren Tastaturfokus haben.
- 2.4.11 Fokus nicht verdeckt (Minimum) (Level AA, WCAG 2.2): Ein fokussiertes Element darf nicht vollständig durch andere Inhalte verdeckt werden.
- 2.4.12 Fokus nicht verdeckt (Erweitert) (Level AAA, WCAG 2.2): Das fokussierte Element muss vollständig sichtbar sein.
Für die BITV-Prüfung, die in Deutschland für öffentliche Stellen verpflichtend ist und auf WCAG 2.1 Level AA basiert, sind vor allem die Level-A- und Level-AA-Kriterien maßgeblich. Das Barrierefreiheitsstärkungsgesetz (BFSG) orientiert sich ebenfalls an diesen Standards und gilt ab 2025 auch für viele private Anbieter.
Wie lassen sich Fokusführungs-Fehler nach einem Check beheben?
Fokusführungs-Fehler lassen sich nach einem Accessibility Check durch gezielte CSS-, HTML- und JavaScript-Anpassungen beheben. Der erste Schritt ist stets, die im Report priorisierten Probleme nach Schweregrad zu bearbeiten, beginnend mit Fokus-Fallen und fehlenden Fokusindikatoren, da diese die Bedienbarkeit am stärksten einschränken.
Fokusindikator wiederherstellen
Entfernen Sie die CSS-Regel outline: none oder outline: 0 aus Ihrem Stylesheet, sofern kein gleichwertiger Ersatz definiert ist. Gestalten Sie einen eigenen Fokusindikator, der zum Design passt und gleichzeitig die Kontrastanforderungen der WCAG erfüllt. Ein Kontrastverhältnis von mindestens 3:1 zwischen dem Fokusrahmen und dem angrenzenden Hintergrund ist empfehlenswert.
Tab-Reihenfolge korrigieren
Vermeiden Sie positive tabindex-Werte. In der Regel genügt es, die DOM-Reihenfolge im HTML so anzupassen, dass sie der visuellen Leserichtung entspricht. Verwenden Sie tabindex=“0″ nur, um nicht interaktive Elemente fokussierbar zu machen, und tabindex=“-1″ gezielt für Elemente, die per JavaScript fokussiert werden sollen, aber nicht in der natürlichen Tab-Reihenfolge erscheinen dürfen.
Fokus-Management in dynamischen Inhalten
Wenn Dialoge, Modals oder neue Seitenbereiche per JavaScript geladen werden, setzen Sie den Fokus programmatisch mit element.focus() auf das erste sinnvolle Element innerhalb des neuen Bereichs. Beim Schließen eines Modals führen Sie den Fokus zurück auf das auslösende Element, etwa den Button, der das Modal geöffnet hat.
Skip-Links einbauen
Fügen Sie am Seitenanfang einen Skip-Link ein, der Tastaturnutzern ermöglicht, direkt zum Hauptinhalt zu springen. Das Ziel-Element muss fokussierbar sein, entweder durch ein natives interaktives Element oder durch tabindex=“-1″ in Kombination mit einem programmatischen Fokus.
Nach jeder Korrektur empfiehlt sich ein erneuter Scan, um zu überprüfen, ob die Änderung den gewünschten Effekt erzielt hat, und eine ergänzende manuelle Tastaturprüfung, um die inhaltliche Logik der Fokusführung zu bestätigen.
So unterstützt decareto bei der Prüfung der Fokusführung
Wir haben decareto entwickelt, um Agenturen, Compliance-Teams und Datenschutzbeauftragte dabei zu unterstützen, Fokusführungs-Probleme und andere Barrierefreiheitsfehler systematisch zu identifizieren und zu dokumentieren, ohne dafür zum WCAG-Spezialisten werden zu müssen.
- Automatisierter Barrierefreiheits-Scan: Wir prüfen Websites seitenübergreifend auf Fokusführungs-Fehler gemäß WCAG und BITV, inklusive fehlender Fokusindikatoren, problematischer tabindex-Nutzung und erkennbarer Fokus-Fallen.
- Priorisierung nach Schweregrad: Jedes gefundene Problem wird als kritisch, schwerwiegend, mittel oder geringfügig eingestuft, damit Sie wissen, wo Sie zuerst ansetzen sollten.
- Konkrete Handlungsempfehlungen: Zu jedem Befund liefern wir Hinweise, wie das Problem behoben werden kann, inklusive CSS-Selektoren und Screenshots des betroffenen Elements.
- Manuell erfassbare Probleme: Probleme, die nur durch manuelle Prüfung erkennbar sind, können direkt im Report ergänzt werden, sodass alle Befunde zentral dokumentiert sind.
- Dauerhaftes Monitoring: Wir überwachen Ihre Websites kontinuierlich und benachrichtigen Sie automatisch, wenn sich nach einem Update neue Barrieren ergeben.
- Whitelabel-Reports: Externe Dienstleister können Berichte unter eigenem Logo mit Kunden teilen.
Möchten Sie wissen, wie Ihre Website bei der Fokusführung und weiteren Barrierefreiheitskriterien abschneidet? Testen Sie decareto jetzt und erhalten Sie in wenigen Minuten einen strukturierten Accessibility-Report.
Dieser Text wurde mit Hilfe von KI erstellt und könnte Fehler beinhalten.
Ähnliche Artikel
- Was ist der Unterschied zwischen WCAG-Stufe A und AA in der Praxis?
- Wie erkennt man Barrierefreiheitsprobleme bei Schriftgrößen und Zoom?
- Was sind die wichtigsten WCAG-Kriterien für Online-Shops?
- Welche Datenschutzrisiken entstehen durch eingebettete Google-Maps-Karten?
- Wie erkennt man Barrierefreiheitsprobleme bei eingebetteten Videos?
