Accessibility Engineering — Lass die Web-Plattform die Arbeit machen

Erstellt am 03.02.2025

Web-Entwickler:innen haben es schwer. Du bekommst ein paar schriftliche Anforderungen und ein visuelles Design. Du beginnst mit der Umsetzung: Du fügst HTML-Elemente hinzu, gestaltest sie mit CSS und implementierst Geschäftslogik mit JavaScript. Du machst dir Gedanken über Usability, Web-Sicherheit, Geschwindigkeit, Datenverwaltung und so weiter.

Du atmest tief durch und sagst zu dir selbst: „Ich schaffe das!“

Plötzlich ruft dein Projektmanager an: „Die Website wird doch barrierefrei sein, oder?“ Du gerätst in Panik und tippst das Wort Barrierefreiheit in die Suchmaschine ein. Du wirst mit Informationen überflutet. Einige davon sind widersprüchlich. Du bittest ChatGPT um Hilfe. Es zeigt dir übertrieben komplexen Code, der mit ARIA-Attributen gespickt ist. Seufz! Du denkst: „Das wird eine Menge Arbeit!“

Ich habe gute Nachrichten für dich: Barrierefreiheit muss nicht anstrengend sein. Sie kann sogar ganz einfach und, ich wage zu behaupten, wunderschön sein. Die Web-Plattform ist dein Verbündeter. Lass sie einfach die Arbeit machen!

Code-Zeilen werden auf eine Frau projiziert, die in die Kamera blickt. Foto: © ThisIsEngineering / pexels.com

Wir werden einen kurzen Blick auf die Grundlagen des Webs werfen und wie man sie effizient einsetzt. Dann gebe ich euch einige konkrete Beispiele für Web-Features mit eingebauter Barrierefreiheit.

Die grundlegenden Werkzeuge des Accessibility Engineering

Die Web-Plattform ist eine Sammlung von Technologien, die vom World Wide Web Consortium und anderen Gremien als offene Standards entwickelt wurden. Zu diesen Technologien gehören HTML, CSS, JavaScript und WAI-ARIA. Diese Bausteine des Webs ermöglichen es uns, Websites zu gestalten, die für alle Menschen zugänglich sind.

Warum tun sich so viele Web-Entwickler:innen dann mit Barrierefreiheit so schwer? Ich sehe dafür zwei Hauptgründe:

Übermäßige Abhängigkeit von externen Bibliotheken.
Unzureichende Erfahrung mit nativen Web-Features.

Die meisten Junior-Developer lernen heutzutage Webentwicklung auf der Grundlage von Frameworks wie Angular, React oder Vue.js. Sie lernen alles über Komponenten und Datenmanagement, machen sich aber kaum mit nativen HTML-Elementen und fortgeschrittenen CSS-Features vertraut.

Ich mache ihnen keinen Vorwurf! Moderne JavaScript-Frameworks und UI-Bibliotheken bieten mächtige Funktionen, die uns bei der Implementierung komplexer Webanwendungen helfen. Aber sie sind eine weitere Ebene der Abstraktion. Sie entfernen uns von den wesentlichen Bausteinen des Webs. Was können wir also tun?

HTML First und die Regel der geringsten Macht

Die Regel der geringsten Macht besagt, dass man die am wenigsten leistungsfähige Sprache wählen sollte, die für einen bestimmten Zweck geeignet ist. Was heißt das für Web-Entwickler:innen? Wenn du etwas mit HTML machen kannst, verwende HTML. Du musst das Styling anpassen? Verwende CSS. Etwas ist nicht allein mit HTML und CSS machbar? Dann verwende JavaScript und WAI-ARIA.

Native HTML-Elemente sind so konzipiert, dass sie in verschiedenen Browsern und mit diversen assistiven Technologien wie Screenreadern funktionieren. Sie sind in der Regel robuster und zuverlässiger als benutzerdefinierte Lösungen. Wenn du das nächste Mal ein neues Feature implementierst, solltest du nach einer Lösung in der folgenden Reihenfolge suchen:

