Die Kosten stehen in keiner Rechnung. Sie stehen in den Tagen, die eine neue Entwicklerin braucht, um zu verstehen, warum das Menü drei Zustände an drei Stellen hält. Sie stehen in dem Fehler, der nur auftritt, wenn zwei Bibliotheken gleichzeitig auf dasselbe Element zugreifen. Und sie stehen in den nicht standardisierten Attributen, die euer Validator nicht kennt und deshalb pauschal wegfiltert. Genau dieser Filter versteckt irgendwann einen echten Fehler.

Der teuerste Posten ist unsichtbar. Ein Overlay, das den Fokus nicht festhält, ist kein Schönheitsfehler, sondern ein Verstoß gegen WCAG 2.2 und damit gegen das Barrierefreiheitsstärkungsgesetz. Seit dem 28. Juni 2025 gilt es für Onlineshops, Banken und viele weitere B2C Dienste. Bußgelder bis 100.000 Euro und Abmahnungen stehen im Raum.

Dazu kommt, was der Nutzer sofort merkt. Jede Bibliothek kostet Download, Parsing und Ausführung, bevor irgendetwas klickbar ist. Das schlägt direkt auf die Core Web Vitals durch. Am Ende zahlt ihr für Verhalten, das der Browser längst kostenlos mitbringt, und sichert es zusätzlich mit Cypress und axe-core ab, damit es nicht wieder kippt.

Das dialog Element ist seit März 2022 in allen modernen Browsern verfügbar und gilt als Baseline. Ein Aufruf von showModal() reicht, und der Browser erledigt vier Dinge auf einmal: Er fängt den Fokus im Dialog, macht den Rest der Seite inert, schließt bei Escape und gibt den Fokus beim Schließen an den auslösenden Button zurück. Genau das, wofür ein Eigenbau mehrere hundert Zeilen und trotzdem Lücken braucht.

Für Akkordeons gilt dasselbe in kleiner. details und summary sind das native Disclosure Pattern. Kein Zustand im JavaScript, kein aria-expanded von Hand, kein kaputter Tab Stop. Und wenn das JavaScript beim Laden hängt oder ein Fehler eine Datei blockiert, funktioniert der Inhalt trotzdem.

Wer eigene Widgets braucht, kommt weiter um ARIA nicht herum. Aber ARIA ist Beschriftung, nicht Funktion. Die erste Regel lautet seit Jahren: erst natives HTML, dann ARIA. Genau danach arbeiten wir.

Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz für Onlineshops, Banken, Buchungsplattformen und viele weitere B2C Dienste. Bußgelder bis 100.000 Euro und wettbewerbsrechtliche Abmahnungen stehen im Raum. Ein Menü, aus dem der Tastaturfokus herausfällt, ist dabei kein Randthema, sondern ein direkter Verstoß gegen mehrere Erfolgskriterien der WCAG 2.2.

Die Zeile in der Tabelle oben, in der 41 Validierungsfehler auf 0 fallen, ist deshalb mehr als Kosmetik. Nicht standardisierte Attribute im Markup bedeuten, dass Browser und Assistenztechnologien raten müssen. Sauberes HTML ist die Grundlage jeder A11Y Strategie und macht die Prüfung im Accessibility Webdesign überhaupt erst belastbar.

Automatisierte Scans finden nur einen Teil der Probleme. Fokusreihenfolge, Screenreader Ausgabe und die Frage, ob ein Dialog sich sinnvoll anfühlt, bleiben manuelle Arbeit. Native Elemente verkleinern diesen manuellen Teil massiv, weil der Browser die schwierigen Anteile bereits richtig macht. Wer tiefer einsteigen will, findet bei uns eine Übersicht zu Accessibility Testing Tools und zu barrierefreien Icons.

Jede JavaScript Bibliothek im Head kostet dreimal: Download, Parsing und Ausführung. Bei einem Menü, das der Browser selbst kann, zahlt ihr diesen Preis für nichts. Native Elemente sind bereits da, wenn das HTML ankommt. Es gibt keine Phase, in der die Seite sichtbar ist, aber noch nicht reagiert.

Das schlägt direkt auf die Core Web Vitals durch, besonders auf Interaction to Next Paint. Ein Klick auf ein summary Element wird vom Browser verarbeitet, nicht von einem Event Listener, der erst nach der Hydration existiert. In Astro Islands Projekten sparen wir damit ganze Inseln ein, die vorher nur wegen eines Toggles interaktiv waren.

Wir arbeiten täglich mit Astro, React und Vue. Die Frage ist nie Framework oder kein Framework, sondern: welcher Teil eurer Seite braucht wirklich Laufzeitlogik. Für alles andere gilt die Script Tag Best Practice: so wenig wie möglich, so spät wie möglich.

Ein Refactoring ohne Tests hält bis zum nächsten Sprint. Deshalb endet unsere Arbeit nicht beim funktionierenden Dialog, sondern bei der Pipeline, die ihn festhält. Wir schreiben Cypress Tests, die den kritischen Pfad mit der Tastatur abfahren: Menü öffnen, Fokus prüfen, Escape drücken, Fokus zurück auf dem Button.

Dazu läuft axe-core über cypress-axe auf jeder Seite und der HTML Validator als eigener Schritt. Beides als Quality Gate: Wer neue Fehler einbaut, merkt es im Pull Request und nicht im Audit. Für schnelle Zwischenstände nutzen wir zusätzlich den Lighthouse Accessibility Audit.

Wir sind Cypress Ambassador und setzen Cypress mit Cypress Cloud in eigenen Projekten täglich ein. Unit Tests im Frontend laufen bei uns über Vitest, typsicher mit TypeScript im Strict Mode. Das ist kein Zusatzangebot, das ist unsere normale Arbeitsweise.

Roland Golla ist der Gründer von Never Code Alone in Duisburg. Sein Thema: Die KI schreibt den Code, er sorgt für die Qualität. Seit über 20 Jahren Webentwicklung, seit 2013 Schwerpunkt Softwarequalität und automatisiertes Testen, Cypress Ambassador und Contributor im TYPO3 Core.

Wir kommen nicht mit einem Foliensatz, sondern mit einem Pull Request. Die Arbeit passiert in eurem Repository, in eurem Branch, mit eurem Team. Das gilt für Frontend Development genauso wie für PHP Refactoring oder Vibe Coding Consulting. Wer im Symfony Umfeld arbeitet und zusätzlich jQuery, Alpine und Stimulus gleichzeitig im Projekt hat, findet den passenden Einstieg beim Symfony Frontend Refactoring.

Wir starten mit einem kostenlosen Kennenlernen. Ihr zeigt uns die Komponenten, die euch Bauchschmerzen machen, wir schätzen den Aufwand ehrlich ein. Abgerechnet wird danach transparent minutengenau, ohne Paket und ohne Mindestlaufzeit. Wenn nach der Analyse klar ist, dass ihr das selbst schafft, sagen wir das auch.

Die häufigsten Fragen aus Erstgesprächen zum Ablösen von JavaScript, zu Aufwand, Risiko und Browserunterstützung.