1. Februar 2018 // von Julian Kern

Accessibility, ein neues Menü und kein JavaScript

Wenn eine größere Änderung ansteht, macht man sich einen Plan was man wie umsetzen will, und mit welchen technischen Mitteln. Unser altes Offscreen-Menü ist schon etwas älter, also musste etwas neues her. Die Optik passend zu aktuellen Webdesign Trends, die Technik dahinter ebenfalls auf neustem Stand, und alte Schwierigkeiten ausräumen, soweit der Plan.

Außerdem wollten wir – weil die Navigation das zentrale Element ist um über die Startseite hinaus zu kommen – sicher gehen, dass sie für jeden Nutzer bedienbar ist. Accessibility, auch a11y genannt, ist also ein großes Thema. Nicht nur im gebräuchlichen Sinne, dass die Komponente also auch beispielsweise via Screenreader benutzbar ist, sondern auch in dem Fall, dass der Nutzer JavaScript deaktiviert hat, oder selbiges durch eine langsame mobile Verbindung noch nicht fertig geladen ist.

Interaktivität ohne JavaScript

JavaScript ist die zentrale Scriptsprache im interaktiven Web, wie also eine interaktive Komponente bauen, die ohne auskommt? Das Stichwort heißt “Checkbox-Hack”. “Hack” ist hier nicht wörtlich zu verstehen, hier wird nirgends eingebrochen oder Dinge zerstört. Vielmehr wird eine schon alte Funktionalität, nämlich die der Checkbox, für Zwecke benutzt, für die sie ursprünglich nicht gedacht war.

Die wahrscheinlich einfachste Version des Checkbox-Hacks ist diese:

<style>
    #some-checkbox {
        position: absolute;
        opacity: 0;
    }
    .checkbox-hack-content {
        display: none;
    }
    #some-checkbox:checked ~ .checkbox-hack-content {
        display: block;
    }
</style>
<input type="checkbox" id="some-checkbox">
<label for="some-checkbox">Click me!</label>
<div class="checkbox-hack-content">
    Show me only if checked!
</div>

(dieses Beispiel zum Testen auf Codepen.io)

Der Div-Container mit der Klasse checkbox-hack-content wird allgemein ausgeblendet. Außer wenn die Checkbox mit der ID some-checkbox gechecked ist, dann werden alle Schwester-Elemente (siehe Sibling-Selector ~ ) mit dieser Klasse sichtbar. Durch die Bindung des Labels via for / id an die Checkbox, wird diese geklickt, obwohl sie visuell versteckt ist.

Ein weiterer Vorteil dieser Lösung ist, dass sie über die gesamte Seite hinweg funktioniert, solange Label und Checkbox aneinander gebunden sind.

Das neue Menü bekommt nicht nur eine schicke neue Optik als Overlay über der gesamten Seite, sondern auch eine neue Hierarchie, und damit erstmal Untermenüs, die über eine sogenannte “Accordion”-Mechanik – sodass also immer nur ein Untermenü gleichzeitig geöffnet sein kann – gezeigt und versteckt werden. Auch hier kommt wieder der Checkbox-Hack zum Einsatz, hier allerdings mit ein wenig Unterstützung von JavaScript, um das “Accordion”-Verhalten zu ermöglichen. Da das aber nur eine zusätzliche Funktionalität ist, die für die reine Benutzung nicht zwingend benötigt wird, kam hier, wie auch später bei den WAI-ARIA-Attributen, JavaScript zum Einsatz.

WAI-ARIA?

WAI-ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications) ist eine Initiative zur Verbesserung von Webseiten und Webanwendungen, um sie für Menschen mit Behinderungen besser zugänglich zu machen, insbesondere für blinde Anwender, die Vorleseprogramme verwenden.

ARIA ist eine technische Spezifikation, die von Mitgliedern der Web Accessibility Initiative entwickelt wurde. Seit März 2014 ist ARIA ein empfohlener Webstandard des World Wide Web Consortium (W3C).
 — Quelle: Wikipedia

Die ARIA-Attribute sind also zusätzliche Attribute, die dem HTML-Code hinzugefügt werden, um Screenreadern das erkennen der Webseite zu erleichtern, und dem beeinträchtigten Nutzer ein besseres Erlebnis zu bieten, als durch das reine Vorlesen der Webseite möglich wäre.

Accessibility = WAI-ARIA?

Jein. ARIA-Attribute helfen bei der Accessibility, also der Unterstützung des Nutzers, sind aber kein Allheilmittel. An eine gute Benutzbarkeit einer Komponente muss schon bei deren Entwurf gedacht werden, und es gibt noch viele weitere Wege die Nutzererfahrung zu verbessern

