Brauchen wir barrierefreie Webauftritte?

Eindeutig: Ja!  Wenn Du Webauftritte möglichst barrierearm gestaltest, ermöglichst Du Menschen mit Behinderung eine bessere Teilhabe an der Arbeitswelt und einen einfacheren Zugang zum gesellschaftlichen Leben. Barrierefreiheit verbessert die Lebensqualität von Menschen mit Behinderung und ihren Angehörigen. Es ermöglicht ein unabhängiges und selbstbestimmtes Leben.
Nicht nur Rollstuhlrampen oder Blindenleitsysteme in Gebäuden sind hier hilfreich, sondern auch Websites sollten möglichst barrierearm sein.

Welche Arten von Behinderungen gibt es? 

Barrierefreie Webauftritte richten sich in erster Linie an Nutzer mit folgenden Einschränkungen:

• Sehschwäche oder Blindheit
• Motorische Einschränkungen
• Kognitive Einschränkungen und Sprachbarrieren
• Epilepsie
• Taubheit 

Hilfsmittel und unterstützende Lösungen

Um Websites trotz der oben genannten Einschränkungen nutzbar zu machen, gibt es unterschiedliche Lösungen.

• Sprachausgabe: Blinde oder sehbehinderte Menschen können Screenreader nutzen, um sich eine Website vorlesen zu lassen. Hier gibt es Lösungen, wie VoiceOver unter MacOS, Narrator, NVDA oder Jaws unter Windows oder diverse Plugins für den Browser.
• Blindenschrift: Eine weitere Möglichkeit für Sehbehinderte ist das Nutzen von Blindenschrift oder Braillezeilen (https://de.wikipedia.org/wiki/Braillezeile), um sich Schrift zu ertasten.
• Spezielle Eingabegeräte: Zum Beispiel Spezialmäuse- und Tastaturen.
• Gebärdensprache: Menschen mit eingeschränktem Sprach- und Hörvermögen können sich mit Gebärdensprache verständlich machen.
• Untertitel: Untertitel in Videos oder Transkriptionen ermöglichen es Menschen mit eingeschränktem Hörvermögen, Inhalte in Videos besser zu verstehen.
• Leichte Sprache: Hilfreich für Internetnutzer mit kognitiven Einschränkungen wie dem Down-Syndrom oder um Sprachbarrieren zu überwinden.

Rechtliche Rahmenbedingungen

Das BFSG (das Barrierefreiheitsstärkungsgesetz) tritt am 28. Juni 2025 in Kraft siehe https://www.revier.de/news/detail/barrierefreiheitsstaerkungsgesetz-BFSG-2025/.
Das Barrierefreiheitsstärkungsgesetz löst die BITV Verordnung (Barrierefreie Informationstechnologie-Verordnung) aus dem Jahre 2002 bzw. mit der Version 2.0 aus dem Jahre 2019 ab. Das BFSG ist der BITV Verordnung sehr ähnlich.
Das BFSG setzt die EU-Richtlinie des European Accessibility Act (EAA) um. Das EAA orientiert sich dabei größtenteils an den Richtlinien der WCAG.

Das BFSG richtet sich in erster Linie an Onlineshops, E-Commerce-Betreiber und darüber hinaus generell an Plattformen, auf denen Dienstleistungen, Services und Produkte und andere geschäftliche Transaktionen durchgeführt werden können. Es richtet sich nicht nur an Websitebetreiber, sondern ganz generell an Hersteller von Produkten wie z.B. Computern, Tablets, Fernsehgeräten mit Internetzugang oder Automaten wie Geld- oder Ticketautomaten.
Welche Interaktionsmöglichkeiten auf Webseiten nun genau betroffen sind, lässt sich im Moment, also im Sommer 2024 noch nicht genau sagen, hier muss sich noch zeigen, wie das Gesetz im Detail ausgelegt wird. Kleinunternehmen sind auf jeden Fall von dem Gesetz nicht betroffen. Das heißt, Unternehmen mit weniger als zehn Mitarbeitern und einem jährlichen Gesamtumsatz von weniger als 2 Millionen Euro werden hier nicht in die Pflicht genommen.
An dieser Stelle noch mal der Hinweis: Dieser Blog ist keine Rechtsberatung. Im Zweifelsfall solltest Du dir also rechtlichen Beistand einholen.

Die Gesetze und Verordnungen zum Thema Barrierefreiheit orientieren sich in der Regel an den sogenannten WCAG-Richtlinien, hier lohnt sich ein genauerer Blick …

Was sind die WCAG?

WCAG steht für „Web Content Accessibility Guideline“, auf Deutsch also Richtlinien für barrierefreie Webinhalte. Die Web Content Accessibility Guidelines sind ein international anerkannter Standard für barrierearme Webauftritte. Die Richtlinien werden vom World Wide Web Consortium (W3C) entwickelt und gepflegt.
Die WCAG enthalten drei Konformitätsstufen:

• A: Die niedrigste Konformitätsstufe, die grundlegende Anforderungen an die Barrierefreiheit erfüllt.
• AA: Die mittlere Konformitätsstufe, die einen höheren Grad an Barrierefreiheit gewährleistet.
• AAA: Die höchste Konformitätsstufe, die den höchsten Grad an Barrierefreiheit fordert.

Die WCAG werden regelmäßig aktualisiert, um neuen Technologien und Bedürfnissen Rechnung zu tragen. Siehe https://www.w3.org/TR/WCAG21/ 

Diese Richtlinien der WCAG sind allerdings nicht immer ganz einfach zu interpretieren, deswegen findest Du unten auf der Seite eine hilfreiche Checkliste zum Erstellen von barrierefreien Websites.

Schau Dir dazu auch gerne den Quellcode in meiner entsprechenden Beispieldatei unter https://web-einfach-machen.de/Kursmaterialien/Barrierearme_Websites/ an.

---

Websites auf Barrierefreiheit testen

Wie testen wir jetzt eine Website auf Barrierefreiheit? Hier gibt es unterschiedlichste Werkzeuge und Methoden. Dazu gehören Screenreader genauso wie Kontrast-Checker oder auch automatisierte Prüfungen mit Lighthouse, Axe oder Wave.

Werkzeuge

Nutze die Wave-Browsererweiterung zum Testen von Websites → https://wave.webaim.org/extension/.
Hilfreich ist auch die Axe Browsererweiterung → https://www.deque.com/axe/browser-extensions/, genauso wie Lighthouse in Chrome → https://developer.chrome.com/docs/lighthouse/overview?hl=de und https://pagespeed.web.dev/.

Und teste die Website mit einem Screenreader wie VoiceOver, NVDA oder Narrator. 

Screenreader

Um Websites zu testen, solltest Du einen Screenreader nutzen. Auch wenn eine nicht-blinde Testperson mit einem Screenreader anders arbeitet, als ein blinder Nutzer, ist ein Screenreader ein hilfreiches Werkzeug in der Webproduktion.

Unter MacOS hast Du bereits einen Screenreader eingebaut, der sich „VoiceOver“ nennt. Du kannst ihn unter Systemeinstellungen → Barrierefreiheit einschalten. Ebenfalls lässt sich VoiceOver über die Command-Taste + F5 einschalten. Wenn Du ein MacBook nutzt, auf dem Du vielleicht keine Funktionstasten F1 bis F12 findest, dann lässt sich die Taste F5 ggf. durch Drücken der Funktion-Taste (fn) unten links auf der Tastatur des MacBooks anzeigen.

Mit VoiceOver arbeiten

Du solltest Dir, wenn Du mit diesem Screenreader arbeitest, ein paar grundlegende Tastaturbefehle merken. Die wichtigste davon ist die VoiceOver Modifikator-Taste. Und das ist standardmäßig Control + Alt-Taste (oder Control und die Option-Taste; die Alt-Taste wird auch Option-Taste genannt). Also wenn ich von der Tastenkombination VO Rede (VO meint VoiceOver) dann wäre das auf meinem Mac die Tastenkombination Control- plus die Alt-Taste.

Um die Sprachausgabe anzuhalten, drückst Du einfach nur die Control-Taste.

Und um einen Mausklick auszuführen, drückst Du Control – Option plus Leerzeichen-Taste.

Jetzt ist die Frage, wie man sich am besten als sehbehinderter Mensch durch einen Text durchnavigiert. Und tatsächlich ist es so, dass die meisten, die einen Screenreader nutzen, sich mit Hilfe von Überschriften in einen Artikel orientieren. Um mit Hilfe der Überschriften zu navigieren, drückst Du Control – Option – Command und H, um von einer Überschrift zur nächsten zu springen.
Und noch hilfreicher ist in VoiceOver der sogenannte Rotor, den Du mit dem Tastaturkürzel Control – Option und U öffnest. Neben Überschriften findest Du im Rotor auch Links, Formularelemente, Tabellen oder Orientierungspunkte genauso wie Fensterspots.

Und mit der Tastenkombination VO + A (Control- plus die Alt-Taste plus A) lässt Du Dir den gefunden Text vorlesen.

Mehr dazu findest Du auf der Seite https://dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts.

Kleiner Tipp am Rande: es ist gar nicht verkehrt, wenn man sich die Vorlesestimme noch ein wenig konfiguriert. Für den Anfang ist es vielleicht besser, die Sprechgeschwindigkeit etwas zu reduzieren und die Standardstimme habe ich bei mir auf „Siri Stimme zwei“ eingestellt. Das lässt sich in den Systemeinstellungen zur Barrierefreiheit anpassen, aber es gibt auch Kurzbefehle in VoiceOver selber, um Stimme und Sprechgeschwindigkeit zu ändern.

In den Systemeinstellungen hast Du übrigens auch die Möglichkeit, ein VoiceOver Training zu starten, was durchaus empfehlenswert sein kann.

Unter Windows 11 gibt es ebenfalls einen eingebauten Screenreader, der nennt sich Narrator. Die dort verwendeten Stimmen klingen angenehm und natürlich. Weitere Screenreader für Windows wären Jaws oder die OpenSource-Software NVDA.

Führe automatisierte und manuelle Tests auf Barrierefreiheit durch

Für eine umfassende Prüfung von Webseiten auf Barrierefreiheit führt kein Weg an einer manuellen Prüfung vorbei. Aber zunächst solltest Du ein paar automatisierte Tests durchführen. Dazu nutzt Du am besten die bereits oben erwähnten Werkzeuge wie Wave, Lighthouse und ähnliche.

Nach den automatischen Tests folgen die manuellen Tests auf mögliche Fehlerquellen. Natürlich gehört vor allem ein Durchlauf mit einem Screenreader wie VoiceOver zum manuellen Test. Zu den ersten generellen Tests gehört das Prüfen der Navigation. Navigiere mit der Tastatur durch die Seite und kontrolliere, ob Du per Skiplink direkt zum Inhalt springen kannst und ob alle anderen Links, die Navigation, wie auch die Formular-Bedienung funktionieren. Auf welche Fehlerquellen Du dabei achten solltest, beschreibe ich im Folgendem:

Fehlerquellen erkennen

Vermeide potentielle Fehlerquellen auf Deiner Website und untersuche Deine Website manuell auf folgende Barrieren:

Farbe und Farbkontraste

Benutze zum Kennzeichnen von Texten zum Beispiel von Warnhinweisen nicht nur Farben allein. Also wenn ein Anwender nur durch die Farbe Rot erkennen kann dass er hier einen Warnhinweis vor sich hat oder ob eine Eingabe in einem Formular fehlerhaft ist, dann ist das für farbenblinde Besucher (beispielsweise mit einer rot-grün-Sehschwäche) oder für komplett blinde Benutzer schwierig. Benutze statt nur eine Farbe zu verwenden, auch noch andere Hinweise, die dann auch von einem Screenreader vorgelesen werden können.

Und vermeide zu geringe Farbkontraste. Ein Kontrast Checker wäre z.B. https://webaim.org/resources/contrastchecker/. Nach WCAG AA brauchen wir für normalen Text ein Kontrastverhältnis von 4,5 zu 1. Für großen Text ab 24 Pixel Schriftgröße wird ein Kontrastverhältnis von 3 zu 1 gefordert.
Für AAA brauchen wir für normalen Text ein Kontrastverhältnis von 7 zu 1 und für größeren Text ab 24 Pixel Schriftgröße ein Kontrastverhältnis von 4,5 zu 1.

Für weitere Infos zum Thema Farbkontraste kann ich Dir die Seite https://web.dev/learn/accessibility/color-contrast?hl=de empfehlen.

Alt Texte

Bilder sollten ein Alt-Attribut haben, siehe https://www.w3schools.com/tags/att_img_alt.asp

Alt-Texte sind für Bilder Pflicht, allerdings nicht notwendigerweise bei dekorativen Bildern, die keinen inhaltlichen Wert haben. Zum Beispiel, wenn du an das Icon eines Vergrößerungsglases denkst (für die Suche innerhalb der Website), dann muss das nicht vom Screenreader vorgelesen werden.
Hier kannst du zwar ein Alt-Attribut setzen, das dann aber leer lassen, also zwischen den Anführungszeichen einfach nichts schreiben. Denn ansonsten würde der Screenreader eventuell den Dateinamen des Bildes vorlesen, was wenig Sinn macht.
Wenn Du am Ende des Alt-Textes einen Punkt setzt, dann bringt es den Screenreader dazu, ihn auch als Satzende vorzulesen, indem er die Stimme am Ende absenkt.

Hyperlinks

Navigiere mit der Tastatur durch die Seite und kontrolliere, ob du per Skiplink zum Inhalt direkt springen kannst und ob alle anderen Links, die Navigation, wie auch die Formular-Bedienung funktionieren.

Links sollten eindeutig sein und der Text sollte dem Nutzer verständlich anzeigen, wohin er gelangt. Ein „Klick hier“ sagt beispielsweise nicht eindeutig, wohin das Linkziel führt. Wenn Du aber den umgebenden Satz komplett mit als Hyperlink formatierst, wird die Sache schon klarer.

An dieser Stelle ist es auch die Frage ob es sinnvoll ist, Hyperlinks ohne Unterstrich zu formatieren wie das ja üblicherweise passiert. Barriereärmer ist es auf jeden Fall, den Hyperlink mit einem Unterstrich zu kennzeichnen.

Formulare

Es ist hilfreich, wenn Du in Deinen Formularen sowohl Labels wie auch Platzhalter und andere Attribute verwendest. Hier sollten aber der Platzhalter-Text und der Text für das Label nicht identisch sein; das Label sollte das Input-Feld sinnvoll beschreiben und der Platzhalter Text sollte tatsächlich ein Beispiel sein, wie dieses Formularfeld ausgefüllt werden sollte.
Mehr zum Thema Formulare findest Du auf https://webaim.org/techniques/forms/, https://blog.pope.tech/2022/10/03/a-beginners-guide-to-form-accessibility/ oder https://www.youtube.com/watch?v=4Sei-7XUscA.

Navigation

Wenn Du weißt, wie sich sehbehinderte Nutzer von Screenreadern auf Webseiten orientieren, dann fällt auf, dass fast 70% der Nutzer vorzugsweise über die Überschriften navigieren.
Sie benutzen also die Überschriften in der HTML Seite, lassen sich die Überschriften vorlesen, entscheiden dann, ob ein Inhalt für sie relevant ist und lassen sich den Inhalt ggf. vorlesen.

Abgesehen von den Überschriften können sehbehinderte Nutzer auch die Landmark Regions (Orientierungspunkte) nutzen, um sich auf einer Webseite zu orientieren. Das können Elemente wie nav, header, main, section, footer und ähnliche sein. Das Navigieren ist dabei einfacher, wenn das HTML semantisch korrekt ist.

Tabindex

Mit Hilfe der Tastatur kann man sich in einer Webseite von einem Link zum nächsten navigieren. Das Attribut „tabindex“ ermöglicht es hier, HTML-Elemente mit der Tab-Taste fokussierbar zu machen und deren relative Reihenfolge für die sequentielle Fokusnavigation zu bestimmen. Siehe https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex.

Du kannst tabindex= „0“ jedem Element hinzufügen, das einen Fokus erfordert, welches sonst nicht über die Tastatur erreicht werden kann.

Man muss übrigens nicht notwendigerweise mit dem Attribut tabindex arbeiten, um die Reihenfolge der Erreichbarkeit von Hyperlinks oder Formularelementen anzupassen. Du kannst es auch einfach früher oder später im Dom also im Quelltext anordnen. Also je früher es im DOM auftaucht, desto höher ist seine Tab-Order.

Weitere Informationen zum tabindex-Attribut findest Du auf https://web.dev/articles/using-tabindex?hl=de.

Positionierte Elemente

Es kann einigermaßen verwirrend sein, wenn z.B. ein Element unten auf der Seite fixiert positioniert ist, aber im Quelltext ziemlich weit oben auftaucht. Das kann den Nutzer eines Screenreaders verwirren. Das Problem lässt sich einfach lösen, indem Du das auf der Seite fixiert positionierte Element im Quelltext einfach nach unten verschiebst.

Semantisch sinnvolles HTML verwenden

In HTML5 hast Du Elemente, wie main, footer, button und viele mehr, um den Inhalt semantisch korrekt auszuzeichnen. Du erleichterst die Nutzung eines Screenreaders, wenn Du damit arbeitest.
Es versteht sich, dass das HTML Deines Webprojekts valide ist. Zu einem Accessibility Test gehört auch eine Validierung; das HTML kannst Du dafür durch einen Validator wie https://validator.w3.org/ schicken.

Weitere Informationen zur Inhaltsstruktur von Webseiten und dem Einsatz von semantisch korrekten HTML-Elementen findest Du unter https://web.dev/learn/accessibility/structure?hl=de und https://web.dev/learn/accessibility/more-html?hl=de.

Biete Inhalte auch in leichter Sprache an

Für Nutzer, die Probleme mit komplexen Zusammenhängen, die Sprachbarrieren oder Leseschwierigkeiten haben, solltest Du Deine Inhalte auch in leichter Sprache anbieten.
Siehe https://www.w3.org/WAI/tips/writing/ und https://www.w3.org/WAI/WCAG2/supplemental/#cognitiveaccessibilityguidance.

Maßeinheiten

Ein Wort zum Thema Maßeinheiten, um Schriftgrößen anzugeben: Nutze bitte nicht px (Pixel) sondern „rem“. Falls ein Nutzer in seinem Webbrowser die Standardschriftgröße geändert hat, wird das berücksichtigt, wenn Du mit der Einheit rem arbeitest.

Stell um das zu testen in Deinen Browservoreinstellungen die Standardtextgröße von 16 Pixel auf 60 Pixel und schau, ob die Seite immer noch lesbar angezeigt wird und ob die geänderte Standard-Schriftgröße von der Website berücksichtigt wird.

Animationen

Automatisch startende Audio- und Videodateien, wie auch überbordende, flackernde Animationen können Nutzer mit Aufmerksamkeitsstörungen irritieren oder bei gefährdeten Patienten einen epileptischen Anfall auslösen. Unabhängig davon kann es generell nerven.

Berücksichtige hier ggf. Browser-Voreinstellungen des Nutzers → prefers reduced motion siehe https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion, https://kulturbanause.de/blog/css-prefer-reduced-motion-media-query-bei-bedarf-weniger-bewegung/ und https://wiki.selfhtml.org/wiki/CSS/Media_Queries/Benutzereinstellungen.

Eine weitere Anforderung der WCAG lautet, dass Animationen gestoppt werden können, zumindest wenn sie länger als 5 Sekunden dauern. Das bedeutet also, dass ein Slider auf einer Webseite, der eigentlich automatisch abläuft, auch eine Möglichkeit bieten muss, diese Animation anzuhalten.

ARIA

ARIA steht für „Accessible Rich Internet Application“. Es ist ein Set von Attributen, was helfen soll, Webseiten oder auch SVG Grafiken besser zugänglich zu machen. Es gibt eine ganze Reihe von ARIA-Rollen, Attributen, Werten und Zuständen; siehe https://www.w3.org/WAI/standards-guidelines/aria/ und https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA.

Es gibt verschiedene Rollen, wie button, checkbox, link oder radio und vieles mehr. Es gibt composite roles oder document structure roles und landmark roles genauso wie live region roles oder auch windows roles.

Lass uns das mal an einem Beispiel demonstrieren, zum Beispiel einem einfachen Button:

<button>x</button>

Wenn es einen Button geben soll, der einen Dialog schließt, habe ich vielleicht dort nur den Buchstaben „x“ als Symbol reingeschrieben. Das ist allerdings für einen Screenreader auch nur ein x, er liest nur diesen Buchstaben vor. Während ein sehender Nutzer weiß, alles klar das wird wohl ein Schließen-Button sein, weil das x ihm vertraut ist. Aber ein blinder Benutzer bekommt vom Screenreader einfach nur den Buchstaben x vorgelesen und kann damit nicht erahnen, dass hier irgendwas geschlossen werden soll.

Um das Problem zu lösen, gebe ich dem Button jetzt das ARIA Label „close window“, also Fenster schließen mit auf den Weg. Was folgendermaßen aussieht:

<button aria-label=“Fenster schliessen“>x</button>

Und jetzt macht der Screenreader auch was sinnvolles, er liest mir nämlich „Button Fenster schließen“ vor!

Ein anderes Beispiel für den Einsatz von Aria Attributen wäre zum Beispiel der Hinweis, ob ein Dropdown-Menü geschlossen oder geöffnet ist. Das kann man zum Beispiel erreichen, indem man einem geöffneten Dropdown-Menü das Attribut aria-expanded gleich „true“ zuweist.

Kleiner Hinweis am Rande: Manchmal siehst Du Aria Attribute mit dem Präfix ARIA – aber nicht immer. Z.B. role wird einfach nur „role“ geschrieben ohne vorher ARIA-role zu schreiben. Also, ein Präfix ARIA ist nicht immer notwendig.

Die wichtigste Regel beim Einsatz von Aria Rollen ist, dass die Aria-Attribute so sparsam wie möglich eingesetzt werden. Versuche stattdessen mit semantisch passenden HTML Elementen zu arbeiten. Erst wenn das nicht möglich sein sollte, kannst Du mit Hilfe von Aria Rollen solchen Elementen die nötige Semantik, also die passende Bedeutung zuweisen.
Wenn es hingegen UI Komponenten gibt, die in HTML nicht existieren, dann ist der Einsatz von Aria sinnvoll.

Mehr zum Thema ARIA findest Du unter folgenden Links:
https://web.dev/learn/accessibility/aria-html?hl=de
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes
Youtube-Video „What is WAI-ARIA?“: https://www.youtube.com/watch?v=CNoz0TXG-vk
https://www.w3.org/WAI/ARIA/apg/example-index/

Und weitere Literaturhinweise zum Testen von Websites findest Du unter:
https://web.dev/articles/how-to-review?utm_source=lighthouse&utm_medium=devtools&hl=de.
BITV-Tests: https://bitvtest.de/pruefverfahren/wcag-21-web, https://bitvtest.de/pruefverfahren/bitv-20-web, https://bitvtest.de/pruefverfahren/bitv-20-app, https://bitvtest.de/test-methodik/web/werkzeugliste.

Fazit

Du ermöglichst mit barrierefreien Webauftritten nicht nur Menschen mit Behinderung eine einfachere Teilhabe am Internet. Wenn Du auf barrierearme Websites achtest, profitieren damit generell alle Nutzer von Deiner gut strukturierten und einfach zu bedienenden Website. Du verbesserst mit einer leichteren Bedienbarkeit allgemein die Benutzbarkeit, die Usability, also das Benutzererlebnis (die User-Experience). 
Man macht seine Website einer größeren Zielgruppe verfügbar und erzielt eine Reichweitenerhöhung, sowie eine längere Verweildauer auf Webseiten.
Ebenfalls wirkt sich Barrierefreiheit positiv auf die Suchmaschinenoptimierung aus.
Darüber hinaus gibt es in verschiedenen Ländern, so auch in der EU, bestimmte gesetzliche Anforderungen an die Barrierefreiheit von Webauftritten.

---

Checkliste für barrierefreie Webauftritte

• Stelle für Bilder und andere nicht textuelle Inhalte alternative Texte bereit.
• Verwende Text nicht als Bild. Ein Screenreader kann den Text in einem Bild nicht erkennen, daher bleibt der entsprechende Text für Leute mit Sehbehinderung verborgen. Text in Logos ist hier ausgenommen.
• Für Video und Audio Dateien sollten Untertitel und Transkriptionen zur Verfügung stehen. 
• Eine Website sollte nicht nur per Maus, sondern auch ausschließlich per Tastatur bedienbar sein. Das gilt für Navigation, Menüs, Formulare genauso wie für Buttons, also Schaltflächen.
• Nutze Skip-links. Ein sogenannter Skip-link (Überspringen-Link) wird im body üblicherweise als erster Link gesetzt. Für den Benutzer eines „normalen“ Webbrowsers ist der Skip-link nicht sichtbar, er wird z.B. per CSS außerhalb des Anzeigebereiches platziert. Nutzer eines Screenreader aber können ihn wahrnehmen. Er führt zum eigentlichen Inhalt der Webseite und ermöglicht es dem Benutzer des Screenreaders, die Links im header (üblicherweise Haupt-Navigation und andere Menüs) zu überspringen und direkt zum Inhalt der Seite zu gelangen.
• Biete Deine Inhalte auch in einfacher Sprache an. 
• Deine Website sollte konsistent gestaltet und die Nutzung vorhersehbar sein. 
• Achte auf semantisch korrektes HTML, das bedeutet, dass die HTML Tags die Bedeutung des Inhalts unterstützen sollten, genauso müssen die Überschriften hierarchisch logisch gegliedert sein.
  Verwende ARIA-Rollen, wenn Du mit HTML selbst die Bedeutung eines Elementes nicht ausreichend beschreiben kannst. ARIA-Rollen (Accessible Rich Internet Applications) sind spezielle Attribute, die in HTML verwendet werden, um zusätzliche Informationen über die Struktur und das Verhalten von Webseiteninhalten bereitzustellen.
• Natürlich sind Deine Websites responsiv, das ist eine generelle Anforderungen an Websites, hilft aber gelegentlich auch bei der Barrierefreiheit.
• Inhalte in positionierten Containern sollten im Quelltext an einer logisch passender Stelle stehen. Und es versteht sich von selbst, dass HTML und CSS valide sind, denn ansonsten könnten Screenreader die Inhalte eventuell nicht korrekt interpretieren.
• Gib die Sprache Deiner Website an, das geht z.B. mit dem Language-Attribut.
  Ebenfalls ist es empfehlenswert, für Zitate und andere Textabschnitte, wenn sie in einer abweichenden Sprache verfasst sind die Sprache anzugeben, damit ein Screenreader bei einem Sprachwechsel weiß, wie er das Zitat mit welcher Intonation und Aussprache auszusprechen hat. Nebenbei trägt das Kennzeichnen der Sprache auch zu besseren automatischen Übersetzungen bei.
• Verwende rem statt Pixel bei der Schriftgrößenangabe. Damit berücksichtigst Du eine eventuell durch den Nutzer im Webbrowser geänderte größere Schriftdarstellung.
• Achte auf ausreichenden Farbkontrast. Das Kontrastverhältnis der Schriftfarbe zur Hintergrundfarbe sollte mindestens 4,5:1 (Level AA) beziehungsweise 7:1 (Level AAA) betragen. Bei großer Schrift (ab 18 Punkt oder 14 Punkt in fett) sollte der Kontrast mindestens 3:1 (Level AA) beziehungsweise 4,5:1 (Level AAA) aufweisen. Berücksichtige Farbfehlsichtigkeiten wie Rot-Grün-Schwächen. 
• Verwende in Formularen das Attribut Label, so dass Nutzer mit einem Screenreader die Formulare besser erkennen können.
  Und zu grafischen Captchas solltest Du eine Text- oder Audio-Alternative bereitstellen. Google Recaptcha Version 3 benötigt keine Benutzerinteraktion und bewertet stattdessen die Interaktion auf der Seite im Hintergrund, was eine sehr benutzerfreundliche Lösung für Barrierefreiheit ist. Auch ein zeitbasiertes Captcha kann hilfreich sein, da Bots in der Regel wesentlich schneller beim Ausfüllen sind als Menschen. 
• Hier ein Beispiel für ein benutzerfreundliches captcha in einem Formular 
  <label for="captcha">Bitte geben Sie die Summe von 2 + 3 ein:</label>
<input type="text" id="captcha" name="captcha" required aria-describedby="captchaHelp">
<small id="captchaHelp">Dies ist eine Sicherheitsabfrage zur Vermeidung von Spam.</small>

Weitere Links und Literaturhinweise zum Thema Barrierefreiheit

Inklusion in der Arbeitswelt: https://www.planet-wissen.de/gesellschaft/behinderungen/inklusion/pwieinklusioninderarbeitswelt100.html Sehbehinderungs-Simulator: https://www.absv.de/themen/sehbehinderungssimulator
Einfache Sprache: https://www.nachrichtenleicht.de/, https://www.spiegel.de/deinspiegel/fuer-kinder-erklaert-wer-die-huthis-sind-und-warum-sie-schiffe-angreifen-a-fc487849-7aa7-47a9-97ec-6d8e4c6c336e oder https://www.bundesverfassungsgericht.de/DE/Service/LeichteSprache/leichtesprache_node.html
Stand der Barrierefreiheit bei Webshops: https://www.aktion-mensch.de/inklusion/barrierefreiheit/barrierefreie-website/test-barrierefreie-webshops
Barrierefreiheit ist SEO: https://www.heise.de/news/Google-I-O-Barrierefreie-Apps-zahlen-sich-aus-6051503.html
Barrierefreiheitsstärkungsgesetz: https://bfsg-gesetz.de/
Empfehlenswerter Blog: https://barrierefreies.design/blog 
Tutorial auf w3Schools: https://www.w3schools.com/accessibility/index.php 
VoiceOver (Screenreader für MacOS): https://www.youtube.com/watch?v=5R-6WvAihms
A11Y-casts-Playlist: https://www.youtube.com/playlist?list=PLNYkxOF6rcICWx0C9LVWWVqvHlYJyqw7g
Wave (Web Accessibility Evaluation Tools): https://wave.webaim.org/
Barrierefreiheit testen: https://www.benutzerfreun.de/newsletter/barrierefreiheit-pruefen-in-der-praxis-newsletter-2-2023/
Checkliste vom A11Y Project: https://www.a11yproject.com/checklist/ 
Barrierefreiheit bei WordPress: https://make.wordpress.org/accessibility/handbook/
Designing for Web Accessibility: https://www.w3.org/WAI/tips/designing/
Techniques for WCAG 2.1: https://www.w3.org/WAI/WCAG21/Techniques/
A customizable quick reference to WCAG requirements: https://www.w3.org/WAI/WCAG22/quickref/?versions=2.1&currentsidebar=%23col_customize
Meine Beispieldatei zum Thema barrierefreie Websites mit vielen Code-Beispielen findest Du unter https://web-einfach-machen.de/Kursmaterialien/Barrierearme_Websites/ 

Bildnachweis

Titelbild Frau mit Blindenhund: Freepik