Die Kosten stehen nirgends in einer Rechnung. Sie stehen in der Woche, die eine neue Entwicklerin braucht, weil sie drei Muster lernen muss statt einem. Sie stehen in dem Bug, der nur auftritt, wenn zwei Bibliotheken gleichzeitig auf dasselbe Element zugreifen. Und sie stehen in den Attributen, die euer HTML Validator nicht kennt und die deshalb pauschal weggefiltert werden. Genau dieser Filter versteckt irgendwann einen echten Fehler.

Der teuerste Posten ist meist unsichtbar. Ein selbstgebautes Menü Overlay sieht auf dem Bildschirm richtig aus, hält aber den Fokus nicht fest. Wer mit der Tastatur navigiert, landet hinter dem geöffneten Menü in Inhalten, die er nicht sieht. Das ist kein Schönheitsfehler, sondern ein Befund nach BFSG und den Regeln für barrierefreies Webdesign.

Der Browser hat diese Probleme längst gelöst. Dialoge, Aufklappbereiche und Overlays sind heute native HTML Elemente mit Fokusverwaltung, Escape Taste und korrekter Semantik ab Werk. Was Teams vor Jahren nachbauen mussten, ist heute eine Zeile Markup.

Wir holen euch dorthin. Der Ablauf ist bei uns immer gleich: kostenloses Kennenlernen, ehrliche Aufwandsschätzung, danach transparente Minuten Abrechnung. Keine Pakete, keine Lizenzen, keine Bindung an uns.

Der wichtigste Satz in diesem Thema lautet: nicht nachbauen, was der Browser kann. Ein modaler Dialog liefert heute von sich aus die oberste Ebene ohne z-index Kämpfe, eine Fokusfalle, einen inerten Hintergrund, die Escape Taste und die Rückgabe des Fokus an den auslösenden Button. Das sind fünf Dinge, die in Eigenbauten fast immer fehlen.

Für kleine Overlays wie Sprachwahl oder Benutzermenü ist die Popover Funktion richtig. Für ein Menü, das den ganzen Bildschirm füllt, ist sie es nicht, denn ein Popover ist bewusst nicht modal. Der Hintergrund bleibt bedienbar und für Screenreader erreichbar. Diese Unterscheidung sauber zu treffen ist die halbe Arbeit.

Aufklappbare Bereiche in Navigationen und FAQ Listen brauchen überhaupt kein Skript. Details und Summary erledigen Zustand, Tastaturbedienung und Semantik allein und funktionieren auch dann, wenn JavaScript scheitert.

Wenn ihr grundsätzlicher über euren Frontend Ansatz nachdenkt, ordnen wir das mit ein. HTMX als Hypermedia Ansatz, TypeScript für mehr Typsicherheit oder Turbo aus dem UX Ökosystem sind je nach Projekt sinnvoll. Wir sagen euch ehrlich, wann sich der Wechsel lohnt und wann euer bestehender Stack völlig ausreicht.

Das ist der Teil, den viele Teams unterschätzen. Wer Eigenbau Widgets durch native Elemente ersetzt, erledigt einen großen Teil seiner Barrierefreiheit nebenbei. Fokusfalle, Fokusrückgabe, Tastaturbedienung und korrekte Rollen liefert der Browser mit. Man muss sie nur nicht kaputt machen.

Wir prüfen das nicht nur einmal, sondern verankern es. Die Tab Reihenfolge machen wir mit taba11y sichtbar, Lighthouse Audits und die Accessibility Werkzeuge in Firefox gehören bei uns zum normalen Arbeiten. Dazu kommt die saubere Überschriftenstruktur, die beim Umbau von Templates ohnehin auf dem Tisch liegt.

Automatisierte Tests finden nicht alles, aber sie finden Rückschritte. Deshalb laufen die Prüfungen bei uns in der Pipeline und nicht in einer einmaligen Auditdatei, die nach drei Monaten niemand mehr öffnet. Wenn ihr weiter denkt, findet ihr unser komplettes Angebot unter Accessibility Webdesign und Frontend.

Frontend Refactoring ist ein gutes Feld für KI Werkzeuge, aber nur mit Vorgabe. Wer einem Coding Agent sagt, er soll Alpine durch Stimulus ersetzen, bekommt eine wortwörtliche Übersetzung zurück. Dieselben Lücken, andere Syntax. Der Agent kennt euer Ziel nicht, er kennt nur euren Auftrag.

Deshalb schreiben wir vorher eine Spezifikation. Jede Anforderung bekommt Szenarien: Der Fokus verlässt das geöffnete Menü nicht. Escape schließt. Der Fokus kehrt zum Button zurück. Der Hintergrund scrollt nicht mit. Erst danach läuft die Umsetzung, und zwar prüfbar gegen diese Punkte.

Das ist derselbe Ansatz, mit dem wir Teams im Vibe Coding Consulting begleiten. Werkzeuge wie Claude Code beschleunigen den Umbau erheblich, wenn Leitplanken stehen. Ohne Leitplanken beschleunigen sie den Weg in die nächste Altlast. Passend dazu sorgen einheitliche Symfony Coding Standards dafür, dass am Ende nicht drei Handschriften im Projekt liegen.

Bei uns sitzen keine Berater mit Folien. 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. Symfony, Sulu und Twig sind unser tägliches Arbeitsgerät, nicht ein Punkt auf einer Referenzliste.

Wir arbeiten im Pair Programming direkt in eurem Projekt. Ihr seht, warum ein Element ersetzt wird, nicht nur dass es ersetzt wurde. Nach dem Umbau kann euer Team die nächste Komponente allein angehen. Genau darum geht es.

Das Frontend ist selten das einzige Thema. Wenn im selben Projekt noch ein PHP Update ansteht, der Backend Code über PHP Refactoring aufgeräumt werden muss oder Rector PHP automatisiert nachzieht, machen wir das im selben Zug. Einen Überblick über unser gesamtes Angebot findet ihr im PHP Consulting, praktische Beispiele wie der Telegram Bot für Symfony Formulare zeigen, wie klein wir anfangen können.

Wer ohne Symfony unterwegs ist und dieselbe Baustelle in Astro, React oder Vue hat, findet die framework neutrale Variante unter JavaScript ablösen für Barrierefreiheit und Performance. Dort steht auch die vollständige Gegenüberstellung von Alpine und nativen Elementen.

Wer lieber im Workshop Format startet, findet das im NCA RuhrRefactoring Consulting. Nachschlagewerk zu allen Werkzeugen ist unser PHP Glossar, inklusive Übersicht über die PHP 8 Versionen im Vergleich.

Die Fragen, die uns Teams in den ersten Gesprächen stellen. Wenn eure nicht dabei ist, stellt sie uns direkt.