Barrierefreie Website: Was bedeuten WCAG und BFSG für Ihr Unternehmen?

Eine barrierefreie Website können Menschen mit Seh-, Hör-, Bewegungs- oder kognitiven Einschränkungen genauso nutzen wie alle anderen. In diesem Leitfaden erkläre ich die Stufen der WCAG 2.2, das Barrierefreiheitsstärkungsgesetz (BFSG), meine Testwerkzeuge und die Fehler, die ich in der Praxis am häufigsten sehe. Das ist keine Rechtsberatung, sondern meine Erfahrung als Designer und Berater seit 2012.

Was ist eine barrierefreie Website?

Eine barrierefreie Website ist so gestaltet und programmiert, dass alle Menschen, auch Menschen mit Behinderungen, ihre Inhalte wahrnehmen, bedienen, verstehen und zuverlässig nutzen können. Wer einen Screenreader verwendet, nur mit der Tastatur navigiert oder schlecht sieht, soll dieselbe Aufgabe genauso leicht erledigen.

Ich empfehle Ihnen, diese Definition weit zu fassen. Barrierefreiheit betrifft nicht nur dauerhafte Behinderungen. Zum Beispiel kann jemand im hellen Sonnenlicht kontrastarmen Text auf dem Smartphone kaum lesen. Ebenso surft, wer den Arm in Gips hat, mit einer Hand. Zudem tun sich ältere Kundinnen und Kunden mit kleiner Schrift und winzigen Buttons schwer. Kurz gesagt: Barrierefreies Design hilft auch bei vorübergehenden und situativen Einschränkungen.

In meinen Projekten behandle ich das Thema deshalb als Qualitätsmaßstab und nicht als Zusatzfunktion. Denn eine barrierefreie Website ist fast immer sauberer programmiert, klarer formuliert und leichter zu bedienen.

Was sind die WCAG und wer gibt sie heraus?

WCAG steht für Web Content Accessibility Guidelines. Die Web Accessibility Initiative (WAI) des W3C gibt diesen internationalen Standard heraus. Die aktuelle Version ist WCAG 2.2; sie ist seit Oktober 2023 eine W3C Empfehlung, und den aktuellen Text finden Sie auf der offiziellen Seite des W3C zu WCAG 2.2.

Der Standard beruht auf vier Prinzipien:

• Wahrnehmbar: Informationen müssen alle erreichen. Bilder brauchen also eine Textalternative.
• Bedienbar: Jede Funktion muss per Tastatur funktionieren, und Nutzer brauchen genug Zeit.
• Verständlich: Texte und Verhalten der Oberfläche müssen vorhersehbar sein. Fehlermeldungen sagen, was zu tun ist.
• Robust: Der Code muss zuverlässig mit Hilfstechnologien wie Screenreadern zusammenarbeiten.

Konkret stehen unter jedem Prinzip Richtlinien und darunter prüfbare Erfolgskriterien. Die WCAG sind also keine vage Absichtserklärung, sondern eine Liste, die Sie Punkt für Punkt abhaken können. Somit wird aus der Diskussion "Ist das barrierefrei?" eine messbare Frage.

Worin unterscheiden sich die Stufen A, AA und AAA?

Die WCAG teilen ihre Erfolgskriterien in drei Konformitätsstufen ein. Stufe A umfasst die Grundlagen; fehlen sie, können manche Menschen die Seite gar nicht nutzen. Danach beseitigt Stufe AA die häufigsten Barrieren. Stufe AAA schließlich ist die höchste Stufe und lässt sich nicht für jede Art von Inhalt erreichen.

In der Praxis ist das Ziel fast immer AA. Auch die europäische Norm EN 301 549 stützt sich für Webinhalte auf die Kriterien der Stufe AA. Deshalb rate ich meinen Kunden: Verfolgen Sie AAA nicht auf der ganzen Website. Erfüllen Sie AA vollständig und nähern Sie sich AAA dort, wo es sinnvoll ist.

Was hat sich mit WCAG 2.2 geändert?

