Nach oben
Voraussetzungen
HTML ist zugänglich
Responsive Webdesign
Tools & Links
Kontakt
Barrierefreie Webseiten / Barrierefrei programmieren

Barrierefrei programmieren

Manche Menschen benutzen gerne die Tabulator-Taste um im Internet zu navigieren. Blinde oder motorisch eingeschränkte Person sind auf diese Art der Fortbewegung angewiesen. Funktioniert das nicht richtig, ist das für sie, wie wenn man den Cursor oder die Maus verstecken würde - es fehlt das entscheidende Werkzeug.

Voraussetzungen

Voraussetzungen

Die Voraussetzungen für die Zugänglichkeit mit assistiven Technologien wie Screenreader oder Spracheingabe sind semantisch korrekter Code und gute Tastaturbedienbarkeit. Alle Interaktionselemente einer Website müssen dafür mit der Tastatur in einer schlüssigen Riehenfolge erreichbar sein und es muss sichtbar sein, wenn sie im Fokus sind.

Kann das allein mit nativem HTML nicht erreicht werden, müssen WAI ARIA Auszeichnungen ergänzt werden. Z.B. bei JavaScript gesteuerten Komponenten wie Tab-Panels oder Akkordeons. Die WAI ARIA Authoring Practices sind dafür eine hilfreiche Ressource.

HTML ist zugänglich

HTML

Gutes semantisches HTML ist von Haus aus barrierefrei. Hier ein Überblick, wie man es bestmöglich zum Einsatz bringen kann.

Basics

  • Die Seitenstruktur und die DOM-Reihenfolge sind wichtig für Screenreader. Elemente sollten dort auf der Seite erscheinen, wo sie aufgrund ihrer Platzierung im HTML-Code sind.  Absolut positionierte Elemente sollten dort stehen, wo sie erscheinen, z. B. ein „nach oben“ Button ganz unten auf der Seite sollte im HTML so weit unten wie möglich platziert sein.
  • Im Head einer Seite sollte immer folgende Informationen angegeben werden: Doctype <!doctype html>, Sprache <htmllang=“de“>, Metas <metacharset="utf-8"> + <metahttp-equiv="x-ua-compatible" content="ie=edge">, Title <title></title> für jede Seite individuell, für mobil <metaname="viewport" content="width=device-width, initial-scale=1.0,shrink-to-fit=no">
  • Richtiges Parsing ermöglichen: Tags schließen, keine doppelten Attribute, keine doppelten ids
  • Relative Einheiten für Größenangaben (rem), um Zoomen zu ermöglichen

Landmarks und Semantik

Landmarks sind spezielle Regionen einer Seite. Sie werden z.B. von Screenreadern erkannt und helfen so bei der Navigation. Sie sollten entsprechend ihrer Funktion verwendet werden. Wichtig sind <header>, <main>, <footer>, <nav> (bei mehreren Navigationsoptionen auf einer Seite sollte sie immer mit  <aria label> unterscheidbar gemacht werden) und <section> (nur bei Regionen, die wichtig genug sind, um direkt dorthin zu navigieren). Daneben könne auch <article>, für in sich abgeschlossene Inhaltseinheit und <aside> für Randinhalte oder Infokästen genutzt werden.

Headlines

Es darf nur eine Überschrift der Ebene 1, also eine <h1> auf einer Webseite geben. Alle weiteren ordnen sich darunter an und es darf danei keine Ebene übersprungen werden. Idealerweise kommt nach jeder Überschrift ein Text und dann erst weitere Elemente.

Überschriften sind auf Websites so wichtig, weil ca. 70% der betroffenen Nutzer:innen auf umfangreichen Seiten über die Überschriften navigieren. Ausnahmen zur Regel mit der <h1> können Modals sein, da sie den Inhalt überlagern und Blog-Übersichtsseiten, die mit <article> gestaltet sind.

Für Screenreader müssen Headlines aussagekräftig sein,  mehr Infos zu einer guten Headline-Struktur gibt es in unserem Blog.

