Semantik, Barrierefreiheit, SEO & Performance

Barrierefreiheit, SEO und Performance werden meist als drei getrennte Aufgaben behandelt, obwohl sie dieselbe Grundlage auswerten: die Bedeutung, die im Markup steckt. Wer das richtige Element wählt statt es nachzubauen, erledigt mit einer Entscheidung Arbeit in allen drei Disziplinen – und bekommt Wartbarkeit obendrauf.

Das Wichtigste in Kürze

• Ein korrekt ausgezeichneter <button> erfüllt gleichzeitig WCAG 2.1.1 und 4.1.2, liefert einer Suchmaschine eine eindeutige Rolle, spart JavaScript und ist in zwei Jahren noch verständlich.
• Der Nachbau als <div> braucht tabindex, role, einen Keydown-Handler für Enter und Leertaste, einen eigenen Fokusstil und eine Formularanbindung – und ist danach in jeder Disziplin schlechter.
• Die häufigsten Barrieren im Web sind Semantikfehler. Laut WebAIM Million (Februar 2026) fehlten auf 53,1 % der Startseiten Alternativtexte, auf 51,0 % Formular-Labels, 46,3 % hatten leere Links. Das entsteht beim Schreiben des Markups und verschwindet dort auch am günstigsten.
• Startseiten mit ARIA hatten im selben Report 59,1 Fehler im Schnitt, Seiten ohne ARIA 42. WebAIM weist ausdrücklich darauf hin, dass das ein Zusammenhang ist und keine belegte Ursache – ARIA-reiche Seiten sind meist auch komplexer.
• Semantik ist kein Rankingfaktor. Sie wirkt indirekt, über auswertbare Struktur, bessere Snippets und schnelleres Rendern.
• Zielkonflikte gibt es, aber sie sind die Ausnahme: Animationen, Endlos-Scroll, aggressives Lazy-Loading. Alle drei lassen sich sauber auflösen.
• Automatische Prüfwerkzeuge finden grob die Hälfte der WCAG-Kriterien. Ein grüner Lighthouse-Wert ist ein Anfang und kein Ergebnis.

Eine Entscheidung, vier Wirkungen

Nimm den kleinsten möglichen Fall: ein Bedienelement, das ein Formular absendet.

<!-- Richtig: bringt alles mit -->
<button type="submit">Termin buchen</button>

<!-- Falsch: sieht gleich aus, kann nichts davon -->
<div class="btn" onclick="submitForm()">Termin buchen</div>

Der zweite Fall ist nicht nur unzugänglich. Er ist auch für einen Crawler ein Textknoten ohne Rolle, er braucht ein Skript, das geladen und ausgeführt werden will, und der nächste Mensch im Projekt muss den Klassennamen lesen, um zu ahnen, was passiert. Vier Nachteile aus einer Entscheidung – so wie es umgekehrt vier Vorteile aus einer Entscheidung sind.

Das ist das Muster, und es lässt sich fast beliebig durchdeklinieren:

Man muss diese Punkte nicht dreimal aus drei Blickwinkeln abarbeiten. Man macht sie einmal richtig – und hakt sie dreifach ab.

Warum das keine schöne Theorie ist

Der Beleg steckt in den Fehlerstatistiken. Der WebAIM-Million-Report untersucht jedes Jahr die Startseiten einer Million Websites automatisiert. Im Februar 2026 lagen an der Spitze der häufigsten Verstöße: fehlende Alternativtexte (53,1 % der Seiten), fehlende Formular-Labels (51,0 %), leere Links (46,3 %) und leere Buttons (30,6 %).

Das sind, bis auf die Kontrastfehler, alles keine exotischen Sonderfälle. Es sind Semantikfehler – Elemente ohne Namen, ohne Rolle, ohne Beziehung. Und es sind gleichzeitig genau die Stellen, an denen eine Suchmaschine nichts zu greifen bekommt: Ein leerer Link hat auch keinen Ankertext, ein Bild ohne alt taucht in keiner Bildersuche auf.

