Barrierefreie Datepicker und Comboboxen implementieren

1. Warum Datepicker und Comboboxen zu den schwierigsten UI-Mustern gehören

Datepicker und Comboboxen zählen zu den anspruchsvollsten Interface-Mustern im Web, weil sie mehrere Eigenschaften gleichzeitig kombinieren: eine visuelle Overlay-Struktur, dynamisch nachgeladenen Inhalt und eine Bedienlogik, die stark von Tastatur- und Mausinteraktion abhängt. Ein einfaches Textfeld hat im Grunde einen einzigen relevanten Zustand, fokussiert oder nicht. Eine Combobox dagegen wechselt ständig zwischen geschlossenem Eingabefeld, geöffneter Vorschlagsliste und aktiv markierter Option, und jeder dieser Zustände muss für assistive Technologien exakt nachvollziehbar sein.

In der Praxis werden solche Widgets häufig als reine div-Konstrukte gebaut, die visuell überzeugend aussehen, aber ohne semantische Rollen auskommen. Screenreader-Nutzer erhalten dann keinerlei Information darüber, dass überhaupt eine Liste existiert, wie viele Einträge sie enthält oder welcher Eintrag aktuell hervorgehoben ist. Auswertungen von Axe-Core-Scans und dem WebAIM Million Report zeigen regelmäßig, dass fehlende oder falsch gesetzte Rollen bei selbstgebauten Widgets zu den häufigsten Barrierefreiheitsfehlern im Web gehören, noch vor einfacheren Problemen wie fehlenden Alternativtexten für Bilder.

2. Das WAI-ARIA Combobox-Pattern im Detail

Die WAI-ARIA Authoring Practices definieren mit dem Combobox-Pattern eine feste Rollenstruktur, die genau festlegt, welches Element welche Aufgabe übernimmt. Das Eingabefeld selbst trägt role="combobox", ist über aria-expanded als geöffnet oder geschlossen markiert und referenziert über aria-controls die ID der zugehörigen Liste. Zusätzlich zeigt aria-haspopup="listbox" an, welche Art von Popup beim Öffnen erscheint. Die Liste selbst trägt role="listbox", jede einzelne Option role="option" mit aria-selected, das den aktuellen Auswahlstatus widerspiegelt.

Wichtig ist, dass dieses Muster nicht nur einmalig beim Rendern gesetzt wird, sondern bei jeder Zustandsänderung aktiv aktualisiert werden muss. Wird die Liste gefiltert, ändert sich die Anzahl der sichtbaren Optionen, und aria-activedescendant muss stets auf eine tatsächlich existierende, sichtbare Option zeigen. Ein verbreiteter Implementierungsfehler ist, das Pattern nur visuell für sehende Nutzer zu testen und dabei zu übersehen, dass ein Screenreader beim Öffnen der Liste keine Ankündigung erhält, weil aria-expanded nie tatsächlich auf true gesetzt wurde.

<!-- Accessible combobox: input + listbox per WAI-ARIA Authoring Practices -->
<div class="relative">
  <label id="city-label" for="city-input">Zielstadt</label>
  <input
    id="city-input"
    type="text"
    role="combobox"
    aria-expanded="false"
    aria-controls="city-listbox"
    aria-autocomplete="list"
    aria-activedescendant=""
    aria-labelledby="city-label"
    autocomplete="off"
  >
  <ul id="city-listbox" role="listbox" aria-label="Stadtvorschläge" class="hidden">
    <li id="opt-0" role="option" aria-selected="false">Berlin</li>
    <li id="opt-1" role="option" aria-selected="false">Bremen</li>
    <li id="opt-2" role="option" aria-selected="false">Bonn</li>
  </ul>
</div>

<!-- Update both attributes together when the list opens, never one alone -->
<!-- input.setAttribute('aria-expanded', 'true') -->
<!-- input.setAttribute('aria-activedescendant', 'opt-0') -->

3. ARIA-Attribute korrekt synchronisieren

aria-activedescendant ist das zentrale, aber am häufigsten missverstandene Attribut des Combobox-Patterns. Anders als bei klassischer Tastaturnavigation bleibt der DOM-Fokus während der gesamten Interaktion auf dem Eingabefeld, niemals auf den Listenoptionen selbst. Stattdessen zeigt aria-activedescendant auf die ID der aktuell hervorgehobenen Option, und der Screenreader liest deren Inhalt vor, obwohl der Browser-Fokus formal unverändert bleibt. Dieses als virtueller Fokus bezeichnete Verhalten verhindert, dass der Tastaturfokus bei jeder Pfeiltaste zwischen Feld und Liste hin und her springt.

