Custom Controls: Barrierefreie Eigenentwicklungen nach WAI-ARIA
Native HTML-Elemente wie <code><button></code>, <code><select></code> oder <code><input type="range"></code> sind von Haus aus barrierefrei – sie bringen Tastaturunterstützung, Screenreader-Kompatibilität und Zustandsmanagement mit. Doch häufig reichen native Elemente nicht aus: komplexe Datepicker, mehrstufige Dropdown-Menüs oder interaktive Slider erfordern Custom Controls. Das BFSG und EN 301 549 verlangen, dass diese Custom Controls die gleiche Barrierefreiheit bieten wie ihre nativen Pendants. Die WAI-ARIA Authoring Practices 1.2 definieren die Patterns und Tastaturkonventionen für über 20 Widget-Typen.
Native HTML vs. Custom Controls – eine Abwägung
Die erste Regel von ARIA lautet: Verwenden Sie ein natives HTML-Element, wenn eines existiert. Bevor Sie ein Custom Control entwickeln, prüfen Sie: Gibt es ein natives Element, das den Zweck erfüllt? Kann das native Element mit CSS so gestaltet werden, dass es den Design-Anforderungen entspricht? Native Elemente bieten folgende Vorteile: Eingebaute Tastaturunterstützung – ein <select> reagiert auf Pfeiltasten, Enter und Escape. Automatische ARIA-Semantik – ein <input type="checkbox"> kommuniziert Rolle und Zustand automatisch. Formular-Integration – native Elemente arbeiten mit <form>-Validierung, FormData und Auto-Fill. Plattformkonsistenz – native Elemente verhalten sich auf allen Geräten und mit allen Screenreadern gleich. Custom Controls hingegen erfordern manuelle Implementierung aller dieser Aspekte. WCAG 4.1.2 verlangt, dass Name, Rolle, Wert und Zustand jedes Custom Controls programmatisch bestimmbar und steuerbar sind.
Anforderungen an barrierefreie Custom Controls
Ein barrierefreies Custom Control muss folgende Kriterien erfüllen: 1. Korrekte ARIA-Rolle: Das Custom Control muss die passende role haben (z. B. role="combobox" für ein Custom Dropdown). 2. Zugänglicher Name: Per aria-label, aria-labelledby oder sichtbarem <label> (WCAG 4.1.2). 3. Zustandskommunikation: Zustände wie aria-expanded, aria-selected, aria-checked, aria-disabled müssen korrekt gesetzt und bei Interaktion aktualisiert werden. 4. Vollständige Tastaturunterstützung: Gemäß WAI-ARIA Authoring Practices muss jedes Widget-Pattern die spezifizierten Tasten unterstützen (WCAG 2.1.1). 5. Fokusmanagement: Fokus muss visuell sichtbar sein (WCAG 2.4.7), logisch bewegt werden (WCAG 2.4.3) und keine Keyboard Traps erzeugen (WCAG 2.1.2). 6. Wertekommunikation: Der aktuelle Wert muss programmatisch lesbar und änderbar sein. EN 301 549 Abschnitt 11.4.1.2 fasst diese Anforderungen zusammen.
Der Accessibility Tree und Custom Controls
Der Accessibility Tree ist die Repräsentation der Benutzeroberfläche für assistive Technologien. Browser erstellen ihn aus dem DOM und ARIA-Attributen. Für Custom Controls ist das Verständnis des Accessibility Trees entscheidend: Name: Der zugängliche Name wird aus aria-label, aria-labelledby, <label> oder dem Textinhalt berechnet (Name Computation Algorithm). Rolle: Die Rolle wird aus dem nativen Element oder dem role-Attribut bestimmt. Wert: Werte wie aria-valuenow für Slider oder der ausgewählte Text bei Comboboxen. Zustand: Zustände wie aria-expanded, aria-pressed, aria-invalid. Beziehungen: Verknüpfungen über aria-controls, aria-describedby, aria-owns. DevTools-Prüfung: Chrome DevTools zeigen den Accessibility Tree unter Elemente → Barrierefreiheit. Firefox bietet einen dedizierten Accessibility-Inspektor. Prüfen Sie dort, ob Ihr Custom Control korrekt repräsentiert wird.
WAI-ARIA Authoring Practices – das Referenzwerk
Die WAI-ARIA Authoring Practices 1.2 (APG) des W3C sind das maßgebliche Referenzwerk für die Implementierung barrierefreier Custom Controls. Sie definieren für über 20 Widget-Patterns die erwartete Tastaturinteraktion und ARIA-Semantik: Accordion: Überschriften mit Buttons, Pfeiltasten-Navigation, aria-expanded. Combobox: Textfeld mit Popup-Liste, role="combobox", aria-autocomplete. Dialog (Modal): Fokus-Trapping, Escape zum Schließen, role="dialog". Tabs: Tab-Leiste mit Pfeiltasten, role="tablist"/role="tab"/role="tabpanel". Tree View: Baumstruktur mit Pfeiltasten, role="tree"/role="treeitem". Carousel: Automatisch rotierende Inhalte, Pause-Funktion (WCAG 2.2.2). Implementieren Sie Custom Controls immer gemäß den APG-Mustern. Sie repräsentieren den Konsens der Barrierefreiheits-Community und sind die Grundlage für EN 301 549 und BFSG-Prüfungen.
Testing-Strategie für Custom Controls
Custom Controls erfordern umfassende Tests auf mehreren Ebenen: 1. Unit Tests: Prüfen Sie ARIA-Attribute und ihre Aktualisierung bei Zustandsänderungen programmatisch. 2. Keyboard-Tests: Navigieren Sie das Widget ausschließlich mit der Tastatur. Prüfen Sie Tab, Shift+Tab, Pfeiltasten, Enter, Leertaste, Escape und Home/End gemäß den APG-Spezifikationen. 3. Screenreader-Tests: Testen Sie mit mindestens NVDA (Windows) und VoiceOver (macOS). Achten Sie auf korrekte Ankündigung von Name, Rolle und Zustand bei jeder Interaktion. 4. Automatisierte Tests: Tools wie axe-core, Pa11y oder bf-check erkennen fehlende ARIA-Attribute, ungültige Rollen und defekte ID-Referenzen. 5. Regressionstests: Integrieren Sie Barrierefreiheitstests in Ihre CI/CD-Pipeline. 6. Nutzertests: Lassen Sie Ihr Custom Control von Nutzern assistiver Technologien testen. Automatisierte Tools finden nur ca. 30-40% der Barrierefreiheitsprobleme. BFSG-Konformität erfordert nachweisliche Tests aller Interaktionspfade.
Wie steht deine Webseite in diesem Punkt da?
Kostenloser Scan gegen 15 WCAG-2.1-AA-Kriterien – inkl. Custom Controls-Check.
Jetzt Webseite prüfen →