Barrierefreies HTML & ARIA

Stell dir vor, ein Sechstel deiner Besucher stünde vor verschlossener Tür – und du wüsstest es nicht einmal. Genau das passiert auf unzähligen Webseiten: Bilder ohne Beschreibung, Buttons, die nur per Maus funktionieren, Formulare ohne Beschriftung. Die gute Nachricht dieser Lektion: Barrierefreiheit ist im Web kein teures Extra, sondern zum größten Teil schlicht korrekt geschriebenes HTML. Das meiste Handwerkszeug besitzt du also bereits – hier lernst du, es bewusst einzusetzen.

Die abgesenkte Bordsteinkante wurde für Rollstühle erfunden – benutzt wird sie von Eltern mit Kinderwagen, Reisenden mit Rollkoffern und Paketboten mit Sackkarren. Dieses Muster (im Englischen „Curb-Cut-Effekt“) gilt im Web genauso, denn Einschränkungen sind selten schwarz-weiß. Sie treten in drei Formen auf:

• Permanent: eine blinde Nutzerin, ein Mensch mit einem Arm, jemand mit dauerhafter motorischer Einschränkung.
• Temporär: der gebrochene Arm im Gips, die Augen-OP, die Migräne, die grelles Licht unerträglich macht.
• Situativ: das Baby auf dem Arm, die pralle Sonne auf dem Display, das Video ohne Ton in der lauten S-Bahn.

Wer für den ersten Fall baut, hilft automatisch allen dreien – und nebenbei auch Suchmaschinen, denn ein Google-Crawler ist funktional ein blinder Nutzer: Er sieht keine Pixel, er liest Struktur und Text. Barrierefreiheit und SEO sind zwei Seiten derselben Medaille.

Aus deinem HTML erzeugt der Browser neben dem sichtbaren Layout eine zweite Datenstruktur: den Accessibility Tree, aus dem Screenreader und andere assistive Technologien die Seite vorlesen und bedienbar machen. Dieser Baum ist exakt so gut wie dein Markup. Eine saubere Überschriften-Hierarchie wird zum Inhaltsverzeichnis, Landmarks wie <nav> und <main> werden zu Sprungzielen, ein <button> wird als Schalter angekündigt und ist sofort bedienbar.

Deshalb die vielleicht wichtigste Botschaft dieser Lektion: Rund 80 Prozent der Barrierefreiheit bekommst du geschenkt, wenn du anwendest, was du in den bisherigen Lektionen gelernt hast – semantische Elemente statt div-Wüsten, echte Listen, beschriftete Formularfelder, lückenlose Überschriften. Alles Weitere in dieser Lektion baut auf diesem Fundament auf; nichts davon kann fehlende Semantik reparieren.

Das alt-Attribut kennst du – aber gute alt-Texte sind eine Entscheidungsfrage, keine Fleißaufgabe. Frage dich bei jedem Bild: Welche Funktion hat es in diesem Kontext? Daraus ergeben sich drei Strategien:

• Informativ: Das Bild transportiert Inhalt. Beschreibe knapp, was es in diesem Zusammenhang aussagt – ohne die Floskel „Bild von …“, denn dass es ein Bild ist, sagt der Screenreader ohnehin an.
• Funktional: Das Bild ist ein Link oder Button, z. B. ein Lupen-Icon. Beschreibe die Aktion, nicht das Motiv: alt="Suchen", nicht alt="Lupe".
• Dekorativ: Das Bild schmückt nur (Zierlinie, Stimmungsfoto ohne Aussage). Dann bewusst leeres alt="" – der Screenreader überspringt das Bild komplett.

Der Unterschied zwischen leerem und fehlendem alt ist entscheidend: Fehlt das Attribut ganz, lesen viele Screenreader ersatzweise den Dateinamen vor – und „IMG_20260713_0042.jpg“ hilft niemandem. alt="" ist also keine Nachlässigkeit, sondern eine aktive, korrekte Entscheidung. Und noch eine Feinheit: Dasselbe Bild kann je nach Kontext jede der drei Strategien erfordern. Ein Porträtfoto ist im Teamverzeichnis informativ („Anna Berg, Leiterin Support“), als klickbarer Profil-Link funktional („Profil von Anna Berg öffnen“) und als reine Hintergrund-Deko leer.

Im folgenden Beispiel existieren die Bilddateien absichtlich nicht – so siehst du direkt in der Vorschau, was sonst nur Screenreader-Nutzer erleben: Der Browser zeigt ersatzweise den alt-Text an. Beobachte, dass das dekorative Bild mit alt="" schlicht verschwindet, statt zu stören. Ändere die Texte und ergänze ein viertes Bild mit einer eigenen Strategie.

Viele Menschen bedienen das Web ganz ohne Maus: blinde Nutzer sowieso, aber auch Menschen mit motorischen Einschränkungen, Nutzer von Spezialgeräten wie Tastensteuerungen – und nicht zuletzt Power-User. Der Maßstab ist einfach: Alles, was klickbar ist, muss per Tab erreichbar und per Enter oder Leertaste auslösbar sein.