WCAG 2.2 ergänzt die Version 2.1 um neun neue Erfolgskriterien. Außerdem gilt das alte Kriterium 4.1.1 Parsing nun als veraltet und fällt weg. Die meisten Neuerungen betreffen die mobile Nutzung, die Sichtbarkeit des Fokus und Anmeldeprozesse.

• 2.4.11 Fokus nicht verdeckt (AA): Ein fokussiertes Element darf nicht vollständig hinter einer fixierten Kopfzeile oder einem Cookie Banner verschwinden.
• 2.5.7 Ziehbewegungen (AA): Alles, was per Ziehen funktioniert, braucht eine Alternative mit einem einzelnen Klick.
• 2.5.8 Zielgröße (AA): Klickziele müssen mindestens 24 x 24 CSS Pixel groß sein oder genug Abstand haben.
• 3.2.6 Konsistente Hilfe (A): Hilfelinks oder Kontaktdaten stehen auf allen Seiten an derselben Stelle.
• 3.3.7 Redundante Eingabe (A): Fragen Sie im selben Prozess nicht zweimal nach denselben Daten.
• 3.3.8 Barrierefreie Authentifizierung (AA): Die Anmeldung darf kein Rätsel und kein Auswendiglernen verlangen; Passwortmanager und Einfügen müssen funktionieren.

Die übrigen drei Kriterien (2.4.12, 2.4.13 und 3.3.9) gehören zur Stufe AAA. Websites mit Cookie Banner und fixiertem Menü scheitern oft an 2.4.11. Prüfen Sie Fokuszustände daher schon im Design und nicht erst nach dem Launch.

Was bedeuten der European Accessibility Act und das BFSG?

Der European Accessibility Act (Richtlinie (EU) 2019/882) gilt seit dem 28. Juni 2025. In Deutschland setzt das Barrierefreiheitsstärkungsgesetz (BFSG) die Richtlinie um. Sie verlangt Barrierefreiheit für bestimmte Produkte und Dienstleistungen für Verbraucher, zum Beispiel E-Commerce, Bankdienstleistungen, elektronische Kommunikation, digitale Bücher und Tickets im Personenverkehr. Den vollständigen Text finden Sie bei im offiziellen Rechtsportal der EU.

Entscheidend ist dabei nicht der Firmensitz, sondern ob Sie die Leistung Verbrauchern in der EU anbieten. Ein Onlineshop, der direkt an Privatkunden in Deutschland verkauft, fällt also grundsätzlich in den Blick des BFSG. Allerdings nimmt die Richtlinie Kleinstunternehmen aus, die Dienstleistungen erbringen: weniger als 10 Beschäftigte und höchstens 2 Millionen Euro Jahresumsatz oder Bilanzsumme.

Ob Sie betroffen sind, hängt von Branche, Vertriebsmodell und Zielmarkt ab. Für eine verbindliche Einschätzung sprechen Sie deshalb mit einer Anwältin oder einem Anwalt. Mein technischer Rat ist einfacher: Wenn Sie an Verbraucher in der EU verkaufen, planen Sie Ihre Website nach WCAG 2.2 AA. Bei mehreren Sprachen kombinieren Sie diese Prüfungen mit der Struktur aus meinem Leitfaden zur mehrsprachigen Website.

Warum ist eine barrierefreie Website wichtig für Ihr Geschäft?

Eine barrierefreie Website ist wichtig, weil Besucher, die Ihre Seite nicht bedienen können, weder kaufen noch ein Formular absenden noch Sie kontaktieren. Menschen mit Behinderungen, ältere Nutzer und Menschen mit vorübergehenden Einschränkungen sind keine kleine Gruppe. Laut Weltgesundheitsorganisation leben weltweit rund 1,3 Milliarden Menschen, also etwa jeder sechste, mit einer erheblichen Behinderung.

Wirtschaftlich ist das Bild klar. Ein Formularfeld ohne Beschriftung ist für Screenreader Nutzer ein leeres Kästchen. Ebenso ist ein Menü, das sich nicht per Tastatur öffnet, eine verschlossene Tür. Folglich bedeutet jeder Barrierefehler einen verlorenen Umsatz.

