Revision 692: javascript:void(0), mit Manuel Matuzović

In dieser Revision sprechen wir mit unserem Gast Manuel Matuzović über moderne HTML-Praktiken, alte Muster, die sich hartnäckig halten, und darüber, warum manche Links eigentlich Buttons sein sollten. Dabei tauchen wir tief in Semantik, Barrierefreiheit und die Frage ein, warum bestimmte Patterns – trotz aller Probleme – immer wieder im Web auftauchen.

Schaunotizen

[00:01:45] javascript:void(0)

Aufhänger dieser Revision ist ein Muster, das uns seit Jahren immer wieder begegnet: Die verbreitete Nutzung von href="javascript:void(0)" und verwandten Dingen in Links. Wir beklagen, dass dieses Pattern nicht nur technisch fragwürdig ist, sondern auch aus Sicht von Barrierefreiheit, Nutzererwartungen und allgemeiner HTML-Semantik massive Probleme nach sich zieht.

Dafür arbeiten wir uns zunächst Schritt für Schritt daran entlang, was einen echten, barrierefreien Link überhaupt ausmacht. Dazu gehören ein <a>-Element, ein gültiges href-Attribut und ein klarer Accessible Name. Erst dadurch entstehen Fokussierbarkeit, Tastaturaktivierung, sinnvolle Screenreader-Ausgaben, das korrekte Verhalten in Linklisten, die bekannten Linkzustände und das erwartete Interaktionsmodell. Alles, was davon abweicht, bricht die Erwartungen der Nutzenden – besonders sichtbar wird das bei Links, die eigentlich Buttons darstellen sollen.

javascript:void(0) sehen wir zudem als ein typisches Beispiel für Cargo-Kult: Ein historisches Muster, das weiterlebt, obwohl kaum jemand noch weiß, wozu es ursprünglich gedacht war. Technisch betrachtet evaluiert eine solche URL einfach JavaScript – im Fall von void wird allerdings bewusst undefined zurückgegeben, also „nichts“.

Wir benennen die vielen praktischen Probleme, die solcher Code hervorruft: Kontextmenüs bieten unsinnige Optionen an, Mittelklicks öffnen leere Tabs, Screenreader kündigen Elemente als Links an, die sich gar nicht wie Links verhalten, Tastaturnutzende stoßen auf widersprüchliche Aktivierungsmuster und in Listen assistiver Technologien erscheint „Navigierbares“, das kein Ziel hat. Wir diskutieren, wie solche Muster häufig entstehen – sei es aus historisch schwer zu stylenden Buttons, aus Einschränkungen in Component-Libraries, aus unglücklichen Framework-Abstraktionen oder schlicht aus fehlendem Basiswissen über HTML.

Aus dieser Perspektive wird klar: In den allermeisten Fällen wäre ein echtes <button>-Element die richtige Wahl. Moderne Browser machen das Styling per all: unset; und wenigen Ergänzungen längst unkompliziert. Wir sprechen darüber, wie hybride Komponenten sinnvoll funktionieren können, warum überflüssige Rollen, Tabindex-Werte oder ARIA-Attribute eher schaden als helfen, und wie man mit einfachen Debug-Strategien – etwa Selektoren wie a[href^="javascript:"] oder Werkzeugen wie a11y.css – problematische Stellen sichtbar machen kann.

Im weiteren Verlauf streifen wir verwandte Themen, etwa die alte Debatte um Cursor-Darstellungen bei Buttons, Überlegungen rund um target="_blank" und seine UX-Probleme (Warum target=“_blank“ nervt), sowie die Frage, welche Rollen historische Mechanismen wie <area>-Elemente heute noch spielen können (MDN). Wir stellen fest, dass viele Entwickler*innen HTML fast nur noch durch die Framework-Brille wahrnehmen– und dass genau diese Abstraktionsschichten es erschweren, zu verstehen, was die Basiselemente der Plattform eigentlich können.

Eine zentrale Erkenntnis des Gesprächs lautet: Gute HTML-Entscheidungen entstehen nicht dadurch, dass man Muster auswendig lernt, sondern indem man versteht, welche Fähigkeiten jedes Element mitbringt und wie es sich im Browser verhält. Wer entscheidet, „was bringt mir dieses Element?“, trifft fast automatisch die richtigen semantischen und barrierefreien Entscheidungen.

Links

Der HTM Hell Adventskalender

veröffentlicht jedes Jahr vom 1. bis 24. Dezember (und manchmal auch länger) täglich einen neuen Artikel rund um HTML, Barrierefreiheit, Semantik, Best Practices und typische Stolperfallen der Webentwicklung.