top of page

Redaktion

—

15. Mai 2026

Barrierefreiheit website testen: Der praktische Leitfaden 2026

Wie Sie Ihre Website auf Barrierefreiheit testen

Introduction

This Privacy Notice aims to clearly and transparently explain which personal data we collect when you visit our website, why we collect it, how we use it, and what Your rights are.

We process your personal data in accordance with Regulation (EU) 2016/679 (GDPR) and applicable national data protection laws. We are committed to ensuring that all processing activities are carried out in accordance with the principles of lawfulness, fairness, transparency, data minimization, integrity, and confidentiality.

Specifically, in this notice you will find information about:
 

  • which data we collect about you and for what purposes;

  • the legal bases on which we process such data;

  • who we may share your data with;

  • how long we retain your data;

  • your rights and how to exercise them.
     

While we sometimes need Your data for example, to respond to your requests or improve our website), we do so with respect, care and only when truly necessary.

Our Privacy Promises
 

  • We deeply value your privacy, and for this reason, we guarantee that:

  • We treat your data as if it were our own.

  • We use your data only for the purposes outlined in this notice.

  • We retain your data only for as long as strictly necessary.

  • We do not share your data with third parties without a valid legal basis or your explicit consent.
     

1. Who Processes Your Personal Data

The Data Controller — that is, the entity that determines the purposes and means of the processing of Your personal data — is AccessiWay S.a.S., with registered office at 7 Rue du Général Henrion Bertier, 92200 Neuilly-sur-Sein registered with the Nanterre Trade and Companies Register under number 914 022 595.

AccessiWay is part of the team.blue group and, in certain cases, acts as joint controller together with team.blue NV, with registered office at Skaldenstraat 121, 9042 Ghent, Belgium. In this context, Your personal data may be shared within the group for statistical, administrative, operational, and service improvement purposes.

AccessiWay and team.blue have defined their respective roles and responsibilities under a joint controllership agreement pursuant to Article 26 of the GDPR, ensuring full compliance with data protection regulations.

For more information regarding joint controllership or to exercise Your rights, you may contact AccessiWay via email at the following email addresses:

📧 legal.fr@accessiway.com or info@accessiway.com.

2. Who This Privacy Notice Applies To

This notice applies to:
 

  • users who browse the website www.accessiway.com,

  • individuals who contact us through the form available on the website or via email;

  • users who interact with tools we have implemented (e.g. widgets, cookies);

  • individuals who, through the website or other channels, access external platforms or third-party entities through which they may submit a job application (e.g. recruiting portals or employment agencies).

  • In such cases, the privacy notices of the third parties involved — independent from AccessiWay — also apply.
     

3. What Data We Process

To manage your interaction with our website, we may process the following categories of personal data:
 

  • Identification and contact details such as name, surname, company, job title, email address, and phone number.

  • These data may be partially processed through our customer relationship management (CRM) system.

  • Data relating to your interaction with our services such as information collected via the website or through Hubspot, such as communication history, preferences, requests, and commercial or technical notes.

  • Technical data such as IP address, device type, operating system, browser, access times, and other data automatically recorded by our systems or servers.

  • Browsing data and preferences such as collected via cookies or similar technologies, in accordance with the choices expressed through the cookie consent banner.

  • Application data such as personal information included in your CV or other documents submitted through third-party platforms (e.g. professional experience, education, contact details).

  • These data are processed by AccessiWay only after being transmitted by the third party, which remains autonomous in the initial processing.
     

4. Purposes and Legal Basis of Processing

We process Your personal data in compliance with Regulation (EU) 2016/679 (GDPR) and applicable national data protection laws. Your data may be processed for the following purposes:
 

  • Technical operation of the website
     

We process technical data, using technical cookies and similar tools, to allow You to access the site, view it correctly, and ensure it functions properly (e.g. browsing, content loading, storing preferences).

