Einführung: Warum Barrierefreiheit wichtig ist

Barrierefreiheit im Web bedeutet, dass Websites und digitale Angebote so gestaltet sind, dass sie von allen Menschen genutzt werden können – unabhängig von Behinderung, Alter oder technischen Hilfsmitteln. Eine barrierefreie Website ermöglicht z.B. blinden Nutzer*innen die Bedienung mit Screenreader und Tastatur, bietet ausreichend Farbkontrast für sehbehinderte Menschen und verständliche Inhalte für alle. Dies verbessert nicht nur die Inklusion, sondern oft auch die allgemeine Benutzerfreundlichkeit.

Ab 2025 wird Web-Barrierefreiheit zudem für viele Unternehmen in Deutschland gesetzlich verpflichtend. Das neue Barrierefreiheitsstärkungsgesetz (BFSG) setzt den European Accessibility Act der EU um und tritt am 28. Juni 2025 vollständig in Kraft (Barrierefreies Internet – Wikipedia). Damit weitet sich die Pflicht zur Barrierefreiheit deutlich aus – sie gilt nicht mehr nur für Behörden, sondern auch für zahlreiche private Anbieter. Eine Studie ergab, dass Ende 2024 noch 99 % von 2.446 untersuchten deutschen Online-Shops die Anforderungen nicht vollständig erfüllten (Barrierefreies Internet – Wikipedia). Es besteht also akuter Handlungsbedarf, um Websites fit für die neuen Vorgaben zu machen.

Dieser Leitfaden richtet sich an Webagenturen und ihre Kundinnen. Er bietet einen umfassenden Überblick, wer die Anforderungen erfüllen muss, bis wann die Umstellung erfolgen muss und welche konkreten Maßnahmen für barrierefreie Websites umzusetzen sind. Außerdem zeigen wir Best Practices mit Beispielen, nennen hilfreiche Tools und geben Hinweise zu mobilen Apps und Dokumenten. Alles in klarer, verständlicher Sprache – für Entwicklerinnen ebenso wie für Projektverantwortliche in Unternehmen.

Wer muss die Anforderungen erfüllen?

Die Verpflichtung zur Web-Barrierefreiheit trifft ab 2025 einen großen Kreis von Akteuren. Grundsätzlich gilt: Öffentliche Stellen mussten ihre Websites und mobilen Angebote bereits in den letzten Jahren barrierefrei gestalten (gemäß BITV 2.0 seit 2019 (Barrierefreies Internet – Wikipedia), mit Übergangsfristen bis 2020/2021 für ältere Websites und Apps (Barrierefreies Internet – Wikipedia)). Neu ist, dass nun auch viele private Unternehmen Barrierefreiheit anbieten müssen. Dies regelt das BFSG, das die EU-Richtlinie 2019/882 (European Accessibility Act) in deutsches Recht umsetzt (Barrierefreiheitsstärkungsgesetz – Wikipedia).

Betroffen sind insbesondere Anbieter folgender Produkte und Dienstleistungen für Verbraucher*innen (BFSG Barrierefreiheitsstärkungsgesetz ) (BFSG Barrierefreiheitsstärkungsgesetz ):

• Telekommunikationsdienste (z.B. Websites von Telefon- und Internetanbietern).
• Personenverkehrsdienste (Webportale von Bahn-, Flug-, Bus- und Schifffahrtsunternehmen; ausgenommen sind rein regionale/local Verkehrsdienste).
• Bankdienstleistungen für Verbraucher (Online-Banking, Finanz-Apps).
• E-Books und zugehörige Lese-Software.
• Elektronischer Geschäftsverkehr – darunter fallen Online-Shops, Buchungsplattformen und andere E-Commerce-Angebote für Waren und Dienstleistungen.

Für diese Bereiche schreibt das BFSG vor, dass Websites (und ebenso mobile Apps, siehe später) den anerkannten Barrierefreiheits-Standards entsprechen müssen. Kleine Betriebe sind jedoch ausgenommen: Kleinstunternehmen mit weniger als 10 Mitarbeiter*innen und unter 2 Mio. € Jahresumsatz sind nicht verpflichtigt, die Anforderungen umzusetzen (BFSG Barrierefreiheitsstärkungsgesetz ). Für sie sollen vom Bundesministerium für Arbeit und Soziales lediglich freiwillige Leitlinien als Unterstützung bereitgestellt werden (BFSG Barrierefreiheitsstärkungsgesetz ). Einzelunternehmer und Freelancer fallen in der Regel in diese Kategorie, sofern sie sehr klein sind. Dennoch kann es auch für sie sinnvoll sein, Websites barrierefrei zu gestalten – sei es um mehr Kundschaft zu erreichen oder weil Barrierefreiheit perspektivisch zum Branchenstandard wird.

Alle größeren Unternehmen (kleine und mittlere sowie Großunternehmen) in den genannten Bereichen müssen hingegen die Vorgaben erfüllen. Das Gesetz bemüht sich, insbesondere mittelständische Firmen nicht übermäßig zu belasten (BFSG Barrierefreiheitsstärkungsgesetz ), aber die Pflicht als solche besteht. Webagenturen sollten ihre Kunden also frühzeitig darauf hinweisen, wenn diese unter die Regelungen fallen. Im Zweifel lohnt es sich, eine juristische Einordnung vorzunehmen, ob ein bestimmtes Angebot als „Dienstleistung im elektronischen Geschäftsverkehr“ etc. im Sinne des Gesetzes gilt. Die oben genannten Branchen dienen als Anhaltspunkt.

Überblick der Verpflichteten und Ausnahmen

Zur besseren Übersicht zeigt Tabelle 1 nochmals, wen die Pflicht zur Web-Barrierefreiheit trifft und wer ausgenommen ist, sowie Beispiele:

(Hinweis: Zusätzlich gelten Barrierefreiheits-Anforderungen z.B. für Geldautomaten, Fahrkartenautomaten, Self-Service-Terminals u.a. physische Produkte – diese liegen jedoch außerhalb des Themas „Websites“ dieser Broschüre.)

Fristen zur Umsetzung

Das Barrierefreiheitsstärkungsgesetz tritt zum 28. Juni 2025 in Kraft (Barrierefreies Internet – Wikipedia). Bis zu diesem Stichtag müssen die betroffenen Unternehmen ihre Websites und Apps barrierefrei gestaltet haben, damit neue und bestehende digitale Angebote die Anforderungen erfüllen. Es handelt sich also faktisch um eine Umsetzungsfrist bis Mitte 2025. Wer bis dahin nicht compliant ist, läuft Gefahr gegen das Gesetz zu verstoßen.

