Infos zum Barrierefreiheitsstärkungsgesetz nach WCAG 2.1 AA

Breite Inhalt
12/12
Breite Layout-Container
Ganze Breite
Spalten Inhalt
12/12

Infos zum Barrierefreiheitsstärkungsgesetz nach WCAG 2.1 AA

Inhaltsverzeichnis

Einleitung

Seit Juni 2025 gilt das neue Barrierefreiheitsstärkungsgesetz. Es herrscht viel Unsicherheit, wer davon betroffen ist und ich versuche (!) hier einen Überblick zu verschaffen, was das für Webseiten-Betreiber und -Entwickler bedeutet.

Auch Hardware muss barrierefrei sein, aber hier wollen wir uns auf Webseiten beschränken.

Der Artikel besteht aus drei Abschnitten. Der erste Schritt: Prüfung auf Pflicht obliegt den Webseiteninhaber:innen. Der zweite Schritt betrifft die Umsetzung und richtet sich an die Webdesigner und Webentwickler. Der dritte Schritt betrifft die künftige Wartung und Weiterentwicklung. 

1. Schritt: Prüfung auf Pflicht

Da die Umsetzung der Barrierefreiheit nach den Kriterien von WCAG 2.1 AA weit über das hinausgeht, was Themes für Drupal oder Wordpress u.a. per Default bieten, macht es Sinn vor der Durchführung zu prüfen, ob die Webseite verpflichtet ist, die strengen Kriterien umzusetzen.
Welche WCAG-Level sind erforderlich (A, AA, AAA)?
WCAG 2.1. AA gilt für alle privaten und öffentlichen Webseiten, die generell verpflichtet sind, das neue Barrierefreiheitsstärkungsgesetzeinzuhalten.

Unabhängig davon, ist es immer guter Stil, die Kriterien einzuhalten.
Auch weil Suchmaschinen in der Regel davon profitieren und Webseiten besser ranken, die die Barrierefreiheit einhalten. Der Google Crawler ist auch eine Art Screenreader.

Wie kann ich mich informieren, ob ich betroffen bin?
Dazu gibt es natürlich jede Menge Links, die man mit den Stichworten Barrierefreiheit + WCAG findet.
Hier nur Beispielhaft:

Selbsteinschätzung, ob Barrierefreiheit nach WCAG 2.1. AA notwendig ist:
Bitte seid euch darüber im Klaren, dass das Thema viele Grauzonen hat – und dass ich als Webentwicklerin keine Rechtsberatung geben kann oder darf.
Es gibt allerdings ein paar grobe Richtlinien zur Selbsteinschätzung

  • Webseite für öffentliche Einrichtungen:
     Pflicht besteht

  • Privater Blog ohne Verkaufabsichten:
     Keine Pflicht 

  • Firma verkauft ausschließlich an Gewerbetreibende (B2B):
     Keine Pflicht

  • Firma hat mehr als 10 Mitarbeiter oder mehr als 2 Millionen Umsatz / Jahr:
     Pflicht besteht

  • Firma hat max. 10 Mitarbeiter und macht max. 2 Millionen Umsatz / Jahr:
    a) verkauft digitale Produkte oder Dienstleistungen:
     Pflicht prüfen!

    b) betreibt einen klassischen Online-Shop:
     Pflicht besteht

    c) Webseite hat einen Spenden-Button:
     Pflicht prüfen!

    d) Webseite hat Elemente zur Anbahnung eines Verkaufs, wie z.B. Kontaktformulare:
     Pflicht prüfen!

    e) Webseite hat Elemente für digitalen Zahlungsverkehr:
     Pflicht besteht

    f) Firma bietet nur Dienstleistungen an und informiert darüber auf der Webseite:
     Keine Pflicht

Wo kann ich mich verbindlich beraten lassen?

2. Schritt: Umsetzung

Planung & Analyse

Zuständigkeiten klären (z. B. Webentwicklung, Design, Redaktion)

Relevante Unterseiten und die Anzahl der zu testenden Seiten definieren

Wieviele Seiten müssen getestet werden? Wie definiert man relevante Seiten?

Generell gilt:

  • Mindestens 5–10 repräsentative Seiten checken

  • Seiten checken, die laut Statistik besonders häufig aufgerufen werden

  • Unterschiedlichen Seitentypen getrennt testen

  • Hauptfunktionen zuerst checken

  • Besonders komplexe Seiten testen

  • Seiten testen, die für die Benutzerführung besonders wichtig sind

  • Checkoutprozess eines Online-Shops

  • Relevante Seiten / Seitentypen sind z. B.: Startseite, Hauptnavigation & Unterseiten, Kontaktformular, Login-/Registrierungsbereich, Produkt-/Detailseite (bei Shops), Interaktive Komponenten (z. B. Suche, Filter, Warenkorb, Tabs, Akkordeons, modale Dialoge), Inhalte mit multimedialen Elementen oder eingebetteten Medien Auswahl

Die Prüfung der Webseite

Die Prüfung erfolgt mit automatisierten Tools (bei öffentlichen oder sehr großen Webseiten auch kostenpflichtig) und durch manuelle Prüfung.

1. Wave

https://wave.webaim.org
https://wave.webaim.org/extension

Der Test kann online auf der Webseite erfolgen, oder mit Browser AddOns.

2. ARC Toolkit

https://www.tpgi.com/arc-platform/arc-toolkit

Als Browser AddOn

3. Lighthouse Chrome Erweiterung

https://barrierefreies.design/blog/lighthouse-100-punkte-in-performance…

4. NVDA (NonVisual Desktop Access) für Windows und VoiceOver für Mac

https://www.nvaccess.org/download/
Nicht irritieren lassen, wenn da noch steht Win 8, XP. Einfach die neueste Version installieren. 

NVDA ist ein kostenloser Open-Source-Screenreader für Windows der umfassende Screenreader-Tests erlaubt. Ein Test mit NVDA simuliert die reale Nutzung durch blinde Menschen. Er zeigt, ob eine Seite wirklich verständlich, strukturiert und vollständig nutzbar ist.

Hauptfunktionen:

  • Vollständige Sprachausgabe für Texte, Bedienelemente, Formulare

  • Kompatibel mit Webbrowsern (Firefox, Chrome, Edge)

  • Tastatursteuerung für Navigation und Interaktion

  • Entwickler-Tools zur Inspektion von ARIA-Rollen, Labels etc.