aria-controls verknüpft das Eingabefeld eindeutig mit seiner Liste, auch wenn beide Elemente nicht im gleichen DOM-Teilbaum liegen, etwa weil die Liste per Portal an das Ende des body gerendert wird. aria-expanded muss synchron mit dem tatsächlichen Sichtbarkeitsstatus laufen. Wird die Liste per CSS mit display: none oder dem hidden-Attribut ausgeblendet, ohne aria-expanded auf false zu setzen, meldet der Screenreader weiterhin eine geöffnete Liste, obwohl visuell nichts mehr zu sehen ist. Diese Diskrepanz zwischen visuellem und semantischem Zustand ist eine der häufigsten Ursachen für verwirrende Screenreader-Erfahrungen bei selbstgebauten Widgets.

4. Tastatursteuerung: Pfeiltasten, Escape, Enter und Tab

Eine vollständige Tastatursteuerung ist bei Datepickern und Comboboxen kein optionales Extra, sondern die Grundvoraussetzung für Bedienbarkeit ohne Maus. Pfeil-runter öffnet eine geschlossene Liste und bewegt die Markierung zur ersten beziehungsweise nächsten Option, Pfeil-hoch bewegt sie rückwärts. Pos1 und Ende springen direkt zur ersten oder letzten Option, was besonders bei langen Vorschlagslisten spürbar Zeit spart. Escape schließt die Liste, ohne eine Auswahl zu übernehmen, und stellt bei Bedarf den vorherigen Eingabewert wieder her. Enter übernimmt die aktuell markierte Option und schließt die Liste.

Tab folgt einer eigenen, oft falsch implementierten Regel: Die Taste bewegt den Fokus grundsätzlich zum nächsten fokussierbaren Element und darf die Liste nicht offen lassen, ohne dabei automatisch eine Auswahl zu erzwingen. Viele selbstgebaute Comboboxen fangen Tab fälschlicherweise ab und verhindern so das Verlassen des Feldes, was für Tastaturnutzer eine echte Fokusfalle erzeugt. Wird die Tastaturlogik konsequent nach dem WAI-ARIA-Pattern implementiert, verhält sich die Combobox unabhängig vom verwendeten Screenreader vorhersehbar identisch.

// Alpine.js combobox keyboard handling per WAI-ARIA combobox pattern
function comboboxField() {
  return {
    open: false,
    activeIndex: -1,
    options: ['Berlin', 'Bremen', 'Bonn', 'Bochum', 'Bayreuth'],

    onKeydown(event) {
      switch (event.key) {
        case 'ArrowDown':
          event.preventDefault();
          this.open = true;
          this.activeIndex = Math.min(this.activeIndex + 1, this.options.length - 1);
          break;
        case 'ArrowUp':
          event.preventDefault();
          this.activeIndex = Math.max(this.activeIndex - 1, 0);
          break;
        case 'Home':
          event.preventDefault();
          this.activeIndex = 0;
          break;
        case 'End':
          event.preventDefault();
          this.activeIndex = this.options.length - 1;
          break;
        case 'Escape':
          this.open = false;
          this.activeIndex = -1;
          break;
        case 'Enter':
          if (this.open && this.activeIndex > -1) {
            event.preventDefault();
            this.selectOption(this.activeIndex);
          }
          break;
        case 'Tab':
          // Never trap Tab: let focus move on, close without forcing a selection
          this.open = false;
          break;
      }
    },

    selectOption(index) {
      this.$refs.input.value = this.options[index];
      this.open = false;
      this.activeIndex = -1;
    },

    get activeId() {
      return this.activeIndex > -1 ? `opt-${this.activeIndex}` : '';
    }
  };
}

5. Barrierefreie Kalender-Widgets: role=grid und Datumsnavigation

Ein Kalender-Widget stellt zusätzliche Anforderungen an die Semantik, weil es de facto eine zweidimensionale Tabelle aus Wochentagen und Datumszellen abbildet. Die WAI-ARIA Authoring Practices empfehlen dafür role="grid" für den Kalenderkörper, role="row" für jede Woche und role="gridcell" für jeden Tag, jeweils mit einem sprechenden aria-label wie „Montag, 12. Juli 2026" statt der reinen Zahl. Der gesamte Datepicker wird meist in einem role="dialog" mit aria-modal="true" präsentiert, wenn er als Overlay über dem restlichen Inhalt erscheint, inklusive Fokus-Falle innerhalb des Dialogs und Rückgabe des Fokus an das auslösende Element beim Schließen.

