NCA Social Media
Erstellt:
Aktualisiert:
Autor:
Roland Golla
Browser mit WCAG-Checkmark-Schild, EU-Flagge, Rakete auf dunkelblauem Hintergrund

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, der europäischen Norm EN 301 549 und dem Barrierefreiheitsstärkungsgesetz (BFSG), das seit dem 28. Juni 2025 gilt. Das BFSG setzt den European Accessibility Act (EAA) in deutsches Recht um und verpflichtet erstmals auch viele private Unternehmen zur digitalen Barrierefreiheit. Bei Verstößen sind Bußgelder bis zu 100.000 Euro möglich.

In der Entwicklung heißt A11Y konkret: semantisches HTML, ausreichende Farbkontraste (mindestens 4,5:1 für normalen Text), vollständige Tastaturnavigation, Alternativtexte für Bilder, Untertitel für Videos und Kompatibilität mit Screenreadern wie NVDA oder VoiceOver. Für Unternehmen im Anwendungsbereich des BFSG ist das keine Kür mehr, sondern Pflicht.

Inhalt

A11Y mit NCA: Schnelle Hilfe vom Experten

Never Code Alone baut Frontends täglich mit Astro, React und Vue und testet sie mit Cypress und Cypress Cloud. Barrierefreiheit ist bei uns kein Zusatz am Projektende, sondern Teil von Komponenten, Design Tokens und Pipeline. Roland Golla ist Cypress Ambassador, und automatisierte Accessibility Checks mit axe gehören bei uns in jeden Testlauf.

Für Teams, die das BFSG umsetzen müssen, bietet NCA barrierefreies Webdesign und Accessibility Webdesign im Frontend. Wir starten mit einem Accessibility Audit, sichern Ergebnisse mit Accessibility Testing in der CI ab und modernisieren bestehende Systeme über Frontend Development und Legacy Modernisierung.

Lass uns sprechen
Finde das passende Angebot für dein Projekt
Anfrage-Konfiguration
Starten Sie Ihre Anfrage
Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

BFSG seit 2025: Was sich für Unternehmen konkret ändert

Seit dem 28. Juni 2025 gilt das BFSG und hat die Spielregeln für digitale Produkte und Dienstleistungen verändert. Die Pflicht trifft nicht nur neue Projekte: Auch bestehende Websites und Apps müssen die Anforderungen erfüllen, wenn sie als Dienstleistung gegenüber Verbrauchern gelten. Für bestimmte Fälle gibt es Übergangsfristen. Ausgenommen sind Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz oder Jahresbilanzsumme, soweit sie Dienstleistungen erbringen.

Die technischen Anforderungen stützen sich auf die harmonisierte Norm EN 301 549 V3.2.1, die auf WCAG 2.1 Level AA verweist. Im September 2026 ist die neue Fassung V4.1.1 mit WCAG 2.2 erschienen. Sie wird zur rechtlichen Referenz, sobald sie im EU Amtsblatt veröffentlicht ist. Besonders relevant sind diese Bereiche:

  • Onlineshops und Webshops (Kontaktformulare, Checkout, Produktseiten)
  • Banking und Finanzdienstleistungen online
  • Messenger und Telefoniedienste
  • Selbstbedienungsterminals (Übergangsfrist bis längstens 2040)
  • E-Books und digitale Lesegeräte
  • Smartphones, Tablets und Betriebssysteme

Die Marktüberwachung liegt bei der gemeinsamen Marktüberwachungsstelle der Länder für die Barrierefreiheit (MLBF). Bei Mängeln folgt zunächst die Aufforderung zur Nachbesserung. Bleibt sie aus, drohen Bußgelder bis zu 100.000 Euro und im äußersten Fall die Einstellung des Angebots. NCA unterstützt Teams bei der Umsetzung, von der Gap Analyse bis zu den Pflichtinformationen zur Barrierefreiheit. Einen Überblick gibt die Seite zu Compliance in der Barrierefreiheit.

WCAG 2.2: Die vier POUR Prinzipien im Überblick