Wie läuft ein Test mit NVDA genau ab?

  • Vorbereitung
    Lade NVDA von https://www.nvaccess.org/download/ herunter und installiere es auf einem Windows-System. Starte NVDA mit dem Desktop-Icon oder der Tastenkombination Strg+Alt+N. Stelle sicher, dass du Kopfhörer oder Lautsprecher aktiviert hast, da NVDA alle Informationen per Sprachausgabe ausgibt.

  • Navigation
    Öffne im Browser (am besten Firefox, da dieser besonders gut mit NVDA funktioniert) die zu testende Webseite.
    Verwende die folgenden Tasten zur Navigation
    Tab – zum Springen zwischen interaktiven Elementen
    Shift+Tab – zurückspringen
    H – durch Überschriften navigieren
    B – zu Buttons springen
    L – zu Listen springen
    T – zu Tabellen springen
    E – zu Eingabefeldern springen
    D – zu Regionen springen (z. B. main, nav)

  • Testschritte
    Navigiere strukturiert durch die Seite. Achte darauf, was NVDA ansagt. Du solltest Überschriften, Links, Formularfelder und Buttons korrekt angesagt bekommen. Auch Fehlermeldungen, Beschriftungen und Rollen (z. B. „Navigationsbereich“, „Hauptinhalt“) müssen verständlich vorgelesen werden.

  • Formulareingaben testen
    Tab durch die Felder. Prüfe, ob NVDA die Beschriftung vorliest. Fülle Felder aus und versuche, absichtlich Fehler zu machen. Achte darauf, ob die Fehlermeldung angesagt wird und ob sie dem richtigen Feld zugeordnet ist.

  • Modale Fenster und Dialoge
    Wenn ein Popup erscheint, sollte der Fokus dort landen und das Fenster als solches erkennbar sein. Nach dem Schließen muss der Fokus zur vorherigen Stelle zurückkehren.

  • Wichtige Hinweise
    Lass während des Tests die Maus unberührt. Alles muss per Tastatur steuerbar sein. Wenn NVDA nichts ansagt oder nur „leeres“ liest, fehlt wahrscheinlich die semantische Struktur oder die Beschriftung.

5. axe core DevTool

https://www.deque.com/axe/devtools/

Das axe DevTools (von Deque Systems) gibt es als Browser-Erweiterung für Chrome und Firefox. Es basiert auf der Open-Source-Bibliothek axe-core und erkennt automatisiert Barrierefreiheitsprobleme auf Webseiten.

Hauptfunktionen:

  • Prüfung auf WCAG 2.1-Konformität

  • Markierung problematischer Elemente im DOM

  • Beschreibung von Fehlern mit Lösungsvorschlägen

  • Integration in Entwicklungs- und Testworkflows (CI/CD möglich)

  

axe DevTools
axe DevTools in den Entwicklertools

  

6. Color Contrast Analyzer (TPGi)

https://www.tpgi.com/color-contrast-checker/
Ein eigenständiges Desktop-Tool für Windows und macOS. Du kannst direkt zwei Farben vergleichen oder den Bildschirm abtasten. Die Konformität nach WCAG AA und AAA wird klar angezeigt. Es eignet sich auch für Logos, Buttons und Texte in Bildern.

8. IBM Equal Access Accessibility Checker

Das Tool liegt als Browser AddOn für Firefox, Chrome und Edge vor. Einmal integriert, scannt es in den Entwickler-Tool die Webseite und zeigt die Fehler im Quelltext an. 
Es erlaubt auch einen Test der Tastatur-Bedienbarkeit. 
Hilfe gibt es unter Github: https://github.com/IBMa/equal-access/discussions

  

IBM Equal Access Accessibility Checker im Chrome Entwicklungstool
IBM Equal Access Accessibility Checker im Chrome Entwickler-Tool

  

9. Eye-Able®

https://shop.eye-able.com

Das Tool scannt die Website, identifiziert digitale Barrieren, erstellt einen Audit-Bericht und liefert eine Barrierefreiheitserklärung. Es ist kostenpflichtig. 

10. Tanaguru

https://www.tanaguru.com/

Steht als Browser Addon zur Verfügung. 

Hier befindet sich eine Doku auf englisch: https://github.com/Tanaguru/webextension/blob/master/README_en.md

Manuelle Tests

Automatisierte Accessibility-Tools erkennen nur etwa 30% aller Barrierefreiheit-Probleme. Deshalb sollten die folgenden Tests manuell gemacht werden:

  • die Erreichbarkeit via Keyboard

  • Fokus Prüfen

  • Menüführung Prüfen

  • Screenreader-Kompatibilität in verschiedenen Browsern mit Tab (vorwärts) und Shift + Tab (rückwärts)

  • Wechsel zwischen interaktiven Elementen

  • Enter / Leertaste – Elementaktivierung für Barrierefreiheit

  • Pfeiltasten – Navigation in komplexen Komponenten (Menüs, Listen, Tabs, Radiobuttons)

  • Escape – Schließen von modalen Fenstern und Overlays

Bei den Tests sind alle betroffene Nutzergruppen zu berücksichtigen.

Relevante betroffene Nutzergruppen

  • Menschen mit Blindheit oder starker Sehbehinderung, die Inhalte mit Sprachausgabe oder Braillezeile wahrnehmen.

  • Menschen mit motorischen Einschränkungen sind z.B. Nutzer:innen mit eingeschränkter Hand- oder Armbeweglichkeit, die auf Tastaturbedienung, Spracherkennung oder Spezialgeräte angewiesen sind.

  • Menschen mit kognitiven Einschränkungen sind z.B. Personen mit Lernbehinderung, Aufmerksamkeitsstörung (z. B. ADHS), Demenz oder eingeschränkter Lesekompetenz.

  • Nutzer:innen mit Sehbehinderung (aber nicht blind) Menschen mit eingeschränktem Gesichtsfeld, Farbsehstörung oder altersbedingtem Sehverlust (z. B. Grauer Star, Makuladegeneration).

  • Nutzer:innen mit Hörbehinderung oder Gehörlosigkeit brauchen Untertitel oder Transkripte für Audioinhalte, da Ton nicht oder nur eingeschränkt wahrgenommen werden kann.

  • Nutzer:innen mit Sprach- oder Sprechbehinderung sind z.B. Menschen mit Stottern, Lähmung oder Mutismus – wichtig für barrierefreie Spracherkennung oder Alternativen zu sprachbasierter Navigation.

  • Menschen mit neurologischen Erkrankungen, z.B. Epilepsie (reagieren auf Flackern/Blinken)

  • Menschen mit Parkinson, Multiple Sklerose (können Maus oder Tastatur schwer bedienen).

  • Menschen mit psychischen Beeinträchtigungen, z.B. Angststörungen oder Depressionen – profitieren von klarer, übersichtlicher, nicht überfordernder Gestaltung.

  • Nutzer:innen mit geringen Sprachkenntnissen / funktionalem Analphabetismus. Für sie müssen Texte verständlich, visuell gestützt oder ggf. in einfacher Sprache verfügbar sein.

  • Ältere Menschen (mit altersbedingten Einschränkungen), z.B. eingeschränktes Sehvermögen, langsamere Reaktionszeiten, reduzierte Feinmotorik – profitieren von klarer Struktur und großer Schrift.