Für bestehende Webinhalte gibt es teilweise Ausnahmen und Übergangsregelungen, die vor allem historische Inhalte betreffen (BFSG Barrierefreiheitsstärkungsgesetz ) (BFSG Barrierefreiheitsstärkungsgesetz ):

• Archiv-Inhalte: Websites oder Apps, die als Archive gelten – d.h. deren Inhalte nach dem 28. Juni 2025 nicht mehr aktualisiert oder überarbeitet werden – sind von den Anforderungen ausgenommen (BFSG Barrierefreiheitsstärkungsgesetz ). Beispiel: Eine alte Webpräsenz, die nur aus Gründen der Dokumentation online bleibt und ab 2025 nicht mehr gepflegt wird, muss nicht nachträglich barrierefrei gemacht werden.
• Ältere Medien: Für aufgezeichnete Videos/Audio die vor dem 28. Juni 2025 veröffentlicht wurden, besteht keine Pflicht, nachträglich Untertitel oder Audiodeskription bereitzustellen (BFSG Barrierefreiheitsstärkungsgesetz ). Ebenso müssen Office-Dokumente (z.B. PDFs), die vor diesem Stichtag online gestellt wurden, nicht rückwirkend angepasst werden (BFSG Barrierefreiheitsstärkungsgesetz ).
• Drittinhalte: Inhalte von Dritten, die weder vom Betreiber der Website finanziert oder erstellt wurden noch seiner Kontrolle unterliegen (z.B. eingebettete Fremd-Inhalte, Social-Media-Feeds), sind ebenfalls ausgenommen (BFSG Barrierefreiheitsstärkungsgesetz ).

Alle neuen Inhalte ab Stichtag 2025 hingegen müssen barrierefrei sein. Für neu hinzukommende Videos gilt z.B., dass Untertitel bereitzustellen sind; neue PDF-Dokumente müssen barrierefrei erstellt sein, etc. Praktisch bedeutet das: Unternehmen sollten spätestens 2024 mit der Umstellung beginnen, um pünktlich zum Juni 2025 konform zu sein. Es empfiehlt sich, Barrierefreiheit bereits jetzt als festen Bestandteil aller Relaunch- und Entwicklungsprojekte einzuplanen.

Tipp: Es ist sinnvoll, schon vor 2025 Verbesserungen vorzunehmen. So profitieren Nutzer*innen umgehend, und man verteilt den Aufwand. Zudem zeigen Erfahrungen aus dem öffentlichen Sektor, dass Barrierefreiheit konsequent eingeplant werden muss – last-minute Anpassungen kurz vor Fristende sind riskant und unter Umständen teuer.

Gesetzliche Grundlagen in Kürze

Um den Kontext zu verstehen, hier ein kurzer Überblick der relevanten gesetzlichen Grundlagen in Deutschland:

• Behindertengleichstellungsgesetz (BGG) und BITV: Seit 2002 verpflichtet das BGG den Bund, seine Websites barrierefrei zu gestalten (Barrierefreies Internet – Wikipedia). Die konkrete Barrierefreie-Informationstechnik-Verordnung (BITV) listet seitdem technische Anforderungen auf, die sich an internationalen Richtlinien orientieren (Barrierefreies Internet – Wikipedia). Eine neue Fassung BITV 2.0 ist am 25. Mai 2019 in Kraft getreten (Barrierefreies Internet – Wikipedia). Sie setzt die EU-Richtlinie 2016/2102 (Webseiten und mobile Apps öffentlicher Stellen) um. Damit gelten für alle öffentlichen Websites strenge Vorgaben (WCAG 2.1 AA) – neue Sites mussten ab Sept. 2019 barrierefrei sein, bestehende ab Sept. 2020, mobile Apps ab Juni 2021 (Barrierefreies Internet – Wikipedia).
• European Accessibility Act (EAA): 2019 beschloss die EU den EAA, eine Richtlinie, die erstmals auch viele private Wirtschaftsbereiche zur Barrierefreiheit verpflichtet (Barrierefreies Internet – Wikipedia). Diese musste bis 2022 in nationales Recht übertragen werden; Umsetzung in der Praxis bis spätestens 28. Juni 2025 (Barrierefreies Internet – Wikipedia).
• Barrierefreiheitsstärkungsgesetz (BFSG): Das BFSG, beschlossen 2021, ist Deutschlands Umsetzung des EAA (Barrierefreiheitsstärkungsgesetz – Wikipedia) (Barrierefreiheitsstärkungsgesetz – Wikipedia). Es erweitert die Pflicht zur Barrierefreiheit auf private digitale Angebote in den genannten Sektoren, zusätzlich zu den bereits durch BGG/BITV abgedeckten öffentlichen Stellen (Barrierefreiheitsstärkungsgesetz – Wikipedia). Die konkreten technischen Anforderungen beziehen sich dabei auf bestehende Standards (insb. die EU-Norm EN 301 549). Diese Norm wiederum basiert auf den international anerkannten Web Content Accessibility Guidelines (WCAG) (Barrierefreies Internet – Wikipedia). Einfach gesagt: Was für Behördenwebsites schon gilt, gilt nun (angepasst an ihre Branche) auch für viele private Websites.
• Strafen und Durchsetzung: Die Einhaltung des BFSG wird durch Marktüberwachungsstellen kontrolliert. Bei Verstößen drohen je nach Fall Auflagen, ggf. Bußgelder oder in Extremfällen Untersagungsverfügungen. Zudem können sich Betroffene beschweren – etwa gibt es für öffentliche Seiten bereits eine Schlichtungsstelle nach BGG (Barrierefreies Internet – Wikipedia). Unternehmen sollten also nicht davon ausgehen, dass ein Ignorieren der Vorgaben folgenlos bleibt.

Technische Anforderungen an Websites (WCAG 2.1 & Co.)

Die Anforderungen an die Barrierefreiheit von Websites sind in Standards detailliert beschrieben. Die WCAG 2.1 Richtlinien (Web Content Accessibility Guidelines) definieren auf internationaler Ebene Erfolgskriterien, um Webinhalte perceivable, operable, understandable, robust (wahrnehmbar, bedienbar, verständlich, robust) zu machen. In der EU wurden diese Kriterien in die Norm EN 301 549 überführt, welche dem BFSG zugrunde liegt (Barrierefreies Internet – Wikipedia).

In der Praxis lassen sich die technischen Anforderungen in einzelne Themenbereiche unterteilen. Im Folgenden erläutern wir die wichtigsten Punkte für Websites – von Kontrasten über Alternativtexte bis zur Tastaturbedienung – und zeigen, wie sie konkret umgesetzt werden können. Dabei beziehen wir uns auf WCAG 2.1 Konformitätsstufe AA, was dem gesetzlichen Mindeststandard entspricht.

