Was ist Fokusreihenfolge-Visualisierer?

Fügen Sie beliebigen HTML-Code ein und sehen Sie die Tastatur-Tab-Reihenfolge auf einen Blick. Nummerierte Markierungen erscheinen auf jedem fokussierbaren Element, damit Sie Navigationsprobleme sofort erkennen. Entwickelt für Barrierefreiheits-Prüfer und Entwickler zur WCAG-Konformitätsprüfung.

Der Visualizer erkennt Links, Buttons, Formularfelder, Textareas, Select-Menüs, details/summary-Komponenten, contenteditable-Bereiche und alles mit einem expliziten tabindex. Jedes fokussierbare Element bekommt ein nummeriertes Badge und einen Hinweis, ob die Position aus der DOM-Reihenfolge (natürlich) oder aus einem überschreibenden tabindex (benutzerdefiniert) stammt. Er bewertet die Seite zusätzlich auf einer Skala bis 100, markiert Bedienelemente ohne zugänglichen Namen (das Problem des reinen Icon-Buttons) und zeigt, wie viele interaktive Elemente per Tab nie erreichbar werden. Die Ergebnisse lassen sich als reiner Textbericht oder als strukturierte CSV für Prüfunterlagen und Bugtracker exportieren.

Anleitung

1. Fügen Sie HTML-Code in den Editor ein oder laden Sie eine HTML-Datei hoch, um die Tab-Reihenfolge zu prüfen.
2. Auf jedem fokussierbaren Element (Links, Buttons, Eingabefelder) erscheinen nummerierte Markierungen, die die Tab-Reihenfolge anzeigen.
3. Sehen Sie sich die Bewertung und das Problempanel an, beheben Sie falsch sortierte, unbeschriftete oder per Tastatur nicht erreichbare Elemente und exportieren Sie die Ergebnisse als Textbericht oder CSV.

Wann verwenden

• Voraudit vor Einreichung einer Seite zur WCAG 2.1 AA-Zertifizierung.
• Eine Tab-Order-Regression nach einem Layout- oder Komponenten-Refactor aufspüren.
• Prüfen, ob ein Modal oder Off-Canvas-Menü den Fokus korrekt einschließt.

Ergebnis

Eine Barrierefreiheits-Beraterin fuegt das HTML des Anmeldeformulars eines Kunden ein. Der Visualisierer merkt, dass der 'Absenden'-Button vor der 'AGB'-Checkbox fokussiert wird, weil ein positiver tabindex die Reihenfolge verschoben hat. Das ist ein Verstoss gegen WCAG 2.4.3.

Häufige Fragen

Ist ein positiver tabindex immer falsch?

Fast immer, ja. Positive Tabindex-Werte (1, 2, 3…) reißen das Element aus der DOM-Reihenfolge und lassen den Cursor unvorhersehbar durch die Seite springen. Nutzen Sie tabindex="0", um ein nicht-interaktives Element fokussierbar zu machen, oder tabindex="-1", um es aus der Tab-Kette zu nehmen, ohne den programmatischen Fokus zu verlieren.

Was bedeuten «natürlich» und «benutzerdefiniert» in der Liste?

Natürlich heißt, die Tab-Position kommt aus dem Ort im HTML-Quelltext. Benutzerdefiniert heißt, ein positiver tabindex hat sie woandershin gezwungen. Benutzerdefinierte Positionen werden markiert, weil sie die häufigste Ursache von WCAG 2.4.3-Verstößen sind.

Tauchen versteckte Elemente in der Fokusreihenfolge auf?

Wenn sie wirklich verborgen sind (display:none oder visibility:hidden), überspringt der Browser sie, und der Visualizer auch. aria-hidden allein entfernt aber nicht die Fokussierbarkeit, das ist ein häufiger Bug. Die Liste zeigt solche Elemente, und an den Rechteckdaten erkennen Sie, ob sie sichtbar sind.

Erkennt das Tool fehlende Focus-Traps in Modals?

Es zeigt die Reihenfolge, nicht ob der Fokus aus dem Modal entweicht. Fügen Sie das HTML des geöffneten Modals ein und prüfen Sie, ob das erste und letzte fokussierbare Element im Dialog liegen. Springt die Reihenfolge in den Body-Inhalt, fehlt der Trap.

Warum fehlt ein Element, das ich fokussierbar erwartete?

Deaktivierte Inputs, Anchor ohne href und Divs ohne tabindex werden übersprungen, weil der Browser sie nicht fokussieren kann. Setzen Sie tabindex="0", wenn ein Div erreichbar sein soll, ergänzen Sie href am Anchor oder entfernen Sie das disabled-Attribut.

Ähnliche Tools