AAA – Accessibility
in Angular dank AI

Die Prämisse

Im Folgenden möchte ich von einem Kundenprojekt berichten, bei dem wir eine Single Page Application mit Angular entwickeln. Seit dem Projektstart vor 15 Monaten setzen wir dabei gezielt Künstliche Intelligenz (KI) ein, um unsere Entwickler bei ihrer Arbeit zu unterstützen. Alle wiederverwendbaren User Interface (UI) Komponenten werden in einem zentralen Verzeichnis gespeichert und von dort aus in die einzelnen Ansichten eingebunden. Um den Migrationsaufwand gering zu halten und Abhängigkeiten zu externen Projekten zu vermeiden, entwickeln wir diese Komponenten vollständig in Angular. Dies bedeutet, dass wir die komplette Kontrolle über das Design und Verhalten jeder einzelnen Komponente haben – aber auch über ihre Barrierefreiheit (Accessibility).

Die Entwicklererfahrung

Die Entwicklererfahrung mit KI in puncto Accessibility hängt stark davon ab, um welche Art von UI-Komponente es sich handelt. Wir haben sie in drei Kategorien unterteilt:

• ‚The Good‘ sind einfache, quasi-atomare HTML-Elemente, die wir von jeder Webseite kennen: Elemente wie Checkboxen, Dropdowns und Inputfelder. Solche Komponenten sind in unserem Projekt minimal gestylt und an deren Verhalten wurde sonst nichts Besonderes verändert. Die Barrierefreiheit solcher Komponenten ist gut dokumentiert und in Web-Accessibility-Standards (wie Web Content Accessibility Guidelines, kurz WCAG) festgelegt.
• ‚The Bad‘ sind komplexe Komponenten, deren Verhalten durch einen intensiveren JavaScript-Einsatz geprägt wird. Beispiele dafür sind eine Zeitraum-Auswahl-Komponente (Date Range Picker) und eine Dropdown-Komponente mit Such- und Anlegefunktion (Combobox). Beide Komponenten sind eng auf projektspezifische Anwendungsfälle zugeschnitten. Hier die Accessibility sicherzustellen, ist oft eine anspruchsvolle Aufgabe.
• ‚The Ugly‘ sind abgewandelte ‚Good‘-Komponenten, die eine gewisse Zweckentfremdung aufweisen: Komponenten, die ‚unter der Haube‘ einfache HTML-Eingabeelemente sind, bekommen aber durch CSS-Veränderungen ein nicht wiedererkennbares Aussehen. Solche Komponenten sind bei uns Theme-Switcher und das Expandable-Element.

Kurzer Exkurs: Was sind eigentlich ARIA-Attribute?

Bevor wir uns die Beispiele genauer ansehen, ein kurzer Blick auf ARIA: ARIA steht für „Accessible Rich Internet Applications“. Es handelt sich um eine Reihe spezieller Attribute, die man zu HTML-Elementen hinzufügen kann, um die Barrierefreiheit zu verbessern, insbesondere bei dynamischen Webanwendungen. Wenn die native Semantik von HTML nicht ausreicht, um die Rolle, den Zustand oder die Eigenschaften einer komplexen UI-Komponente zu beschreiben, hilft ARIA, diese Lücke zu schließen. Es versorgt assistierende Technologien, wie Screenreader, mit zusätzlichen Informationen, damit Nutzer verstehen können, was ein Element darstellt und wie sie damit interagieren können. Im Folgenden werden wir auf einige dieser Attribute stoßen:

• aria-label: Gibt einem Element einen zugänglichen Namen (eine Beschriftung), wenn kein sichtbares <label>-Element vorhanden oder ausreichend ist (z.B. bei einem Button, der nur ein Icon zeigt). Dieser Name wird von Screenreadern anstelle des normalen Elementinhalts vorgelesen.
• aria-describedby: Verweist auf die id eines anderen Elements, das eine zusätzliche Beschreibung oder einen Hinweis für das aktuelle Element enthält. Screenreader lesen diese Beschreibung dann im Kontext vor.
• aria-checked: Zeigt den Zustand eines Elements an, das markiert werden kann (wie eine Checkbox oder ein Radiobutton), z.B. „true“, „false“ oder „mixed“ (für teilweise markiert). Bei nativen HTML-Checkboxen ist es oft redundant.
• aria-expanded: Signalisiert, ob ein Element, das einen anderen Bereich ein- oder ausklappen kann (wie bei einem Akkordeon oder Menü), aktuell ausgeklappt („true“) oder eingeklappt („false“) ist.
• aria-controls: Gibt die id des Elements (oder der Elemente) an, dessen Inhalt oder Sichtbarkeit vom aktuellen Element gesteuert wird. So weiß ein Screenreader, welcher Bereich von einem Button geöffnet wird.
• aria-hidden: Versteckt ein Element und all seine Unterelemente vor assistierenden Technologien ("true"). Es bleibt visuell sichtbar (es sei denn, es wird auch durch CSS versteckt), wird aber von Screenreadern ignoriert. Nützlich für rein dekorative Elemente oder Elemente, die für Screenreader-Nutzer irrelevant sind.