Die Fokus-Reihenfolge folgt dabei der Reihenfolge im Quelltext. Das ist ein Feature, kein Zufall: Ist dein HTML logisch aufgebaut, stimmt die Tab-Reihenfolge automatisch. Eingreifen kannst du mit dem tabindex-Attribut – aber nur zwei Werte sind je sinnvoll:

• tabindex="0" nimmt ein Element, das von Natur aus nicht fokussierbar ist, an seiner natürlichen Position in die Tab-Reihenfolge auf.
• tabindex="-1" macht ein Element per Skript fokussierbar (etwa das Ziel eines Sprunglinks oder eine Fehlerbox), ohne es in die Tab-Reihenfolge einzuhängen.

Und tabindex="1" oder höher? Niemals. Positive Werte erzeugen eine zweite, parallele Reihenfolge, die vor allen normalen Elementen abgearbeitet wird. Der Fokus springt dann kreuz und quer über die Seite, und jedes später eingefügte Element macht das Kartenhaus unwartbarer. Wer die Reihenfolge ändern will, ändert die Reihenfolge im Quelltext – nicht die Nummerierung.

Damit Tastaturbedienung funktioniert, muss der Fokus außerdem sichtbar sein: Der Rahmen, den der Browser um das aktive Element zeichnet, ist für Tastaturnutzer das, was der Mauszeiger für alle anderen ist. Wie man ihn gestaltet, ist ein CSS-Thema – hier nur der Merkposten: outline: none ohne gleichwertigen Ersatz ist ein Barrierefreiheits-Bug.

ARIA ist ein Satz von Attributen, mit denen du dem Accessibility Tree zusätzliche Informationen mitgibst: Rollen, Namen, Zustände. Das klingt mächtig – und genau darin liegt die Gefahr. Die offizielle erste Regel von ARIA lautet sinngemäß: Benutze kein ARIA, wenn es ein natives HTML-Element gibt, das dasselbe leistet. Oder zugespitzt: Kein ARIA ist besser als falsches ARIA.

Das Paradebeispiel ist der nachgebaute Button. Ein <div role="button"> klingt im Screenreader wie ein Schalter – aber die Rolle ist nur ein Etikett. Sie liefert weder Tastatur-Fokus noch das Auslösen per Enter und Leertaste, kein disabled, keine Formular-Integration. All das müsstest du mit tabindex und JavaScript mühsam nachbauen – und vergisst dabei garantiert einen Teil. Das native <button> bringt alles gratis mit:

Der Unterschied ist keine Theorie – du kannst ihn sofort fühlen: Klicke in die Vorschau unten und drücke dann mehrmals Tab. Der Link und die echten Buttons erhalten nacheinander den Fokus (sichtbar am Rahmen), das div mit role="button" wird schlicht übersprungen, als wäre es gar nicht da.

Nach so viel Warnung die Entwarnung: Richtig eingesetzt ist ARIA wertvoll – nämlich dort, wo HTML allein keine Ausdrucksmöglichkeit hat. Diese sieben Attribute decken den Alltag ab:

Ein letztes Attribut in diesem Abschnitt ist gar kein ARIA, aber genauso wichtig: lang. Du kennst es vom <html lang="de"> – es steuert, mit welcher Aussprache Screenreader vorlesen. Weniger bekannt: Es funktioniert auch mitten im Text für Sprachwechsel. Ohne Auszeichnung liest eine deutsche Screenreader-Stimme englische Begriffe in deutscher Lautung vor – aus „One-Page-Design“ wird unverständliches Kauderwelsch. Mit <span lang="en">One-Page-Design</span> wechselt die Stimme korrekt ins Englische.

Barrierefreiheit ist längst nicht mehr nur guter Stil, sondern zunehmend Pflicht – und der Rahmen ist übersichtlicher, als er auf den ersten Blick wirkt. Die fachliche Grundlage bilden die WCAG, der internationale Standard mit den drei Konformitätsstufen A, AA und AAA (angestrebt wird in der Praxis fast immer AA). Die europäische Norm EN 301 549 übernimmt die WCAG als technische Messlatte für Europa. In Deutschland gilt für öffentliche Stellen die BITV 2.0 – und seit dem 28. Juni 2025 verpflichtet das Barrierefreiheitsstärkungsgesetz (BFSG) auch viele private Anbieter: Onlineshops und Verbraucher-Dienstleistungen wie Banking, Ticketbuchung oder E-Book-Portale müssen barrierefrei nutzbar sein.

Grund zur Panik? Nein – eher Grund zur Gelassenheit für alle, die sauber arbeiten. Wer semantisches HTML schreibt, Bilder korrekt beschreibt und Tastaturbedienung sicherstellt, erfüllt bereits einen erheblichen Teil der Anforderungen. Barrierefreiheit ist kein Zusatzprojekt am Ende, sondern ein Qualitätsmerkmal, das du von der ersten Zeile an mitbaust – und genau das übst du in diesem Kurs ohnehin schon.

In der nächsten Lektion – „Formulare für Profis“ – wendest du vieles davon sofort an: eingebaute Validierung, durchdachte Gruppierung und Fehlermeldungen, die wirklich bei allen ankommen.