Es ist in Sonderfällen möglich Headlines, die Off-screen sind, einsetzen. Speziell als Hilfe für Screenreader, z. B. wenn auf der Seite visuell kein Platz für eine Headline ist. Diese Technik ist bei mehrsprachigen Angeboten nicht einfach zu handhaben.

Links

Links müssen eindeutig sein, und die Linkbezeichnung muss einmalig sein. Es darf keine Links geben, die gleich lauten, aber zu verschiedenen Zielen führen.
‍
Der Sinn eines jeden Links sollte allein durch den Linktext klar werden. Vermeidet Ausdrücke wie „Details“ oder „Mehr lesen“. Besser Wäre: „Details zu Thema XY “ oder „Mehr lesen über XY“, einen anderen Teil im Absatz verlinken, oder die Überschrift.
‍
Alles, was als Link fungiert, muss einen <a>-Tag haben. Dann erscheint der Link in der „Linkslist“ des Screenreaders und funktioniert mit der Tastatur. Deshalb sollten Links nicht zu Buttons umfunktioniert werden und umgekehrt. Bei Buttons sollte <button> verwenden werden, da Screenreader sonst das Element nicht als Button erkennen. Zur Unterscheidung: Ein Link zeigt immer irgendwo hin, ein Button ist eine Schaltfläche und löst etwas aus.

Fließtextlinks

Wichtig ist, dass alle Links außerhalb ihres Kontextes für sich stehen können, damit z.B. in Sprachausgaben die Navigation mit der Tabulatorentaste möglich ist. Wenn also Fließtext verlinkt wird, sollten die verlinkten Begriffe „für sich“ stehen können. Beispielsweise ist in einemSatz „Die Grundsatzrede finden Sie auch in unserem Archiv“ das Wort„Grundsatzrede“ vermutlich eindeutiger als „Archiv“ (mehr zu Treffenden Linkbezeichnungen).

Listen

Es gibt 3 Listen-Typen mit verschiedenen Bedeutungen: Ordered list <ol>, Unordered list <ul>, Description list <dl> (z. B. Glossar oder sogar FAQ). Listen sollten mit der richtigen Semantik genutzt werden. So können Screenreader Listen identifizieren, den Typ der Liste festzustellen und die Anzahl der Listeneinträge erkennen und übermitteln, wo in der Liste man sich befindet.

Navigation und Skip-Links

Wichtig ist eine konsistente Navigation, mit konsistentem Interface. Gute Praxis ist es, mehrere Wege zur Verfügung zu stellen, um durch eine Website zu navigieren.

Best Practice bei Navigationen

  • Innerhalb von <nav> eine Liste mit <ul> und <li> benutzen
  • Navi-Einträge: Für die Links Text nutzen, keine Bilder
  • Navi-Einträge sollten immer und überall an der gleichen Stelle stehen und in der gleichen Reihenfolge sein
  • Hilfreich ist es mehrere Wege, Inhalte zu finden, anzubieten: z. B. Navigation, Suche (<form> mit role=“search“), Sitemap (z, B. verlinkt vom Footer aus), Breadcrumb-Navigation, usw.

Buttons und Bilder sollten immer gleich benannt werden, wenn sie die gleiche Funktion haben und auch hier sollten die Linktexte sprechend sein. Ist das nicht möglich, kann für Screenreader Text eingefügt werden. Mehr dazu im Artikel "Texte und HTML mit CSS und Aria barrierefrei verstecken" bei kulturbanause.

Skip Link

Mithilfe von Skip Links können Bereiche auf Webseiten übersprungen werden, damit Menschen, die Screenreader oder Tastatursteuerung nutzen, sich nicht wiederholt durch Navigationselemente kämpfen müssen, um zum Hauptinhalt zu gelangen.  Ein oder auch mehrere Skip Links sind idealerweise am Beginn des <body> und vor oder innerhalb des ersten interaktiven Elements der Seite, damit direkt mit der Tab-Taste fokussiert werden kann. Mehr Infos zu Skip Links gibt es hier.

Tabellen