Mit diesem Wissen können wir nun besser verstehen, warum und wie die KI versucht hat, diese Attribute in unseren Komponenten einzusetzen.

‚The Good‘ – Einfache Komponenten im KI-Check

Beginnen wir mit den Komponenten, bei denen die KI eine positive Rolle spielen konnte.

<select> (Dropdown)

• Was ist es: Ein select (auch Dropdown genannt) ist ein Auswahl-Element, das nach einem Mausklick oder Tastaturinteraktion mehrere Optionen anbietet.
• Was ist zu tun: Um ein Dropdown mit der Tastatur navigierbar zu machen, ist aus Entwicklersicht nichts Besonderes notwendig. Das erledigt der Browser für uns. Für Assistenztechnologien wie Screenreader ist es entscheidend, dass das select-Element korrekt mit seinem Beschreibungstext (Label) verknüpft ist. Dies geschieht durch die Nutzung der id des select-Elements im for-Attribut des label-Elements.
• Was macht die KI damit: Die KI konnte genau das hinzufügen, was für die grundlegende Barrierefreiheit notwendig ist:

<label + for="nato"> Select a Nato phonetic Letter </label> <select + id="nato"> <option value="None" selected disabled>Select a letter</option> <option value="A">Alpha</option> <option value="B">Bravo</option> <option value="C">Charlie</option></select>

Eine der KIs tendierte jedoch dazu, mehr als nötig zu implementieren. Es wurden zusätzliche aria-label-Attribute hinzugefügt, was keinen zusätzlichen Accessibility-Mehrwert bringt, wenn bereits ein korrekt verknüpftes label vorhanden ist (es würde das label sogar überschreiben).

<input> (Eingabefeld)

• Was ist es: Hier handelt es sich um ein einfaches Eingabefeld für Text.
• Was ist zu tun: Ein Eingabeelement soll analog zum select eine Verknüpfung zwischen label und input-Tag mittels id und for-Attribut aufweisen. Des Weiteren ist oft ein zusätzlicher Hinweis (Hint) mit Eingabebeispielen oder Formatvorgaben hilfreich. Dieser Hinweis sollte semantisch über aria-describedby mit dem Eingabefeld verknüpft sein.
• Was macht die KI damit: Die KI schlug korrekterweise das Hinzufügen eines Hints (div mit id) vor und verknüpfte sowohl das label (via for/id) als auch den Hint (via aria-describedby) mit dem Eingabefeld.

<label + for="best-nato-letter"> The best NATO letter is: </label> <input type="text" + id="best-nato-letter" + aria-describedby="best-nato-letter-hint"/> +<div class="hint" + id="best-nato-letter-hint"> + Example: Alpha, Bravo, Charlie+</div>

<input type=checkbox> (Checkbox)

• Was ist es: Ein Kästchen mit einem Label. Beim Mausklick oder Tastaturinteraktion wird ein Häkchen hinzugefügt oder entfernt.
• Was ist zu tun: Ähnlich wie bei input und select ist die Verknüpfung des label mit dem input[type=checkbox] über for und id entscheidend.
• Was machte die KI damit: Die KI erkannte korrekt, dass das for-Attribut nötig ist:

<input type="checkbox" + id="alphaCheckbox"/> <label + for="alphaCheckbox"> Alpha </label>

Die meisten KIs wollten jedoch auch ein aria-checked-Attribut hinzufügen. Dieses Attribut ist primär für benutzerdefinierte Elemente mit role="checkbox" gedacht und bei einem nativen <input type="checkbox"> redundant, da der Browser den Zustand selbst verwaltet und an die Accessibility-API meldet. Es hat hier also keinen Mehrwert.

Ausblick auf Teil 2

Bisher haben wir gesehen, dass KI bei den grundlegenden, „guten“ HTML-Komponenten durchaus eine wertvolle Unterstützung für mehr Barrierefreiheit leisten kann. Sie erkennt fehlende Verknüpfungen und schlägt sinnvolle ARIA-Attribute für einfache Anwendungsfälle vor. Doch wie sieht es aus, wenn die Komplexität steigt?

Im zweiten Teil dieser Artikelreihe werden wir uns den anspruchsvolleren Kategorien – ‚The Bad‘ und ‚The Ugly‘ – widmen. Wir untersuchen, wo die KI an ihre Grenzen stößt und welche Strategien wir als Entwickler benötigen, um auch komplexe und stark gestylte Komponenten barrierefrei zu gestalten. Bleibt dran!