📌Legal basis: this processing is necessary to provide a service requested by the user, pursuant to Article 6(1)(b) of the GDPR. Your consent is not required for these cookies.
 

  • Handling contact or support requests
     

When you send us a request — via the contact form or by email — we process your data to respond and provide the information requested.

📌 Legal basis: this processing is necessary to take steps at your request prior to entering into a contract, pursuant to Article 6(1)(b) of the GDPR.
 

  • Compliance with legal obligations
     

In certain cases, we may need to process your data to comply with legal obligations, such as tax, accounting, or IT security requirements.

📌 Legal basis: this processing is based on compliance with a legal obligation, pursuant to Article 6(1)(c) of the GDPR.

  • Statistical analysis and website improvement
     

We use analytical tools (e.g. analytical cookies) to collect aggregated data in order to understand how the website is used and to improve its content and functionality.

📌 Legal basis: we process this data only with your freely given and specific consent, pursuant to Article 6(1)(a) of the GDPR.

  • Marketing and Profiling
     

If you authorize us to do so, we may use your data to send you promotional communications or provide personalized content (e.g. through profiling cookies).

📌 Legal basis: this processing is carried out only with your explicit consent, pursuant to Article 6(1)(a) of the GDPR. You may withdraw your consent at any time without affecting the lawfulness of processing based on consent before its withdrawal.
 

  • Management of job applications through third parties
     

We may receive job applications via third-party platforms (e.g. job portals) or through recruitment agencies. In such cases, we process the submitted data to assess your suitability for the proposed role.

📌 Legal basis: this processing is necessary to take steps at your request prior to entering into a contract, pursuant to Article 6(1)(b) of the GDPR.

Note: the privacy policies of the third-party platforms or agencies involved also apply, independently of AccessiWay.

5. Cookies and Tracking Tools

This website uses a cookie management system provided by iubenda, which allows you to:
 

  • view a full and transparent list of the cookies in use;

  • modify or withdraw your consent at any time;

  • access the complete Cookie Policy, integrated in the cookie widget.
     

You can manage your preferences by clicking on the cookie widget icon located at the bottom left corner of every page on the site.

Technical cookies are necessary and therefore enabled by default. Other non-essential cookies (analytical, profiling) are only enabled with your consent.

For more information, please refer to the full Cookie Policy accessible from the cookie widget.

6. Use of accessWidget

This website integrates accessWidget, an automated accessibility tool developed by accessiBe Ltd. and distributed by AccessiWay. The widget allows users to personalize their browsing experience based on their needs.

When the user activates the widget, their IP address is technically transmitted, but:
 

  • it is not stored, tracked, or associated with identifiable individuals;

  • it is anonymized via a proxy located in the European Union;

  • it is not used for profiling or marketing purposes.
     

📌 Legal basis: provision of a service requested by the user (Article 6(1)(b) of the GDPR).

7. Data Security

We adopt appropriate technical and organizational measures to ensure the security, integrity, and confidentiality of the personal data we process. These measures are designed to prevent unauthorized access, loss, disclosure, or alteration of your data. In particular, we implement:
 

  • secure connections via HTTPS (SSL/TLS);

  • authentication systems and access control;

  • access limitation and internal access tracking mechanisms;

  • regular audits and verification procedures;

  • continuous updates to systems and security measures according to the level of risk.
     

8. Data Retention

Your personal data is stored only for the time strictly necessary to achieve the purposes for which it was collected. Specifically:
 

  • Contact data: up to 10 years if relevant for contractual or legal purposes;

  • Technical and browsing data: according to what is outlined in the Cookie Policy;

  • Marketing data: until consent is withdrawn.
     

9. Your Rights (Data Subject Rights)