Dafür ist das “alt”-Attribut bei Bildern ein gutes Beispiel. Dieses Attribut gibt es schon wesentlich länger als die ARIA-Attribute. Im “alt”-Attribut sollte eine kurze Beschreibung des Bildes oder der Grafik stehen, vor allem der Teil auf dem der Fokus liegt. Von einem Screenreader wird dieser Text dann vorgelesen – er wird aber auch schon angezeigt, falls das Bild nicht geladen werden kann, oder es noch nicht fertig geladen wurde bei einer langsamen Verbindung. Das “alt”-Attribut bringt also potentiell nicht nur dem blinden Nutzer Vorteile.

Ähnliches gilt für das “title”-Attribut, das an jedes Element geheftet werden kann, und dem sehenden Nutzer angezeigt wird, wenn er mit der Maus über das Element fährt. Auch dieses Attribut gibt es schon länger.

Das was dem beeinträchtigten Nutzer am Meisten hilft, ist aber die semantisch korrekte Verwendung von HTML-Elementen. Natürlich kann man auch ein <div>-Element aussehen und via JavaScript funktionieren lassen wie einen <button>, letzteres Element wird aber auch ohne weitere Kennzeichnung als Bedienfläche vorgelesen. Das gilt natürlich für die allermeisten Elemente.

Im Prinzip werden ARIA-Attribute erst dann nötig und interessant, wenn man Funktionalitäten umsetzen möchte, die es in HTML so (noch) nicht gibt, oder Elemente entgegen ihrer semantischen Bestimmung benutzt — beide Fälle haben wir mit dem neuen Menü.

Wie sieht ARIA aus?

Die ARIA-Attribute können Standard-Attribute für Screenreader sozusagen überschreiben. Zentral ist hier das “role”-Attribut. Ein <button> wird, je nach Screenreader, im Deutschen als “Knopf” oder “Schaltfläche” vorgelesen, ein <button role="menuitem"> wird jedoch als “Menüpunkt” angesagt.

Ein weiteres wichtiges Attribut ist aria-labelledby das eine Element-ID beinhalten kann, welches das Element besser beschreibt. Eine weitere Möglichkeit ist, die Beschreibung direkt in das Attribut einzufügen. Wird eine ID benutzt, hilft das dem Screenreader Beziehungen zwischen Elementen zu erkennen, hier ein Beispiel für so eine Verbindung:

<div role="article" aria-labelledby="article-headline">
    <h1 id="article-headline">
        Wild fires spread across the San Diego Hills
    </h1>
    <p>
        Strong winds expand fires ignited by high temperatures ...           
    </p>
</div>

Hier sieht also der Screenreader, dass das H1-Element der Titel für den gesamten Container ist, und kann ggf. später darauf zurückgreifen.

Es gibt natürlich noch weitere Attribute die Beziehungen kennzeichnen. Die zweite wichtige Art von ARIA-Attributen, sind die Status. Zum Beispiel kann man mit aria-expanded="true" kennzeichnen, dass ein bestimmter Bereich ausgeklappt wurde, und vom Screenreader beachtet werden muss. Mittlerweile erkennen viele Screenreader diese Veränderung auch an Änderungen im CSS, sagen diese dem Nutzer aber oft nicht konkret an.

aria-expanded ist natürlich ein wichtiger Bestandteil von unserem neuen Menü, allerdings muss dieses Attribut auch via JavaScript geändert werden. Der Wert wird bei ausgeklapptem (Unter-) Menü einfach von false auf true gesetzt, beim zuklappen anders herum. Dem sehenden Nutzer ergibt sich auch hier kein Nachteil wenn JavaScript (noch) nicht funktioniert, Screenreader lassen es wegen solcher Attribute in der Regel gar nicht zu dass man JavaScript manuell deaktiviert — das Menü ist also auch hier für alle benutzbar.

Weitere ARIA-Attribute werden im Mozilla Developer Network näher erläutert.

Das neue Menü ist also in vielerlei Hinsicht neu, sowohl technisch als auch konzeptionell, und wird uns bei zukünftigen Änderungen oder neu-Umsetzungen als Referenz dienen, wie gut Funktionen für möglichst jeden Nutzer benutzbar sein sollen. Accessibility ist kein Nischenthema mehr, und jeder Kunde sollte das bestmögliche Nutzererlebnis bekommen.

Verwandte Blogposts