@@Henry
weils schöner aussieht und sehr wenig code? 😉
Die Schönheit liegt im Auge des Betrachters. Und 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.)
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“ 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"> wäre gern ein nav-Element. (Screenreader-Nutzer orientieren sich an solchen landmarks.)
<a href="javascript:void(0);" style="font-size:15px;" class="icon" onclick="myFunction()">☰</a> – aua!
-
Glaubst du, dass
☰ein sinnvoller Linktitel wäre? Was soll ein Screenreader da vorlesen? „Trigram for Heaven“?Da sollte schon sowas wie „Menü“ stehen. Ein Icon kannst du hinzufü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"].)„Eventuell verstecken“ heißt: Hier besser nicht. Sondern „☰ Menü“. Nicht alle Nutzer kennen die Bedeutung des Hamburger-Icons.
-
href="javascript:void(0);"ist ein sicheres Zeichen dafür, dass dies kein Link ist, folglich keina-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">) 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:
function myFunction() {
var x = document.getElementById("myTopnav");
if (x.className === "topnav") {
x.className += " responsive";
} else {
x.className = "topnav";
}
}
-
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");gehört außerhalb vonmyFunction() -
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(),classList.remove(),classList.toggle().Und wozu soll überhaupt die Klasse "topnav"? Du kommst doch über die ID an das Element ran!
-
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