Textalternativen für Bilder und Medien

Nicht-textuelle Inhalte müssen durch Text-Beschreibungen zugänglich gemacht werden. Insbesondere gilt: Bilder auf Websites brauchen Alternativtexte („alt-Texte“). Der Alternativtext ist eine kurze Beschreibung, die im HTML im alt-Attribut des <img>-Elements hinterlegt wird. Screenreader lesen diesen Text vor, damit z.B. blinde Menschen erfahren, was das Bild darstellt.

Der Alternativtext soll direkt das Bild und seine visuelle Aussage wiedergeben, kurz und prägnant, und alle für das Verständnis nötigen Informationen aus dem Bild enthalten, die nicht schon im umliegenden Text stehen (HTML: Eine gute Grundlage für Barrierefreiheit – Webentwicklung lernen | MDN). Ein gutes Beispiel:

<img src="logo.jpg" alt="Firmenlogo der Beispiel AG">

– hier beschreibt alt klar den Inhalt (ein Logo der Firma).

Negative Beispiele wären alt=“bild1″ (keine hilfreiche Info) oder gar kein alt-Attribut (dann bleibt das Bild für Screenreader-Nutzer unzugänglich). Wenn ein Bild rein dekorativ ist und keinerlei inhaltliche Information trägt, soll es ein leeres alt=““ erhalten – so wird es von Hilfsmitteln ignoriert. Nicht zulässig ist, aussagekräftigen Content nur als Bild einzubinden ohne alt-Text (etwa Text im Bild) (HTML: Eine gute Grundlage für Barrierefreiheit – Webentwicklung lernen | MDN) (HTML: Eine gute Grundlage für Barrierefreiheit – Webentwicklung lernen | MDN).

Tipps für Alternativtexte: Versetzen Sie sich in die Lage, jemandem das Bild am Telefon zu beschreiben. Nennen Sie relevante Objekte, Personen, Aktionen etc., aber keine irrelevanten Details. Beispiel: Ein Produktfoto eines roten Pullovers könnte alt=“Roter Damenpullover aus Wolle, Vorderansicht“ haben – Farbe und Art des Kleidungsstücks sind relevant, der Hintergrund des Fotos eher nicht. Wenn der umliegende Text ohnehin schon sagt „roter Pullover“, muss der alt-Text das nicht wiederholen, sondern kann sich auf ggf. zusätzliche Merkmale konzentrieren (z.B. Muster, Ausschnittform). Kurze, präzise Alt-Texte sind ideal (HTML: Eine gute Grundlage für Barrierefreiheit – Webentwicklung lernen | MDN).

Neben statischen Bildern benötigen auch andere Medien Alternativen:

• Videos sollten mit Untertiteln für hörbehinderte Menschen versehen sein (mindestens für alle gesprochenen Inhalte und wichtige Sounds). Wenn ein Video rein informativ ist, kann man alternativ auch ein Transkript anbieten. Für wichtige Videos (z.B. Produktpräsentationen) ist zudem eine Audiodeskription wünschenswert, die visuelle Szenen für Blinde beschreibt – oft kann man dies auch lösen, indem der Sprecher im Video relevante Vorgänge verbal beschreibt.
• Audio-Inhalte (z.B. Podcasts, Audiodateien) sollten ein Transkript oder schriftliche Zusammenfassung erhalten, damit gehörlose Menschen den Inhalt erfassen können.
• Icons und Grafiken: Wenn Symbole verwendet werden (z.B. ein Drucker-Icon als Link auf eine Druckversion), sollte entweder ein alt-Text oder eine ARIA-Label vorhanden sein, die die Funktion beschreibt (z.B. aria-label=“Seite drucken“). Alternativ kann ein erklärender Text neben dem Icon stehen.
• CAPTCHA-Bilder: Vermeiden Sie nach Möglichkeit visuelle CAPTCHAs. Wenn sie nötig sind, bieten Sie barrierefreie Alternativen (z.B. Audio-CAPTCHA oder logikbasierte Fragen).

Beispiel Best Practice: Ein Online-Shop zeigt ein Produktfoto einer Handtasche. Der Artikelname („Ledertasche Modell X“) steht bereits als Überschrift daneben. Ein passender alt-Text könnte lauten: alt=“Schwarze Handtasche aus Leder, Modell X, Vorderansicht“. Dieser ergänzt die Überschrift um visuelle Details (Farbe, Material), ohne Redundanz. Würde die Tasche in mehreren Ansichten gezeigt, könnte man z.B. alt=“Rückansicht der Tasche“ bei den zusätzlichen Bildern nutzen.

Kontraste und Farbgestaltung

Kontrast ist für sehbehinderte Menschen entscheidend, um Texte lesen zu können. Der Mindestkontrast zwischen Vordergrund (Text) und Hintergrund sollte 4,5:1 betragen ( Understanding Success Criterion 1.4.3 | Understanding WCAG 2.0 ) (Ausnahme: großer fetter Text darf 3:1 haben, Logos sind ausgenommen ( Understanding Success Criterion 1.4.3 | Understanding WCAG 2.0 )). Dies entspricht den WCAG-Vorgaben auf Niveau AA. In der Praxis bedeutet das: Hellgraue Schrift auf weißem Grund oder gelber Text auf hellgrünem Button sind in der Regel zu kontrastarm. Stattdessen sollten z.B. dunkle Schrift auf hellem Hintergrund oder umgekehrt verwendet werden.

Ein einfaches Mittel zur Überprüfung ist die Nutzung eines Kontrast-Checkers (siehe Tools weiter unten). Dieser berechnet das Verhältnis aus Farbwerten. Beispiel: Schwarzer Text auf weißem Hintergrund hat den maximalen Kontrast von 21:1. Weiß auf mittelblau erreicht z.B. ~8:1, was gut ist. Hellgrau auf weiß kann hingegen nur ~1.5:1 sein und wäre unzulässig.

Neben Fließtext müssen auch Bedienelemente ausreichend kontrastieren. Zum Beispiel sollten Buttons und Links sich deutlich vom Hintergrund abheben, und ihr Text oder Symbol (z.B. Pfeil auf Button) ebenfalls kontrastreich sein. Auch Grafiken, die Informationen vermitteln (Diagramme, Icons mit Bedeutung), sollten kontrastreich gestaltet sein – ggf. durch Konturen oder Umrandungen, damit alle Details erkennbar sind (G18: Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text | Techniques for WCAG 2.0 ).

Farben nie als einziges Unterscheidungsmerkmal verwenden: Menschen mit Farbfehlsichtigkeit (z.B. Rot-Grün-Schwäche) könnten farbcodierte Infos sonst nicht verstehen. Wenn also z.B. Fehlermeldungen rot markiert werden, sollte zusätzlich ein Symbol oder Text darauf hinweisen (etwa „*Bitte korrigieren Sie die rot markierten Felder.“ und vielleicht ein ⚠️-Icon). Links sollten nicht nur durch Farbe, sondern z.B. auch durch Unterstreichung erkennbar sein.

