Was ist A11Y? Definition und Bedeutung 2026

A11Y ist eine Kurzform des englischen Begriffs Accessibility (Barrierefreiheit) und leitet sich aus dem Wort ab, indem die 11 Buchstaben zwischen dem ersten „A“ und dem abschließenden „Y“ durch die Zahl 11 ersetzt werden. Im Kontext digitaler Produkte steht A11Y dafür, dass Websites, Apps und Software so gestaltet sind, dass sie von allen Menschen genutzt werden können, einschließlich Personen mit visuellen, motorischen, auditiven oder kognitiven Einschränkungen.

A11Y ist eng verknüpft mit den Web Content Accessibility Guidelines (WCAG) des W3C, dem europäischen Standard EN 301 549 und dem seit dem 28. Juni 2025 in Kraft getretenen deutschen Barrierefreiheitsstärkungsgesetz (BFSG). Das BFSG setzt den European Accessibility Act (EAA) in deutsches Recht um und verpflichtet erstmals auch privatwirtschaftliche Unternehmen zur digitalen Barrierefreiheit. Wer jetzt noch keine A11Y-Strategie hat, riskiert Bußgelder von bis zu 100.000 Euro.

In der Entwicklungspraxis bedeutet A11Y konkret: semantisches HTML, ausreichende Farbkontraste (mindestens 4,5:1 für normalen Text), vollständige Tastaturnavigation, Alt-Texte für Bilder, Untertitel für Videos und Kompatibilität mit Screenreadern wie NVDA oder VoiceOver. Diese Anforderungen sind keine optionalen „Nice-to-haves“ mehr, sondern gesetzliche Pflicht für alle Unternehmen im Anwendungsbereich des BFSG.

Mit dem 28. Juni 2025 ist das BFSG in Kraft getreten und hat die Spielregeln für digitale Produkte und Dienstleistungen grundlegend verändert. Anders als viele erwartet haben, gilt die Pflicht nicht nur für neue Projekte: Auch bestehende Websites und Apps müssen die Anforderungen erfüllen, sofern sie als „Dienstleistung gegenüber Verbrauchern“ eingestuft werden. Eine Ausnahme gilt nur für Kleinstunternehmen mit weniger als zehn Mitarbeitenden und maximal zwei Millionen Euro Jahresumsatz, die Dienstleistungen erbringen.

Die technischen Anforderungen basieren auf der EN 301 549 V3.2.1, die wiederum auf die WCAG 2.1 Level AA verweist. Folgende Bereiche sind im BFSG-Kontext besonders relevant:

• Webshops und E-Commerce-Plattformen (Kontaktformulare, Checkout-Prozesse, Produktseiten)
• Banking und Finanzdienstleistungen online
• Messenger- und Telefoniedienste
• Selbstbedienungsterminals (mit Sonderfristen bis 2040)
• E-Books und digitale Lesegerate
• Smartphones, Tablets und Betriebssysteme

Zuständig für die Marktüberwachung sind die Länderbehörden. Bei festgestellter Nicht-Konformität erfolgt zunächst eine Aufforderung zur Nachbesserung, im Wiederholungsfall drohen Bußgelder bis zu 100.000 Euro und im äußersten Fall das Einstellen des Online-Betriebs. NCA unterstützt Unternehmen bei der rechtssicheren Umsetzung des BFSG, von der Gap-Analyse bis zur vollständigen Barrierefreiheitserklärung.

Die WCAG strukturieren Barrierefreiheitsanforderungen nach vier Grundprinzipien, bekannt unter dem Akronym POUR. Jedes Prinzip adressiert eine andere Dimension der Zugänglichkeit:

• Perceivable (Wahrnehmbar): Inhalte müssen von allen Nutzern wahrgenommen werden können. Das bedeutet Alt-Texte für Bilder, Untertitel für Videos und ausreichende Farbkontraste (4,5:1 für Fließtext, 3:1 für großen Text).
• Operable (Bedienbar): Alle Funktionen müssen per Tastatur erreichbar sein. Fokus-Indikatoren dürfen nicht versteckt werden. Bewegte Inhalte, die länger als 5 Sekunden laufen, müssen pausierbar sein.
• Understandable (Verständlich): Texte und Bedienvorgänge müssen für alle verständlich sein. Fehlerhinweise in Formularen müssen konkret und hilfreich formuliert sein.
• Robust: Inhalte müssen mit verschiedenen Browsern, Betriebssystemen und assistiven Technologien wie Screenreadern oder Sprachsteuerung funktionieren.

WCAG 2.2 erweitert den Standard um sechs neue Kriterien gegenüber Version 2.1, darunter sichtbare Fokus-Indikatoren (2.4.11), ausreichend große Klickbereiche mindestens 24x24 CSS-Pixel (2.5.8) und konsistente Helfermechanismen (3.2.6). Die für das BFSG aktualisierte EN 301 549 wird künftig auf WCAG 2.2 verweisen. Wer heute schon auf 2.2 Level AA setzt, ist optimal aufgestellt.