Zudem verbessern Maßnahmen für Barrierefreiheit das Erlebnis für alle. Besserer Kontrast, größere Klickziele und klarere Fehlermeldungen helfen jedem Besucher. Wenn Sie mit einer hohen Absprungrate kämpfen, werden Sie feststellen, dass sich viele Prüfpunkte aus meinem Beitrag zur Senkung der Absprungrate mit Barrierefreiheit überschneiden.

Welche Fehler verhindern am häufigsten eine barrierefreie Website?

Die häufigsten Fehler sind erstaunlich einfach. Der WebAIM Million Report prüft jedes Jahr eine Million Startseiten automatisch. Laut der Ausgabe 2026 hatten 95,9 Prozent der Startseiten erkennbare WCAG Fehler, im Schnitt 56,1 Fehler pro Seite.

1. Text mit zu geringem Kontrast: 83,9 Prozent der Seiten.
2. Fehlende Alternativtexte bei Bildern: 53,1 Prozent.
3. Formularfelder ohne Beschriftung: 51 Prozent.
4. Leere Links ohne Text: 46,3 Prozent.
5. Leere Buttons ohne Namen: 30,6 Prozent.
6. Fehlende Sprachangabe im Dokument: 13,5 Prozent.

Laut Report fallen 96 Prozent aller erkannten Fehler in diese sechs Kategorien. Anders gesagt: Sie können Ihre Website ohne großes Budget spürbar verbessern. Allerdings erfassen automatische Scans nur einen Teil der Probleme.

Wie prüfen Sie den Farbkontrast?

Der Farbkontrast ist das Helligkeitsverhältnis zwischen Textfarbe und Hintergrund. WCAG AA verlangt mindestens 4,5:1 für normalen Text und 3:1 für großen Text. Auch Symbole, Rahmen von Formularfeldern und Fokusringe brauchen 3:1.

In der Praxis sehe ich am häufigsten hellgrauen Fließtext und weiße Schrift auf der Markenfarbe. Gerade Orange, Gelb und helles Grün erreichen mit weißem Text selten 4,5:1. Sie müssen Ihre Markenfarbe deshalb nicht ändern. Stattdessen reservieren Sie einen dunkleren Ton derselben Farbe für Text.

Zum Prüfen gibt es mehrere Wege. Die Chrome DevTools zeigen das Verhältnis im Farbwähler an, wenn Sie Text untersuchen. Beim Aufbau einer Palette wählen Sie Töne zunächst mit dem Tool für HTML Farbcodes und messen dann das Verhältnis. Außerdem gilt: Vermitteln Sie Informationen nie nur über Farbe. Ein rot markiertes Fehlerfeld braucht zusätzlich ein Symbol oder einen Text. Wenn Sie ohnehin Ihre Unternehmensfarben überarbeiten, lösen Sie das am saubersten im Rahmen der Markenidentität.

Warum ist die Tastaturbedienung so entscheidend?

Die Tastaturbedienung ist entscheidend, weil Screenreader Nutzer, Menschen mit motorischen Einschränkungen und viele erfahrene Anwender ohne Maus navigieren. Jeder Link, jeder Button, jedes Menü und jedes Formularfeld muss per Tab erreichbar sein und mit Enter oder Leertaste funktionieren.

Ein einfacher Test: Legen Sie die Maus beiseite und versuchen Sie, von der Startseite aus Ihr Kontaktformular abzusenden. Achten Sie dabei auf diese Fragen:

• Sehen Sie jederzeit, welches Element den Fokus hat, oder hat CSS den Fokusring entfernt?
• Folgt die Fokusreihenfolge der sichtbaren Reihenfolge der Seite?
• Öffnen sich Dropdowns und Dialoge per Tastatur und schließen sie mit Esc?
• Bleibt der Fokus in einem geöffneten Modal und kehrt er danach zurück?
• Gibt es oben einen Link "Zum Inhalt springen"?