As a data subject, you may exercise the rights provided under Articles 15–22 of the GDPR at any time. In particular, you have the right to:
 

  • Obtain confirmation as to whether or not your personal data is being processed and access such data (right of access);

  • Request the rectification of inaccurate personal data or the completion of incomplete data (right to rectification);

  • Request the erasure of your data, if the conditions set out in the GDPR are met (right to erasure);

  • Obtain restriction of processing where applicable (right to restriction);

  • Object to the processing of your data, in whole or in part, under certain circumstances (right to object);

  • Receive your data in a structured, commonly used, and machine-readable format, and, where technically feasible, have it transmitted directly to another controller (right to data portability);

  • Withdraw your consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal.
     

📧 You can exercise Your rights at any time by contacting us at: legal.fr@accessiway.com.

🔗 If you are located in France and believe that the processing of your personal data violates applicable law, you have the right to lodge a complaint with the French Data Protection Authority (Commission Nationale de l’Informatique et des Libertés – CNIL) via the website: www.cnil.fr.

*If you have difficulty accessing our form, please feel free to contact us. Send an e-mail to info@accessiway.com

Aktualisiert am: 07/07/2026

Auf einen Blick: Eine vollständige Barrierefreiheits-Prüfung kombiniert automatisierte Scans, manuelle Tests und echte Nutzer:innen. Hier sind die acht Schritte, die du selbst gehen kannst.

In diesem Artikel

  • So testest du deine Website auf Barrierefreiheit Schritt für Schritt

  • Barrierefreiheit Website prüfen: automatisiert, manuell oder mit echten Nutzer:innen

  • Kostenlose Tools zum Testen der Website-Barrierefreiheit

  • Wie du deine Website auch ohne Tools auf Barrierefreiheit prüfst

  • Die häufigsten Barrieren auf jeder Website

  • Was bei der Barrierefreiheits-Prüfung wirklich zählt

  • Welche Standards dein Barrierefreiheits-Test abdecken muss

  • Der Accessibility Tree und warum KI-Agenten ihn lesen

  • Ergebnisse bewerten, dokumentieren und priorisieren

  • Häufig gestellte Fragen zum Barrierefreiheits-Test

Für rund 87 Millionen Menschen mit Behinderungen in Europa entscheiden solche Tests jeden Tag, ob eine Website nutzbar ist.

So testest du deine Website auf Barrierefreiheit Schritt für Schritt

Wir nutzen mit unseren Kund:innen einen Acht-Schritte-Rahmen, der die WCAG-Prinzipien abdeckt und auch in kleineren Teams umsetzbar ist. Du brauchst kein Budget, nur Zeit und Ehrlichkeit.

Schritt 1: Automatisierten Scan starten

Gib deine URL in einen kostenlosen Checker ein (axe DevTools, WAVE oder Lighthouse). Wiederhole den Scan auf mindestens fünf repräsentativen Seitentypen:

  • Startseite

  • Kategorieseite

  • Produktseite

  • Formular

  • Checkout

Wiederkehrende Komponenten wie Header, Footer oder Cookie-Banner ziehen Fehler durch die ganze Website, deshalb sind sie besonders wichtig.

Schritt 2: Nur mit der Tastatur navigieren

Leg die Maus beiseite und prüfe:

  • Erreichst du mit Tab alle interaktiven Elemente?

  • Ist der Fokus jederzeit sichtbar?

  • Funktionieren Dropdown-Menüs, Modale und Cookie-Banner?

  • Kommst du aus jedem Modal mit Esc heraus?

Deckt WCAG 2.1.1 (Tastatur) und 2.4.7 (Sichtbarer Fokus) ab.

Schritt 3: Mit einem Screenreader testen

Aktiviere NVDA (Windows), VoiceOver (Mac, iOS) oder TalkBack (Android), dann Bildschirm aus oder Augen zu. Hör zu:

  • Werden Bilder mit sinnvollen Alt-Texten beschrieben oder hörst du nur „Bild, Bild, Bild"?

  • Werden Buttons mit klarer Funktion angekündigt?

  • Ergibt die Seitenstruktur für jemanden Sinn, der nichts sieht?