Barrierefreiheit ist kein Thema, das sich am Ende eines Projekts per Plugin lösen lässt, das zeigt das Bußgeld gegen den Anbieter accessiBe in den USA eindrucksvoll. A11Y muss von Anfang an in die Entwicklung integriert werden. Die wichtigsten technischen Maßnahmen:

• Semantisches HTML: <button> statt <div onclick>, korrekte Heading-Hierarchie (h1-h6), ARIA-Rollen nur wo nötig
• Kontrast und Farbe: Kein Inhalt darf ausschließlich über Farbe kommuniziert werden. Tools wie axe DevTools oder Lighthouse prüfen Kontraste automatisiert.
• Formulare: Jedes Eingabefeld braucht ein verknüpftes <label>. Fehlermeldungen müssen programmatisch mit dem Feld verbunden sein (aria-describedby).
• Tastaturnavigation: Tab-Reihenfolge muss logisch sein. Fokus-Trap in Modals, damit Tastaturnutzer nicht in den Hintergrund navigieren können.
• Bilder: Informative Bilder benötigen beschreibenden Alt-Text. Dekorative Bilder erhalten alt="".
• Videos: Untertitel und Audiobeschreibungen für voraufgezeichnete Medieninhalte.

Für die automatisierte Qualitätssicherung empfiehlt NCA die Integration von axe-core in CI/CD-Pipelines und Cypress-Tests. Werkzeuge wie eslint-plugin-jsx-a11y fangen viele Fehler bereits im Editor ab. Allerdings decken automatisierte Tests nur etwa 30 Prozent aller WCAG-Kriterien ab, manuelle Tests mit echten Screenreadern (NVDA unter Windows, VoiceOver unter macOS) sind unverzichtbar.

Kein automatisiertes Tool ersetzt manuelle A11Y-Tests, aber die Kombination aus beiden Ansätzen ist die effizienteste Strategie. Automatisierte Scans decken rund 30 Prozent der WCAG-Kriterien ab, manuelle Prüfungen mit echten Assistenztechnologien sind für den Rest unverzichtbar.

Automatisierte Tools:

• axe DevTools (Browser-Extension und axe-core für CI/CD-Integration)
• Lighthouse (in Chrome DevTools integriert, bewertet Accessibility-Score)
• WAVE (WebAIM, visuelle Darstellung von Barrierefreiheitsproblemen)
• Silktide Accessibility Checker (automatisiertes Crawling ganzer Websites)
• eslint-plugin-jsx-a11y (statische Analyse in React-Projekten)

Manuelle Tests:

• Tastatur-Navigation: Alle Funktionen nur per Tab, Enter, Pfeiltatsten bedienbar?
• NVDA + Firefox (Windows, kostenlos): Branchen-Standard für Screenreader-Tests
• VoiceOver + Safari (macOS/iOS): Für Apple-Plattformen unabdingbar
• TalkBack (Android): Für mobile Apps
• 200%-Zoom-Test: Layout darf nicht brechen, kein horizontales Scrollen
• Farbblindheits-Simulation: Stark, Colorblindly oder Browser-DevTools

NCA integriert Accessibility-Tests direkt in CI/CD-Pipelines, sodass A11Y-Regressions frühzeitig erkannt und behoben werden. Das spart erhebliche Nachbesserungskosten und stellt sicher, dass neue Features die bestehende Barrierefreiheit nicht zerstören.

Trotz wachsendem Bewusstsein für Barrierefreiheit gibt es in der Praxis wiederkehrende Missverständnisse, die zu falscher Sicherheit führen. Die größten Fallstricke:

• Overlay-Tools als Abkürzung: Anbieter wie accessiBe, UserWay oder AudioEye versprechen automatische Barrierefreiheit per JavaScript-Snippet. Das funktioniert nicht. Das Bußgeld der US-amerikanischen FTC gegen accessiBe ist ein deutliches Signal: KI-Overlays ersetzen keine echte A11Y-Implementierung und können Screenreader sogar gestört werden.
• Einmalige Audits statt kontinuierliches Monitoring: A11Y ist kein Projekt, sondern ein Prozess. Jede neue Feature-Entwicklung kann bestehende Barrierefreiheit beeinträchtigen.
• Nur automatisierte Tests: Tools wie axe oder Lighthouse liefern wichtige Hinweise, aber kein vollständiges Bild. Manuelle Tests mit echten Nutzern mit Behinderungen liefern wertvolle Erkenntnisse, die kein Scan aufdeckt.
• ARIA falsch einsetzen: Zu viele oder falsch eingesetzte ARIA-Attribute können die Barrierefreiheit verschlechtern statt verbessern. Faustregel: Erst natives HTML nutzen, ARIA nur bei Bedarf.
• Barrierefreiheitserklärung fehlt oder ist veraltet: Das BFSG fordert eine aktuelle, aufrichtige Erklärung. Eine veraltete oder unvollständige Erklärung ist selbst ein Konformitätsrisiko.

Die wichtigsten Fragen rund um A11Y, WCAG und BFSG 2026, kompakt beantwortet.