Die meisten Kunden, die diesen Test machen, finden in den ersten fünf Minuten mindestens eine Falle. Denn meist steckt ein klickbares div dahinter oder eine aus optischen Gründen entfernte Fokuslinie. Daher lösen echte button und a Elemente die meisten Probleme schon von Anfang an.

Wie schreiben Sie gute Alternativtexte?

Der Alternativtext ist die Textfassung eines Bildes für Screenreader und für Browser, wenn das Bild nicht lädt. Ein guter Alternativtext beschreibt die Funktion des Bildes im Kontext. Er zählt also nicht einfach auf, was zu sehen ist.

Diese Regeln wende ich an:

• Bei informativen Bildern nennen Sie den Inhalt, etwa "Schema der vier Schritte unseres Angebotsprozesses".
• Bei verlinkten Bildern nennen Sie das Ziel, etwa "Startseite" oder "Zum Warenkorb".
• Bei dekorativen Bildern lassen Sie das alt Attribut leer (alt=""), damit Screenreader sie überspringen.
• Beginnen Sie nicht mit "Bild von" oder "Foto von", denn das sagt der Screenreader ohnehin.
• Stopfen Sie keine Keywords hinein; der Alternativtext ist kein SEO Feld.

Diagramme und Infografiken brauchen mehr als einen kurzen Alternativtext. Geben Sie dann zusätzlich eine Zusammenfassung der Daten als Text oder Tabelle neben dem Bild aus. Bei Tausenden Produktbildern starten Sie mit einer Vorlage und überarbeiten danach zuerst die Bestseller von Hand.

Wie gestalten Sie ein barrierefreies Formular?

Ein barrierefreies Formular hat für jedes Feld eine sichtbare, im Code verknüpfte Beschriftung, meldet Fehler verständlich und lässt sich vollständig per Tastatur ausfüllen. Laut WebAIM fehlen auf jeder zweiten Startseite Beschriftungen. Folglich verlieren viele Unternehmen genau im Formular still Anfragen.

Diese Korrekturen nehme ich am häufigsten vor:

1. Nutzen Sie keinen Platzhaltertext als Beschriftung, denn er verschwindet beim Tippen.
2. Verknüpfen Sie jedes label über for und id mit seinem Feld.
3. Zeigen Sie Fehlermeldungen als Text neben dem Feld und erklären Sie die Lösung.
4. Kennzeichnen Sie Pflichtfelder in Worten und nicht nur mit einem Sternchen.
5. Verwenden Sie das autocomplete Attribut für Name, E-Mail und Telefon.
6. Fragen Sie in einem späteren Schritt nicht erneut nach denselben Daten; WCAG 2.2 behandelt das inzwischen als eigenes Kriterium.

Den Aufbau von Anfrageformularen beschreibe ich ausführlich im Beitrag zum Optimieren von Termin, Angebots und Demoformularen. Kombinieren Sie ihn mit dieser Liste, dann erhalten Sie mehr Anfragen und weniger fehlerhafte Eingaben.

Warum sind Überschriften und semantisches HTML so wichtig?

Screenreader Nutzer hören eine Seite selten von oben bis unten. Stattdessen springen sie von Überschrift zu Überschrift. Die Überschriftenhierarchie ist für sie somit das Inhaltsverzeichnis der Seite. Nach H1 folgt H2, unter H2 steht H3; wählen Sie eine Ebene nie wegen der Schriftgröße.

Dasselbe gilt für andere semantische Elemente. Wenn Sie die Navigation mit nav, den Hauptinhalt mit main und die Fußzeile mit footer auszeichnen, erkennen Hilfstechnologien die Bereiche der Seite. Außerdem sorgt ein lang Attribut am html Element dafür, dass der Screenreader die richtige Sprache und Aussprache nutzt. Laut WebAIM fehlt genau diese eine Zeile auf 13,5 Prozent der Seiten.

Diese Struktur hilft zugleich der Suchmaschinenoptimierung. Eine saubere Hierarchie und aussagekräftiges HTML erleichtern auch Suchmaschinen das Verständnis. Weitere technische Grundlagen habe ich in meinen 10 Tipps für technisches SEO zusammengefasst.