Dokumentieren der festgestellten Accessability-Probleme

Alle festgestellten Probleme werden dokumentiert und dann die ToDos an Redakteure, Entwickler, Texter ect. vergeben. 
Auch die Beschreibung von Lösungsansätzen ist Teil der Dokumentation.

Struktur & Semantik

HTML-Semantik korrekt nutzen

HTML-Semantik betrifft die korrekte Verwendung von <header>, <nav>, <main>, <section>, <footer>, <button>, <label>, usw.
Womit kann man am besten die Semantik testen?
Jeweils in Klammern wird die Ziffer angezeigt, unter der das Tool oben beschrieben ist.

  • Browser-Entwicklertools (Chrome / Firefox / Edge)
    Rechtsklick auf ein Element → „Untersuchen“
    Prüfen, ob semantische Tags wie <header>, <nav>, <main>, <button> etc. tatsächlich im DOM verwendet werden.
    Tipp: In Firefox werden Rollen wie landmark, button, form etc. gut angezeigt.

  • WAVE Accessibility Tool mit Browser-Erweiterung (1)
    Markiert Landmarken, Überschriftenstruktur und semantische Probleme.
    Zeigt Warnungen bei div-basierten Buttons ohne semantisches Markup.

  • axe DevTools (5)
    Erkannt werden u. a. nicht beschriftete Formularelemente, falsche Buttons, fehlerhafte ARIA-Nutzung.
    Hinweis bei nicht-semantischen Klickflächen wie <div onclick="...">.

  • HTML-Validator vo3C https://validato3.org/
    Meldet fehlerhafte oder unpassend geschachtelte semantische Elemente. Hilfreich zur Prüfung auf strukturelle Korrektheit (nicht auf Barrierefreiheit allein).

  • Screenreader-Test (z. B. NVDA, VoiceOver) (4)
    Damit kann man prüfen, ob die semantische Struktur sinnvoll erfasst wird: Navigiert der Screenreader durch Landmarken?
    Sind Buttons, Überschriften und Formulare erkennbar?

  • Semantische Übersicht im Firefox DevTools – "Accessibility" Tab
    Zeigt HTML-Rollen, Eigenschaften, Namensgebung und Landmarkenstruktur. Besonders gut für Rollen- und Strukturkontrolle.

  • IBM Equal Access Accessibility Checker (7)
    Findet z.B. Fehlende <label> bei <input>, aria-label oder aria-labelledby, fehlende alt-Attribute bei Bildern

Dokumentstruktur mit Überschriften

Auf der Seite darf es nur eine <h1> geben, danach logisch wiederholt Unterüberfschriften <h2>, <h3>.
Womit kann man Dokumentstruktur mit Überschriften am besten Testen?

  • WAVE Accessibility Tool als Browser-Erweiterung (Chrome, Firefox) (1)
    Zeigt eine visuelle Gliederung der Überschriften-Hierarchie
    Findet Doppelte <H1> oder übersprungene Ebenen.

  • Accessibility-Tab in Firefox DevTools
    Öffne DevTools → Tab „Barrierefreiheit“ → Struktur anzeigen.
    Zeigt die semantische Gliederung inkl. Überschriften in logischer Reihenfolge.
    Ein Filter für role="heading" ist möglich

  • Tanaguru Chrome AddOn (10)
    Leider ist es mir nicht gelungen, das Tool auf Englisch statt Französisch zu verwenden. Aber die Überschriften Hierarchie wird sehr schön angezeigt, deshalb ist es dennoch nützlich. 

 

Tanaguru Chrome AddOn zum Anzeigen der Überschriften Hierarchien
Tanaguru Chrome AddOn zum Anzeigen der Überschriften Hierarchien

 

d) Nutzen
Du erkennst sofort, ob mehrere h1-Elemente verwendet wurden, Überschriften-Ebenen ausgelassen wurden (z. B. h2 → h4 ohne h3) und die Struktur logisch und hierarchisch aufgebaut ist.
Das ist besonders wichtig für Barrierefreiheit, da Screenreader-Nutzer sich oft nur über die Überschriften-Struktur orientieren.


Navigation logisch und konsistent auf allen Seiten

Woran erkennt man eine logische und auf allen Seiten konsistente Navigation?

  • Konsistenz der Navigationsstruktur
    Die Reihenfolge und Position der Navigationslinks (z. B. im Header, Footer oder in der Sidebar) müssen auf allen Seiten gleich sein.
    Beispiel: Wenn der Link „Kontakt“ auf der Startseite an Position 5 in der Hauptnavigation ist, soll er auf Unterseiten nicht plötzlich an Position 2 auftauchen.

  • Gleichbleibende Benennung
    Links und Buttons, die dieselbe Funktion haben, sollen auch gleich heißen.
    Z. B. nicht einmal „Anmelden“ und woanders „Login“.

  • Wiedererkennbare Navigation
    Hauptnavigation, Seitennavigation, Breadcrumbs, Fußzeilenmenüs etc. sollten gleich aussehen und sich gleich verhalten.
    Das ist besonders wichtig für Menschen mit kognitiven Einschränkungen oder Orientierungsschwierigkeiten.

  • Zugängliche Navigation
    Navigation sollte als <nav>-Element gekennzeichnet sein (semantisch).
    Die Links müssen sinnvoll betitelt und tastaturbedienbar sein.
    Optional: ARIA-Rollen (z. B. role="navigation") zur weiteren Kennzeichnung

Sprunglinks zum Hauptinhalt einfügen

Im Quelltext vom Bootstrap Theme steht z.B.
<nav aria-label="Sprunglink">
<a href="#main-content" class="visually-hidden-focusable">Direkt zum Inhalt </a> </nav>

