NCA Social Media
Erstellt:
Aktualisiert:
Autor:
Roland Golla
Dunkelblaues Bild: Wegweiser Barrierefreiheit mit vier Pfaden zu Symbolen

Was ist digitale Barrierefreiheit?

Digitale Barrierefreiheit bedeutet, dass Websites, Apps, Dokumente und digitale Dienste von allen Menschen genutzt werden können, unabhängig von Behinderung oder Hilfsmittel. Die technische Messlatte dafür sind die Web Content Accessibility Guidelines in der Stufe AA.
In der Praxis heißt das vier Dinge: Ein Screenreader muss den Inhalt sinnvoll vorlesen können. Die Tastatur muss jede Funktion erreichen. Der Kontrast muss auch im Sonnenlicht reichen. Und die Seite darf bei 200 Prozent Zoom nicht auseinanderfallen. Wer diese vier Punkte hält, hat den größten Teil geschafft.
Betroffen sind mehr Menschen, als die meisten annehmen. Blindheit ist nur ein Teil davon. Dazu kommen Sehbehinderung, Hörbehinderung, motorische Einschränkungen, kognitive Beeinträchtigungen, Farbsehschwäche und schlicht das Alter. Und dann die Situationen: grelles Licht, kaputtes Trackpad, gebrochener Arm, laute Bahn ohne Kopfhörer. Barrierefreiheit hilft am Ende allen.
Die englische Kurzform lautet a11y: ein a, elf Buchstaben, ein y. Gemeint ist immer dasselbe Ziel. Der technische Rahmen dafür sind semantisches HTML, sauber gesetzte Rollen und Zustände sowie Inhalte, die ohne Maus funktionieren.

Inhalt

Digitale Barrierefreiheit mit NCA: Schnelle Hilfe vom Experten

Barrierefreiheit ist bei uns kein Zusatzmodul, sondern Teil der normalen Frontend Arbeit. Sulu CMS, Astro, React und Vue liefern bei uns semantisches HTML von Anfang an. Cypress mit axe-core prüft jede Änderung gegen WCAG 2.2 AA, bevor sie live geht. Roland Golla ist Cypress Ambassador und baut seit über 20 Jahren Qualitätssicherung in Webprojekte. Was wir dabei lernen, geht in Open Source Projekte und Talks zurück.
Dazu passen unsere Leistungen rund um Accessibility Webdesign und Frontend, automatisiertes Accessibility Testing mit axe DevTools und Cypress, Lighthouse Accessibility Audits, das visuelle Prüfen der Tab Reihenfolge mit taba11y, barrierefreie Überschriftenstrukturen und unsere Frontend Development Beratung für Teams, die Barrierefreiheit dauerhaft in die Pipeline holen wollen.
Lass uns über deine Barrierefreiheit 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

Wer digitale Barrierefreiheit umsetzen muss

Für öffentliche Stellen ist Barrierefreiheit schon lange Pflicht. Neu ist der Druck auf die Privatwirtschaft. Das Barrierefreiheitsstärkungsgesetz setzt den European Accessibility Act in deutsches Recht um und gilt seit dem 28. Juni 2025. Seitdem müssen betroffene Dienstleistungen barrierefrei angeboten werden.
Typisch betroffen sind diese Bereiche:
  • Onlineshops und Buchungsstrecken im Geschäft mit Verbrauchern, vom Produktlisting bis zur Bestellbestätigung.
  • Bank und Zahlungsdienste inklusive Onlinebanking und Authentifizierung.
  • Personenbeförderung und Ticketing, also Fahrpläne, Buchung und digitale Tickets.
  • Telekommunikationsdienste und die dazugehörigen Kundenportale.
  • E-Books und ihre Lesesoftware sowie Geräte wie Geldautomaten oder Fahrkartenautomaten.
Ausgenommen sind Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz beziehungsweise Jahresbilanzsumme. Diese Ausnahme greift nur bei Dienstleistungen, nicht bei Produkten. Wer eine der Grenzen überschreitet, fällt voll unter das Gesetz.
Kontrolliert wird über die Marktüberwachungsstelle der Länder mit Sitz in Magdeburg. Sie arbeitet auf zwei Wegen: aktiv mit systematischen, oft automatisierten Prüfungen und reaktiv über Beschwerden von Verbrauchern. Stellt sie einen Verstoß fest, gibt es zuerst eine Frist zur Nachbesserung, danach greifen weitere Maßnahmen bis zum Bußgeld. Ein direktes Klagerecht für jeden einzelnen Nutzer schafft das Gesetz nicht. Wir sind keine Anwälte und geben keine Rechtsberatung. Für die juristische Bewertung verweisen wir an Fachanwälte, für die technische Seite sind wir da.