Wann sollten Sie ARIA Attribute einsetzen?

ARIA ist ein Satz von Attributen, der Hilfstechnologien zusätzliche Informationen liefert, wo HTML allein nicht ausreicht. Zum Beispiel geben Sie einem reinen Symbolbutton über ein ARIA Label den Namen "Suchen". Ebenso melden Sie über einen ARIA Zustand, ob ein Dropdown offen ist.

Die erste Regel im Leitfaden des W3C lautet allerdings: Wenn ein natives HTML Element die Aufgabe erfüllt, verzichten Sie auf ARIA. Ein echtes button Element bringt Tastaturbedienung, Fokus und Rolle bereits mit. Geben Sie dagegen einem div die Rolle button, müssen Sie all das selbst programmieren. Falsches ARIA kann schlimmer sein als gar keines, denn es gibt dem Screenreader falsche Informationen.

Kurz gesagt: Betrachten Sie ARIA als letztes Mittel und nicht als Flickzeug. Lösen Sie das Problem zuerst mit semantischem HTML, ergänzen Sie ARIA nur bei Bedarf und hören Sie sich das Ergebnis dann mit einem Screenreader an.

Lösen Overlay Tools das Problem?

Die kurze Antwort lautet nein. Overlays sind Werkzeuge, die Sie mit einer Codezeile einbinden. Sie blenden ein Menü mit Schaltern für größere Schrift oder mehr Kontrast ein und werben oft mit "Barrierefreiheit per Klick".

Die eigentlichen Probleme stecken jedoch im Code. Eine Schicht darüber repariert ein unbeschriftetes Feld, ein Menü ohne Tastaturbedienung oder eine falsche Fokusreihenfolge nicht zuverlässig. Zudem haben viele Screenreader Nutzer ihre Hilfstechnologie längst selbst eingerichtet, und ein Overlay kann damit kollidieren. Auch das WAI Team des W3C betont, dass automatische Werkzeuge allein keine Konformität feststellen können.

Deshalb empfehle ich, das Budget für ein Overlay lieber in echte Korrekturen im Quellcode zu stecken. Falls Ihre Website bereits ein Overlay nutzt, testen Sie vor dem Entfernen, was darunter liegt. Meist finden Sie Fehler, die das Widget nie berührt hat.

Wie testen Sie, ob Ihre Website barrierefrei ist?

Sie testen auf drei Ebenen: automatischer Scan, manuelle Prüfung und Test mit echten Nutzern. Automatische Werkzeuge sind schnell, messen aber nicht alle Kriterien der WCAG. Sie erkennen zum Beispiel, dass ein Alternativtext existiert, aber nicht, ob er stimmt.

Für einen ersten Blick eignet sich der Barrierefreiheitswert in Lighthouse gut; wie Sie ihn lesen, erkläre ich im Beitrag zum Lighthouse Test. Trotzdem heißt ein Wert von 100 nicht, dass Ihre Website barrierefrei ist. Er zeigt nur, dass sie die maschinell prüfbaren Tests besteht.

Wie wirkt sich eine barrierefreie Website auf SEO aus?

Google hat Barrierefreiheit nicht als direkten Rankingfaktor benannt. Trotzdem überschneidet sich eine barrierefreie Website stark mit SEO. Alternativtexte liefern Kontext für die Bildersuche, eine klare Überschriftenstruktur erleichtert das Verständnis, und aussagekräftige Linktexte beschreiben das Linkziel für Screenreader und Crawler gleichermaßen.

Zudem verbessern solche Korrekturen das Nutzerverhalten. Gut lesbarer Text, klare Buttons und einfache Formulare helfen Besuchern, zu bleiben und ihr Ziel zu erreichen. Auf dem Smartphone hängen Regeln wie die Zielgröße von 24 x 24 Pixeln direkt mit den Punkten zusammen, die Sie beim Test der Mobilfreundlichkeit finden.