Der Bereich ist unsichtbar durch CSS. Springt der User mit TAB oder SHIFT+TAB in das Element, wird der Schriftzug sichtbar und mit Enter aktiviert, so dass der Haupt-Inhalt angesteuert wird, ohne dass erst alle Menüpunkte mit Tab angesteuert werden müssen.

Inhalte & Medien

Alternativtexte (alt) für Bilder, Icons und Logos sollen immer verwendet werden, außer sie haben ausschließlich dekorativen Charakter.

Wie finde ich am schnellsten fehlende ALT Texte?

WAVE Accessibility Tool (1)
Das WAVE-Tool zeigt auf der Seite direkt an, welche Bilder kein oder ein leeres alt-Attribut haben. Alle Bilder mit fehlendem oder fragwürdigem alt-Text werden farblich markiert. Das ist ideal für manuelle Prüfungen einzelner Seiten.

 

WAVE zeige an, welche Bilder keinen ALT-Text haben
WAVE zeige an, welche Bilder keinen ALT-Text haben bzw. hier wird angezeigt, dass ein ALT Text vorhanden ist.

 

axe DevTools Axe (8)
Die Browsererweiterung erkennt automatisch Bilder ohne alt-Text und gibt klare Fehlermeldungen aus. Die Erweiterung ist in der Entwicklerkonsole eingebunden und kann ohne Programmierkenntnisse genutzt werden. (Nur PRO Version)

JavaScript im Browser
In der Browser-Konsole kann man gezielt nach Bildern ohne alt-Attribut suchen.
Öffne die Entwicklertools (F12), gehe in den „Konsole“-Tab und gib folgendes ein:
$$("img:not([alt])").forEach(img => console.log(img.src))
Zeigt alle Bilder ohne alt-Attribut.
$$("img[alt='']").forEach(img => console.log(img.src))
Zeigt Bilder mit leerem alt-Attribut.

  

Mit diesem Konsolenbefehl kann man leere ALT-Texte bei Bildern feststellen
Mit diesem Konsolenbefehl kann man leere ALT-Texte bei Bildern feststellen

 

W3C HTML-Validator
Der Validator erkennt fehlende oder ungültige alt-Attribute. Die Seite wird hochgeladen oder per URL geprüft. Geeignet für Einzelprüfungen.

Manuelle Prüfung
Im Seitenquelltext oder DOM-Inspektor kann überprüft werden, ob zu jedem <img> ein alt-Attribut vorhanden ist. Leere alt-Attribute sind nur zulässig bei rein dekorativen Bildern, die keine inhaltliche Bedeutung haben.

Textversionen für Audios / Videos (z. B. Transkripte, Untertitel)

Wie geht das z.B. bei Youtube?

Entweder hat der Video selbst einen Transkript, oder er kann so einbunden werden:
<div aria-labelledby="video-transcript">
 <h2 id="video-transcript">Transkript des Videos</h2>
 <p>[00:00] Herzlich willkommen zum Einführungsvideo ...</p>
 <p>[00:15] In diesem Abschnitt erklären wir ...</p>
</div>
Das HTML Element <div aria-labelledby="video-transcript"> wird von Screenreadern gelesen.

Tabellen korrekt strukturiert

Tabellen sind korrekt strukturiert, wenn sie <th>, <caption> und <scope> enthalten.

Wie prüfe ich, ob Tabellen richtig strukturiert sind?

  • Direkt im HTML prüfen
    Öffne den Quellcode oder die Entwicklertools (F12 im Browser).
    Suche nach <table>.
    Prüfe, ob die Tabelle folgende Elemente enthält:
    <caption> als Beschreibung (optional, aber empfohlen)
    <th> für Spalten- oder Zeilenüberschriften mit scope="col" oder scope="row" an jedem <th>, um die Beziehung zur Datenzelle klarzustellen

  • WAVE Accessibility Tool (1)
    Dieses Tool zeigt direkt an, ob eine Tabelle semantisch korrekt strukturiert ist. Wenn th fehlt oder scope nicht gesetzt ist, gibt es eine Warnung. Auch der caption wird überprüft.

  • axe DevTools (5)
    Erkennt strukturelle Fehler bei Tabellen, z. B. Datenzellen ohne zugeordnete Header. Die Prüfung bezieht sich auf die logische Zuordnung für Screenreader.

  • Screenreader-Test (4)
    Mit einem Screenreader (z. B. NVDA) durch die Tabelle navigieren. Wenn th und scope korrekt verwendet wurden, liest der Screenreader beim Wechsel in eine Datenzelle automatisch den zugehörigen Spalten- oder Zeilenkopf mit vor.

Keine alleinige Informationsvermittlung durch Farbe

Eine automatische Prüfung ist begrenzt möglich, aber es gibt Werkzeuge, die Hinweise geben.

  • WAVE Accessibility Tool (1)
    Das Tool prüft, ob Farbinformationen ohne alternative Kennzeichnung verwendet werden. Wenn zum Beispiel in einem Formular „Pflichtfelder rot“ markiert sind, aber kein Text oder Symbol vorhanden ist, gibt es einen Hinweis: „Color is used to convey information“. Zusätzlich prüft WAVE den Farbkontrast.
      

WAVE zeigt fehlenden Farbkontrast auf einer Webseite an
WAVE zeigt fehlenden Farbkontrast auf einer Webseite an

  

  • axe DevTools (5)
    Erkennt nicht automatisch jede Farbabhängigkeit, gibt aber Warnungen in Kombination mit Kontrast und struktureller Markierung. Einige Fehler erscheinen unter dem Punkt: „Element must have sufficient color contrast“.
    Andere Fälle (z. B. Validierungsfehler nur durch Farbe) erfordern manuelle Prüfung.

  • Manuelle Sichtprüfung
    Unverzichtbar, da keine automatische Logik erfassen kann, ob Farbe die einzige Trägerin von Bedeutung ist.
    Typischer Test: Seite in Graustufen oder mit Farbsimulation ansehen. Das geht mit einem Browser-Plugin wie „Colorblindly“ (Chrome-Erweiterung).

Design & Kontrast