Die vier Prinzipien der WCAG in der Praxis

Die Web Content Accessibility Guidelines ordnen alles unter vier Prinzipien. Im Englischen ergeben die Anfangsbuchstaben das Wort POUR. Wer die vier versteht, kann die einzelnen Erfolgskriterien einordnen, statt eine Checkliste abzuarbeiten.
  • Wahrnehmbar: Jede Information muss über mehr als einen Sinn ankommen. Bilder brauchen einen Alternativtext, Videos brauchen Untertitel und bei Bedarf Audiodeskription. Der Farbkontrast muss stimmen, und Farbe allein darf nie die einzige Information sein.
  • Bedienbar: Alles muss ohne Maus gehen. Keyboard Navigation, sichtbarer Fokus, ausreichend große Klickflächen und genug Zeit für Eingaben. Mehr dazu unter Operabilität.
  • Verständlich: Sprache auszeichnen, Navigation konsistent halten, Fehlermeldungen im Klartext schreiben. Leichte und Einfache Sprache hilft weit über die Zielgruppe hinaus.
  • Robust: Der Code muss auch für Hilfsmittel lesbar sein, die es heute noch nicht gibt. Das bedeutet gültiges Semantic HTML und korrekte Angaben zu Name, Rolle und Zustand. Details unter Robustheit.
Rechtlich referenziert das BFSG über die Norm EN 301 549 auf die WCAG. Für Websites ist damit die Stufe AA der Maßstab. Die WCAG 3.0 existiert bisher nur als Arbeitsentwurf beim W3C und ist kein Ziel, auf das man warten sollte. Wer heute WCAG 2.2 AA erfüllt, hat auch für die nächste Generation die beste Ausgangslage.

Semantisches HTML zuerst, ARIA nur wenn nötig

Der größte Hebel liegt nicht in Zusatzattributen, sondern im richtigen Element. Ein Button ist ein Button. Er ist fokussierbar, reagiert auf Leertaste und Enter, meldet sich beim Screenreader als Schaltfläche und braucht dafür keine einzige Zeile JavaScript. Ein div mit Klickhandler kann davon nichts.
Code: 
          
<!-- Nicht barrierefrei -->
<div class="btn" onclick="submit()">Absenden</div>
<div class="label">Mail</div>
<input type="text">

<!-- Barrierefrei -->
<label for="mail">Mail</label>
<input type="email" id="mail" name="mail" autocomplete="email">
<button type="submit">Absenden</button>
Die zweite Variante ist kürzer und funktioniert für alle. Das Label ist über das for Attribut mit dem Feld verbunden, ein Klick auf den Text setzt den Fokus, der Screenreader liest die Beschriftung vor. Der Input Typ email holt auf dem Handy die passende Tastatur, autocomplete füllt gespeicherte Daten. Mehr dazu unter Accessible Forms und barrierefreie Formulare.
ARIA kommt erst danach, für Dinge, die HTML nicht abbildet: ein Tab Panel, ein Dialog, eine Live Region für Statusmeldungen. Falsch gesetzte Rollen richten dabei mehr Schaden an als gar keine, weil sie das Element im Accessibility Tree falsch beschreiben. Die Regel im Team lautet deshalb: erst nach einem nativen Element suchen, ARIA nur begründet einsetzen.
Dazu kommen die Punkte, die im CSS entschieden werden: sichtbarer Fokusring statt outline none, eine sinnvolle Lesereihenfolge, die zur logischen Reihenfolge im Markup passt, und ein Responsive Design, das bei 200 Prozent Zoom noch bedienbar bleibt.

Vier Reifegrade der digitalen Barrierefreiheit