Deshalb baue ich Barrierefreiheit auch in SEO Projekte ein. Überschriften, Alternativtexte, Linktexte und das Sprachattribut stehen ohnehin auf meiner technischen Prüfliste. Somit dient dieselbe Korrektur der Sichtbarkeit und der Nutzererfahrung. Mehr zu diesem Zusammenspiel lesen Sie im Beitrag zu SEO und UX.

Worauf achten Sie bei Video und Audio?

Ohne Untertitel oder Transkript bleiben Video und Audio für gehörlose Menschen unzugänglich. Die WCAG verlangen auf Stufe A Untertitel für aufgezeichnete Videos. Auf Stufe AA kommt zusätzlich eine Audiodeskription wichtiger Bildinformationen hinzu, und auch Livevideos brauchen dann Untertitel.

Am häufigsten sehe ich automatisch erzeugte Untertitel. Sie sind ein guter Anfang, schreiben aber Markennamen, Fachbegriffe und Zahlen oft falsch. Prüfen Sie die Untertitel daher vor der Veröffentlichung. Achten Sie außerdem darauf, dass das Video auch ohne Ton verständlich bleibt, denn viele Menschen schauen mobil stumm.

• Geben Sie automatisch startenden Videos eine Pausetaste und starten Sie sie stumm.
• Ergänzen Sie Podcasts und Audioinhalte um ein Transkript.
• Testen Sie, ob die Steuerung des Players per Tastatur funktioniert.

Die Wirkung auf die Conversion Rate beleuchte ich im Beitrag zu Video auf der Website. Barrierefreie Videos tragen diese Effekte zu einem größeren Publikum.

Warum sind Bewegung, Animation und Zeitlimits riskant?

Für manche Besucher ist Bewegung nicht nur störend, sondern körperlich unangenehm. Starke Parallax oder Scrolleffekte können bei Menschen mit vestibulären Störungen Schwindel auslösen. Außerdem begrenzen die WCAG auf Stufe A Inhalte, die mehr als dreimal pro Sekunde blitzen, wegen des Risikos epileptischer Anfälle.

Auch automatisch wechselnde Slider machen Probleme. Die WCAG verlangen für automatische Bewegung, die länger als fünf Sekunden dauert, eine Möglichkeit zum Pausieren, Stoppen oder Ausblenden. Wenn Sie also einen Slider nutzen, ergänzen Sie eine sichtbare Pausetaste. Zudem kostet die Unterstützung der Media Query für reduzierte Bewegung nur wenige Zeilen CSS und respektiert die Systemeinstellung der Nutzer.

Zeitlimits gehören in dieselbe Gruppe. Läuft beim Checkout oder in einem langen Antragsformular die Sitzung ab, warnen Sie vorher und bieten Sie eine Verlängerung an. Sonst verliert jemand, der langsam tippt oder eine Hilfstechnologie nutzt, seine Eingaben.

Was ist eine Erklärung zur Barrierefreiheit?

Eine Erklärung zur Barrierefreiheit ist eine Seite, die den angestrebten Standard nennt, bekannte Lücken auflistet und einen Weg für Rückmeldungen bietet. Öffentliche Stellen in der EU müssen sie veröffentlichen. Auch das BFSG verlangt von betroffenen Dienstleistern Informationen dazu, wie sie die Anforderungen erfüllen. Das W3C WAI stellt dafür einen kostenlosen Generator bereit.

Diese Punkte gehören meiner Meinung nach hinein:

• Der angestrebte Standard und die Stufe, etwa WCAG 2.2 AA.
• Datum und Methode der letzten Prüfung.
• Bekannte Einschränkungen und der geplante Termin für die Behebung.
• E-Mail und Telefon für Menschen, die auf eine Barriere stoßen.

Eine ehrliche Erklärung schafft mehr Vertrauen als die Behauptung vollständiger Konformität. Schreiben Sie sie allerdings nicht einmal und vergessen sie dann. Aktualisieren Sie Datum und Lückenliste nach jedem größeren Release.

Wann planen Sie Barrierefreiheit am besten ein?