Wie prüfe ich ob Kontrastverhältnis Text zu Hintergrund: ausreicht?

  • WAVE Accessibility Tool (1)
    Die WAVE-Erweiterung zeigt direkt auf der Seite, ob der Farbkontrast zwischen Text und Hintergrund den Anforderungen nach WCAG 2.1 Level AA entspricht. Problematische Stellen werden markiert. Du erhältst eine genaue Fehlermeldung mit den betroffenen Farben und dem gemessenen Verhältnis.

  • axe DevTools (5)
    Dieses Tool erkennt alle Textbereiche mit unzureichendem Kontrast. Die Messung erfolgt automatisch. Die Ausgabe enthält den Kontrastwert (z. B. 3.2:1) und den Schwellenwert (z. B. 4.5:1 für normalen Text), mit konkreten CSS-Hinweisen.

  • Color Contrast Analyzer (TPGi) (6)

  • WebAIM Contrast Checker https://webaim.org/resources/contrastchecker
    Dort gibst du den Farbcode des Vorder- und Hintergrunds ein (z. B. #ffffff und #999999). Das Tool berechnet das Verhältnis und zeigt, ob es für normalen und großen Text ausreichend ist.

Welche Kontrastverhältnisse sind ausreichend?

  • Normaler Text
    mind. 4.5:1“ ist das erforderliche Kontrastverhältnis zwischen Textfarbe und Hintergrundfarbe, das nach WCAG 2.1 Level AA erfüllt sein muss. Ein Kontrastverhältnis von mindestens 4.5:1 ist erforderlich für normale Schriftgrößen nicht-fette Texte alle Fließtexte und beschriftende Inhalte, die nicht als groß gelten Beispiel:
    Schwarzer Text (#000000) auf weißem Hintergrund (#FFFFFF) hat ein Verhältnis von 21:1 – also sehr gut.
    Grauer Text (#999999) auf weiß (#FFFFFF) liegt nur bei 3:1 – unzureichend für normalen Text.
    Für großen oder fetten Text gelten gelockerte Regeln: Mindestens 3:1 für Text ab 18pt normal oder 14pt fett.
    Diese Grenzwerte sollen sicherstellen, dass Menschen mit eingeschränktem Sehvermögen oder Kontrastwahrnehmung Texte noch erkennen können. Die Prüfung kann mit Tools wie WAVE oder dem WebAIM Contrast Checker erfolgen.

  • Links
    Links müssen sich klar vom Fließtext abheben – entweder durch Unterstreichung oder durch starke visuelle Unterschiede (z. B. Fett und hoher Farbkontrast).

Wie finde ich Links, für die das nicht gilt?

  • WAVE Accessibility Tool
    WAVE prüft, ob Links farblich ausreichend vom umgebenden Text unterscheidbar sind. Wenn ein Link nur durch Farbe markiert ist und keinen zusätzlichen visuellen Hinweis wie Unterstreichung hat, wird eine Warnung angezeigt. Die Meldung lautet: „Links must be distinguishable without color alone“.

  • axe DevTools
    Das Tool erkennt ebenfalls Fälle, in denen ein Link nicht deutlich als solcher wahrnehmbar ist. Wenn der Farbunterschied zu gering ist oder die Links nicht deutlich gestaltet sind, wird das unter dem Punkt „Links must have a discernible difference“ ausgewiesen.
    Verwende eine Farbschwäche-Simulation wie die Chrome-Erweiterung „Colorblinding“. Wenn Links in diesem Modus nicht mehr als solche erkennbar sind, sind sie nicht barrierefrei gestaltet.
    Manuelle Prüfung: Lies den Text ohne Mausbedienung. Achte darauf, ob du jeden Link sofort als solchen erkennst. Wenn Links nicht unterstrichen oder farblich kaum unterscheidbar sind, liegt ein Problem vor. Auch wenn der Link nur auf Hover erkennbar wird, ist das nicht ausreichend.

Die Farbpalette sollte auf Kontrast überprüft werden, z. B. mit dem Color Contrast Checker (6)

Interaktion & Bedienbarkeit

Barrierefreie Tastaturnutzung bedeutet: Alles, was mit der Maus möglich ist, muss auch mit der Tastatur allein zugänglich und bedienbar sein – ohne Umwege, ohne Hürden und mit sichtbarem Fokus.

Wie stelle ich das sicher?

  • Tab-Test
    Öffne die Webseite im Browser und verwende ausschließlich die Tastatur.
    Nutze Tab, Shift+Tab, Enter und Leertaste.
    Gehe alle interaktiven Elemente durch.
    Achte darauf, ob du jedes Bedienelement erreichen und aktivieren kannst

  • Fokus sichtbar
    Stelle sicher, dass beim Ansteuern per Tab ein sichtbarer Fokusrahmen erscheint. Wenn nicht, könnte der Fokus durch CSS wie outline: none unterdrückt sein – das ist nicht barrierefrei.

  • Keine Tastaturfalle
    Achte darauf, dass du aus Modalfenstern, Dropdowns oder eingebetteten Komponenten wieder herauskommst. Wenn du mit Tab „stecken bleibst“, liegt eine sogenannte Tastaturfalle vor, was gegen WCAG 2.1.2 verstößt.

  • Interaktive Komponenten prüfen
    Teste auch komplexe Komponenten wie Slider, Akkordeons, Menüs, Tabs oder Filter. Diese müssen mit den Pfeiltasten, Enter und ggf. Escape steuerbar sein. Wenn du ein Element nur mit der Maus bedienen kannst, muss es angepasst werden.

  • Tool-Einsatz
    Mit axe DevTools oder der Tab-Taste kannst Du die Tab-Reihenfolge und Erreichbarkeit testen. Prüfe auch, ob Elemente fokussierbar sind.

Sichtbarer Tastaturfokus

Du findest fehlenden Tastaturfokus (z. B. bei Buttons, Links, Formularen) am zuverlässigsten durch Tab-Navigation und Sichtprüfung. Jede Funktion, die nicht mit Tab erreichbar und per Enter oder Leertaste auslösbar ist, verstößt gegen WCAG 2.1.1.

  • Manueller Tab-Test
    Drücke auf der Webseite die Tab-Taste.
    Bewege dich Schritt für Schritt durch alle interaktiven Elemente wie Links, Buttons und Formularfelder. Wenn du ein Element erreichst, aber visuell keine Veränderung siehst, fehlt ein sichtbarer Fokus. Du solltest immer einen Rahmen, Hintergrundwechsel oder eine andere klare Markierung sehen.

  • CSS-Inspektion
    Öffne die Entwicklertools (F12), wähle ein Element und prüfe, ob es eine sichtbare Fokus-Stilregel hat.
    Beispiel: button:focus { outline: 2px solid blue; }
    Wenn stattdessen outline: none gesetzt ist, wird der Fokus unterdrückt.

  • axe DevTools (5)
    Dieses Tool erkennt fehlenden Tastaturfokus nicht direkt, aber es meldet Elemente, die nicht erreichbar sind oder unzureichend definiert wurden. Damit findest du oft die Ursache für Fokusprobleme.

  • Firefox Accessibility-Tab
    Im Reiter „Barrierefreiheit“ siehst du den aktuellen Fokuspunkt. Du kannst prüfen, ob ein Element fokussiert ist, auch wenn es visuell nicht erkennbar ist.

  • IBM Equal Access Accessibility Checker (8)
    Das Tool zeigt im Entwicklungstool von Chrome sehr schön die Tab-Reihenfolge und die Focusfarbe an. 

 

der IBM Equal Access Accessibility Checker zeigt die Tab-Reihenfolge an
Der IBM Equal Access Accessibility Checker zeigt die Tab-Reihenfolge an

 

Tastaturfallen vermeiden

Wie finde ich Tastaturfallen?

  • Tab-Test mit Escape-Versuch
    Gehe mit der Tab-Taste durch die Seite.
    Öffne ein modales Fenster, Dropdown, Akkordeon oder Overlay.
    Achte darauf, ob du mit Tab weiter kommst oder „stecken bleibst“.
    Versuche mit Shift+Tab rückwärts zu navigieren und mit Escape zu schließen. Wenn du nur noch innerhalb eines Elements tabben kannst und nicht wieder zum restlichen Seiteninhalt zurückkehrst, liegt eine Tastaturfalle vor.

  • Modale Dialoge prüfen
    Wenn ein Dialog geöffnet wird, sollte der Fokus automatisch auf ein sinnvolles Element im Dialog springen (z. B. Überschrift oder Schließen-Button).
    Beim Schließen des Dialogs muss der Fokus dorthin zurückkehren, wo er vorher war. Bleibt er im Nichts oder springt an den Seitenanfang, ist das ein Fehler.

  • Interaktive Komponenten untersuchen
    Tastaturfallen entstehen oft bei schlecht programmierten Komponenten wie benutzerdefinierten Dropdowns, Carousels, eingebetteten Formularen oder eingebetteten iFrames.
    Prüfe, ob du den Fokus darin verlieren kannst oder nicht mehr rauskommst. Browser-Werkzeuge, wie der Firefox-„Barrierefreiheit“-Tab oder über die „Inspect“-Funktion kannst du den aktuellen Fokuspfad sehen. Dort erkennst du, ob der Fokus in einem Bereich hängen bleibt oder korrekt weiterläuft.

  • Test mit Screenreader oder sichtbarem Fokusrahmen (4)
    Aktiviere eine Fokusanzeige (z. B. mit Firefox oder einem CSS-Hilfsstil). Wenn der Fokus innerhalb eines Elements bleibt und nie zur Seite zurückkehrt, ist die Navigation unterbrochen – das ist eine Tastaturfalle.

Keine Funktionen darf nur mit Maus oder Touch zugänglich sein

  • Tastaturtest
    Navigiere die komplette Seite ausschließlich mit der Tastatur (Tab, Shift+Tab, Enter, Leertaste, Pfeiltasten).
    Achte darauf, ob du alle interaktiven Elemente erreichen und aktivieren kannst. Wenn ein Button, Link, Menüpunkt oder eine Funktion nur bei Hover mit der Maus erscheint, aber per Tastatur nicht erreichbar ist, liegt ein Problem vor.

  • Hover-basierte Inhalte
    Teste Tooltips, Dropdown-Menüs, Bild-Overlays oder Schnellaktionen. Wenn sie nur sichtbar oder nutzbar sind, wenn man mit der Maus darüberfährt, aber nicht bei Tastaturfokus erscheinen, sind sie nicht barrierefrei.

  • Unsemantische Klickflächen
    Achte auf Links oder Buttons, die mit div, span oder i realisiert wurden und nur bei onclick mit der Maus reagieren. Solche Elemente sind für Tastaturnutzer nicht bedienbar, es sei denn, sie wurden korrekt mit tabindex und Tastaturereignissen ausgestattet.

  • axe DevTools
    Das Tool zeigt keine dedizierte Fehlermeldung für „nur Mausbedienung“, aber es meldet fehlende Tastaturbedienbarkeit, fehlende Rollen und falsche HTML-Struktur – häufige Ursachen für solche Fehler.

  • Screenreader-Test (4)
    Ein Element, das nicht per Tastatur erreicht werden kann, ist auch für Screenreader-Nutzer nicht nutzbar. Wenn du mit einem Screenreader ein Element nicht findest oder nicht auslösen kannst, fehlt die Tastaturunterstützung.

Mobile Accessibility

  • Mindestgröße von Touch-Zielen (z. B. 44x44 px)

  • Bedienbarkeit per Screenreader und Sprachsteuerung auf Mobilgeräten

  • Prüfung per Device-Emulation im Browser oder echten Geräten

PDFs und eingebettete Dokumente

PDFs und eingebettete Dokumente (z. B. Flyer oder Formulare) müssen ebenfalls barrierefrei sein.

  • Verwendung von getaggten PDFs

Formulare & Eingaben

Interaktiven Formularelemente

Alle interaktiven Formularelemente benötigen Label.
Wie finde ich solche ohne Label?

  • Browser-Konsole
    Öffne die Entwicklertools im Browser (F12), wechsle in den „Konsole“-Tab und gib folgenden Befehl ein:
    $$('input:not([type="hidden"]):not([id]), input:not([type="hidden"]):not([aria-label]):not([aria-labelledby])')
    Dieser Befehl listet Eingabefelder, die weder ein id noch ein ARIA-Label besitzen und damit wahrscheinlich nicht korrekt beschriftet sind.
    Für <select>, <textarea> oder <button> kannst du entsprechende Varianten verwenden.

  • WAVE Accessibility Tool
    WAVE zeigt bei fehlenden oder nicht verknüpften Labels eine Warnung an. Die Meldung lautet zum Beispiel „Missing form label“ oder „Form element has no label“. Besonders hilfreich für schnelle visuelle Prüfung.

  • axe DevTools
    Das Tool erkennt Eingabefelder ohne Label und meldet diese unter „Form elements must have labels“. Es gibt Hinweise, ob ein Label vorhanden, aber nicht richtig verknüpft ist.

  • Screenreader-Test (4)
    Wenn du mit einem Screenreader wie NVDA durch die Formulare gehst und ein Eingabefeld wird nicht angekündigt oder bleibt ohne Beschreibung, fehlt ein korrektes Label.

  • HTML-Inspektion
    Suche gezielt nach <input>, <select>, <textarea> und prüfe, ob jeweils ein <label for="..."> vorhanden ist oder ob aria-label oder aria-labelledby korrekt gesetzt sind. Auch visuell: Ist im UI eine Beschriftung für das Feld sichtbar?
    Wenn <label for="..."> gesetzt ist, dann sollte nicht auch noch aria-label gesetzt sein, damit der Screenreader nicht doppelt vorliest.

Fehlermeldungen

Wie stelle ich sicher, dass Fehlermeldungen verständlich und deutlich sichtbar sind?

  • Visuelle Sichtprüfung
    Löse bewusst typische Fehler im Formular aus, zum Beispiel durch das Absenden ohne Eingabe oder mit falschem Format. Achte darauf, ob eine Fehlermeldung erscheint, wo sie erscheint und ob sie verständlich formuliert ist. Sie sollte in direkter Nähe zum betroffenen Feld stehen oder eindeutig darauf verweisen.

  • Technische Prüfung
    Untersuche mit den Entwicklertools, ob die Fehlermeldung programmatisch mit dem Feld verknüpft ist. Die gängige Methode ist das Attribut aria-describedby, das auf die ID des Fehlerelements verweist.
    Beispiel: <input id="email" aria-describedby="email-error"> <span id="email-error">Bitte geben Sie eine gültige E-Mail-Adresse ein</span>

  • Kontraste und Sichtbarkeit (6)
    Die Fehlermeldung muss kontrastreich zum Hintergrund dargestellt werden. Nutze ein Kontrast-Tool, um sicherzustellen, dass das Verhältnis mindestens 4.5:1 beträgt. Die Meldung darf nicht nur rot sein – sie braucht eine Textaussage.

  • Screenreader-Test (4)
    Gib absichtlich falsche Eingaben ein und prüfe mit einem Screenreader (z. B. NVDA), ob die Fehlermeldung beim Fokus des Eingabefeldes vorgelesen wird.
    Nur dann ist sie barrierefrei eingebunden.

  • axe DevTools (5)
    Das Tool meldet, wenn Eingabefelder bei Fehlern keine ausreichende Rückmeldung bieten. Typische Hinweise sind: „Form field has no associated error message“ oder „ARIA attributes are not correctly associated“.

Pflichtfelder gekennzeichnet

Verwende eine übliche Kennzeichnung von Pflichtfeldern, z.B. durch einen roten Stern

Sprache, Lesbarkeit & Verständlichkeit

Seiten-Sprache korrekt definieren

Sorge für Angabe der Sprache im <html lang="de"> - Tag.

Verständliche Sprache, Vermeidung von Fachbegriffen oder Erklärung bei Bedarf

Welches Tool testet hierauf?

  • Textanalyse-Tools
    wie der „TextLab“ oder der „Hurraki Checker“ analysieren Texte auf Lesbarkeit. Sie bewerten zum Beispiel Satzlänge, Wortschwierigkeit und Fremdwörter. Du bekommst Hinweise auf zu lange Sätze oder unübliche Begriffe. Auch der Flesch-Wert wird oft berechnet, um die Lesbarkeit einzuschätzen.

  • Leichte-Sprache-Prüfer
    Webseiten wie www.leichtesprache.org oder tools wie „Readable“ geben Feedback zur sprachlichen Zugänglichkeit, richten sich aber vorrangig an redaktionelle Prozesse. Sie erkennen keine fachlichen Zusammenhänge, können aber schwierige Formulierungen markieren.

  • WAVE (1) und axe (5)
    Diese Tools prüfen keine Sprachqualität. Sie analysieren nur technische Barrierefreiheit. Du bekommst keine Hinweise auf Fachsprache oder missverständliche Begriffe.

  • Manuelle Prüfung
    Lies den Text mit dem Ziel, ihn jemandem mit geringer Lesekompetenz zu erklären. Wenn du dabei Sätze umformulieren oder Begriffe erläutern musst, sind sie vermutlich zu kompliziert. Nutze auch Rückmeldungen von echten Nutzern, um Verständlichkeit zu testen.

Keine blinkenden / flackernden Inhalte

Solche Inhalte sind für Menschen mit eingeschränkter Sehfähigkeit, Epileptiker*innen oder Menschen mit psychischen Erkrankungen ungeeignet oder gar gefährlich.

Welches Tool testet hierauf?

  • axe DevTools (5)
    axe erkennt animierte Inhalte, insbesondere wenn blinkende Elemente mit CSS oder JavaScript erzeugt wurden. Es meldet z.B. die Nutzung des HTML-Tags <blink> oder CSS-Eigenschaften wie animation, transition, setInterval. Es prüft aber nicht automatisch die Blinkfrequenz in Hertz.

  • WAVE Accessibility Tool
    WAVE meldet das Vorhandensein von <blink> oder <marquee>. Es erkennt jedoch kein flackerndes Video oder dynamisches Bildmaterial. Du bekommst also Hinweise auf veraltete oder problematische HTML-Technik, aber keine Prüfung von visuellen Effekten.

  • Lighthouse (Chrome)
    Google Lighthouse analysiert, ob bewegte Inhalte gestoppt oder pausiert werden können, meldet aber keine spezifischen Frequenzen oder epilepsiegefährdendes Flackern.

  • Manuelle Prüfung
    Blinken oder Flackern mit mehr als drei Lichtwechseln pro Sekunde (3 Hz) kann Menschen mit photosensibler Epilepsie gefährden. Solche Effekte sind mit Tools kaum automatisiert erkennbar. Hier hilft nur ein Sichttest: Prüfe, ob sich Banner, Werbeflächen, Videos oder Slides sehr schnell oder unkontrolliert bewegen.

Fazit:
Tools wie axe oder WAVE geben technische Hinweise, erkennen aber keine gefährliche Frequenz. Wenn du sicherstellen willst, dass Inhalte nicht flackern, musst du manuell testen und auf schnelle, grelle Animationen verzichten. WCAG 2.3.1 fordert, dass Inhalte nicht öfter als dreimal pro Sekunde blinken, außer die Blinkfläche ist sehr klein.

Technische Robustheit

Valider HTML-Code (z. B. über den W3C Validator)

Welches Tool testet hierauf?

  • W3C Markup Validation Service https://validator.w3.org
    Offizieller Validator des World Wide Web Consortium (W3C). Du kannst eine URL, HTML-Datei oder Quelltext eingeben. Er meldet alle strukturellen HTML-Fehler wie vergessene Tags, ungültige Attribute, fehlerhafte Schachtelung.

  • Nu Html Checker https://validator.nu
    Alternative zum W3C-Tool, nutzt denselben technischen Hintergrund. Erkennt auch HTML5-spezifische Fehler. Besonders nützlich für einzelne Code-Snippets oder automatisierte Prüfungen per API.

  • Browser-Entwicklertools
    In Firefox oder Chrome kannst du beim Untersuchen von Elementen strukturelle Fehler erkennen. Diese Tools sind nicht primär für HTML-Validierung gedacht, helfen aber bei offensichtlichen Problemen wie ungeschlossenen Tags oder fehlenden Attributen.

  • IDE-Plugins und Linter Editoren
    wie Visual Studio Code, WebStorm oder Sublime Text bieten HTML-Validatoren als Erweiterungen. Tools wie HTMLHint oder eslint-plugin-html prüfen HTML-Dateien während der Entwicklung und geben direktes Feedback.

  • axe DevTools (5)
    axe prüft nicht direkt auf HTML-Konformität, aber auf typische Fehler, die mit fehlerhaftem HTML zusammenhängen – zum Beispiel falsche Struktur, nicht schließende Tags oder fehlende Rollen.

Fazit :
Der W3C Validator ist das zuverlässigste Werkzeug zur strukturellen HTML-Prüfung.

Kompatibilität mit Screenreadern getestet (z. B. NVDA, VoiceOver)

Wie funktioniert das genau?

  • Lade NVDA von https://www.nvaccess.org/download/ herunter und installiere es auf einem Windows-System.
  • Starte NVDA mit dem Desktop-Icon oder der Tastenkombination Strg+Alt+N.
  • Stelle sicher, dass du Kopfhörer oder Lautsprecher aktiviert hast, da NVDA alle Informationen per Sprachausgabe ausgibt.
  • Öffne im Browser (am besten Firefox, da dieser besonders gut mit NVDA funktioniert) die zu testende Webseite.
  • Verwende die folgenden Tasten zur Navigation

    • Tab – zum Springen zwischen interaktiven Elementen

    • Shift+Tab – zurückspringen

    • H – durch Überschriften navigieren

    • B – zu Buttons springen

    • L – zu Listen springen

    • T – zu Tabellen springen

    • E – zu Eingabefeldern springen

    • D – zu Regionen springen (z. B. main, nav)

Testschritte:

  • Navigiere strukturiert durch die Seite.

  • Achte darauf, was NVDA ansagt. Du solltest Überschriften, Links, Formularfelder und Buttons korrekt angesagt bekommen. Auch Fehlermeldungen, Beschriftungen und Rollen (z. B. „Navigationsbereich“, „Hauptinhalt“) müssen verständlich vorgelesen werden.

Formulareingaben testen

  • Tab durch die Felder.

  • Prüfe, ob NVDA die Beschriftung vorliest.

  • Fülle Felder aus und versuche, absichtlich Fehler zu machen. Achte darauf, ob die Fehlermeldung angesagt wird und ob sie dem richtigen Feld zugeordnet ist.

Modale Fenster und Dialoge
Wenn ein Popup erscheint, sollte der Fokus dort landen und das Fenster als solches erkennbar sein. Nach dem Schließen muss der Fokus zur vorherigen Stelle zurückkehren. Wichtige Hinweise Lass während des Tests die Maus unberührt. Alles muss per Tastatur steuerbar sein. Wenn NVDA nichts ansagt oder nur „leeres“ liest, fehlt wahrscheinlich die semantische Struktur oder die Beschriftung.

ARIA-Rollen sinnvoll verwendet, wo nötig – nicht als Ersatz für sauberes HTML

Was bedeutet das genau?
ARIA steht für Accessible Rich Internet Applications.
ARIA-Rollen, -Attribute und -Eigenschaften ergänzen HTML, um interaktive oder dynamische Inhalte für Screenreader zugänglich zu machen.
Sinnvoll verwendet heißt, ARIA soll nur dort eingesetzt werden, wo semantisches HTML nicht ausreicht. Wenn ein Element wie ein Button, ein Link oder eine Überschrift bereits mit nativem HTML darstellbar ist, ist ARIA nicht nötig und sogar riskant, weil es leicht falsch angewendet wird.

Beispiel korrekt:

  • Ein benutzerdefiniertes Dropdown-Menü aus div-Elementen bekommt role="listbox" und aria-selected, weil kein echtes <select> verwendet wird.

Beispiel nicht korrekt:

  • Ein <div> mit role="button" wird verwendet, obwohl ein <button> möglich gewesen wäre.

  • Ein <h2>-Element wird ersetzt durch ein <span role="heading" aria-level="2">, obwohl ein echtes <h2> die bessere Wahl ist.

Risiko bei Missbrauch:
Wenn ARIA falsch verwendet wird oder die zugehörigen Tastaturfunktionen fehlen, ist das Ergebnis für Screenreader-Nutzer verwirrend oder unbrauchbar. Zudem überlagern ARIA-Rollen die native Semantik und können diese zerstören.

Fazit:
Immer zuerst korrektes HTML verwenden. Nur wenn die gewünschte Interaktion oder Struktur mit HTML allein nicht darstellbar ist, sollte ARIA ergänzend eingesetzt werden.

JavaScript prüfen

Diese Funktionen müssen ohne JavaScript, oder mit barrierefreiem Fallback funktionieren:

  • Inhalte laden
  • Dropdowns
  • Akkordeons
  • Tabs
  • Modals

3. Schritt: Barrierefreiheitserklärung bereitstellen

Diese soll auch einen Feedback-Mechanismus enthalten.

Weitere Infos: 

Hier gibt es eine Mustervorlage:
https://bitvtest.de/files/bitv-erkl%C3%A4rung-barrierefreiheit-vorlage-2022-03-17.html
Diese enthält:

  • Stand der Barrierefreiheit (z. B. „teilweise barrierefrei“)

  • Datum der letzten Prüfung

  • Kontaktstelle für Feedback

  • Hinweis zur Durchsetzungsstelle

  • Erklärung zur Erstellungsmethode („Selbstbewertung“ / „extern geprüft“ etc.)

4. Schritt: Wartung & Weiterentwicklung

  • Redaktionssystem & Content-Workflows auf Barrierefreiheit abstimmen

  • Redakteure & Entwickler regelmäßig schulen

  • regelmäßige Audits der Barrierefreiheit (z. B. jährlich)

  • Monitoring mit automatisierten Checks im Deployment-Prozess (z. B. GitHub Actions mit axe-core )