Autocomplete und Live-Suchvorschläge barrierefrei nach ARIA

Eine Sucheingabe mit Live-Vorschlägen wirkt für sehende Nutzer selbsterklärend: tippen, Liste erscheint, Pfeiltaste, Enter. Für Screenreader-Nutzer ist genau dieser Ablauf ohne die richtige ARIA-Auszeichnung praktisch nicht nachvollziehbar.

Das Combobox-Pattern der WAI-ARIA Authoring Practices beschreibt exakt, welche Rollen und Attribute nötig sind, damit Vorschlagslisten korrekt angesagt und mit der Tastatur bedient werden können – ohne die Maus überhaupt zu berühren.

Warum Live-Suchvorschläge ein eigenes Pattern brauchen

Ein einfaches Textfeld reicht für Autocomplete nicht aus, weil zusätzlich zum Eingabefeld eine dynamische Liste entsteht, die sich mit jedem Tastenanschlag ändert. Screenreader müssen wissen, dass diese Liste existiert, wie viele Einträge sie enthält und welcher Eintrag gerade fokussiert ist.

Ohne saubere Auszeichnung hört ein Screenreader-Nutzer nur das Tippen im Feld, aber nichts von der erscheinenden Liste – die Vorschläge bleiben faktisch unsichtbar, obwohl sie visuell direkt unter dem Feld stehen.

Das ARIA-Combobox-Pattern schließt genau diese Lücke, indem es Eingabefeld und Vorschlagsliste über feste Attribute miteinander verknüpft.

Die Grundstruktur des Combobox-Patterns

Das Eingabefeld erhält role="combobox", aria-expanded für den Zustand der Liste und aria-controls mit der ID der Vorschlagsliste. Die Liste selbst trägt role="listbox", jeder Vorschlag role="option".

Zusätzlich braucht das Feld aria-autocomplete="list", damit Hilfstechnologie weiß, dass Vorschläge in einer separaten Liste erscheinen, statt den Feldinhalt automatisch zu vervollständigen.

Wichtig ist, dass die Liste nur eingeblendet wird, wenn tatsächlich Vorschläge vorhanden sind, und dass aria-expanded bei jeder Änderung korrekt zwischen „true" und „false" wechselt.

aria-activedescendant statt Fokus-Verschiebung

Der Fokus bleibt beim Combobox-Pattern durchgehend im Eingabefeld – er springt nicht in die Liste hinein. Stattdessen zeigt aria-activedescendant auf die ID des gerade markierten Vorschlags.

Diese Technik erlaubt es, weiterzutippen, während gleichzeitig ein Vorschlag als „aktiv" markiert ist, ohne dass der Screenreader den Kontext des Eingabefelds verliert.

Ändert sich der aktive Vorschlag per Pfeiltaste, muss aria-activedescendant sofort aktualisiert werden – bleibt der Wert stehen, verliest der Screenreader einen veralteten oder gar keinen Vorschlag.

Tastaturnavigation ohne Maus

Pfeil-runter bewegt die Markierung zum nächsten Vorschlag, Pfeil-hoch zum vorherigen. Enter übernimmt den markierten Vorschlag in das Feld, Escape schließt die Liste, ohne die Eingabe zu verändern.

Die Liste darf beim Drücken der Pfeiltasten nicht den Fokus aus dem Eingabefeld herausnehmen – sonst lässt sich nicht mehr weitertippen, um die Suche zu verfeinern.

Tab sollte die Liste schließen und zum nächsten fokussierbaren Element springen, statt in der Vorschlagsliste hängen zu bleiben, was in fehlerhaften Implementierungen häufig vorkommt.

Trefferanzahl für Screenreader ansagen

Zusätzlich zur Liste selbst sollte eine unsichtbare Live-Region die Anzahl gefundener Vorschläge ansagen, etwa „8 Vorschläge verfügbar" nach jeder Eingabe. Ohne diese Ansage bleibt unklar, ob überhaupt Ergebnisse existieren.

Die Live-Region braucht aria-live="polite", damit die Ansage die aktuelle Spracheingabe nicht unterbricht, sondern erst nach einer kurzen Pause folgt.

Bei null Treffern muss ebenfalls eine Rückmeldung erfolgen, zum Beispiel „Keine Vorschläge gefunden", statt die Liste einfach leer und unkommentiert verschwinden zu lassen.

Ein häufig übersehener Punkt ist das Timing der Ansage: Wird die Live-Region bei jedem einzelnen Tastenanschlag aktualisiert, überschneiden sich mehrere Ansagen und der Screenreader bricht mitten im Satz ab. Ein kurzes Debounce von wenigen hundert Millisekunden, bevor die Trefferanzahl tatsächlich angesagt wird, sorgt dafür, dass erst nach einer kurzen Tippunterbrechung eine einzige, vollständige Ansage erfolgt, statt bei jedem Buchstaben eine neue Meldung anzustoßen.

