AAA – Accessibility
in Angular dank AI

Willkommen zum zweiten Teil unserer Untersuchung, wie Künstliche Intelligenz uns bei der Barrierefreiheit von Angular-Anwendungen unterstützen kann. Im ersten Teil haben wir die Grundlagen der Accessibility im Projektkontext beleuchtet, uns mit ARIA-Attributen vertraut gemacht und gesehen, wie KI bei den einfachen ‚Good‘-Komponenten wie <select>, <input> und Checkboxen hilfreiche Beiträge leisten kann.

Jetzt wird es anspruchsvoller: Wir wenden uns den Kategorien ‚The Bad‘ und ‚The Ugly‘ zu – also komplexen JavaScript-Komponenten und stark umgestalteten Standardelementen. Hier zeigt sich oft, wo die Grenzen aktueller KI-Systeme liegen und menschliche Expertise sowie ein tiefes Verständnis von Accessibility-Prinzipien unerlässlich sind.

‚The Bad‘ – Komplexe JavaScript-Komponenten

Combobox

• Was ist es: Als Combobox bezeichne ich eine Mischung aus einer Dropdown-Komponente, die aber auch Freitexteingabe und Filterung der Optionen erlaubt. Manchmal gibt es Anwendungsfälle, bei denen nach mehreren Wörtern oder komplexeren Mustern gesucht werden soll.
• Was ist zu tun: In solchen Fällen stößt das bekannte <select>-Element an seine Grenzen. Es bleibt oft nichts anderes übrig, als ein <input>-Feld zu nutzen und eine aufklappende Liste mit Optionen mittels JavaScript dynamisch zu generieren und zu steuern. Hier entstehen die Herausforderungen in Bezug auf Barrierefreiheit:
  • Die Tastaturnavigation muss korrekt funktionieren, z. B. mit Pfeiltasten, Enter und Esc.
  • Die aktuell aktive oder ausgewählte Option sollte deutlich markiert sein.
  • Screenreader müssen über Änderungen informiert werden – das geschieht durch dynamische Updates mit ARIA-Attributen wie role="combobox", aria-autocomplete, aria-controls und aria-expanded.
  • Außerdem ist wichtig, dass Screenreader das Eingabefeld und die zugehörige Optionsliste als eine zusammengehörige, interaktive Komponente erkennen.
• Was macht die KI damit: Keine der KIs konnte eine vollständig barrierefreie Implementierung für diese komplexe Komponente generieren. Die Vorschläge waren oft unvollständig oder fehlerhaft in Bezug auf die notwendigen ARIA-Attribute und das Event-Handling.

Date Range Picker

• Was ist es: Ein Date Range Picker kann einen Zeitraum erfassen – Anfangs- und Enddatum. Wochentage, Monate und Jahre sind sichtbar dargestellt und individuell einstellbar.
• Was ist zu tun: Datum-Eingabe ist erfahrungsgemäß nicht einfach barrierefrei zu gestalten. Sogar das eingebaute <input type="date"> ist aufgrund unterschiedlicher Datumsformate und browserabhängiger Implementierungen nicht ganz trivial. Und jetzt kommt die Projektvorgabe hinzu, in einer Komponente gleich einen Zeitraum (zwei Zeitpunkte) auswählen zu können.
• Was macht die KI damit: Die angegebene Implementierung konnte keine der KIs (OpenAI 4.x, Claude Sonnet 3.x und Google Gemini 2.x) auf Anhieb barrierefrei gestalten. Es fühlte sich mehr nach Symptombekämpfung mit noch mehr aria-Attributen an, um eine geöffnete Kalenderansicht und deren Interaktion zu beschreiben. Was an der Stelle helfen könnte, wäre ein Vorschlag, die Kalender-Komponente um einen Texteingabemodus zu erweitern, sodass Nutzer das Datum direkt eintippen können, ohne sich mit Kalendermonaten und Wochentagen auseinandersetzen zu müssen. Da sich die KI aber bemühte, meine Anfrage zur bestehenden Komponente zu ‚vervollständigen‘, bestärkte dies meinen Eindruck, dass die KI den (bereits komplexen) Kalender-Ansatz als gegeben hinnahm, anstatt grundlegend andere, potenziell zugänglichere Muster vorzuschlagen.

‚The Ugly‘ – Stark umgestaltete Standardkomponenten

Theme Switcher

• Was ist es: Unter einem Theme Switcher wird ein UI-Element verstanden, das Nutzern eine schnelle Änderung des Designs (z.B. zwischen Light- und Dark-Mode) ermöglicht. In unserem Fall (mit 2 Themes) nutzen wir eine einfache Checkbox, die wir anschließend mittels CSS stark umgestalten, sodass sie nicht mehr wie eine Checkbox aussieht, sondern z.B. ein Mond- oder Sonnen-Icon anzeigt. Wenn ein Icon aktiv ist, wird das andere versteckt, sodass immer nur ein Icon gleichzeitig sichtbar ist.
• Was ist zu tun: Da die visuelle Standard-Checkbox durch Icons ersetzt wird, ist es entscheidend, eine klare, zugängliche Beschriftung (Accessible Name) bereitzustellen, da nicht jeder die Piktogramme sehen oder eindeutig interpretieren kann. Dies geschieht am besten über aria-label auf dem (logisch noch vorhandenen) Checkbox-Input. Obwohl die Checkbox durch CSS visuell stark verändert wird, muss sie per Tastatur erreichbar und bedienbar bleiben. Ein tabindex="0" kann hier nützlich sein, falls das Styling die native Fokussierbarkeit beeinträchtigt. Die Icons selbst sollten als dekorativ (aria-hidden="true") markiert werden, da die Funktion und der Zustand über das input-Element kommuniziert werden.
• Was macht die KI damit: Die KI meisterte diese Aufgaben gut und schlug die korrekten Accessibility-Verbesserungen vor:

// Angular Component Code Example
@Component({ /* ... */ })
export class ThemeSwitcher {
isDarkMode = signal(false); // Example state signal

// Computed signal for the dynamic ARIA label
+ protected ariaLabel = computed(() => {
+ return this.isDarkMode() ? 'Wechsle zu Light Mode' : 'Wechsle zu Dark Mode'; + });

onThemeModeChange(event: Event) {
const target = event.target as HTMLInputElement;
this.isDarkMode.set(target.checked); // ... apply theme change } }

// Angular Template Code Example
<input type="checkbox" class="theme-controller" id="themeToggle"
+ tabindex="0" /* Ensures focusability if default is altered */
+ [attr.aria-label]="ariaLabel()" /* Provides accessible name */ [checked]="isDarkMode()" (change)="onThemeModeChange($event)" />

@if (isDarkMode()) {
<svg /* ... */
+ aria-hidden="true"> /* Hides decorative icon from screen reader */ </svg> }
@else {
<svg /* ... */
+ aria-hidden="true"> /* Hides decorative icon from screen reader */ </svg> }

Expandable

• Was ist es: Mit Expandable (oft auch als Accordion-Element oder Disclosure Widget bezeichnet) ist hier eine zweigeteilte Komponente gemeint. Ein Teil (der Inhalt) wird ursprünglich nicht angezeigt und erst nach einem Klick auf ein Steuerelement (oft ein Header oder ein Pfeil-Button) wird dieser ‚ausgeklappt‘ bzw. sichtbar gemacht. Ein wiederholter Klick klappt den Inhaltsbereich wieder ein.
• Was ist zu tun: Hier ist es wichtig, assistiven Technologien (wie Screenreadern) zu signalisieren, dass es sich um ein ausklappbares Element handelt und in welchem Zustand (ausgeklappt/eingeklappt bzw. expanded/collapsed) es sich gerade befindet. Dies geschieht hauptsächlich über das aria-expanded-Attribut am Steuerelement (Button oder Header). Zusätzlich sollte das Steuerelement mittels aria-controls auf die id des Inhaltsbereichs verweisen, der ein- oder ausgeklappt wird. Wenn Icons (z.B. Pfeile) zur visuellen Indikation des Zustands verwendet werden, sollten diese als dekorativ (aria-hidden="true") gekennzeichnet werden.
• Was macht die KI damit: Die KI schlug korrekterweise die Nutzung der Attribute aria-expanded und aria-controls vor. So kann die Komponente ihren Zustand korrekt im Accessibility Tree abbilden und signalisieren, welcher Inhaltsbereich durch eine Interaktion beeinflusst wird.

<details (toggle)="onToggle($event)">
<summary [id]="summaryId()">
Summary Text
+ <span aria-hidden="true"> ▼ </span> </summary>
<div
+ [id]="contentId()">
Collapsible Content... </div> </details>

<button
+ [id]="buttonId()"
+ [attr.aria-expanded]="expanded()" /* Signals state (true/false) */
+ [attr.aria-controls]="contentId()" /* Links to content area */ (click)="toggleExpand()">
Expandable Header
<span
+ aria-hidden="true">
{{ expanded() ? '▲' : '▼' }} </span> </button>
<div
[id]="contentId()"
[hidden]="!expanded()"
+ role="region" /* Optional: role="region" if content is significant */
+ [attr.aria-labelledby]="buttonId()"> /* Optional: links content back to button */ Collapsible Content...</div>

Darüber hinaus wurde vorgeschlagen, dass die SVG-Icons der Pfeiltasten für Screenreader versteckt werden, damit diese nicht (potenziell irreführend) vorgelesen werden müssen.

Fazit

Unsere Reise durch die Welt der KI-gestützten Accessibility in Angular zeigt ein gemischtes Bild. In zwei der drei Komponentenkategorien (‚The Good‘ und ‚The Ugly‘) konnte die KI für die Accessibility eine Bereicherung sein und korrekte, hilfreiche Vorschläge liefern. Sie erkennt Standardmuster und kann Entwicklern Routineaufgaben abnehmen.

Die manchmal übereifrige oder oberflächliche „Interpretation“ des Vorhabens bei den komplexeren Komponenten (‚The Bad‘) führte jedoch dazu, dass mehr Zeit für die Überprüfung und Korrektur der KI-Vorschläge aufgewendet werden musste und am Ende oft kein direkt brauchbares Ergebnis zustande kam. Hätten wir die Fragen an die KI anders formuliert – spezifischer und weniger offen (z.B. ‚Wie kann ich eine Datum-Auswahl-Komponente barrierefrei gestalten?‘ statt ‚Mach diese Komponente accessible‘), wären wir möglicherweise nicht in der Accessibility-Sackgasse gelandet, sondern hätten gezieltere und potenziell nützlichere Informationen erhalten.

Es zeigt sich, dass KI bei Standardfällen gut unterstützt und als Werkzeug dienen kann. Bei komplexen, individuellen UI-Komponenten und tiefgreifenden Accessibility-Anforderungen stößt sie jedoch (noch) an ihre Grenzen. Menschliche Expertise, ein solides Verständnis der WCAG-Richtlinien und der ARIA-Spezifikationen sowie sorgfältiges Testen bleiben unerlässlich, um wirklich barrierefreie Webanwendungen zu schaffen. KI kann ein Partner sein, aber nicht der alleinige Architekt für digitale Zugänglichkeit.