HTML
CSS
JavaScript
WAI-ARIA
Externe Bibliotheken

Als erstes suche ich immer nach einer nativen Lösung in den MDN Web Docs. Wenn ich etwas mit HTML und CSS allein nicht hinbekomme, recherchiere ich die richtige Verwendung von ARIA-Attributen und JavaScript, um eine barrierefreie Lösung zu schaffen. Der ARIA Authoring Practices Guide (APG) bietet alle Infos, die du brauchst.

Warum stehen externe Bibliotheken an letzter Stelle der Liste? Weil sie eine zusätzliche Abhängigkeit für dein Projekt schaffen. Sobald du dich für eine UI-Komponentenbibliothek entschieden hast, bist du daran gebunden. Deshalb achte unbedingt darauf, eine barrierefreie UI-Bibliothek zu verwenden. Schau dir am besten meine „Checkliste für barrierefreie UI-Komponenten-Bibliotheken“ an.

Der aktuelle Zustand des Webs

Die Web-Plattform entwickelt sich ständig weiter. Jeden Tag werden neue HTML-Elemente, CSS-Eigenschaften und Web-APIs spezifiziert und von den Browsern implementiert. Initiativen wie Interop 2024 tragen dazu bei, die Interoperabilität des Webs zu verbessern.

Für Web-Entwickler:innen ist es heute viel einfacher und unkomplizierter, barrierefreie Websites zu erstellen als noch vor 10 Jahren. Ich gebe zu, nicht alles lässt sich allein mit HTML und CSS bewerkstelligen. Im Moment braucht man noch ARIA und JavaScript, um eine Tab-Liste oder benutzerdefinierte Tooltips zu implementieren.

Aber ich möchte mich auf das Positive konzentrieren! Werfen wir einen Blick auf einige native HTML-Features, die es euch sehr einfach machen, robuste, barrierefreie Websites zu erstellen.

Beispiele für native HTML-Features

Das `button`-Element: Ein mächtiger Allrounder

Vielleicht ist das button-Element schon älter als du! Es wurde erstmals im Dezember 1997 in der HTML 4.0-Spezifikation definiert. Das heißt, Schaltflächen gibt es schon eine ganze Weile. Dennoch unterschätzen viele Entwickler:innen dieses mächtige und vielseitige HTML-Element. Manche halten es sogar für eine gute Idee, stattdessen ein div-Element zu verwenden. Horror! 😱

Vielleicht denkst du jetzt: „Na gut, Romeo! Warum bist du so verliebt in das Button-Element?“ Lass mich mit der kurzen Beschreibung von MDN antworten:

The <button> HTML element is an interactive element activated by a user with a mouse, keyboard, finger, voice command, or other assistive technology. Once activated, it then performs an action, such as submitting a form or opening a dialog.

Das button-Element wurde so konzipiert, dass es für alle Nutzer:innen gut funktioniert. Du kannst es mit der Maus anklicken. Du kannst eine Schaltfläche mit der TAB-Taste fokussieren und sie mit der Eingabe- oder Leertaste aktivieren. Wenn du mit einem Screenreader zu einem Button navigierst, wird er dir sagen, dass es sich um eine Schaltfläche handelt, die aktiviert werden kann.

Browser wenden auch Standard-Styles auf HTML-Schaltflächen an. Einige Web-Entwickler:innen empfinden das als lästig, weil sie das Styling mit CSS überschreiben müssen. Da verwenden sie lieber das div-Element und klatschen einen click-Event-Handler darauf, weil sie glauben, das sei genug. Das ist es aber nicht!

Es gibt große Unterschiede zwischen button und div-Elementen! Eine Schaltfläche löst den click-Event-Handler für alle Arten der Interaktion aus: Maus, Tastatur, Screenreader usw. Das div-Element hingegen wird nur bei Maus- oder Touch-Interaktion ausgelöst. Um ein div-Element in eine barrierefreie Schaltfläche zu verwandeln, ist folgendes notwendig:

Einen tabindex hinzufügen, um das Element fokussierbar zu machen.
Einen sichtbaren Fokusindikator anzeigen, wenn die Schaltfläche den Fokus erhält.
Tastatur-Event-Handler für die Enter- und Leertaste definieren.
Ein role-Attribut hinzufügen, um Screenreader-Nutzer:innen mitzuteilen, dass es sich um eine Schaltfläche handelt.

Wow, das sind eine Menge Arbeit und viele unnötige Code-Zeilen! Wenn du stattdessen eine native Schaltfläche verwendest, ist dein Code einfacher zu lesen und zu pflegen. Immer noch nicht überzeugt? Dann lies meinen Artikel „3 Gründe, warum auch Web-Entwickler:innen von Barrierefreiheit profitieren“.

Das ist schon eine Menge Text über Buttons. Aber es gibt noch eine Sache, die ich erwähnen möchte: Native Schaltflächen bekommen laufend mehr Superkräfte!

Das letzte Upgrade verdanken wir der neuen Popover-API. Du kannst das popovertarget-Attribut verwenden, um das button-Element in einen Popover-Steuerungs-Button zu verwandeln. Hier eine Demo für Menü-Buttons (funktioniert derzeit nur in Chromium-Browsern):

Es gibt so viele Anwendungsfälle für Buttons mit angehängten Popovers: Menüs, Tooltips, Datumsauswahlen usw. Wenn das Thema für dich neu ist, kannst du einen Blick auf die folgenden Artikel von mir werfen:

Aber das ist noch nicht alles! Das nächste Button-Upgrade beschert uns die (derzeit noch experimentelle) Invoker Commands API. Diese API bietet die Möglichkeit, Schaltflächen deklarativ Aktionen zuzuweisen, wie das Öffnen oder Schließen eines modalen Dialogs. Genial! 🥰

Na schau an, was für ein Zufall! Dialoge sind das nächste native HTML-Feature auf meiner Liste.

Das `dialog`-Element: Immer oben auf

Dialoge sind ein wesentlicher Bestandteil moderner Web-Oberflächen: Von einfachen Aufforderungen, eine Aktion zu bestätigen, bis hin zu Fenstern mit komplexen Inhalten. Mit dem nativen dialog-Element ist es ganz einfach, einen barrierefreien Modal-Dialog über den anderen Seiteninhalten zu öffnen.

Das Dialog-Element ist standardmäßig barrierefrei. Wenn du die Methode showModal() verwendest, um einen modalen Dialog zu öffnen, geschieht Folgendes:

Der Browser setzt den Fokus automatisch auf das erste interaktive Element innerhalb des Dialogs.
Ein Screenreader weist darauf hin, dass der neue Inhalt Teil eines Dialogs ist.
Solange der Modal-Dialog geöffnet ist, können Nutzer:innen mit dem restlichen Inhalt der Seite nicht interagieren. Das bedeutet, dass Tastaturnutzer:innen den Dialog nicht mit der TAB-Taste verlassen können. Auch der virtuelle Cursor des Screenreaders kann sich nur innerhalb des Dialogs bewegen.
Der Modal-Dialog kann standardmäßig mit der ESC-Taste geschlossen werden.
Nach dem Schließen wird der Fokus automatisch zurück auf das Bedienelement gesetzt, mit dem der Dialog geöffnet wurde. Davon profitieren Tastatur- und Screenreader-Nutzer:innen, die sofort an der Stelle weitermachen können, wo sie aufgehört hatten.

Natürlich musst du nicht unbedingt das native dialog-Element verwenden. Du kannst auch ein benutzerdefiniertes, barrierefreies Dialogfeld mit ARIA und JavaScript implementieren. Aber warum solltest du das tun? Komm schon! Sei clever und lass die Web-Plattform die Arbeit machen. 😉