Für die Navigation innerhalb des Kalenders gilt roving tabindex: Nur die aktuell fokussierte Zelle trägt tabindex="0", alle anderen tabindex="-1", sodass ein einziger Tab-Druck aus dem gesamten Gitter herausführt. Pfeiltasten bewegen die Auswahl tageweise, Bild-auf und Bild-ab wechseln den Monat, Umschalt plus Bild-auf beziehungsweise Bild-ab wechseln das Jahr. Der ausgewählte Tag erhält aria-selected="true", der heutige Tag zusätzlich eine eigene visuelle und semantische Kennzeichnung über aria-current="date".

<!-- Accessible calendar grid inside a modal dialog -->
<div role="dialog" aria-modal="true" aria-label="Datum auswählen">
  <div class="flex items-center justify-between mb-2">
    <button type="button" aria-label="Vorheriger Monat">‹</button>
    <span id="cal-caption">Juli 2026</span>
    <button type="button" aria-label="Nächster Monat">›</button>
  </div>
  <table role="grid" aria-labelledby="cal-caption">
    <thead>
      <tr role="row">
        <th role="columnheader" abbr="Montag">Mo</th>
        <th role="columnheader" abbr="Dienstag">Di</th>
        <th role="columnheader" abbr="Mittwoch">Mi</th>
      </tr>
    </thead>
    <tbody>
      <tr role="row">
        <!-- Roving tabindex: only the focused cell is tabbable -->
        <td role="gridcell" tabindex="-1" aria-label="Montag, 6. Juli 2026">6</td>
        <td role="gridcell" tabindex="0" aria-selected="true" aria-current="date"
            aria-label="Dienstag, 7. Juli 2026, heute, ausgewählt">7</td>
        <td role="gridcell" tabindex="-1" aria-label="Mittwoch, 8. Juli 2026">8</td>
      </tr>
    </tbody>
  </table>
</div>

6. Text-Input-Fallback ohne Abhängigkeit vom visuellen Widget

So sorgfältig ein Kalender-Widget auch implementiert ist, es bleibt für einen Teil der Nutzer die schlechtere Wahl. Menschen mit motorischen Einschränkungen, Nutzer von Schalt- oder Sprachsteuerungen und viele Screenreader-Nutzer navigieren schneller und zuverlässiger über ein einfaches Textfeld als über ein zweidimensionales Gitter mit mehreren Navigationsebenen. Die robusteste Lösung ist deshalb kein Ersatz, sondern eine Ergänzung: ein natives type="text"- oder type="date"-Feld, das komplett unabhängig vom visuellen Kalender funktioniert, mit einem klaren Formathinweis wie TT.MM.JJJJ direkt neben dem Label.

Der Kalender-Button öffnet das visuelle Widget optional als Komfortfunktion, ändert aber niemals den grundlegenden Bedienweg über die Tastatur. Serverseitige Validierung interpretiert unterschiedliche Eingabeformate tolerant und gibt bei Fehlern eine konkrete, mit dem Feld verknüpfte Fehlermeldung über aria-describedby zurück, statt nur eine rote Umrandung anzuzeigen. Diese Trennung von visueller Komfortfunktion und funktionalem Kernpfad ist das wichtigste Prinzip progressiver Barrierefreiheit: Fällt JavaScript aus oder wird das Kalender-Widget von einer assistiven Technologie nicht unterstützt, bleibt das Formular vollständig nutzbar.

7. Live-Regions und Ankündigungen für Screenreader

Live-Regions machen dynamische Änderungen hörbar, die rein visuell wären, etwa wenn beim Blättern im Kalender ein neuer Monat angezeigt wird oder eine gefilterte Combobox-Liste plötzlich nur noch drei statt zwanzig Optionen enthält. Ein Bereich mit aria-live="polite" liest seinen aktualisierten Inhalt vor, sobald der Screenreader gerade nichts anderes vorliest, ohne die aktuelle Sprachausgabe zu unterbrechen. aria-live="assertive" unterbricht sofort und sollte ausschließlich für wirklich kritische Meldungen reserviert bleiben, etwa Validierungsfehler nach dem Absenden eines Formulars.

Die Live-Region selbst sollte dauerhaft im DOM vorhanden sein, nicht erst bei Bedarf eingefügt werden, weil manche Screenreader neu eingefügte Live-Regions ignorieren. Visuell wird sie meist mit einer sr-only-Klasse ausgeblendet, bleibt für assistive Technologien aber vollständig zugänglich. aria-atomic="true" sorgt dafür, dass immer der komplette neue Inhalt vorgelesen wird, statt nur die geänderten Teilzeichenketten, was bei kurzen Statustexten wie „Mai 2026" oder „3 Ergebnisse gefunden" die verständlichste Ausgabe erzeugt.

/* Visually hidden but still announced by screen readers */
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