Tabellen sind zur Darstellung von Daten in Reihen und Spalten und sollten nicht für Layout benutzt werden. Sinnvoll aufgebaute Tabellen zeigen, welche Informationen in den einzelnen Spalten und Zeilen enthalten sind. Die Bedeutung der einzelnen Spalten und Zeilen kann im Tabellenkopf und/oder der ersten Spalte angezeigt werden. Aber auch eine Tabelle ohne Überschriften kann sinnvoll strukturiert sein. Für Screenreader müssen Tabellen mit <caption>, <thead>, <tbody>, <tfoot>, <th>, <tr>, <td>, scope, colgroup. Mehr Info zu barrierefreien Tabellen.
‍
So kann ohne Screenreader geprüft werden, ob eine Datentabelle richtig aufgebaut ist: Lies eine beliebige Zelle zusammen mit den zugehörigen Spalten- und Zeilenüberschriften:  „[Überschrift(en) der Spalte] – [Überschrift(en) der Zeile]:[Inhalt der Zelle]“. Ist die Bedeutung der Zelle so verständlich?

Formulare

Die technischen Grundfunktionen eines Formulars – erfassen, ausfüllen und abschicken – müssen mit allen möglichen Mitteln der Ein- und Ausgabe gelingen.
‍
In unserem Barrierefreien Blog gibt es eine Artikel-Reihe über gute Formulare, in der ausführlich beschrieben wird, wie Planung, Design und Entwicklung ineinander übergreifen. Wie man Formulare testet, kann man im Artikel„Formulare testen“ bei web.dev erfahren.

Einige wichtige Punkte zu barrierefreien Formularen:

  • Ein Absende-Button ist nötig und Buttons und Inputs brauchen zugängliche Namen, also Label (wenn kein Label möglich/gewünscht, dann z. B. mit aria-label arbeiten). 
  • Interaktive Elemente zeigen ihren Zweck und ihren Status: Mit Tabulator-Taste erreichbar und sichtbar, wo man sich befindet (verändert das Element sein Aussehen, wenn man es auswählt?) Gibt es einen visuellen Hinweis, dass man hier etwas tun kann?
  • Formular mit Screenreader testen: Liest der Screenreader den Namen jedes Elements vor, die Rolle, den gegenwärtigen interaktiven Status? Wenn die Rolle oder der Status unklar ist, muss man evtl. die entsprechenden ARIA-Rollen hinzufügen.
  • Barrierefreie Formulare haben eine eindeutige Fehleridentifizierung, eindeutige Pflichtfelder-Kennzeichnung, gute Farb-Kontraste von Vorder- zu Hintergrund und umgebenden Farben. Sie sind mit der Tastatur gut bedienbar und haben eine klare Fokus-Anzeige.
  • Keine Placeholder Texte, da sie für vorausgefüllte Felder gehalten werden können, Browser sie unterschiedlich behandeln und sie in manchen Fällen verschwinden, sobald man ins Feld klickt. Dann ist die Beschreibung nicht mehr zu„sehen“ und es ist unklar, was ins Feld muss. Besser sind beispielhafte Beschreibungen unter dem Feld.
  • Gruppierung mit <fieldset> und <legend> für umfangreichere zusammengehörende Formularbereiche ist  wichtig, z. B. bei Radios und Checkboxen).
  • Man sollte die native HTML5 Browser Validierung abschalten, da diese „HTML5 Validation Ballons“ nicht barrierefrei sind. Außerdem gibt es nur sehr wenig Möglichkeiten, sie zu stylen.
  • Text (<p>) sollte nicht innerhalb von <form> verwendet werden.

Medien

Auf Webseiten eingebundene Bilder, Videos und  Audio-Dateien benötigen etwas Zuwendung, wenn man sie barrierefrei machen möchte.

