ARIA für AI Agents und Barrierefreiheit

In meinem letzten Artikel “Warum AI Agents von Accessibility profitieren” habe ich Dir erklärt, was der Accessibility Tree ist und welche Vorteile ein korrekter Accessibility Tree für AI Agents hat. Heute geht es um ARIA. Denn zum Beispiel empfiehlt OpenAI explizit den Einsatz von WAI-ARIA:

“ChatGPT Atlas uses ARIA tags—the same labels and roles that support screen readers—to interpret page structure and interactive elements. To improve compatibility, follow WAI-ARIA best [sic!] practices by adding descriptive roles, labels, and states to interactive elements like buttons, menus, and forms. This helps ChatGPT recognize what each element does and interact with your site more accurately.”

Falls Du Dich fragst “Und was ist dieses WAI-ARIA?” Dann lies jetzt weiter. Ich erkläre es Dir. Und auch, warum Du Dich OpenAI widersetzen und kein ARIA nutzen solltest.

Was ist WAI-ARIA überhaupt?

Die Abkürzung WAI-ARIA steht für Web Accessibility Initiative Accessible Rich Internet Applications.

WAI-ARIA (oder auch nur ARIA) ist eine semantische Erweiterung für HTML. Damit ergänzt Du Rollen, Zustände und Eigenschaften, wenn HTML allein nicht ausreicht. Das kann bei dynamischen Inhalten und komplexen Benutzeroberflächen hilfreich sein.

Ein paar Beispiele:

• Rolle (Zweck eines Elements), z. B.role="button" ergänzt die Rolle „Button", role="presentation" entfernt die Semantik eines Elements.
• Zustand (aktuelle Bedingung oder Status eines Elements), z. B. aria-expanded="true" für ein geöffnetes Dropdown oder aria-hidden="true", um Elemente vor Screenreadern zu verstecken.
• Eigenschaft (zusätzliche Information), z. B. aria-label="Zusatzinfo" oder aria-labelledby="h2".

Aber Achtung! Mehr ARIA führt zu mehr Fehlern

WebAIM untersucht jedes Jahr im Million-Report die Top 1 Million Homepages hinsichtlich Accessibility-Fehlern. 2026 (wie auch die Jahre zuvor) lautet ein Ergebnis: Je mehr ARIA vorhanden ist, desto mehr Fehler gibt es bei der Barrierefreiheit.

“Home pages with ARIA present had significantly more errors (59.1 on average) than pages without ARIA (42 on average). [...] Increased ARIA usage on pages was associated with higher detected errors. The more ARIA attributes that were present, the more detected accessibility errors could be expected."

ARIA ergänzt keine Funktionen. Elemente mit role=”button” erkennen Screenreader zwar als Schaltfläche. Das Element ist dadurch aber noch nicht tastaturbedienbar/anklickbar. Diese Funktion musst Du zusätzlich einbauen. Ein HTML <button> kann das hingegen von Haus aus.

Und außerdem:

• ARIA kann fast die gesamte HTML-Semantik überschreiben.
• Nicht alle Browser/Screenreader unterstützen alle ARIA-Attribute.

Wenn Du ARIA also falsch einsetzt, entfernst du Bedeutungen oder ergänzt unnötig Informationen auf Elementen. Diese (falschen/verwirrenden) Informationen stehen dann im Accessibility Tree. Und diesen nutzen nicht nur Screenreader, sondern auch AI Agents. Falsches oder schlechtes ARIA beeinträchtigt daher nicht nur die Barrierefreiheit, sondern auch AI Agents.

Wenn Du also nicht sicher im Umgang mit ARIA bist, halte Dich an den Rat des ARIA Authoring Practices Guide (APG) von W3C:

„No ARIA is better than Bad ARIA." (Kein ARIA ist besser als schlechtes ARIA.)

Also: Ignoriere, was OpenAI schreibt und…

Nutze HTML statt ARIA

Eine barrierefreie Struktur sorgt dafür, dass AI Agents den Inhalt und Zweck Deiner Website korrekt erfassen. Deswegen:

• Nutze semantisches HTML.
• Verwende ARIA nur, wenn HTML nicht mehr ausreicht (und wenn Du weißt, was Du tust).

Gut umgesetzte Accessibility ermöglicht es Menschen und Agents, Interaktionen wie Formulare oder Käufe fehlerfrei für den User auszuführen.