Schritt 4: Farbkontraste prüfen

Der WebAIM Contrast Checker liefert in Sekunden eine Antwort. Achte zusätzlich darauf:

  • Werden Fehlermeldungen ausschließlich über Farbe markiert? Ergänze Symbol oder Text.

  • Sind Pflichtfeld-Hinweise nur farbig? Ergänze ein Sternchen oder Wort.

  • Sind aktive Tabs oder Buttons nur farbig markiert? Ergänze ein anderes visuelles Signal.

WCAG 1.4.1 verlangt, dass Informationen nicht allein durch Farbe vermittelt werden.

Schritt 5: Formulare und interaktive Elemente testen

Formulare entscheiden über Käufe, Anmeldungen und Buchungen. Checkliste:

  • Alle Felder mit sichtbaren Labels beschriftet, nicht nur Placeholdern.

  • Fehlermeldungen klar formuliert und programmatisch mit dem Feld verknüpft.

  • Pflichtfelder, Auswahllisten und Checkboxen vollständig per Tastatur und Screenreader bedienbar.

  • Jedes Icon trägt einen sinnvollen Alt-Text oder ein leeres alt-Attribut für dekorative Elemente.

Schritt 6: Multimedia und PDFs nicht vergessen

  • Videos: Untertitel vorhanden? Wo nötig auch Audiodeskription?

  • PDFs: Liest dein Screenreader sie in der richtigen Reihenfolge? Erkennt er Überschriften, Tabellen und Listen?

  • Eingescannte Dokumente: OCR vorhanden oder hört der Screenreader nur Stille?

  • Für PDFs eignet sich der kostenlose PDF Accessibility Checker (PAC), der automatisch gegen PDF/UA und WCAG prüft. Word- und PowerPoint-Dateien lassen sich zusätzlich mit der eingebauten Barrierefreiheitsprüfung von Microsoft Office kontrollieren.


    Mehr dazu in unserem Beitrag zur Barrierefreiheit von digitalen Dokumenten.

Schritt 7: Bei 200 Prozent Zoom prüfen

Drücke Strg/Cmd plus die Plus-Taste, bis die Seite auf 200 Prozent vergrößert ist. Achte auf:

  • Bleibt der Inhalt lesbar?

  • Gehen Texte verloren oder überlappen sich Elemente?

  • Funktioniert die Navigation weiter?

WCAG 1.4.4 verlangt Lesbarkeit ohne Funktionsverlust bis 200 Prozent.

Schritt 8: Echte Nutzer:innen einbeziehen

Werkzeuge finden Fehler, Menschen finden Reibung. Drei bis fünf Tester:innen mit unterschiedlichen Behinderungen reichen für ein klares Bild:

  • sehbehinderte oder blinde Tester:innen

  • motorisch eingeschränkte Tester:innen

  • kognitiv eingeschränkte Tester:innen

Das ist der teuerste, aber auch wertvollste Schritt.

Barrierefreiheit Website prüfen: automatisiert, manuell oder mit echten Nutzer:innen?

Eine seriöse Prüfung kombiniert immer drei Ebenen. Jede hat eine klare Aufgabe, und keine ersetzt die andere.


  • `Automatisiert. Scanner wie axe-core, WAVE oder Lighthouse finden in Sekunden fehlende Alt-Texte, niedrige Kontraste und doppelte IDs. Ideal als Erstdiagnose. Grenze: laut WebAIM decken automatisierte Checker nur rund 30 Prozent der WCAG-Kriterien zuverlässig ab.

  • Manuell. Mit Tastatur und Screenreader prüfst du, was Algorithmen nicht beurteilen können: logische Struktur, Fokusreihenfolge, ob interaktive Elemente erwartbar reagieren.

  • Mit echten Nutzer:innen. Drei bis fünf Tester:innen mit verschiedenen Behinderungen decken reale Reibungspunkte auf, die kein Tool sieht.

`Compliance heißt nicht automatisch Nutzbarkeit. Eine Seite kann technisch konform und in der Praxis trotzdem schwer zu bedienen sein.