Wenn du mit dem nativen dialog-Element nicht vertraut bist und mehr darüber erfahren möchtest, lies meinen Artikel „Warum du das native Dialog-Element nutzen solltest“.

Formularfelder: Gute Zeiten, schlechte Zeiten

Allzu oft verwenden Web-Entwickler:innen benutzerdefinierte Formularfelder, um Designanforderungen zu erfüllen – und vernachlässigen dabei die Barrierefreiheit. Das können wir besser!

Mit modernen Browsern kannst du auf die meisten nativen Formular-Elemente dein eigenes Styling anwenden. Auf diese Weise können wir barrierefreie Webformulare erstellen, die auf allen Plattformen ein einheitliches Aussehen haben.

Native Formular-Elemente wie input oder select sind standardmäßig barrierefrei. Sie erhalten den Tastaturfokus und können mit der Eingabetaste oder der Leertaste aktiviert werden, z.B. um eine Checkbox auszuwählen. Sie kommunizieren ihre Rolle und ihren aktuellen Status an Screenreader.

Die folgende Demo zeigt ein barrierefreies Webformular mit eigenem Styling für die native Auswahlliste und die Radio-Buttons:

Leider lassen sich nicht alle nativen Formular-Elemente leicht mit benutzerdefinierten Styles anpassen. Mozilla bietet einen tollen Artikel über die Gestaltung von Webformularen, den ich sehr empfehlen kann. Darin werden native Formular-Elemente in drei Gruppen eingeteilt: „Die Guten“, „Die Schlechten“ und „Die Hässlichen“.

Meiner Meinung nach sind die nativen Elemente für Eingabefelder, Radio-Buttons, Checkboxen und einfache Auswahllisten sehr gut gestaltbar. Es gibt keinen Grund, stattdessen benutzerdefinierte Elemente zu verwenden. Es sei denn, du hast eine masochistische Veranlagung. Mehr Infos findest du in meinem Artikel „Barrierefreie Web-Formulare mit individuellem Design gestalten“.

Und was ist mit dem Rest? Einige native Formular-Elemente verfügen über interne Elemente, die nicht allein mit CSS gestaltet werden können. Dazu gehören der Farbwähler, der Datumswähler, die Datei-Auswahl und das select-Element. In diesen Fällen verstehe ich den Bedarf an benutzerdefinierten Komponenten. Stellt nur sicher, dass sie barrierefrei sind.

Zum Glück für uns wird das select-Element bald ein wichtiges Upgrade erhalten. Eine anpassbare Version des Elements befindet sich offiziell in Phase 2 der WHATWG, mit starkem Cross-Browser-Interesse und einem in Chrome Canary verfügbaren Prototypen. Weitere Informationen findest du in diesem Chrome-Blogbeitrag. 🤩

Disclosure- und Akkordeon-Widgets mit nativem HTML

Das native HTML-Element details erzeugt ein Disclosure-Widget, dessen Inhalt nur dann sichtbar ist, wenn das Widget geöffnet wurde. Der Inhalt des verschachtelten summary-Elements liefert das Label für das Disclosure-Widget. Die perfekten HTML-Elemente für eine FAQ-Seite oder einen ausklappbaren Info-Abschnitt in einem Artikel.

<details>
    <summary>What is HTML?</summary>
    HTML is the standard markup language for web pages, defined by the W3C and WHATWG.
</details>

Früher war es nicht möglich, den display-Typ des details-Elements zu ändern. Diese Einschränkung wurde in Chromium-Browsern bereits gelockert, so dass du Grid- oder Flex-Layouts verwenden kannst. Der Artikel „More options for styling <details>“ enthält eine wirklich coole Demo für ein exklusives Akkordeon.

Fazit

Also gut. Dieser Artikel ist viel länger geworden, als ich beabsichtigt hatte. 😂

Ich hoffe, er hilft dir auf deinem Weg zum Accessibility Engineer. Die wichtigste Botschaft: Native HTML-Elemente sind einfach klasse und (meistens) von Haus aus barrierefrei. Nutze sie!