Die WCAG ordnen alle Anforderungen nach vier Grundprinzipien, bekannt als POUR. Jedes Prinzip deckt eine andere Seite der Zugänglichkeit ab:

  • Perceivable (Wahrnehmbar): Inhalte müssen von allen Nutzern wahrgenommen werden können. Das bedeutet Alternativtexte 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. Der Fokus muss sichtbar bleiben. 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 ist seit Oktober 2023 W3C Empfehlung und bringt neun neue Erfolgskriterien, sechs davon auf Level A und AA. Dazu gehören nicht verdeckter Fokus (2.4.11), ausreichend große Klickflächen von mindestens 24 mal 24 CSS Pixel (2.5.8), konsistente Hilfe (3.2.6) und barrierefreie Authentifizierung (3.3.8). Das Kriterium 4.1.1 Parsing ist entfallen. Wer heute auf WCAG 2.2 Level AA setzt, ist für die neue EN 301 549 gut aufgestellt. WCAG 3 ist im Oktober 2026 noch ein Working Draft und kein prüfbarer Standard.

A11Y in der Praxis: Technische Umsetzung für Entwickler

Barrierefreiheit lässt sich nicht am Ende eines Projekts per Plugin nachrüsten. A11Y gehört von Anfang an in die Entwicklung. Die wichtigsten technischen Maßnahmen:

  • Semantisches HTML: <button> statt <div onclick>, korrekte Überschriften Hierarchie (h1 bis h6), ARIA Rollen nur wo nötig
  • Kontrast und Farbe: Kein Inhalt darf nur über Farbe vermittelt werden. axe DevTools oder Lighthouse prüfen Kontraste automatisiert.
  • Formulare: Jedes Eingabefeld braucht ein verknüpftes <label>. Fehlermeldungen werden per aria-describedby mit dem Feld verbunden. Mehr unter Accessible Forms.
  • Tastaturnavigation: Die Tab Reihenfolge muss logisch sein. In Modals hält ein Fokus Trap Tastatur Nutzer im Dialog.
  • Bilder: Informative Bilder brauchen beschreibenden Alternativtext, dekorative Bilder alt="".
  • Videos: Untertitel und Audiodeskription für aufgezeichnete Medien.
Code: 
          
<!-- Gutes Beispiel: Barrierefreier Button -->
<button type="button" aria-label="Suche starten">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

<!-- Schlechtes Beispiel -->
<div onclick="search()" class="btn">Suche</div>

Für die automatisierte Qualitätssicherung binden wir axe-core in Cypress Tests und die CI ein. eslint-plugin-jsx-a11y fängt in React Projekten viele Fehler schon im Editor ab. Automatisierte Tests finden aber nur einen Teil der WCAG Probleme. Manuelle Tests mit echten Screenreadern wie NVDA unter Windows und VoiceOver unter macOS bleiben unverzichtbar.

A11Y Testing: Tools und Methoden 2026

Kein automatisiertes Tool ersetzt manuelle A11Y Tests. Die Kombination aus beiden ist die effizienteste Strategie: Scanner finden typische Fehler schnell, Menschen mit echten Assistenztechnologien finden den Rest.