Kostenlose Tools zum Testen der Website-Barrierefreiheit

Tool

Wofür


Für wen

axe DevTools (Deque)

Browser-Erweiterung mit Detail-Reports und Fix-Vorschlägen

Entwickler:innen

WAVE (WebAIM)

Visualisiert Fehler direkt auf der Seite

Redakteur:innen ohne Code-Wissen

Lighthouse (Chrome)

Accessibility-Score kombiniert mit Performance und SEO

Generalist:innen, ganzheitliche Reviews

WebAIM Contrast Checker

Schneller Farbkontrast-Test gegen WCAG AA und AAA

Designer:innen

BIK BITV-Test

Standardisiertes Verfahren mit 98 Prüfschritten — kostenlose Selbstbewertung oder Prüfung durch zertifizierte Prüfstellen

Öffentliche Verwaltung

NVDA, VoiceOver, TalkBack

Screenreader für Windows, Mac/iOS, Android

Alle (Pflicht für manuelle Prüfung)

PAC (PDF Accessibility Checker)

Prüft PDFs automatisiert gegen PDF/UA und WCAG, inkl. KI-gestützter Struktur-Checks seit PAC 2026

Redakteur:innen und Entwickler:innen mit PDF-Workflows

HeadingsMap

Zeigt die Überschriften-Hierarchie einer Seite auf einen Blick, inklusive Struktur-Fehlern

Zeigt die Überschriften-Hierarchie einer Seite auf einen Blick, inklusive Struktur-Fehlern

Redakteur:innen und Designer:innen

Unser Tipp: Geh selbst zehn Minuten lang nur mit Tastatur und Screenreader durch deine kritischsten Flows. Diese Erfahrung verändert oft das ganze Designdenken. Für eine vollständige Bewertung kombinierst du automatisierte Werkzeuge mit einem professionellen Audit, denn kein einzelnes Tool deckt alle WCAG-Kriterien ab.

Wie du deine Website auch ohne Tools auf Barrierefreiheit prüfst

Falls du kein Budget für Software hast, kommst du mit vier Schritten erstaunlich weit:

  • Tab-Reise durch die ganze Seite. Erreichst du jedes interaktive Element und siehst du jederzeit, wo der Fokus liegt?

  • Bildschirm aus, Screenreader an. NVDA und VoiceOver sind kostenlos. Hör dir an, was tatsächlich vorgelesen wird.

  • Browser auf 200 Prozent zoomen. Bricht etwas? Geht Text verloren?

  • Heading-Struktur in DevTools prüfen. In Chrome unter Accessibility-Tree-View. Eine sinnvolle Hierarchie ist eines der stärksten Signale für gute Strukturierung.

Diese vier Schritte decken einen großen Teil der häufigsten WCAG-Verstöße auf und kosten nichts außer deiner Zeit.

📋 Die vollständige Checkliste als PDF

Alle WCAG-2.2-Prüfpunkte für Web-Barrierefreiheit, sortiert nach den vier POUR-Prinzipien plus einem Abschnitt zu Konformität und Pflege. Inklusive Implementierungshinweisen für dein Team.

Die häufigsten Barrieren auf jeder Website