Der zweite Befund aus demselben Report ist der interessantere: Seiten, die ARIA verwenden, hatten im Schnitt 59,1 erkennbare Fehler, Seiten ohne ARIA 42. WebAIM warnt selbst davor, daraus eine Ursache zu machen – komplexe Anwendungen nutzen mehr ARIA und haben mehr Fehler. Aber die Richtung passt zur ersten Regel von ARIA: Kein ARIA ist besser als schlechtes ARIA.

Wo es sich tatsächlich reibt

Es gehört zur Sache dazu, dass die vier Ziele nicht immer am selben Strang ziehen. Drei Fälle, die mir regelmäßig begegnen – und wie sie sich auflösen lassen:

Animation. Eine aufwendige Bewegung hebt die wahrgenommene Qualität, kostet Renderzeit und kann bewegungsempfindlichen Menschen körperlich schaden. Auflösung: prefers-reduced-motion respektieren. Damit ist es keine Entweder-oder-Frage mehr, sondern eine Voreinstellung des Nutzers.

.karte { transition: transform 220ms ease; }

@media (prefers-reduced-motion: reduce) {
  .karte { transition: none; }
}

Endlos-Scroll. Fühlt sich modern an, macht Orientierung schwerer, verhindert Lesezeichen auf eine bestimmte Stelle und erschwert die Indexierung tieferer Inhalte. Auflösung: Paginierung mit echten URLs, optional durch einen „Mehr laden“-Button ergänzt – die Varianten stehen unter Pagination & mehr laden.

Aggressives Lazy-Loading. Spart Ladezeit und kann dazu führen, dass Inhalte erst beim Scrollen im DOM landen – für Screenreader-Nutzer eine wandernde Seite, für einen Crawler ein unvollständiges Dokument. Auflösung: Text immer serverseitig ausliefern, Lazy-Loading auf Bilder und Videos unterhalb des Sichtbereichs beschränken.

Was diese drei gemeinsam haben: Der Konflikt entsteht nie zwischen Barrierefreiheit und SEO, sondern zwischen einem Effekt und allen anderen Zielen zusammen. Das macht die Entscheidung leichter, als sie zunächst klingt.

Warum ich so baue

Ich optimier diese vier Dinge schon lange nicht mehr getrennt. Ich baue zuerst semantisch sauber und stelle dann fest, dass ein großer Teil der Barrierefreiheit, der Auffindbarkeit und der Ladezeit bereits erledigt ist. Das ist kein Dogma, sondern der kürzeste Weg – und es hat einen Nebeneffekt, der sich erst später zeigt: Diese Seiten altern besser. Ein <button> funktioniert in zehn Jahren noch; ein <div> mit drei Event-Listenern und einem Polyfill wird irgendwann von einem Browser-Update eingeholt.

Der Anspruch hat auch eine Grenze, die ich benennen will: Struktur allein prüft sich nicht. Ein grüner Lighthouse-Wert für Barrierefreiheit bedeutet, dass die automatisch prüfbaren Kriterien erfüllt sind – das ist grob die Hälfte. Ob ein Alt-Text sinnvoll ist, ob die Reihenfolge logisch klingt, ob ein Dialog die Aufmerksamkeit richtig lenkt, entscheidet weiterhin ein Mensch mit Tastatur und Screenreader.

Der Reihenfolge-Effekt: warum später teurer ist

Die vier Wirkungen fallen nicht nur gemeinsam an, sie fallen auch gemeinsam weg, wenn man die Struktur zu spät angeht. Das lässt sich an einem einzigen Bauteil durchspielen.

Angenommen, eine Filterleiste wird als Reihe von <div>-Elementen gebaut, weil das Design-System das so vorsieht. Beim ersten Audit ein Jahr später stehen dann vier Befunde an derselben Stelle: kein Tastaturzugang, keine Rolle für den Screenreader, kein erkennbarer Zustand „ausgewählt“, und die Filter tauchen im ausgelieferten HTML gar nicht auf, weil sie per JavaScript nachgeladen werden.