Automatisierte Tools:

  • axe DevTools (Browser Extension, dazu axe-core für die CI, siehe axe DevTools und Cypress)
  • Lighthouse (in Chrome DevTools integriert, liefert einen 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:

  • Tastaturnavigation: Sind alle Funktionen nur per Tab, Enter und Pfeiltasten bedienbar? Die Tab Reihenfolge macht taba11y sichtbar.
  • NVDA mit Firefox (Windows, kostenlos): weit verbreitet für Screenreader Tests
  • VoiceOver mit Safari (macOS und iOS): Pflicht für Apple Plattformen
  • TalkBack (Android): für mobile Apps
  • Zoom auf 200 und 400 Prozent: Das Layout darf nicht brechen (WCAG 1.4.4 und 1.4.10)
  • Simulation von Farbsehschwäche: Stark oder die Browser DevTools

NCA bindet Accessibility Tests direkt in CI/CD Pipelines ein, damit A11Y Regressionen früh auffallen. So zerstören neue Features die bestehende Barrierefreiheit nicht unbemerkt. Einen Überblick über Werkzeuge gibt die Seite zu Accessibility Testing Tools.

A11Y kritisch betrachtet: Grenzen und häufige Fehler

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. Die US Handelsbehörde FTC hat accessiBe im April 2025 wegen irreführender Werbeversprechen zu einer Zahlung von 1 Million US Dollar verpflichtet. Overlays ersetzen keine echte Umsetzung und können Screenreader sogar stören.
  • Einmalige Audits statt kontinuierlicher Prüfung: A11Y ist kein Projekt, sondern ein Prozess. Jedes neue Feature kann bestehende Barrierefreiheit beeinträchtigen.
  • Nur automatisierte Tests: Tools wie axe oder Lighthouse liefern wichtige Hinweise, aber kein vollständiges Bild. Tests mit Menschen mit Behinderungen liefern Erkenntnisse, die kein Scan aufdeckt.
  • ARIA falsch einsetzen: Zu viele oder falsche ARIA Attribute verschlechtern die Barrierefreiheit statt sie zu verbessern. Faustregel: erst natives HTML, ARIA nur bei Bedarf.
  • Pflichtinformationen zur Barrierefreiheit fehlen: Das BFSG verlangt, dass Dienstleister erklären, wie ihr Angebot die Anforderungen erfüllt. Fehlende oder veraltete Angaben sind selbst ein Konformitätsrisiko.

Access by everyone regardless of disability is an essential aspect.

Tim Berners-Lee, Erfinder des World Wide Web und Gründer des W3C – W3C Web Accessibility Initiative, Introduction to Web Accessibility

A11Y bei NCA: Was wir aus der Praxis mitnehmen

In Projekten zur Barrierefreiheit sehen wir immer wieder dieselben Muster. Drei Punkte machen in der Praxis den größten Unterschied:

  • Semantik zuerst: Wer mit sauberem HTML startet, braucht später kaum ARIA. Ein echter Button schlägt jedes nachgebaute Widget. Mehr dazu im Eintrag zum DOM und Accessibility Tree.
  • Tests in die Pipeline: Ein einmaliges Audit veraltet mit dem nächsten Release. axe in Cypress hält das erreichte Niveau.
  • Design und Code gemeinsam: Kontraste, Fokus Zustände und Klickflächen gehören ins Designsystem, nicht in ein spätes Ticket. Praktische Regeln dazu stehen bei CSS und Barrierefreiheit.

Einen guten Einstieg ins Thema bietet unser Überblick zur digitalen Barrierefreiheit. Wer sein Team gezielt aufstellen will, findet bei NCA Unterstützung für barrierefreies Webdesign von der Analyse bis zur Umsetzung.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
Erreichen Sie unsere Spezialisten zu barrierefreien Webdesign

Wir sind hier, um Ihnen zu helfen. Gemeinsam meistern wir Ihre digitalen Herausforderungen und fördern die Inklusion im Internet. Lassen Sie uns Ihre Projekte mit barrierefreiem Webdesign erfolgreich machen.

Kostenlose Demo Jetzt anrufen

Häufige Fragen zu A11Y

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

Was bedeutet A11Y 2026 konkret für Unternehmen?

A11Y steht für Accessibility, also Barrierefreiheit. Seit dem 28. Juni 2025 ist sie durch das BFSG für viele Unternehmen Pflicht. Wer digitale Produkte oder Dienstleistungen für Verbraucher anbietet, muss die Anforderungen der EN 301 549 erfüllen, die heute auf WCAG 2.1 Level AA verweist. Bei Verstößen drohen Bußgelder bis zu 100.000 Euro.

Welche WCAG Version gilt 2026 nach dem BFSG?

Rechtliche Referenz ist bis auf Weiteres die EN 301 549 V3.2.1 mit WCAG 2.1 Level AA. Im September 2026 erschien die neue Fassung V4.1.1, die WCAG 2.2 übernimmt. Sie gilt als Referenz, sobald die EU Kommission sie im Amtsblatt veröffentlicht. Wer heute auf WCAG 2.2 Level AA setzt, ist für beide Fassungen gut aufgestellt.

Wie unterscheiden sich A11Y, WCAG, BITV und BFSG 2026?

A11Y ist der Oberbegriff für digitale Barrierefreiheit. Die WCAG sind die technischen Richtlinien des W3C. Die BITV 2.0 gilt für öffentliche Stellen des Bundes. Das BFSG setzt den European Accessibility Act in deutsches Recht um und gilt für viele private Anbieter. Technisch stützen sich alle Regelwerke auf WCAG Kriterien.

Welche Unternehmen sind 2026 vom BFSG ausgenommen?

Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz oder Jahresbilanzsumme sind von den Pflichten für Dienstleistungen ausgenommen. Achtung: Wer Produkte wie Hardware in Verkehr bringt, fällt unabhängig von der Größe unter das BFSG. Für einige Altfälle gibt es zudem Übergangsfristen, etwa bei Selbstbedienungsterminals.

Was kostet BFSG Konformität 2026?

Das hängt vom Ausgangszustand ab. Eine Website mit sauberem semantischem HTML braucht oft nur gezielte Korrekturen, ein altes System mit vielen Custom Widgets deutlich mehr. Wir starten mit einem kostenlosen Kennenlernen, schätzen den Aufwand nach einem ersten Blick auf die Seite und rechnen transparent minutengenau ab. Pauschalpreise ohne Analyse sind nicht seriös.

Kann ich mit einem Accessibility Overlay wie accessiBe BFSG konform werden?

Nein. Overlay Tools ersetzen keine echte A11Y Umsetzung und können Screenreader sogar stören. Die US Handelsbehörde FTC hat accessiBe 2025 wegen irreführender Versprechen zu einer Zahlung von 1 Million US Dollar verpflichtet. Das BFSG verlangt echte technische Konformität im Code, kein JavaScript Pflaster über einer unzugänglichen Seite.

Wie teste ich meine Website auf A11Y Konformität?

Kombiniere drei Wege: automatisierte Scans mit axe DevTools oder Lighthouse, manuelle Tests mit NVDA unter Windows und VoiceOver unter macOS sowie einen reinen Tastaturtest mit Tab, Enter und Pfeiltasten. Dazu kommt die Kontrastprüfung. Dauerhaft absichern lässt sich das mit Cypress und axe in der CI Pipeline.

Brauche ich eine Barrierefreiheitserklärung nach BFSG?

Dienstleister müssen nach BFSG öffentlich erklären, wie ihr Angebot die Barrierefreiheitsanforderungen erfüllt. Die Inhalte regelt Anlage 3 des Gesetzes. Viele Unternehmen veröffentlichen das als Barrierefreiheitserklärung auf der Website. Sie sollte den Stand ehrlich beschreiben, bekannte Barrieren nennen und bei größeren Änderungen aktualisiert werden.

Welche ARIA Attribute sind für A11Y besonders wichtig?

Die wichtigsten sind aria-label und aria-labelledby für Beschriftungen, aria-describedby für ergänzende Beschreibungen, aria-live für dynamische Änderungen und aria-expanded für Akkordeons und Dropdowns. Für Modals nutzt du am besten das native dialog Element. Faustregel: natives HTML bevorzugen, ARIA nur ergänzend einsetzen.

Wie integriere ich A11Y Tests in CI/CD Pipelines?

axe-core lässt sich als Node Paket in Cypress einbinden, etwa über cypress-axe. Pre Commit Hooks mit eslint-plugin-jsx-a11y fangen statische Fehler früh ab. Wir führen A11Y Tests als eigene Stage in der Pipeline, damit Regressionen sofort sichtbar werden. Mit Cypress Cloud behalten Teams die Ergebnisse über alle Läufe hinweg im Blick.

Welche Farbkontrast Anforderungen gelten nach WCAG 2.2?

Normaler Text braucht mindestens 4,5:1, großer Text ab 18 Punkt oder 14 Punkt fett 3:1. UI Komponenten, Icons und Fokus Indikatoren brauchen nach 1.4.11 Non-text Contrast ebenfalls 3:1. Dieses Kriterium gibt es seit WCAG 2.1 und gilt in WCAG 2.2 unverändert. Auf Stufe AAA steigen die Werte für Text auf 7:1 und 4,5:1.

Ist A11Y nur für Menschen mit Behinderungen relevant?

Nein. Barrierefreiheit hilft allen. Untertitel nutzen Menschen in lauten Umgebungen, gute Kontraste erleichtern das Lesen in der Sonne, saubere Tastaturnavigation schätzen auch Power User. Dazu kommen ältere Menschen und Menschen mit vorübergehenden Einschränkungen. Saubere Semantik hilft außerdem Suchmaschinen und KI Agenten, deine Inhalte zu verstehen.

Wie hilft NCA bei der BFSG Umsetzung?

Wir begleiten Teams von der Gap Analyse über die technische Umsetzung bis zu den Pflichtinformationen zur Barrierefreiheit. Wir binden A11Y Tests mit Cypress in die CI/CD Pipeline ein, schulen Entwicklungsteams und unterstützen bei der laufenden Qualitätssicherung. Den Aufwand schätzen wir vorab und rechnen transparent minutengenau ab.