In der Praxis tauchen dieselben fünf Fehler auf fast jeder Website auf. Aus unseren Audits in IT, FR, DE und AT wissen wir: Diese fünf machen den größten Teil aller WCAG-Verstöße aus, branchenübergreifend.

  • Fehlende oder nichtssagende Alt-Texte. Bilder ohne alt-Attribut oder mit Dateinamen als Beschreibung. Erkennbar mit jedem Scanner, sofort behebbar.

  • Niedrige Farbkontraste. Hellgraue Texte auf weißem Hintergrund, schwache Buttons. Oft Folge von Designentscheidungen, die Barrierefreiheit nicht mitdenken.

  • Formulare ohne Labels. Felder mit reinen Placeholdern. Sobald die Nutzerin tippt, verschwindet der Hinweis, Screenreader-Nutzer:innen wissen ohnehin nicht, was hineingehört.

  • Tastatur-Fallen. Modale Fenster, aus denen man mit Tab nicht herauskommt. Cookie-Banner, die den Fokus festhalten.

  • Unzugängliche PDFs. Eingescannte Dokumente ohne OCR, fehlende Tags, falsche Lesereihenfolge. Besonders kritisch bei Verträgen, Rechnungen und Produktdatenblättern.

Wer diese fünf systematisch erkennt und angeht, hat den größten Teil der schweren Verstöße bereits abgedeckt.

Was bei der Barrierefreiheits-Prüfung wirklich zählt

Eine vollständige Prüfung deckt alle vier WCAG-Prinzipien ab. Diese drei Bereiche sind in der Praxis die häufigsten Stolperfallen.

Kontrast, Alt-Texte und Struktur

  • Kontrast: mindestens 4,5:1 für normalen Text, 3:1 für große Schrift ab 18 pt und UI-Komponenten.

  • Alt-Texte: beschreibend für informative Bilder, leeres alt-Attribut für rein dekorative Grafiken.

  • Überschriften: logische Hierarchie vom H1 abwärts, keine Ebenen überspringen.

  • Farbe nie allein: Fehler, Pflichtfelder und Status nicht ausschließlich über Farbe vermitteln.

Tastaturbedienung, Fokus und Formulare

  • Tab-Reise: jedes interaktive Element per Tab erreichbar.

  • Fokus immer sichtbar: klarer Fokusring, niemals ausblenden ohne Ersatz.

  • Modale schließen mit Esc: keine Tastatur-Fallen.

  • Formularfelder mit sichtbaren Labels: Placeholder reichen nicht.

  • Fehlermeldungen programmatisch verknüpft: sonst lesen Screenreader sie ohne Kontext.

Verständlichkeit und Screenreader-Tauglichkeit

  • Klare Sprache: kurze Absätze, Aktiv, Fachbegriffe bei erster Erwähnung erklären.

  • Vorhersehbares Verhalten: Navigation und Buttons reagieren auf jeder Seite gleich.

  • Konsistente Lesereihenfolge: Code-Reihenfolge muss zur visuellen Reihenfolge passen.

  • Buttons mit klarer Funktion: „Anmelden" statt „Klicken".

Welche Standards dein Barrierefreiheits-Test abdecken muss

  • WCAG 2.2: internationaler Standard vom W3C, drei Stufen (A, AA, AAA). Pflicht ist Stufe AA. Mehr in unserem Beitrag Was bedeutet WCAG 2.2?

  • BFSG: deutsches Gesetz, seit Juni 2025 für viele B2C-Anbieter Pflicht. Setzt den European Accessibility Act (EAA) um.

  • BITV 2.0: gilt für Behörden und öffentliche Stellen in Deutschland.

  • EN 301 549: europäische technische Norm, referenziert die WCAG.

  • BaFG (Österreich) und BehiG (Schweiz): vergleichbarer Rahmen für DACH.

Bei Verstößen gegen das BFSG drohen Bußgelder bis 100.000 Euro pro Fall, dazu kommen Marktrücknahmen und Imageschäden. Eine digitale Barrierefreiheitsplattform hilft dir, die Konformität dauerhaft im Blick zu behalten.

Der Accessibility Tree, und warum KI-Agenten ihn lesen

Chrome DevTools bietet eine Funktion, die das Testen deutlich greifbarer macht: den vollständigen Accessibility Tree.

So öffnest du ihn:

  • Elements-Panel öffnen

  • Oben rechts auf „Switch to Accessibility Tree View" klicken

  • Du siehst jetzt genau das, was Screenreader aus deiner Seite herauslesen