Beispiel: Ein Kontaktformular markiert fehlende Eingaben rot. Besser: Zusätzlich erscheint unter dem Feld ein Text wie „Dieses Feld ist erforderlich.“ und oben eine Zusammenfassung „Bitte füllen Sie alle erforderlichen Felder aus.“ So verstehen auch farbblinde Nutzer*innen, was zu tun ist.

Tastaturbedienbarkeit und Navigation

Eine zentrale Anforderung ist, dass alle Funktionen einer Website mit der Tastatur bedienbar sind. Viele Menschen können keine Maus nutzen – z.B. Blinde, die mit Screenreader und Tastatur arbeiten, oder motorisch Eingeschränkte, die nur mit speziellen Tasten oder Schaltern navigieren. WCAG 2.1 Kriterium 2.1.1 schreibt vor, dass kein Keyboard-Trap entstehen darf (d.h. man darf nicht in einem Element „steckenbleiben“).

Konkret heißt das:

• Fokussteuerung: Mit der Tabulator-Taste muss man durch alle interaktiven Elemente (Links, Buttons, Eingabefelder, Menüpunkte etc.) in logischer Reihenfolge navigieren können. Ein drück auf Tab springt zum nächsten fokussierbaren Element, Shift + Tab zum vorherigen.
• Sichtbarkeit des Fokus: Es muss klar erkennbar sein, welches Element gerade den Tastaturfokus hat. Standardmäßig zeigen Browser einen blauen oder gepunkteten Rahmen um fokussierte Links/Buttons. Dieser Focus-Indikator sollte nicht per CSS entfernt werden! Falls doch angepasst, dann nur, um ihn deutlich sichtbar zu gestalten (z.B. ein kontrastreicher, deutlicher Rahmen oder Hintergrundänderung beim Fokussieren).
• Zugängliche Menüs und Steuerelemente: Navigations-Menüs sollten so umgesetzt sein, dass man sie per Tastatur öffnen und schließen kann. Beispiel: Ein Dropdown-Menü lässt sich per Tab fokussieren und mit Enter oder Pfeiltaste öffnen, danach mit den Pfeiltasten durch die Einträge gehen, und mit Enter auswählen. Wenn dafür JavaScript verwendet wird, müssen entsprechende ARIA-Attribute und Keyboard-Events programmiert sein.
• Kein Zwang zur Maus: Elemente wie Slideshows, Carousels oder Karten sollten alternative Bedienmöglichkeiten bieten (z.B. Pfeiltasten für ein Bildkarussell, statt nur Pfeil-Buttons anklickbar zu machen).
• Sprunglinks (Skip Links): Ganz oben auf der Seite kann ein versteckter Sprunglink eingefügt werden, der beim Fokussieren sichtbar wird, z.B. „Zum Inhalt springen„. So können Tastaturnutzer direkt zur Hauptinhalt springen und müssen nicht jedes Mal durchs Menü tabben. Dies ist in der BITV für Behörden vorgeschrieben und auch allgemein Best Practice.

Beispiel: Ein Webshop hat ein großes Navigationsmenü. Ein Nutzer ohne Maus drückt Tab: Zuerst erscheint am oberen Bildschirmrand ein Fokusrahmen auf „Zum Inhalt springen“ – durch Drücken von Enter springt er sofort zum Hauptbereich und überspringt das Menü. Alternativ könnte er auch Schritt für Schritt durchs Menü tabben. Beim Fokussieren eines Menüeintrags mit Untermenü öffnet sich dieses automatisch (oder per Enter), und er kann mit den Pfeiltasten darin navigieren. Alle Produktlinks sind ebenfalls per Tab erreichbar. Im Produktgalerie-Slider kann er mit Pfeil-Links/Rechts zwischen den Bildern wechseln. Dadurch ist der gesamte Kaufprozess ohne Maus machbar.

Strukturierung von Inhalten (Überschriften, Listen, Tabellen)

Eine gute semantische Struktur der Webseite ist ein Grundpfeiler der Barrierefreiheit. Überschriften, Absätze, Listen und Tabellen sollen korrekt mit HTML-Tags ausgezeichnet sein, damit assistive Technologien die Struktur erkennen.

Überschriften-Hierarchie: Jede Seite sollte eine Hauptüberschrift <h1> haben (z.B. der Seitentitel oder Artikelname), darunter Unterüberschriften <h2>, <h3> etc. in logischer Verschachtelung. Überschriften gliedern den Inhalt und ermöglichen es z.B. Screenreader-Nutzern, schnell von Überschrift zu Überschrift zu springen. Viele Screenreader bieten eine Übersicht aller Überschriften einer Seite, was als Inhaltsverzeichnis dient (HTML: Eine gute Grundlage für Barrierefreiheit – Webentwicklung lernen | MDN). Wenn diese Überschriften aussagekräftig benannt sind, findet man sich leicht zurecht. Wichtig: Niemals Überschriften lediglich optisch durch fett und groß darstellen, ohne die entsprechenden <h1>-<h6>-Tags – das würde für sehende Menschen zwar wie eine Überschrift aussehen, aber für Blinde nicht als solche erkennbar sein (HTML: Eine gute Grundlage für Barrierefreiheit – Webentwicklung lernen | MDN).

Listen und Aufzählungen: Verwenden Sie für Aufzählungen und nummerierte Schritte unbedingt die <ul>/<ol>- und <li>-Tags (ungeordnete/geordnete Liste). So wird die Gruppierung der Listenelemente deutlich. Screenreader kündigen z.B. an „Liste mit 5 Einträgen“ und lesen dann die Liste vor. Auch hier gilt: nicht einfach manuell „•“ Symbole einsetzen, sondern echte Listenelemente nutzen.

Tabellen: Tabellen sollen nur für echte tabellarische Daten genutzt werden, nicht fürs Layout. Eine Datentabelle muss Überschriften in der ersten Zeile und/oder ersten Spalte als <th>-Zellen haben. Verwenden Sie das scope-Attribut (<th scope=“col“> bzw. scope=“row“), um zu markieren, ob eine Überschrift sich auf die Spalte oder Zeile bezieht (HTML: Eine gute Grundlage für Barrierefreiheit – Webentwicklung lernen | MDN). Screenreader können dann beim Navigieren die Überschriften mit vorlesen, damit man weiß, in welcher Spalte/Zeile man sich befindet. Bei komplexeren Tabellen ggf. headers-Attribute nutzen, um Zellen Überschriften zuzuordnen.