Stufe Was im Projekt passiert Ergebnis
Ignoriert Keine Prüfung, kein Wissen im Team, Barrierefreiheit taucht in keinem Ticket auf Blocker im Checkout, offenes Risiko bei Beschwerden und Marktüberwachung
Geprüft Einmaliges Audit, Bericht liegt als PDF vor, Umsetzung offen Der Stand ist bekannt, veraltet aber mit dem nächsten Release
Behoben Kritische Pfade repariert, Barrierefreiheitserklärung veröffentlicht Nutzbar und dokumentiert, hält solange niemand Neues baut
Abgesichert axe und Cypress laufen in der CI, Reviews mit Tastatur und Screenreader gehören zum Prozess Der Stand bleibt, auch nach Redesign und Teamwechsel

Barrierefreiheit testen: was Werkzeuge können und was nicht

Automatisierte Tests sind schnell, günstig und blind für den wichtigsten Teil. Sie finden fehlende Alternativtexte, zu schwache Kontraste, doppelte IDs und Formularfelder ohne Label. Sie erkennen nicht, ob ein Alternativtext den Inhalt des Bildes wiedergibt, ob die Fokusreihenfolge Sinn ergibt oder ob eine Fehlermeldung verständlich ist. Beides zusammen ergibt ein Bild, keins davon allein.
Die automatisierte Schicht bauen wir mit axe-core in Cypress. Der Test läuft in der Pipeline und blockiert den Merge, wenn ein Verstoß dazukommt:
Code: 
          
describe('Barrierefreiheit der Kernseiten', () => {
  const seiten = ['/', '/produkte', '/warenkorb', '/kasse'];

  seiten.forEach((seite) => {
    it(`${seite} erfüllt WCAG 2.2 AA`, () => {
      cy.visit(seite);
      cy.injectAxe();
      cy.checkA11y(null, {
        runOnly: { type: 'tag', values: ['wcag2a', 'wcag2aa', 'wcag21aa', 'wcag22aa'] },
      });
    });
  });
});
Die manuelle Schicht braucht keine Spezialsoftware, nur Disziplin. Einmal durch die Seite mit der Tabulatortaste: Ist der Fokus immer sichtbar, kommt man überall hin, gibt es Tastenfallen. Danach mit einem Screenreader über die Hauptpfade, unter Windows mit NVDA, auf dem Mac mit VoiceOver. Zum Schluss auf 200 Prozent zoomen und prüfen, ob noch alles lesbar und bedienbar ist.
Die Werkzeuge dafür beschreiben wir im Detail bei den Accessibility Testing Tools, im Vorgehen unter Accessibility Testing und in der Prüfsystematik beim Accessibility Audit. Für einzelne Prüfungen helfen der Farbkontrast Rechner, der Silktide Accessibility Checker und die Accessibility Werkzeuge in Firefox.
Wichtig ist außerdem die Stichprobe. Niemand prüft tausend Seiten manuell. Die repräsentative Stichprobentestung wählt Seitentypen und kritische Pfade so aus, dass das Ergebnis aussagekräftig bleibt.

Die Fehler, die wir immer wieder sehen

Barrierefreiheit scheitert selten an exotischen Sonderfällen. Es sind fast immer dieselben acht Punkte, und die meisten davon sind in Stunden statt Wochen behoben.
  • Fokus unsichtbar gemacht. Ein outline none im CSS, weil der blaue Ring nicht ins Design passt. Damit ist die Seite für Tastaturnutzer blind bedienbar.
  • Overlay statt Umbau. Ein eingebundenes Skript verspricht Konformität per Knopfdruck. Es repariert kaputtes Markup nicht und stört oft die Hilfsmittel, die Nutzer schon eingerichtet haben.
  • Alternativtexte als Pflichtfeld. Dateiname oder Keyword im Alt Attribut sind schlimmer als ein leeres Alt bei einem Dekobild. Wie es richtig geht, steht unter Alternativtext.
  • Überschriften nach Optik gewählt. H3 weil kleiner, nicht weil untergeordnet. Screenreader nutzen diese Struktur zur Navigation. Mehr unter barrierefreie Headlines.
  • CAPTCHA ohne Alternative. Ein reines Bildrätsel sperrt blinde Nutzer komplett aus. Die Optionen stehen unter CAPTCHA.
  • Farbe als einzige Information. Ein rotes Feld ohne Text sagt bei Farbsehschwäche gar nichts.
  • PDF als Ausweg. Formulare und Informationen landen als Scan im Netz. Was ein PDF wirklich braucht, steht unter PDF und Barrierefreiheit.
  • Video ohne Untertitel. Automatisch generierte Untertitel ohne Korrektur zählen nicht, besonders bei Fachbegriffen und Eigennamen.