Statt eines HTML-Baums siehst du Knoten mit Rollen wie button, link oder heading, mit zugänglichen Namen und ARIA-Eigenschaften. Wo dein Code semantisch leer ist, erscheint ein generic ohne Namen.

Was viele Teams noch unterschätzen: KI-Agenten wie OpenAI Atlas, Microsofts Playwright MCP und Vercels agent-browser navigieren Websites nicht über Screenshots oder rohes HTML, sondern über genau diesen Accessibility Tree. Sie fragen:

  • Welche Buttons gibt es?

  • Welche Links?

  • Welche Formulare?

  • Was ist deren Funktion?

Ein konkretes Beispiel: Ein:e Nutzer:in bittet einen KI-Agenten, ein Produkt in deinem Shop zu kaufen. Dein „In den Warenkorb"-Button ist als <div> mit JavaScript-Handler umgesetzt, ohne semantische Rolle, ohne Label. Im Accessibility Tree erscheint der Knoten als generic ohne Namen. Der Agent sucht im Baum nach einem Button mit Funktion „Add to cart" oder „In den Warenkorb", findet nichts Passendes, klickt auf irrelevante Elemente wie das Suchfeld und bricht ab. Wäre derselbe Button als <button>In den Warenkorb</button> implementiert, hätte der Agent ihn beim ersten Scan gefunden.

Eine Website, die für Screenreader unsichtbar ist, bleibt auch für KI-Agenten unsichtbar.

Ergebnisse bewerten, dokumentieren und priorisieren

Nach drei Kriterien priorisieren

  • Schwere der Auswirkung. Verhindert die Barriere die Nutzung komplett (Login geht nicht ohne Maus) oder erschwert sie sie nur (niedriger Kontrast)?

  • Reichweite. Sitzt der Fehler in einer Komponente, die auf jeder Seite vorkommt (Header, Footer, Navigation)? Dann ist der Hebel groß.

  • Geschäftsrelevanz. Liegt die Barriere in einem kritischen Flow wie Checkout oder Kontoeröffnung? Dann zuerst beheben.

So dokumentierst du Mängel sinnvoll

Für jede gefundene Barriere notierst du idealerweise:

  • Wo sie auftritt: URL, Komponente und ein Screenshot mit markiertem Element.

  • Welches WCAG-Kriterium betroffen ist: Nummer und Stufe, etwa „1.4.3 Kontrast, AA".

  • Wie schwer der Verstoß wiegt: kritisch, mittel oder gering.

  • Wer den Fix übernimmt: Entwicklung, Design, Redaktion oder PDF-Team.

  • Empfohlene Lösung: ein Satz, was geändert werden muss.

Lege die Fehler in Jira, Asana oder einem Ticket-Tool ab, getaggt nach WCAG-Kriterium und Komponente. So erkennst du Muster und fixt geteilte Komponenten in einem Rutsch statt auf jeder Seite einzeln.

Bewährte Reihenfolge für die Umsetzung

  1. Kritische Flows reparieren (Login, Checkout, Kontaktformular).

  2. Wiederkehrende Komponenten (Header, Footer, Navigation, Cookie-Banner).

  3. Seltener besuchte Seiten und einzelne Inhalte.

  4. Jede Korrektur dokumentieren, damit sie bei zukünftigen Änderungen nicht versehentlich rückgängig gemacht wird.

  5. Die Barrierefreiheit der Website regelmäßig überprüfen, idealerweise einmal pro Quartal.

Eine ausführliche Anleitung zur Umsetzung findest du in unserem Beitrag Website barrierefrei machen.

Häufig gestellte Fragen zum Barrierefreiheits-Test

Wie oft sollte ich meine Website auf Barrierefreiheit testen?