Absätze und Abschnitts-Tags: Strukturieren Sie Text in Absätzen <p> – lange Textblöcke sollten in Sinnabschnitte gegliedert sein. Verwenden Sie bei Bedarf weitere semantische Container wie <article>, <section>, <nav> und <aside> um verschiedene Bereiche der Seite zu markieren (Hauptinhalt, Navigation, Randspalte etc.). Diese ARIA-Landmarks helfen ebenfalls bei der Orientierung, da Screenreader z.B. direkt zum <nav> springen können, wenn es korrekt deklariert ist.

Beispiel: Auf einer Nachrichtenseite ist ein Artikel folgendermaßen aufgebaut: Der Titel ist ein <h1>, Zwischenüberschriften sind <h2> (und ggf. weitere Unterebenen als <h3>). Darunter stehen die Inhalte in <p>-Absätzen. Wichtige Punkte sind in einer <ul>-Liste zusammengefasst. Am Ende gibt es vielleicht eine Tabelle mit Fakten; die Kopfzeile der Tabelle ist mit <th> als Überschriftzelle markiert. Neben dem Artikel (im HTML evtl. als <aside>) sind Links zu weiteren Artikeln aufgeführt, diese Liste hat eine Überschrift <h2> wie „Weitere News“. Der Header-Bereich und die Navigation sind mit <header> und <nav> gekennzeichnet. Diese klare Struktur ermöglicht allen Nutzer*innen – ob mit oder ohne Hilfstechnik – den Inhalt leicht zu erfassen. Zudem verbessert semantisch korrekter Code oft auch die SEO (Suchmaschinenbewertung), da z.B. Suchmaschinen Überschriften höher gewichten (HTML: Eine gute Grundlage für Barrierefreiheit – Webentwicklung lernen | MDN).

Barrierefreie Formulare und Interaktionen

Formulare (Kontaktformulare, Bestellprozesse, Suchfelder etc.) sind interaktive Elemente, die besondere Sorgfalt brauchen. Hier passieren häufig Barrierefreiheitsfehler, z.B. fehlende Labels. Wichtige Grundregeln für barrierefreie Formulare (Accessible forms | ASU IT Accessibility) (Accessible forms | ASU IT Accessibility):

• Jedem Eingabefeld muss ein zugehöriges Beschriftungs-Element (<label>) zugeordnet sein, das dessen Zweck beschreibt (Accessible forms | ASU IT Accessibility). Dies kann auf zwei Weisen erfolgen:
  • Entweder umschließt das <label> das Input-Feld direkt (z.B. <label>E-Mail: <input type=“email“ …></label>),
  • oder das <label> hat ein for-Attribut, das auf die id des entsprechenden Feldes verweist (z.B. <label for=“email“>E-Mail:</label> <input id=“email“ type=“email“ …>). Beide Varianten verbinden die Textbeschreibung „E-Mail“ mit dem Eingabefeld. Screenreader lesen dann beim Fokus z.B. „E-Mail, Eingabefeld“ vor.
• Keine alleinige Platzhaltertexte als Beschriftung nutzen: Ein grauer Platzhalter im Feld (placeholder) ist kein Ersatz für ein sichtbares Label – er verschwindet beim Tippen und Screenreader behandeln ihn unterschiedlich. Nutzen Sie Platzhalter nur als ergänzenden Hinweis, aber nicht als einzige Kennzeichnung. Wenn aus Designgründen kein sichtbares Label gewünscht ist, binden Sie es dennoch im Code ein und verstecken es per CSS (mit Techniken wie position:absolute; clip: rect(1px,1px,1px,1px)), damit es für Screenreader vorhanden bleibt (Accessible forms | ASU IT Accessibility).
• Gruppierung verwandter Felder: Verwenden Sie <fieldset> und <legend> um zusammengehörige Felder zu gruppieren (z.B. Adressfelder, oder eine Gruppe von Optionsfeldern) (Accessible forms | ASU IT Accessibility). Der <legend>-Text dient als übergeordnete Beschreibung der Gruppe.
• Listen bei Auswahlfeldern: Bei sehr langen Dropdown-Listen (<select> mit dutzenden <option>s) können Sie mittels <optgroup label=“…“> Unterteilungen vornehmen (Accessible forms | ASU IT Accessibility), damit Nutzer schneller navigieren können (Screenreader können von Gruppe zu Gruppe springen).
• Sichtbare Hinweise auf Pflichtfelder: Wenn Felder erforderlich sind, sollte dies im Label kenntlich gemacht werden (z.B. durch ein „*“ und/oder den Text „Pflichtfeld“) (Accessible forms | ASU IT Accessibility). Nicht erst beim Absenden klarmachen, dass etwas vergessen wurde, sondern idealerweise schon am Feld selbst.
• Fehlermeldungen benutzerfreundlich gestalten: Wenn ein Formular nicht korrekt ausgefüllt wurde, müssen klare Fehlermeldungen erscheinen (Accessible forms | ASU IT Accessibility). Diese sollten verständlich formuliert sein („Bitte geben Sie eine gültige E-Mail-Adresse ein.“ statt nur „Fehler!“), und sie sollten programmatisch mit dem fehlerhaften Feld verknüpft sein. Dies erreicht man z.B., indem man der Fehlermeldung ein id gibt und via aria-describedby=“fehler-id“ im Feld darauf verweist. Wichtig: Fehlermeldungen dürfen nicht nur farblich markiert sein, sondern auch textlich.
• Hilfetexte und Hinweise zugänglich machen: Viele Formulare haben Hilfetexte (z.B. „Ihr Passwort muss 8 Zeichen lang sein.“). Stellen Sie sicher, dass solche Hinweise von Screenreadern erfasst werden. Man kann sie z.B. in ein span mit eigener ID packen und dann das Eingabefeld mit aria-describedby darauf verweisen lassen. So wird der Hinweis vorgelesen, sobald das Feld fokussiert ist (Accessible forms | ASU IT Accessibility).
• Button-Beschriftungen: Buttons sollten klar sagen, was sie tun („Absenden“, „Suchen“, etc.). Wenn ein Button nur ein Icon hat (z.B. Lupe als Suchbutton), braucht er einen aria-label=“Suche absenden“ oder einen versteckten Text im Button.
• Accessible Rich Internet Applications (ARIA): Für komplexere Widgets (Datumsauswahl, modale Dialoge, etc.) müssen ARIA-Rollen und Attribute benutzt werden, um Status und Struktur mitzuteilen. Zum Beispiel role=“dialog“ und aria-modal=“true“ für einen modalen Dialog, sowie Tastatursteuerung dafür implementieren. ARIA ist jedoch ein fortgeschrittenes Thema – Grundsatz: “Use native HTML elements first, ARIA as last resort.” Natürliche HTML-Elemente (Buttons, Links, selects etc.) bringen viel eingebaute Barrierefreiheit schon mit, während ARIA gezielt dort hilft, wo Standard-HTML nicht reicht.