Tipps zu Bildern:

  • Keine ins Bild gerenderten Texte verwenden
  • Text-Alternativen für Bilder anbieten: Alt-Attribut, dekorative Bilder müssen ein leeres alt-Attribut haben: alt=““, aber als Faustregel gilt, dass auch blinde Nutzer gerne über alles Bescheid wissen möchten, was zu sehen ist.
  • Ein guter Alt-Text beschreibt das Bild nicht buchstäblich, sondern sagt aus, was die Bedeutung oder der Zweck des Bildes ist. Was visuell übermittelt wird, muss auch programmatisch übermittelt werden. Zu diesem Thema siehe auch A11y: Bilder und Alt-Text in unserem Barrierefreien Blog.
  • Hintergrundbilder mit css müssen mit einem Text beschrieben werden, wenn sie eine Information beinhalten.
  • SVGs: Brauchen die role="img", <title> mit id benutzen, <desc> bei längerem Content, Aria-labelledby benutzen um den<title> oder die<desc> zu referenzieren.

Barrierefreie Videos

Barrierefreie Online-Videos zeichnen sich durch folgende Merkmale aus:
  • sie sind barrierefrei erreich- und bedienbar,
  • für höreingeschränkte Menschen wird ein Untertitel zur Verfügung gestellt und
  • wichtige visuelle Informationen werden für blinde Menschen über eine Audiodeskription vermittelt.
Wichtige Punkte für die Bereitstellung von Videos:
  •  Wenn ein Audio vorhanden ist, dann muss eine Transkription, wie bei Audio-Dateien vorgesehen werden.
  • Captions anbieten. Entweder "Open" dann sind sie immer sichtbar oder eingebettet (Closed), dann können sie von Nutzer:innen an- und abgeschaltet werden)
  • Autosubtitles können über YouTube Auto-Subtitles automatisch eingebunden werden, was eine gute Einstiegsmöglichkeit ist. Sie können aber auch selbst oder von einen Dienstleister (Video Captioning Services) angelegt werden.
  • Audio-Beschreibung: Alle nicht sichtbaren Hinweise sollten beschrieben werden, z. B. Donner und Blitz vor dem Fenster.
  • Es gibt einen Artikel zum Thema Video-Einbindung bei BIK: hier wird erklärt, was die Anforderungen an das Media-Element gemäß BITV sind: Tastaturbedienbarkeit, sichtbarer Fokus, Objekt identifizierbar und Bedienelemente beschriftet. Das ist über den HTML-Tag <video> gegeben, Bedienelemente müssen in der Hauptsprache der Website beschriftet sein, Kontrast, Untertitelung (Captions) einbindbar (je nach Player verschieden, dynamische Text-Untertitelung geht über den HTML-Tag <track>), Audiodeskription einbindbar.
  • Wer Videos über YouTube einbetten möchte, sollte sich an den Empfehlungen für Entwickler orientieren, damit YouTube-Videos über einen HTML5-Player wiedergegeben werden. 

Audio

Bei Audio-Dateien ist es wichtig, eine Textalternative anzubieten (z. B. Transkript des Audio direkt auf der Seite als Download). Es gibt verschiedenen Möglichkeiten ein Transkript herzustellen oder zu generieren, über bezahlte Services oder Spracherkennungs-Apps. Eine gute Praxis ist, den Namen der Sprecher einzufügen und nicht nur das gesprochene Wort zu transkribieren, sondern auch Sounds, Musik und Geräusche zu beschreiben. 

Animationen

Wenn sich etwas bewegt, kann das problematisch für bestimmte Nutzer sein, deshalb gibt es auch hier einige Dinge, die beachtet werden sollten. Die Animation sollte systemisch abstellbar sein (über das css über die media query „prefers-reduced-motion“ und/oder über einen Button zum Starten und Stoppen der Animation),  sie darf nicht schneller blinken als 3-mal in der Sekunde oder schneller,  und es sollten nicht zu viele Animationen gleichzeitig ablaufen.
Responsive Webdesign

Responsive Webdesign

Websites werden auf vielen verschiedenen Geräten ausgegeben, unter anderem auf Smartphones und Tablets. Überall müssen sie bedienbar sein, und es gibt bei Mobilgeräten einiges  zusätzliche zu beachten.