Vier Befunde, vier Zuständigkeiten, vier Tickets – und die Reparatur betrifft eine Komponente, die inzwischen an achtzehn Stellen eingebunden ist. Hätte dieselbe Leiste am ersten Tag aus <button>-Elementen mit aria-pressed bestanden, wäre keiner der vier Punkte entstanden.

Das ist der eigentliche Grund, warum ich Struktur nicht als Qualitätsthema behandle, sondern als Terminfrage: Sie kostet zu Beginn nichts und danach exponentiell mehr. Wer im Code-Review nur drei Fragen stellen kann, sollte diese nehmen:

1. Gibt es hier ein natives Element, das das schon kann? Wenn ja, warum steht es nicht da?
2. Trägt jedes Bedienelement einen Namen, den man vorlesen könnte? Icon ohne Text heißt: Es braucht einen.
3. Steht der Inhalt im ausgelieferten HTML? Wenn er erst durch Interaktion entsteht, existiert er für Auswertung und Hilfsmittel nicht.

Womit man welche der vier Wirkungen misst

Die gemeinsame Grundlage bedeutet nicht, dass ein einziges Werkzeug alles abdeckt. Jede Disziplin hat ihre eigene Messstelle – und wer das durcheinanderbringt, hält eine bestandene Prüfung für ein Ergebnis, das sie nicht ist.

Zwei Dinge fallen dabei auf. Erstens: Für die Barrierefreiheit gibt es keine Werkzeugzeile ohne Menschen – jede automatische Prüfung deckt grob die Hälfte ab, den Rest erledigt ein Testdurchlauf von Hand. Zweitens: Bei der Performance messen Labor und Feld verschiedene Dinge, und nur die Felddaten aus dem Chrome UX Report zählen für die Bewertung durch Google.

Der praktische Nutzen der gemeinsamen Grundlage zeigt sich genau hier: Wer semantisch sauber baut, hat in allen sieben Zeilen weniger zu tun. Nicht null – aber deutlich weniger.

Häufige Fragen

Heißt das, ich brauche keine separaten Audits mehr?

Doch. Jede Disziplin hat Eigenheiten, die die gemeinsame Grundlage nicht abdeckt: Kontrastwerte, Ladezeiten unter realen Netzbedingungen, Suchintention. Was sich ändert, ist die Menge der Befunde – man räumt nicht dreimal auf, sondern baut einmal ordentlich und prüft danach gezielt.

Was, wenn ein Ziel mit einem anderen kollidiert?

Dann abwägen, und meist gibt es eine Lösung, die allen dient – die drei Beispiele oben sind typisch. Echte, unauflösbare Konflikte sind selten. Wenn doch einer auftritt, gilt die Reihenfolge: Was Menschen aussperrt, wiegt schwerer als was einen Effekt kostet.

Wo fange ich an, wenn ich es richtig machen will?

Bei der Struktur, und zwar an der Stelle mit dem größten Hebel: Überschriften und Landmarks. Was ist semantisches HTML? ist der Einstieg; für ein bestehendes Projekt ist Div-Suppe vermeiden der praktischere Start.

Lohnt sich das auch bei einer kleinen Website?

Gerade da. Bei einem Projekt ohne eigenes Frontend-Team ist der Verzicht auf Nachbauten der einzige realistische Weg zu Barrierefreiheit – die native Lösung bringt mit, was sonst niemand pflegen würde.

Verwandte Themen

• Was ist semantisches HTML? – die gemeinsame Wurzel der vier Ziele
• Semantik & SEO – was Struktur für die Auffindbarkeit konkret leistet
• Die vier Prinzipien der WCAG – deren viertes, Robustheit, direkt auf semantisches Markup zeigt
• Core Web Vitals – die Messgrößen hinter der Performance-Spalte
• Erste Regel von ARIA – warum weniger Nachbau auch weniger ARIA bedeutet
• Barrierefreiheit selbst testen – die Hälfte, die kein Werkzeug abnimmt

Quellen

• The WebAIM Million (WebAIM, Februar 2026 – Fehlerhäufigkeiten auf einer Million Startseiten)
• Using ARIA (W3C – die erste Regel von ARIA)
• prefers-reduced-motion (MDN – Umsetzung der Bewegungsvoreinstellung)