Beispiel – Kontaktformular:

<form action="/send" method="post">

  <fieldset>

    <legend>Kontaktinformationen</legend>

    <p>

      <label for="name">Name:<span title="Pflichtfeld">*</span></label>

      <input type="text" id="name" name="name" required>

    </p>

    <p>

      <label for="email">E-Mail:<span title="Pflichtfeld">*</span></label>

      <input type="email" id="email" name="email" required aria-describedby="emailHint">

      <small id="emailHint">Wir geben Ihre E-Mail nicht weiter.</small>

    </p>

  </fieldset>

  <p>

    <label for="message">Nachricht:</label><br>

    <textarea id="message" name="message" rows="5" cols="30"></textarea>

  </p>

  <button type="submit">Nachricht senden</button>

</form>

In diesem Beispiel sind alle Felder mit <label> versehen. Pflichtfelder sind mit einem Sternchen markiert (und required im Code erzwingt, dass der Browser bei Leerlassen eine Meldung zeigt). Für das E-Mail-Feld gibt es einen Hilfetext <small> mit der ID emailHint, auf den das Feld via aria-describedby verweist – Screenreader lesen also z.B. „E-Mail, Editierfeld, erforderlich, Wir geben Ihre E-Mail nicht weiter“ vor. Die Struktur ist mit <fieldset> und <legend> logisch gruppiert. Ein Nutzer mit Screenreader oder nur Tastatur kann dieses Formular problemlos verstehen und ausfüllen.

Vermeidung von Fehlern: Häufige Probleme in Formularen sind z.B. fehlende Labels – diese kann man mit Tools leicht aufspüren. Das WAVE Tool markiert Formularfelder mit ordnungsgemäßem Label mit einem grünen Icon, und solche ohne Label mit einem gelben Warnsymbol (Accessible forms | ASU IT Accessibility). So erkennt man schnell, wo noch Beschriftungen fehlen. Ebenso sollte man testen, ob das Drücken von Tab logisch von Feld zu Feld springt (Reihenfolge im HTML beachten oder tabindex entsprechend setzen, wobei übermäßiger Einsatz von tabindex vermieden werden sollte).

Weitere Aspekte und Anforderungen

Zusätzlich zu den oben genannten Kernpunkten gibt es weitere Anforderungen, die für vollständige Barrierefreiheit zu beachten sind:

• Sprache kennzeichnen: Im HTML-Tag der Seite sollte das lang-Attribut gesetzt sein (z.B. lang=“de“ für deutsch). Falls innerhalb der Seite Abschnitte in einer anderen Sprache stehen (z.B. ein englisches Zitat), sollte auch dafür das lang-Attribut am entsprechenden Element gesetzt werden. So können Screenreader die richtige Aussprache wählen.
• Keine automatischen Zeitlimits ohne Alternative: Wenn Inhalte sich automatisch verändern, rotieren oder nach Zeit ablaufen (z.B. ein automatischer Slider oder ein Logout-Timer), sollte der Nutzer die Kontrolle haben können – etwa Möglichkeit zum Pausieren eines Sliders, Warnung vor Session-Timeout mit Option zu verlängern, etc. Automatisch scrollende oder blinkende Inhalte können für manche Nutzer irritierend sein.
• Vermeidung von flackernden Inhalten: Inhalte, die hell flackern oder blitzen (insbesondere im Frequenzbereich um 3–50 Hz), können epileptische Anfälle auslösen. Solche Effekte sind unbedingt zu vermeiden oder müssen unter der Schwelle von drei Blitzen pro Sekunde bleiben.
• Responsive und zoom-freundliche Gestaltung: Nutzer sollten die Seite bis auf 200 % vergrößern können, ohne dass Inhalte verloren gehen oder unbedienbar werden (WCAG Kriterium 1.4.4). Ein flexibles, responsives Layout und skalierbare Schriftgrößen (relativ statt absolut in CSS) unterstützen dies. Auf Mobilgeräten sollte kein horizontales Scrollen nötig sein bei 200% Zoom.
• Eingabehilfen: Für mobile Websites sollte man darauf achten, richtige input-Typen zu verwenden (type=“email“, type=“tel“ etc.), damit auf Smartphones die passenden virtuellen Tastaturen erscheinen. Solche Feinheiten sind auch Teil der Accessibility (erleichtern die Bedienung).

Zusammenfassend lässt sich sagen, dass barrierefreies Webdesign sauberes HTML, durchdachtes UX-Design und Beachtung der Nutzerbedürfnisse erfordert. Die WCAG-Liste mag zunächst überwältigend wirken, aber viele Anforderungen ergeben sich aus grundsätzlichen Prinzipien: Inhalte textlich verfügbar machen, Interaktionen robust und alternativ steuerbar halten, und klare, konsistente Strukturen bieten. In Tabelle 2 sind die wichtigsten Anforderungen und Beispiele noch einmal übersichtlich zusammengefasst:

(Tabelle 2: Wichtigste Barrierefreiheits-Anforderungen für Websites mit Beispielen)

Mobile Apps und PDF-Dokumente (kurzer Überblick)

Die Pflicht zur Barrierefreiheit erstreckt sich neben Websites auch auf mobile Anwendungen (Apps) sowie auf digitale Dokumente, die bereitgestellt werden. An dieser Stelle soll dies nur kurz erwähnt werden, da der Fokus der Broschüre auf Websites liegt – dennoch ein paar Hinweise:

Mobile Apps: Für die von BFSG erfassten Dienste müssen auch deren mobile Apps barrierefrei sein. Die Kriterien ähneln den WCAG-Vorgaben, angewendet auf Apps. Praktisch heißt das: Apps sollten mit VoiceOver (iOS) bzw. TalkBack (Android) vollständig bedienbar sein. Entwickler müssen z.B. Bedienelemente mit Accessibility-Labels versehen, die Reihenfolge des Fokus bei Swipe-Gesten bestimmen, ausreichende Kontraste auch im App-Design sicherstellen und Gesten-Alternativen bieten (eine Funktion, die nur per komplexer Geste erreichbar ist, muss auch anders erreichbar sein). Die EN 301 549 enthält auch für Software und mobile Anwendungen genaue Anforderungen. Unternehmen, die Apps anbieten (z.B. Banken mit Banking-App, Verkehrsbetriebe mit Fahrplan-App), sollten ein Accessibility-Review ihrer Apps vornehmen. Ab Juni 2025 müssen neue Apps barrierefrei sein; bestehende sollten entsprechend aktualisiert werden.