Auffällig ist, wie oft diese Punkte im Redaktionsalltag entstehen und nicht in der Entwicklung. Ein Bild ohne Alternativtext, eine Überschrift aus dem Stilmenü, ein PDF statt einer Seite. Deshalb gehört Barrierefreiheit auch in die Einarbeitung der Redaktion, nicht nur ins Frontend Team.

Access by everyone regardless of disability is an essential aspect.

Tim Berners-Lee, Erfinder des World Wide Web und Gründungsdirektor des W3C – W3C Pressemitteilung zum Start der Web Accessibility Initiative

Digitale Barrierefreiheit in NCA Projekten

Wir starten nie mit einem Audit über alles. Der erste Schritt ist die Einordnung: Welche Seiten und Prozesse sind wirklich betroffen, wo steht das Projekt technisch heute, welches CMS und welches Framework stehen dahinter. Erst danach prüfen wir die kritischen Pfade. In einem Shop sind das Produktseite, Warenkorb, Kasse und Kontoverwaltung, nicht der Blog aus dem Jahr davor.
Die Ergebnisse priorisieren wir nach Wirkung. Was blockiert eine Bestellung komplett, was erschwert sie, was ist kosmetisch. Blockierende Fehler wie fehlende Keyboard Navigation, unbeschriftete Formularfelder, unbrauchbarer Farbkontrast oder CAPTCHAs ohne Alternative kommen zuerst. Parallel entstehen die Cypress Tests, damit behobene Fehler nicht zurückkommen.
Im Frontend arbeiten wir mit Astro, React und Vue, im CMS mit Sulu. Alle drei liefern sauberes Markup, wenn man sie richtig einsetzt. Wir helfen Teams bei Semantic HTML, ARIA in eigenen Komponenten, barrierefreien Schriftarten, barrierefreien Icons und beim Umgang mit Nicht Text Inhalten. Wo es um Universal Design und verständliche Sprache geht, holen wir die passenden Leute aus unserem Netzwerk dazu.
Am Ende soll Barrierefreiheit vom Projekt zum Prozess werden: Guardrails in der Pipeline, ein dokumentierter Stand als Grundlage für die Barrierefreiheitserklärung und ein klarer Ablauf für gemeldete Barrieren. Wenn ihr wissen wollt, wie sich das mit KI gestützter Entwicklung verträgt, findet ihr das in unserer Vibe Coding Beratung. Alle Begriffe rund um das Thema stehen im NCA Glossar für Barrierefreiheit, angrenzende Themen wie Headless, CSS, Text-to-Speech, Voice Recognition, alternative Eingabegeräte, Deutsche Gebärdensprache und Konformität ebenfalls.
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 digitaler Barrierefreiheit

Die Fragen, die uns Teams und Entscheider am häufigsten stellen. Kurz beantwortet, ohne Juristendeutsch.

Was bedeutet digitale Barrierefreiheit 2026 konkret?

Digitale Barrierefreiheit heißt, dass Website, App oder Dokument von allen Menschen genutzt werden können, auch mit Hilfsmitteln. Konkret prüfbar wird das über vier Punkte: Screenreader lesen den Inhalt sinnvoll vor, die Tastatur erreicht jede Funktion, der Kontrast reicht aus, und bei 200 Prozent Zoom bleibt alles bedienbar. Der technische Maßstab dafür ist WCAG 2.2 Stufe AA.

Welches Gesetz gilt 2026 für Websites von Unternehmen?

In Deutschland gilt das Barrierefreiheitsstärkungsgesetz, kurz BFSG. Es setzt den European Accessibility Act um und ist seit dem 28. Juni 2025 in Kraft. Betroffen sind unter anderem Onlineshops, Bank- und Zahlungsdienste, Telekommunikation, Personenbeförderung und E-Books. Für öffentliche Stellen gelten weiterhin das Behindertengleichstellungsgesetz und die BITV.

Welche WCAG Version ist 2026 der Maßstab?

WCAG 2.2 in der Stufe AA. Die Norm EN 301 549 verweist darauf, und über sie hängt auch das BFSG an den WCAG. Die WCAG 3.0 liegt beim W3C bisher nur als Arbeitsentwurf vor und ist nicht vor 2028 als Standard zu erwarten. Wer heute AA erfüllt, hat für alles Weitere die beste Ausgangslage.