/* Live region for month/year change announcements, stays in the DOM */
.calendar-status {
  /* combined with .sr-only in markup, never re-created on update */
}

/* Focus ring on the active grid cell, not just on hover */
[role="gridcell"]:focus-visible,
[role="option"][aria-selected="true"] {
  outline: 2px solid #18181b;
  outline-offset: 2px;
}

/* Never remove focus outlines without a visible replacement */
input[role="combobox"]:focus-visible {
  outline: 2px solid #3f3f46;
  outline-offset: 1px;
}

8. Testen mit Tastatur und Screenreader gemeinsam

Automatisierte Tools wie Axe-Core oder Lighthouse finden zuverlässig fehlende Rollen, fehlende Labels oder Kontrastprobleme, aber sie können nicht beurteilen, ob eine Pfeiltaste tatsächlich zur richtigen Option springt oder ob eine Ankündigung im richtigen Moment erfolgt. Genau diese dynamischen Aspekte sind bei Datepickern und Comboboxen der Kern des Problems. Deshalb ist manuelles Testen mit Tastatur und Screenreader gleichzeitig unverzichtbar, nicht nur eine optionale Ergänzung zu automatisierten Scans.

In der Praxis hat sich eine feste Kombination aus drei Testpaaren bewährt: NVDA mit Firefox unter Windows, JAWS mit Chrome unter Windows und VoiceOver mit Safari unter macOS oder iOS. Die Maus bleibt während des gesamten Tests deaktiviert oder wird bewusst nicht benutzt. Geprüft wird, ob jede Tastenkombination aus dem Pattern funktioniert, ob jede Zustandsänderung angesagt wird und ob der Fokus nach dem Schließen des Widgets an einer sinnvollen Stelle landet. Automatisierte Regressionstests mit Playwright und axe-core ergänzen diese manuellen Durchläufe, indem sie zumindest die statischen ARIA-Attribute bei jedem Build erneut prüfen.

{
  "testEngine": "axe-core",
  "url": "https://shop.example.com/checkout/delivery-date",
  "violations": [
    {
      "id": "aria-required-attr",
      "impact": "critical",
      "description": "Required ARIA attribute is missing on combobox",
      "nodes": [
        {
          "target": ["#city-input"],
          "failureSummary": "Fix: element has role=\"combobox\" but is missing aria-expanded"
        }
      ]
    }
  ],
  "manualChecks": [
    "Arrow keys move aria-activedescendant through visible options",
    "Escape closes the listbox without changing the input value",
    "Month change is announced once via aria-live, not twice",
    "Tab never gets trapped inside the calendar dialog"
  ]
}

9. Datepicker- und Combobox-Patterns im Vergleich

Die folgende Übersicht stellt verbreitete, aber fehlerhafte Implementierungen den nach WAI-ARIA-Pattern korrekten Lösungen gegenüber. Die Unterschiede wirken auf den ersten Blick klein, entscheiden in der Praxis aber darüber, ob ein Datepicker oder eine Combobox mit Screenreader überhaupt bedienbar ist.

In der Summe zeigen die Beispiele ein wiederkehrendes Muster: Fast jeder Fehler entsteht dadurch, dass ein Zustand nur visuell, aber nicht semantisch abgebildet wird. Wer ARIA-Attribute konsequent synchron zum tatsächlichen UI-Zustand hält und zusätzlich einen textbasierten Fallback anbietet, deckt die überwiegende Mehrheit der Problemfälle bereits ab.

10. Zusammenfassung

Barrierefreie Datepicker und Comboboxen lösen wiederkehrende Kernprobleme: Der Zustand der Liste muss über role="combobox", aria-expanded und aria-controls jederzeit korrekt kommuniziert werden. aria-activedescendant hält den virtuellen Fokus synchron, ohne den DOM-Fokus zwischen Feld und Optionen springen zu lassen. Kalender-Widgets benötigen eine Grid-Semantik mit sprechenden Datumslabels, roving tabindex und Pfeiltasten-Navigation, ergänzt um Bild-auf und Bild-ab für Monats- und Jahreswechsel.

Der wichtigste strukturelle Baustein ist der Text-Input-Fallback, der unabhängig vom visuellen Widget funktioniert und damit die Grundfunktion des Formulars absichert, selbst wenn JavaScript fehlschlägt oder eine assistive Technologie das Kalender-Widget nicht unterstützt. Live-Regions mit aria-live="polite" machen dynamische Änderungen hörbar. Getestet werden muss zwingend mit echter Tastatur- und Screenreader-Kombination, weil automatisierte Scanner die dynamischen Kernaspekte dieser Muster grundsätzlich nicht erfassen können.

11. FAQ: Barrierefreie Datepicker und Comboboxen