Dokumente (PDF & Co.): Häufig stellen Websites PDFs oder andere Dokumente zum Download bereit (Berichte, Formulare, Produktinformationen). Solche Dateien sind Teil des Webangebots und müssen ebenfalls barrierefrei sein, sofern sie nach dem Stichtag veröffentlicht werden. Ein barrierefreies PDF beinhaltet z.B. Textschichten (nicht nur eingescannte Bilder), korrekte Überschriften-Tags, Lesezeichen, Alternativtexte für Bilder, Tabellenstruktur und eine logische Lese-Reihenfolge. Es gibt PDF/UA als Standard für barrierefreie PDFs. Tools wie Adobe Acrobat Pro oder PAC (PDF Accessibility Checker) können zur Prüfung genutzt werden. Alternativ sollten HTML-Seiten bereitgestellt werden, wo möglich, da HTML in der Regel einfacher zugänglich ist als komplexe PDF-Dateien.

Office-Dokumente (Word, PowerPoint) sollten ebenfalls nach Accessibility-Grundsätzen erstellt sein (z.B. mit richtigen Überschriftformatvorlagen, Beschriftungen für Grafiken etc.), bevor sie als PDF exportiert werden. Bei technischen Dokumentationen oder Berichten ist es empfehlenswert, auf Anfrage auch alternative Formate (HTML, barrierefreie PDF) bereitzuhalten.

Kurz gesagt: Wenn Ihr Webangebot neben HTML-Seiten auch andere digitale Inhalte enthält, denken Sie daran, auch diese inklusiv zu gestalten. Oft gelten hier dieselben Prinzipien: Text statt Bild, Struktur statt visuellem Layout, Beschriftungen statt reiner Optik.

Tools und Hilfsmittel zur Unterstützung

Die Umsetzung und Prüfung von Barrierefreiheit kann mit verschiedenen Tools erleichtert werden. Es gibt eine Reihe von kostenlosen Prüfwerkzeugen, mit denen Webentwickler und Redakteure ihre Seiten analysieren können. Hier eine Auswahl wichtiger Hilfsmittel:

• WAVE Web Accessibility Evaluation Tool: Ein Browser-Add-on (oder Online-Dienst) von WebAIM, das eine Seite analysiert und grafisch Hinweise einblendet. Es markiert z.B. vorhandene Alt-Texte, fehlende Formularlabels, Kontrastprobleme u.v.m. Für Entwickelnde ist es hilfreich, weil man direkt auf der eigenen Seite farbige Icons und Umrandungen sieht, wo etwas zu verbessern ist. Wie erwähnt, zeigt WAVE z.B. ein grünes Symbol bei korrekt beschrifteten Feldern und ein gelbes Warnsymbol bei fehlenden Labels (Accessible forms | ASU IT Accessibility). WAVE ist verfügbar für Chrome und Firefox.
• axe by Deque Systems: Ein ebenfalls als Browser-Erweiterung verfügbares Tool, das auf Knopfdruck eine Seite scannt und einen Bericht von erkannten Problemen gemäß WCAG ausgibt. Axe integriert sich z.B. in die Chrome Developer Tools. Es listet Fehler (z.B. „Bild ohne alt-Attribut“) und gibt Hinweise zum Beheben. Viele automatische Test-Suiten (Nightwatch, Selenium usw.) lassen sich mit Axe regeln erweitern, um Barrierefreiheit in Continuous Integration zu prüfen.
• Color Contrast Analyzer: Ein kleines Tool (von TPGi, ehem. Paciello Group) für Windows/Mac, mit dem man beliebige Farb-Paare auf dem Bildschirm prüfen kann. Man wählt per Pipette Vorder- und Hintergrundfarbe, und das Tool zeigt das Kontrastverhältnis und ob es WCAG-konform ist (für AA und AAA). So kann man Design-Entscheidungen schnell validieren. Alternativ bieten Webseiten wie WebAIM Contrast Checker ähnliche Funktionalität im Browser.
• Screenreader zum Testen: Um ein Gefühl für die Nutzbarkeit zu bekommen, empfiehlt es sich, selbst mal mit einem Screenreader zu testen. Unter Windows ist NVDA kostenlos verfügbar – nach kurzer Einarbeitung kann man damit die eigene Seite „von hinten durchs Auge“ erleben. Auf dem Mac ist VoiceOver eingebaut (Cmd+F5 schaltet es ein). Prüfen Sie damit zum Beispiel: Lässt sich per Tab überall hin navigieren? Werden sinnvolle Beschriftungen vorgelesen? Ist die Reihenfolge logisch? – Das sind Dinge, die automatische Tools nicht immer vollständig erkennen, weshalb ein manueller Test mit Assistenztechnik sehr wertvoll ist.
• Browser-Entwicklertools: Moderne Browser haben oft eingebaute Accessibility-Inspektion. In Chrome z.B. gibt es im DevTools unter „Lighthouse“ einen Audit für Accessibility, der eine Prozentbewertung liefert und Problembereiche aufzeigt. Edge und Firefox haben ähnliche Funktionen. Diese ersetzen zwar keine gründliche Prüfung, geben aber einen guten Überblick. Ebenso kann man im DOM-Inspector die berechneten Accessibility-Properties von Elementen einsehen (Rolle, Name, Beschreibungen), um zu kontrollieren, ob z.B. ein ARIA-Label angekommen ist.
• BITV-Test: In Deutschland gibt es den BITV-Test (bitv-test.de), ein umfangreiches Prüfverfahren mit 60 Prüfschritten, entwickelt im Projekt „BIK – barrierefrei informieren und kommunizieren“. Dieser wird oft von Experten durchgeführt, kann aber auch zur Selbstbewertung dienen. Er deckt alle WCAG-Kriterien systematisch ab. Zwar ist der vollständige BITV-Test sehr detailliert, doch auf der Website gibt es Checklisten und Beispiele, die hilfreich sein können, um nichts Wichtiges zu übersehen.

Tipp: Eine Kombination aus automatisierten Checks und manuellen Tests führt zum besten Ergebnis. Nutzen Sie Tools wie WAVE oder axe, um einfach erkennbare Fehler schnell aufzuspüren (sie finden z.B. fehlende Alt-Texte, fehlende Labels, eindeutige Kontrastverstöße zuverlässig). Danach sollten aber immer kompetente Tester – idealerweise auch selbst Nutzer*innen mit Behinderung – die Anwendung prüfen. Nur so erkennt man z.B. verständlichkeitsbezogene Probleme oder spezielle Nutzungsanforderungen.

Best Practices und Ausblick

