Darstellung auf mobilen Geräten
bearbeitet von Gunnar Bittersmann@@Henry
> weils [schöner aussieht](https://www.w3schools.com/howto/tryit.asp?filename=tryhow_js_topnav) und sehr wenig code? 😉
Die Schönheit liegt im Auge des Betrachters. Und geht geht nicht darum, möglichst wenig Code zu haben, sondern möglichst sinnvollen.
Den Seitenkopf in ein `header`-Element zu stecken ist schon sinnvoll. (Screenreader-Nutzer orientieren sich an solchen *landmarks*{: @en}.)
Der Link zum Überspringen der Navigation auch. (Abkürzung bei Navigation mit Tastatur)
Und die Aufzählung der Links als Liste auszuzeichnen auch. (Screenreader-Nutzer bekommen sowas wie *„Item 7 of 9“*{: @en} angesagt.)
> Aber mal im Ernst, was hältst du von diesem Beispiel im Hinblick auf Barrierefreiheit?
Von den erwähnten fehlenden Elementen abgesehen: `<div class="topnav" id="myTopnav">`{: .language-html.bad} wäre gern ein `nav`-Element. (Screenreader-Nutzer orientieren sich an solchen *landmarks*{: @en}.)
`<a href="javascript:void(0);" style="font-size:15px;" class="icon" onclick="myFunction()">☰</a>`{: .language-html.bad} – aua!
1. Glaubst du, dass `☰`{: .language-html.bad} ein sinnvoller Linktitel wäre? Was soll ein Screenreader da vorlesen? *„Trigram for Heaven“*{: @en}?
Da sollte schon sowas wie *„Menü“* stehen. Ein Icon kannst du *hinzu*fügen. Die Beschriftung kannst du evtl. visuell verstecken. „Visuell verstecken“ heißt: Wird nicht auf dem Bildschirm angezeigt, aber von Screenreadern vorgelesen. (Wie’s gemacht wird: siehe in meinem Beispiel bei `[aria-controls="main-nav-list"]`{: .language-css}.)
„Eventuell verstecken“ heißt: Hier besser nicht. Sondern „☰ Menü“. Nicht alle Nutzer kennen die Bedeutung des Hamburger-Icons.
2. `href="javascript:void(0);"`{: .bad} ist ein sicheres Zeichen dafür, dass dies kein Link ist, folglich kein `a`-Element sein sollte. Links führen *zu* anderen Ressourcen oder *zu* anderen Stellen auf einer Seite.
Für Aktionen *auf* einer Seite sind Buttons (`<button type="button">`{: .language-html}) da. Für Screenreader macht das einen Unterschied: sie geben Links und Buttons unterschiedlich an; sie führen eine Liste aller Links, die der Nutzer anspringen kann …
Zu deinem JavaScript: Dass du den Eventhandler im HTML mittels `onclick` registrierst anstatt im JavaScript mittels `addEventListener` macht den Code vielleicht kürzer, aber nicht besser.
Schauen wir mal in diesen rein:
~~~JavaScript,bad
function myFunction() {
var x = document.getElementById("myTopnav");
if (x.className === "topnav") {
x.className += " responsive";
} else {
x.className = "topnav";
}
}
~~~
1. Bei Aufruf (d.h. bei jedem Click auf den Hamburger) wird das Element mit der ID "myTopnav" erneut im DOM gesucht. Warum? Reicht doch einmal – vorm ersten Aufruf. Die Zeile `var x = document.getElementById("myTopnav");`{: .language-js} gehört außerhalb von `myFunction()`{: .language-js}
2. Das Script ist nicht robust. Es wird davon ausgegangen, dass das Element nur die Klassen "topnav" haben darf und "responsive" zugefügt bzw. weggenommen wird. Was aber, wenn das Element die Klassen "topnav" und "nochwas" haben soll? Dann musst du außer dem Markup auch noch das JavaScript ändern – das ist schlecht.
Klassen hinzufügen/wegnehmen geht mit `classList.add()`{: .language-js}, `classList.remove()`{: .language-js}, `classList.toggle()`{: .language-js}.
Und wozu soll überhaupt die Klasse "topnav"? Du kommst doch über die ID an das Element ran!
3. Es ist vom Aufwand her egal, ob man Klassen oder andere Attribute umschaltet. Wenn andere Attribute aber ARIA-Attribute sind, haben Nutzer assistiver Technologien was davon.
Und dann braucht man die Klassen gar nicht mehr.
LLAP 🖖
--
“When UX doesn’t consider *all* users, shouldn’t it be known as ‘*Some* User Experience’ or... SUX? #a11y” —[Billy Gregory](https://twitter.com/thebillygregory/status/552466012713783297)