Wird digitale Barrierefreiheit 2026 tatsächlich kontrolliert?

Ja. Die Marktüberwachungsstelle der Länder für Barrierefreiheit mit Sitz in Magdeburg ist seit Anfang 2026 in der aktiven Kontrollphase. Sie prüft systematisch und oft automatisiert und bearbeitet zusätzlich Beschwerden von Verbrauchern. Bei einem festgestellten Verstoß gibt es zuerst eine Frist zur Nachbesserung, danach folgen weitere Maßnahmen bis hin zum Bußgeld.

Was kostet digitale Barrierefreiheit 2026?

Das hängt vollständig vom Zustand des Projekts ab. Eine Seite mit sauberem Markup braucht oft nur Korrekturen an Kontrast, Fokus und Formularen. Eine gewachsene Anwendung mit div Buttons und eigenem Komponentenbaukasten ist deutlich mehr Arbeit. Wir starten deshalb mit einem kostenlosen Kennenlernen, schätzen den Aufwand ehrlich und rechnen danach minutengenau ab.

Sind Kleinstunternehmen von der Pflicht ausgenommen?

Teilweise. Ausgenommen sind Unternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz beziehungsweise Jahresbilanzsumme. Diese Ausnahme gilt nur für Dienstleistungen, nicht für Produkte. Wer eine Grenze überschreitet, fällt voll unter das Gesetz. Ob die Ausnahme im Einzelfall greift, sollte ein Fachanwalt bewerten.

Reicht ein Accessibility Overlay als Lösung?

Nein. Overlays sind Skripte, die per JavaScript nachträglich Korrekturen versuchen. Sie reparieren kaputtes Markup nicht, können mit den Hilfsmitteln der Nutzer kollidieren und erzeugen vor allem ein falsches Sicherheitsgefühl. Barrierefreiheit entsteht im HTML, im CSS und in den Komponenten. Alles andere ist Kosmetik über einem ungelösten Problem.

Wie teste ich meine Website auf Barrierefreiheit?

In zwei Schichten. Automatisiert mit axe-core, Lighthouse oder Pa11y für Kontraste, Alternativtexte und Label. Manuell mit der Tabulatortaste durch alle Kernpfade, danach mit einem Screenreader wie NVDA oder VoiceOver und einem Test bei 200 Prozent Zoom. Automatisierte Tests finden nur einen Teil der Probleme, sie ersetzen die manuelle Prüfung nicht.

Was ist der Unterschied zwischen BFSG und BITV?

Die BITV richtet sich an öffentliche Stellen und stützt sich auf das Behindertengleichstellungsgesetz. Das BFSG richtet sich an die Privatwirtschaft und setzt den European Accessibility Act um. Technisch führen beide Wege zum selben Ziel, weil beide über die Norm EN 301 549 auf die WCAG verweisen. Der Unterschied liegt im Adressaten und im Verfahren.

Braucht meine Seite eine Barrierefreiheitserklärung?

Öffentliche Stellen brauchen eine Erklärung zur Barrierefreiheit inklusive Feedback Möglichkeit. Unternehmen unter dem BFSG müssen Informationen zur Barrierefreiheit ihrer Dienstleistung bereitstellen und zugänglich machen. Fehlen diese Angaben, ist das ein formaler Mangel, über den niemand diskutieren muss. Genau deshalb ist dieser Punkt oft der erste, den eine Prüfung findet.

Leidet das Design unter Barrierefreiheit?

Nein. Kontrastwerte, sichtbarer Fokus und lesbare Schriftgrößen sind Gestaltungsparameter wie jeder andere. Sie schränken die Palette ein, nicht die Idee. Was tatsächlich verschwindet, sind graue Texte auf grauem Grund und Fokusringe, die jemand aus dem CSS entfernt hat. Beides hat auch ohne Gesetz niemandem geholfen.

Was hat Barrierefreiheit mit SEO zu tun?

Sehr viel, weil Suchmaschinen dieselben Signale lesen wie Hilfsmittel. Eine saubere Überschriftenstruktur, sprechende Linktexte, Alternativtexte und ausgezeichnete Sprache helfen Screenreadern und Crawlern gleichermaßen. Dazu kommt die Reichweite: Wer Nutzergruppen aussperrt, verliert Umsatz, unabhängig von jeder Rankingfrage.