Bei der Umsetzung von Web-Barrierefreiheit hat es sich bewährt, frühzeitig im Projekt an die Anforderungen zu denken und sie fest im Prozess zu verankern. Einige Best Practices zum Abschluss:

• Design-Phase: Schon im Design sollten Farbkontraste und Schriftgrößen berücksichtigt werden. Legen Sie eine Farbpalette fest, die WCAG-konform ist. Planen Sie genügend Platz für Bedienhilfen (z.B. sichtbar werdende Fokusrahmen, Sprunglinks) ein. Ein Designer sollte wissen, dass z.B. Platzhaltertexte nicht als alleinige Labels gedacht sind, etc.
• Entwicklungs-Phase: Nutzen Sie HTML5 semantische Elemente und avoiden Sie unnötige div-Spaghetti. Binden Sie direkt in der Entwicklung Tools wie axe in die Testpipeline ein. Erstellen Sie Coding-Guidelines für Accessibility (z.B. immer <button> statt div für klickbare Elemente, immer alt bei <img>, etc.).
• Inhalte pflegen: Redakteur*innen sollten geschult werden, wie man barrierefreie Inhalte schreibt – z.B. Überschriften in richtiger Reihenfolge, Beschreibungen für Bilder im CMS-Feld „Alternativtext“ eintragen, verständliche Linktexte wählen („Jetzt anmelden“ statt „Hier klicken“), usw. Ein Redaktionshandbuch mit Do’s and Don’ts kann hilfreich sein.
• Testing und Feedback: Führen Sie Nutzertests mit Personen mit Behinderung durch, wenn möglich. Selbst ein kleiner Test mit 1-2 Screenreader-Nutzern kann wertvolle Erkenntnisse bringen (z.B. ob Ihre ARIA-Beschriftungen wirklich sinnvoll vorgelesen werden). Nutzen Sie Browser-Erweiterungen und Validierungsdienste regelmäßig während der Entwicklung, nicht erst am Ende.
• Kontinuierliche Verbesserung: Barrierefreiheit ist kein einmaliges Abhaken, sondern ein fortlaufender Prozess. Technologien und Hilfsmittel entwickeln sich weiter. Halten Sie Ihre Website aktuell, beheben Sie neu auftretende Probleme (z.B. wenn ein Inhaltsmodul hinzugefügt wird, prüfen Sie es gleich auf Accessibility). Bleiben Sie auch auf dem Laufenden über Updates der WCAG – Version 2.2 steht vor der Tür, WCAG 3.0 in Planung, was künftig weitere Aspekte bringen könnte.

Ab 2025 wird Barrierefreiheit ein selbstverständlicher Teil von professionellen Webauftritten sein müssen – ähnlich wie Responsivität oder Datenschutz heute. Für Webagenturen bedeutet dies einerseits eine Herausforderung, sich Know-how anzueignen, andererseits auch eine Chance: Sie können Ihren Kunden einen echten Mehrwert bieten und sich durch Qualität und inklusives Design auszeichnen. Kunden wiederum profitieren von erweiterter Reichweite (rund 20% der Bevölkerung haben eine anerkannte Behinderung, und auch viele ältere Menschen schätzen barrierearme Angebote) und vom positiven Image, alle Nutzer willkommen zu heißen. Zudem verbessern barrierefreie Seiten oft die Usability insgesamt – klare Strukturen und Texte kommen jedem zugute, nicht nur Menschen mit Behinderung.

Fazit: Die Anforderungen des BFSG mögen komplex wirken, doch mit den richtigen Methoden lassen sie sich erfolgreich umsetzen. Diese Broschüre hat die wichtigsten Leitlinien und Beispiele gegeben. Nutzen Sie die Referenzen und Tools, um sich weiter in die Tiefe einzuarbeiten. Barrierefreiheit ist Teamarbeit – Designer, Entwickler, Redakteure und Auftraggeber müssen an einem Strang ziehen. Beginnen Sie am besten heute damit, Ihre Webangebote Schritt für Schritt barrierefrei zu gestalten. So sind Sie bestens vorbereitet, wenn am 28. Juni 2025 die neuen Regelungen in Kraft treten (Barrierefreies Internet – Wikipedia) – und Sie tun gleichzeitig etwas Gutes für eine inklusivere digitale Welt.

Quellen und weiterführende Links

• Bundesministerium für Arbeit und Soziales (BMAS): Barrierefreiheitsstärkungsgesetz (BFSG) – Gesetzestext und Informationen. (BGBl. 2021 I S. 2970) (Barrierefreiheitsstärkungsgesetz – Wikipedia) (Barrierefreiheitsstärkungsgesetz – Wikipedia).
• Europäische Union: Richtlinie (EU) 2019/882 (European Accessibility Act) – EU-Vorgaben für barrierefreie Produkte und Dienstleistungen (Barrierefreies Internet – Wikipedia).
• Wikipedia: Barrierefreies Internet – Hintergrund zu gesetzlichen Regelungen, WCAG und Studienlage (Barrierefreies Internet – Wikipedia) (Barrierefreies Internet – Wikipedia).
• W3C Web Accessibility Initiative: Web Content Accessibility Guidelines (WCAG) 2.1 – Internationale Richtlinien für barrierefreie Webinhalte ( Understanding Success Criterion 1.4.3 | Understanding WCAG 2.0 ).
• W3C WAI: Understanding WCAG 2.0/2.1 – Erklärungen zu Erfolgskriterien (z.B. Kontrast min. 4.5:1) ( Understanding Success Criterion 1.4.3 | Understanding WCAG 2.0 ).
• MDN Web Docs: HTML: A good basis for accessibility – Tutorial (englisch) für HTML-Grundlagen inkl. Alternativtexten (HTML: Eine gute Grundlage für Barrierefreiheit – Webentwicklung lernen | MDN) und Strukturierung (HTML: Eine gute Grundlage für Barrierefreiheit – Webentwicklung lernen | MDN). Deutsche Übersetzung verfügbar.
• Accessible University (ASU) Guides: Accessible Forms – Best Practices für barrierefreie Formulare (Accessible forms | ASU IT Accessibility) (Accessible forms | ASU IT Accessibility).
• WebAIM: Contrast Checker – Online-Tool zur Kontrastprüfung, WAVE Tool – Accessibility-Checker im Browser (zeigt u.a. Formularlabels an) (Accessible forms | ASU IT Accessibility).
• Deutsches BITV-Test Verfahren (BIT inklusiv) – Prüfkriterienkatalog und Selbstbewertungs-Tool für Barrierefreiheit im Web.

(Stand: April 2025 – alle Informationen und Rechtsgrundlagen nach bestem Wissen recherchiert. Bei gesetzlicher Beratung wenden Sie sich bitte an offizielle Stellen oder Rechtsberater.)