Reihenfolge bzw. Tab-Order

  • Die Tab-Order muss eine logische Reihenfolge abbilden, der Fokus muss sichtbar sein.  
  • Falls nötig, kann mit Tabindex gearbeitet werden. Ein Tabindex von -1 sorgt dafür, dass das Element nicht in der natürlichen Tab-Reihenfolge ist, aber per JavaScript mit der focus() method fokussiert werden kann. Dies ist z. B. wichtig bei Offscreen Inhalten wie einer Flyout-Navigation. Solange sie eingeklappt ist, darf sie nicht den Fokus erhalten, sondern nur wenn sie ausgeklappt ist. Ein weiterer Anwendungsfall sind Modals (Popups). Ein tabindex=“0″ fügt das Element der natürlichen Tab-Reihenfolge hinzu und kann so fokussiert werden. Ein Tabindex, der größer als 0 ist, bringt das Element in der Tab-Reihenfolge nach vorne, egal wo es im html Code (= in der DOM-Order) ist. Da hier leicht Chaos entstehen kann, ist die Empfehlung, keinen tabindex größer als 0 zu verwenden. Der beste Weg, etwas weiter in der Reihenfolge anzuordnen, ist es, das Element an der richtigen Stelle im DOM zu haben, also im HTML Code.
  • Offscreen-Inhalt sollte vom Fokus ausgenommen sein und mit display:none oder visibility:hidden verborgen sein.
  • Die Reihenfolge von Content und des Fokus muss beim Durch-Navigieren gleich bleiben, z. B. wenn sich Elemente auf einem Smartphone untereinander statt nebeneinander anordnen. Die visuelle Ordnung muss weiterhin der DOM-Reihenfolge entsprechen.

Mobile Geräte

Smartphones haben zwei verschiedene Ausrichtungen, deshalb dürfen sich Websites nicht nur auf eine Screen-Orientierung beschränken, sondern müssen vertikal und horizontal benutzbar sein.
‍
Mobile Geräte werden weitestgehend mit Finger-Gesten benutzt. Für Gesten wie „Wischen“ oder „Ziehen“ sollte es Interaktionsmöglichkeiten geben, die auf „Touch“ reagieren. Schaltflächen müssen groß genug sein, um einfach bedient werden zu können. Auch müssen Interaktionen rückgängig gemacht werden können, was schwierig ist, wenn sie direkt auf Touch-down ausgelöst werden. Besser ist es Interaktionen mit auf Klick oder Tap auszulösen, da hier die Möglichkeit der „Rücknahme“besteht, z.B. wenn die bereits gedrückte Schaltfläche „verlassen“ wird.
‍
Daneben gibt es "Motion Actuation" (Bewegungsaktionen): das ist Schütteln oder Rotieren. Dies sollte nicht die einzige  Möglichkeit sein, eine Aktion auszulösen. Auch hier ist es nötig, einen Button anzubieten und die Möglichkeit, Bewegungsaktionen abzuschalten, um Fehlbedienung zu vermeiden. 

Zusätzliche responsive Richtlinien

  • Es müssen im css relative Einheiten benutzt werden (em, rem, %), damit Inhalte einfach vergrößert werden können.
  • Text-Spacing sollte von Nutzern selbst einstellbar sein, ohne dass die Benutzung der Seite beeinträchtigt wird. Mindestmaße zum Testen sind: Line-height ist 1,5x der font-size, nach Absätzen 2x font-size spacing, Letter-spacing sollte mindestens .12x der font-size sein, Word-space sollte mindestens .16x der font-size sein
  • Der Text muss auf 200% vergrößerbar/zoombar sein, ohne dass dabei Funktionalität oder Inhalt verloren geht. Um die höchstmögliche Zugänglichkeit (Stufe AAA) zu erreichen, muss Text auf 200% lesbar sein, ohne horizontal scrollen zu müssen.
Tools und Links
Du hast Fragen oder brauchst Unterstützung?

Wir helfen

Wenn du Unterstützung brauchst oder Fragen hast, schreib uns. Wir nehmen uns gerne Zeit für dich.

Schreib uns