Hinter jeder Website steht ein individueller Quellcode inklusive verschiedener, komplexer HTML-Strukturelemente. Stetig im Wandel bieten diese weitaus mehr Informationen, als auf den ersten Blick erkennbar. In den ersten Teilen unserer Blogreihe haben wir bereits über die Relevanz von barrierefreien Inhalten, der rechtlichen Grundlage durch verschiedene Tests und auch über Möglichkeiten der Gestaltung gesprochen. In diesem Artikel wird es nun technisch: wir gehen direkt in den Code und schauen uns beispielhaft ausgewählte Spezifikationen und Formatierungen an.
Funktionalität und Kompatibilität mit technischen Hilfsmitteln
Im Kontext von barrierefreiem Webdesign ist oft die Rede von speziellen Tools, Geräten oder Software – wie z. B. Braille-Tastaturen, Screenreadern oder Software zur Vergrößerung oder Erhöhung von Kontrasten.
Diese sind wichtig für Menschen mit Behinderungen und Einschränkungen, genauso wichtig ist aus Sicht von Barrierefreiheit aber, dass alleNutzer:innen eine Website problemlos bedienen können.
Egal ob für die Anzeige im Browser oder das Vorlesen durch den Screenreader – die Basis bildet immer der HTML-Code einer Website. Und damit der HTML-Code bestmöglich durch alle Ausgabegeräte verarbeitet werden kann, sind wir auch direkt beim ersten wichtigen Grundsatz für die Programmierung barrierefreier Websites:
Das HTML muss valide sein und den offiziellen Spezifikationen folgen.
Nur dann können Browser und andere Tools zuverlässig arbeiten.
Den HTML-Code kann man sich als von der konkreten Darstellung unabhängige, abstrakte Form eines Dokuments vorstellen.
So ist auf HTML-Ebene beispielsweise erst einmal völlig unwichtig, ob eine Überschrift eine bestimmte Schriftgröße oder Schriftdicke hat – entscheidend ist, dass eben dieser Text, der als Überschrift dienen soll, auch als Überschrift gekennzeichnet ist (in diesem Fall geschieht dies durch Verwendung der h-Tags).
Dies führt uns zu einem zweiten Grundsatz:
Das HTML soll semantisch korrekt ausgezeichnet sein und losgelöst von der konkreten Darstellung die inhaltliche Gliederung des Dokuments (der Website) korrekt widerspiegeln.
So gibt es spezielle HTML-Tags, die für den grundlegenden Aufbau eines Dokuments genutzt werden können:
- "nav" für die Auszeichnung von Navigationsbereichen wie z. B. Menüs,
- "main" für den Bereich der Seite, die den Hauptinhalt enthält,
- "footer", "header",
- die h-Tags "h1", "h2", "h3", "h4", "h5", "h6", die mittels Überschriften das Dokument gliedern
Exkurs – richtige h-Tags
- h1 als oberste Ebene sollte der Titel des Dokuments sein; setze daher auch nur eine h1-Überschrift
- h2 bis h6 dienen dann der weiteren Gliederung, es dürfen aber keine Ebenen ausgelassen werden; d. h. auf eine h2 folgt entweder eine h3, die einen Unterabschnitt zu der h2 kennzeichnet, oder eine h2, die einen neuen Abschnitt auf gleicher Ebene zu der vorangegangen h2 beginnt
Gut:
- h1
- h2
- h3
- h3
- h4
- h2
- h2
- h3
- h2
Schlecht:
- h1
- h3
- h2
- h4
- h2
Die korrekte semantische Auszeichnung erleichtert auch die Navigation mit Tools wie Screenreadern ungemein. So können Nutzer:innen einfach zum Hauptinhalt (<main>) springen oder sich anhand der Überschriften eine Übersicht des Contents verschaffen.
Hilfreich sind dabei auch Sprungmarken: Links, die auf einen anderen Abschnitt eines Dokuments verweisen. Damit lässt sich z. B. das Navigationsmenü überspringen, oder man kann vom Ende des Dokuments wieder an den Anfang springen.
Technisch sind diese Sprungmarken einfache Links, die im href-Attribut auf die ID des Elements verweisen, zu dem gesprungen werden soll:
Die Sprungmarke:
<a href=“#>zum Content</a>
Durch entsprechendes CSS kann die Sprungmarke dann auch visuell versteckt werden, wenn diese sich primär an Screenreader richtet.
Das Ziel, an das gesprungen wird:
<main id=“content“>
Links und Buttons
Ein Link ist ein Element, das bei Nutzung (i. d. R. durch einen einfachen Klick, aber auch das ist kontext-abhängig – Screenreader „klicken“ nicht) ein anderes Dokument oder einen anderen Abschnitt eines Dokuments öffnet. Dafür ist das <a>-Tag zu nutzen.
Für ein klickbares Element, das kein Link ist, sondern irgendeine andere Art von Interaktion auslöst, ist <button> das korrekte Tag.
Gerade Javascript-Frameworks machen es einfach, hier zu „mogeln“ und statt der korrekten Elemente zum Beispiel neutrale <div>-Tags zu nutzen, und diese mittels Javascript in Links oder Buttons umzuwandeln. Davon ist aber in jedem Fall abzuraten. Ebenso sollte auch ein a-Tag nicht als Button genutzt werden.
Gut:
<a href=“https://example.org/XY“ title=“Dieser Link führt auf die Seite XY“>Link zu XY</a>
<button>Ich bin ein Button</button>
Schlecht:
<a href=“#“>Ich bin gar kein richtiger Link, sondern werde als Button genutzt</a>
<a href=“javascript:void(0)“>Bitte nicht nachmachen</a>
<div onclick=“someJavascriptFunction()“>not a real button</div>
Formular-Elemente wie Input-Felder oder Select-Elemente erfordern natürlich auch eine korrekte Auszeichnung.
Formulare sind ein komplexes Thema bezüglich Barrierearmut, dennoch sei hier auf zwei wichtige Punkte verwiesen:
1) Nutze native Formular-Elemente.
Gut:
<select>
<option value=“1″>Eins</option>
<option value=“2″>Zwei</option>
</select>
Schlecht:
<div class=“select“>
<div class=“option“ value=“1″>Eins</div>
<div class=“option“ value=“2″>Zwei</div>
</div>
Über CSS und Javascript lässt sich das Aussehen und Verhalten eines Select-Elements zwar nachbauen, im Gegensatz zu nativen Elementen funktionieren diese aber eben nicht einfach so bei Tastaturbedienung, im Screenreader oder anderen Ausgabegeräten.
2) Stelle sicher, dass jedes Formular-Element ein Label hat.
Gut:
<label for=“feldName“>Beschriftung des Feldes</label>
<input type=“checkbox“ name=“feldName“ value=“1″ id=“feldName“>
<label>Beschriftung des Feldes<input type=“checkbox“ name=“feldName“ value=“1″ id=“feldName“></label>
Schlecht:
<p>Beschriftung des Feldes</p>
<input type=“checkbox“ name=“feldName“ value=“1″>
(es gibt keine semantische Verknüpfung zwischen dem p-Tag und dem input-Feld)
Und noch ein Grundsatz für die Programmierung: biete Alternativen für audiovisuelle Medien.
Wichtige Bilder, die zum Verständnis der Seite notwendig sind, sollten zum Beispiel mit einem Alt-Text (alt=“Beschreibung des Bildinhalts“) beschrieben werden, damit er von Screenreadern entsprechend auditiv wiedergegeben werden kann. In den Alt-Texten sollte der Inhalt genau beschrieben werden.
Hier ein Beispiel :
<img src=“marktplatz.jpg“ alt=“Ein belebter Marktplatz vor einer Kirche mit diversen Marktständen“>
Ebenso wichtig ist hierbei, dass rein dekorative Bilder mit einem leeren Alt-Tag versehen werden, sodass diese von Ausgabegeräten entsprechend ignoriert werden können.
Spezielle Komponenten zur barrierearmen Programmierung: Beispiel ARIA
Barrierefreie Programmierung hat verschiedene Ausprägungen und Optionen. Eine gängige und beliebte Ergänzung sind bestimmte Spezifikationen wie z. B. ARIA. Bei Accessible Rich Internet Applications (ARIA) handelt es sich um einen Webstandard (seit 2014) in Form von zusätzlichen HTML-Attributen. Diese bieten eine zusätzliche Semantik und ermöglichen Entwickler:innen, die Inhalte einer Website für Menschen mit Einschränkungen besser zugänglich zu machen.
Beispiele für den Einsatz von ARIA:
Beschreibendes ARIA-Label für ein besseres Verständnis eines Buttons
<a href=“/unterseite“>Mehr erfahren</a> wird zu <a aria-label=“Erfahre hier mehr über barrierefreies Webdesign“ href=“/unterseite“>Mehr erfahren</a>
Verwendung der ARIA alert-Rolle, damit ein Screenreader einen solchen zuvor versteckten Text erkennt und vorliest, sobald er sichtbar ist
<div>Vielen Dank für Ihre Anmeldung zu unserem Newsletter</div> wird zu <div role=“alert“>Vielen Dank für Ihre Anmeldung zu unserem Newsletter</div>
Wie barrierearm ist der Code meiner Website?
Um dies herauszufinden, gibt es verschiedene Tools und Techniken – je nach Betriebssystem und Browser. Zum Beispiel kann hier Firefox in der Developer-Version genutzt werden.
In den Entwickler-Werkzeugen befindet sich der Reiter Barrierefreiheit, der uns genaue Auskünfte über die Einstellungen auf einer Website gibt. Untersuchen können wir mit Hilfe dieser Funktion einzelne Elemente unserer Website, zum Beispiel einen Textblock innerhalb des Cookie-Banners. Wir sehen auf dem Beispielbild, dass dem Text die Rolle „text leaf“ zugeordnet ist. Durch diese zusätzliche Auszeichnung werden Screenreader unterstützt, den Inhalt und die Struktur einer Seite zu verstehen. Zudem wurde der Kontrast von Text zu Hintergrund überprüft nach den Richtlinien der WCAG-AA-Standards für barrierefreien Text.
Diese hier aufgeführten Code-Beispiele zeigen deutlich auf, welchen essentiellen Beitrag barrierefreie Programmierung leisten kann, um Menschen mit unterschiedlichen Fähigkeiten und Einschränkungen gleichermaßen Zugang zu digitalen Inhalten und Services zu ermöglichen. Gibt es Fragen zum Thema oder Ihr möchtet noch mehr erfahren? Schreibt uns gern unter [email protected]