Mindestens vierteljährlich und zusätzlich nach jedem größeren Release oder Redesign. Plugin-Updates und neue Marketing-Kampagnen können neue Barrieren einführen, deshalb lohnt sich automatisiertes Monitoring fast immer.

Reicht ein Accessibility-Widget für die Compliance?

Nein. Widgets können einzelne Nutzer:innen unterstützen, ersetzen aber keinen Audit und keine Behebung im Quellcode. Die Europäische Kommission hat 2023 klargestellt, dass Overlays allein keine Compliance herstellen.

Was passiert bei Verstößen gegen das BFSG?

Bußgelder bis zu 100.000 Euro pro Fall sind möglich. Marktaufsichtsbehörden können Anordnungen erlassen oder digitale Dienste untersagen, dazu kommen mögliche Verbandsklagen und Reputationsschäden.

Kann ich meine Website allein mit kostenlosen Tools BFSG-konform machen?

Für kleinere Seiten teilweise. Kostenlose Werkzeuge wie axe DevTools, WAVE oder Lighthouse decken rund 30 Prozent der WCAG-Kriterien ab. Bei komplexen Customer Journeys oder größeren PDF-Mengen brauchst du Expert:innen-Audits.

Wie teste ich Barrierefreiheit manuell, ganz ohne Tools?

Vier Tests reichen für einen ersten Eindruck: mit der Tastatur durch alle wichtigen Flows tabben, Screenreader bei ausgeschaltetem Bildschirm nutzen, auf 200 Prozent zoomen und die Überschriftenstruktur in den Browser-DevTools prüfen.

Wie dokumentiere ich Mängel und Maßnahmen?

Für jeden Fund hältst du fest: wo er auftritt, welches WCAG-Kriterium betroffen ist, wie schwer der Verstoß wiegt und wer den Fix übernimmt. Eine Ablage in Jira oder Asana mit Tags nach WCAG-Kriterium macht spätere Audits leichter.

Was ist der Unterschied zwischen WCAG, EN 301 549 und BFSG?

WCAG ist der internationale technische Standard vom W3C. EN 301 549 ist die europäische harmonisierte Norm, die WCAG um Software, Apps und Hardware erweitert. BFSG ist das deutsche Gesetz, das den European Accessibility Act umsetzt und auf EN 301 549 verweist.

Wie kann ich die digitale Barrierefreiheit meiner Unternehmenswebsite automatisch prüfen und verbessern?

Automatisierte Tools wie axe DevTools, WAVE oder Lighthouse prüfen einzelne Seiten in Sekunden und finden rund 30 Prozent aller WCAG-Verstöße. Für eine Unternehmenswebsite mit vielen Seiten, Templates und regelmäßigen Releases reicht das nicht: du brauchst kontinuierliches Monitoring, das Regressionen nach jedem Deployment erkennt, Issues nach Schwere priorisiert und sie direkt deinem Entwicklungsteam zuweist. Genau das leistet eine digitale Barrierefreiheitsplattform: wiederkehrende Scans, ein zentrales Dashboard, Anbindung an Jira oder Asana und eine Roadmap zur strukturierten Behebung. Komplexe Flows und PDF-Inhalte brauchen zusätzlich manuelle Audits durch Expert:inne

Redaktion

Warum scheitern Overlays am BFSG, BaFG und BehiG? Wir vergleichen beide Ansätze und zeigen auf, warum nur eine hybride Barrierefreiheitslösung dokumentierte und fortlaufende Konformität im DACH-Raum liefert.

Digitale Barrierefreiheit

Artikel ahnsehen

Redaktion

Wie du deine Website barrierefrei machst: Die Schritt-für-Schritt-Anleitung

Digitale Barrierefreiheit

Artikel ahnsehen

Author

Was ist digitale Barrierefreiheit? Ein umfassender Leitfaden zu allem, was Sie wissen müssen

Digitale Barrierefreiheit

Artikel ahnsehen

Related Articles

bottom of page