Typische Fehler in React- und Vue-Suchkomponenten

Viele fertige UI-Bibliotheken bauen die Vorschlagsliste als reines <div> ohne role="listbox" und role="option", weil sie primär für die Maus-Bedienung entworfen wurden.

Ein weiterer verbreiteter Fehler: Der Fokus springt beim Öffnen der Liste tatsächlich auf den ersten Vorschlag, statt im Eingabefeld zu bleiben. Damit lässt sich die Sucheingabe nicht mehr weiter verfeinern, ohne die Liste erneut zu öffnen.

Auch aria-expanded wird oft nur beim Öffnen, aber nicht beim Schließen der Liste zurückgesetzt – der Screenreader meldet dann dauerhaft eine geöffnete Liste, selbst wenn sie längst verschwunden ist.

Kombination mit Kategorien und Filtern

Viele Sucheingaben gruppieren Vorschläge zusätzlich nach Kategorien, etwa in „Produkte", „Kategorien" und „Marken" innerhalb einer einzigen Liste. Für Screenreader-Nutzer muss diese Gruppierung hörbar bleiben, sonst wirkt die Liste wie eine einzige unstrukturierte Aufzählung ohne erkennbare Ordnung, obwohl sie visuell klar in Abschnitte unterteilt ist.

Das Combobox-Pattern erlaubt dafür zusätzliche Gruppenrollen innerhalb der Listbox, kombiniert mit einer eigenen Beschriftung je Gruppe, etwa „Produkte" oder „Marken". So kündigt der Screenreader beim Erreichen einer neuen Gruppe deren Bezeichnung an, bevor er die einzelnen Optionen vorliest, und Nutzer wissen jederzeit, in welchem Abschnitt der Vorschlagsliste sie sich gerade befinden.

Wichtig ist, dass Pfeil-runter weiterhin durchgehend durch alle Optionen über Gruppengrenzen hinweg navigiert, ohne dass Nutzer eine zusätzliche Taste für den Gruppenwechsel lernen müssen. Die Gruppierung dient ausschließlich der Orientierung, nicht einer zusätzlichen Navigationsebene, die den ohnehin schon komplexen Bedienablauf einer Live-Suche unnötig verkomplizieren würde.

Mobile Sucheingaben und virtuelle Tastaturen

Auf Smartphones ersetzt die virtuelle Tastatur einen Teil des sichtbaren Bildschirms, sobald das Suchfeld fokussiert wird. Die Vorschlagsliste muss deshalb so positioniert sein, dass sie oberhalb der eingeblendeten Tastatur sichtbar bleibt, statt darunter zu verschwinden, wo sie weder gesehen noch per Wischgeste erreicht werden kann.

Für Screenreader-Nutzer auf dem Smartphone, etwa mit VoiceOver oder TalkBack, ersetzt eine Wischgeste die Pfeiltasten der Desktop-Tastatur. Damit das funktioniert, muss die Vorschlagsliste dieselben ARIA-Rollen tragen wie am Desktop – fehlt role="option" auf den einzelnen Einträgen, liest die mobile Hilfstechnologie beim Wischen nur unstrukturierten Text vor, statt einzelne, klar abgegrenzte Vorschläge anzukündigen.

Ein häufiger mobiler Fehler: Der Bestätigungs-Button der virtuellen Tastatur schließt gleichzeitig die Vorschlagsliste, bevor ein Vorschlag ausgewählt werden konnte. Hier hilft es, das Schließen der Liste an eine bewusste Nutzeraktion zu binden, statt es automatisch mit jedem Tastatur-Ereignis auszulösen.

Testablauf mit NVDA und Tastatur

Öffne das Suchfeld ausschließlich mit der Tastatur, tippe einen Suchbegriff und prüfe, ob NVDA die Anzahl der Vorschläge ansagt, sobald die Liste erscheint.

Navigiere mit Pfeil-runter durch die Vorschläge und kontrolliere, ob jeder markierte Eintrag einzeln vorgelesen wird und der Fokus dabei im Eingabefeld bleibt.

Bestätige einen Vorschlag mit Enter und prüfe, ob der Wert korrekt ins Feld übernommen wird und die Liste sich zuverlässig schließt – ein kostenloser Scan ergänzt das um die statische Prüfung der ARIA-Attribute im Code.

Hinweis: Dieser Beitrag bietet allgemeine technische Orientierung und ersetzt keine individuelle Rechtsberatung zur Umsetzung des BFSG.

Häufig gestellte Fragen