Am günstigsten ist der Beginn des Designs. Sind Farbpalette, Typografie, Komponentenbibliothek und Formularvorlagen barrierefrei, erbt jede weitere Seite diese Basis. Korrekturen nach dem Launch bedeuten dagegen, dieselbe Arbeit Seite für Seite zu wiederholen.

So verankere ich Barrierefreiheit im Projekt:

1. Zunächst schreibe ich in der Konzeptphase die Zielstufe, meist WCAG 2.2 AA, in Angebot und Vertrag.
2. Im Design definiere ich Kontrast, Fokuszustände und Klickziele auf Komponentenebene.
3. Danach nutze ich in der Entwicklung semantisches HTML und echte Buttons und Links.
4. Beim Testen führe ich einen Scan, einen Tastaturtest und mindestens einen Screenreader Durchgang durch.
5. Schließlich erhält das Redaktionsteam nach dem Launch einen kurzen Leitfaden zu Alternativtexten und Überschriften.

Vor allem der letzte Schritt ist wichtig, denn später eingefügte Inhalte zerstören Barrierefreiheit oft stärker als das Design. Fragen Sie deshalb schon bei der Angebotsanfrage, ob Barrierefreiheit enthalten ist und auf welcher Stufe. Diese Frage passt gut in meine Checkliste für die Beauftragung von UI und UX Design.

Wie lange dauert es, eine bestehende Website barrierefrei zu machen?

Das hängt von Größe, Theme und Fehlerquelle ab. Stammen die meisten Fehler aus einer gemeinsamen Vorlage wie Menü, Kopfzeile, Fußzeile oder Formularkomponente, verbessert eine Korrektur Hunderte Seiten auf einmal. Liegen die Fehler dagegen im Inhalt, etwa bei Tausenden Bildern ohne Alternativtext, dauert es länger.

Als Startwert aus meiner Praxiserfahrung, ohne Garantie: Bei einer Unternehmenswebsite mit einer Vorlage und 20 bis 30 Seiten lassen sich die zentralen AA Korrekturen meist in wenigen Wochen umsetzen. Bei einem individuell entwickelten Onlineshop mit vielen Komponenten kann sich dieselbe Arbeit über mehrere Monate ziehen. Hat ein fertiges Theme tiefe strukturelle Mängel, ist ein Neuaufbau manchmal sinnvoller als Flickwerk.

Deshalb beginne ich immer mit Prioritäten. Zuerst kommen die Abläufe, die Geld bringen, also Checkout, Kontakt und Angebotsformular. Dann folgen die Vorlagen und zuletzt die Inhalte. So sehen Sie schon in den ersten Wochen einen messbaren Unterschied. Im Onlinehandel bearbeiten wir diese Abläufe gemeinsam im Rahmen der E-Commerce Beratung.

Wo fangen Sie mit einer barrierefreien Website an?

Für den Anfang brauchen Sie kein großes Projekt. Diese kurze Reihenfolge bringt auf den meisten Websites den größten Effekt mit dem geringsten Aufwand:

• Prüfen Sie Startseite, eine Produkt oder Leistungsseite und die Kontaktseite mit Lighthouse.
• Legen Sie die Maus weg und machen Sie auf diesen drei Seiten den Tastaturtest.
• Ersetzen Sie Farben mit zu wenig Kontrast durch dunklere Töne.
• Korrigieren Sie Beschriftungen und Fehlermeldungen in Ihren Formularen.
• Ergänzen Sie den richtigen lang Wert am html Element.
• Geben Sie Ihrem Redaktionsteam eine schriftliche Regel für Alternativtexte.

Zusammengefasst ist eine barrierefreie Website kein einmaliges Projekt, sondern Teil der laufenden Pflege. In meinen eigenen Projekten im Webdesign steht WCAG 2.2 AA von Anfang an im Plan. Wenn Sie Ihre bestehende Website gemeinsam prüfen möchten, schreiben Sie mir über die Kontaktseite. Wir messen zuerst und setzen dann Prioritäten.