Semantisches HTML als Grundlage

Semantisches HTML als Grundlage

0:00 Das ist das technische Herzstück von Tag zwei. Wir wissen jetzt, dass assistive Technik den Accessibility Tree liest — und in diesem Modul geht es darum, wie dieser Baum entsteht. Die gute Nachricht vorweg: Zum größten Teil entsteht er von allein, wenn Sie die richtigen Elemente verwenden. Der Leitsatz warnt vor der beliebtesten Abkürzung: ARIA fügt keine Funktion hinzu, es ändert nur, was gemeldet wird. Es ist ein Etikett, kein Motor.

0:26 Wer hier sauber arbeitet, spart sich in den Modulen zehn bis zwölf die Hälfte der Reparaturen — und zwar buchstäblich.

Semantisches HTML als Grundlage

0:34 Neun Kapitel, und sie gehen von der groben Struktur ins Detail. Erst Landmarks und Überschriften — das Gerüst der Seite. Dann Listen und Tabellen, dann die Unterscheidung von Link und Schaltfläche, dann die Grundsatzfrage nativ oder Eigenbau. Danach die vier Angaben, die assistive Technik über ein Element hat, der Abgleich der drei Darstellungen, und zum Schluss ARIA — mit einer Regel, die viele überrascht.

0:57 In der Übung bauen Sie ein Gerüst aus Container-Elementen in semantisches HTML um, ohne dass sich optisch irgendetwas ändert.

Dokumentstruktur und Landmark-Bereiche

1:05 Beginnen wir beim Gerüst. Landmarks sind Bereiche, die man direkt anspringen kann — und sie ersetzen für viele Menschen die Übersicht, die Sehende in einer Sekunde durch Hinsehen bekommen. Stellen Sie sich vor, Sie betreten einen Bahnhof. Mit einem Blick sehen Sie: dort die Anzeigetafel, dort die Schalterhalle, dort die Bahnsteige. Das dauert eine Sekunde.

1:27 Genau diese Sekunde ersetzen Landmarks. Die Elemente für Kopfbereich, Navigation, Hauptinhalt, Seitenbereich und Fußbereich erzeugen anspringbare Regionen. Drei Regeln dazu: genau ein Hauptbereich pro Seite, benannte Navigationen, wenn es mehrere gibt, und kein Inhalt außerhalb der Bereiche. Das Beste daran ist der Preis.

1:47 Es kostet nichts — Sie verwenden ohnehin Container, nur eben mit dem passenden Namen. Und der Gewinn ist für einen Teil Ihrer Nutzer erheblich. Fast jede Seite hat zwei Navigationen: oben die Hauptnavigation, unten die im Fußbereich. Ohne Namen heißen beide gleich, nämlich „Navigation" — und wer beim Anspringen zwischen ihnen wechselt, weiß nicht, wo er gelandet ist. Ein Label löst das mit einem Attribut.

2:14 Ein Detail, das oft falsch gemacht wird, steht in der Fußzeile: Das Wort „Navigation" gehört nicht ins Label. Die Rolle wird ohnehin angesagt, sonst hören die Nutzenden „Navigation Hauptnavigation". Das gilt allgemein für Namen — nennen Sie nie die Rolle mit. Bei Schaltflächen ist es derselbe Fehler: „Knopf Buchen buchen" hat noch niemandem geholfen.

2:37 Der erste Stolperstein ist eine reine Nachlässigkeit, die schnell passiert: mehrere Hauptbereiche auf einer Seite. Dann ist die Ansage „Hauptinhalt" wertlos, weil es drei davon gibt. Der zweite ist häufiger, als man denkt: Inhalt außerhalb aller Landmarks stehen lassen. Der ist dann nicht anspringbar und wird beim strukturierten Navigieren schlicht übersprungen — meist trifft es Hinweisbanner und Cookie-Leisten, also ausgerechnet wichtige Dinge.

3:03 Und der dritte ist ein Umweg: Landmarks per Rollen-Attribut nachrüsten, wo das native Element gereicht hätte. Das funktioniert zwar, ist aber mehr Code für dasselbe Ergebnis — und eine Stelle mehr, an der etwas veralten kann.

Überschriftenhierarchie

3:16 Weiter zu den Überschriften. Sie sind das Inhaltsverzeichnis Ihrer Seite — und werden trotzdem in den meisten Projekten nach Schriftgröße ausgewählt statt nach Struktur. Screenreader-Nutzende springen von Überschrift zu Überschrift, so wie Sie in einem Buch das Inhaltsverzeichnis überfliegen. Damit das funktioniert, müssen Überschriften die Struktur abbilden: eine erste Ebene, danach lückenlos absteigend. Zwei Beispiele zur Abgrenzung.

3:42 Eine Ergebnisliste bei Fahrtwind mit zwanzig gleichrangigen Überschriften der dritten Ebene ist völlig korrekt — zwanzig gleichrangige Dinge. Eine Seite, die von der ersten auf die vierte Ebene springt, weil die vierte kleiner aussah, ist es nicht. Da klafft eine Lücke im Inhaltsverzeichnis, und der Nutzer fragt sich, was er übersehen hat.

4:02 Hier steht die Lösung für das häufigste Argument gegen saubere Überschriften: „aber die Zweite ist zu groß". Trennen Sie die beiden Dinge. Die Ebene ist eine Aussage über die Struktur — sie sagt, wo dieser Abschnitt im Inhaltsverzeichnis steht. Die Schriftgröße ist eine Gestaltungsentscheidung und gehört in eine Klasse. Im Beispiel sehen Sie oben die falsche Lösung, bei der die Ebene nach dem Aussehen gewählt wurde, und unten die richtige: korrekte Ebene, Größe per Klasse. Das ist wirklich alles.

4:31 Und es löst neunzig Prozent aller Konflikte zwischen Entwurf und Semantik. Der erste Stolperstein ist der eben behandelte: Ebenen überspringen, weil die nächstkleinere Größe besser aussah. Der zweite ist eine Nebenwirkung mancher Baukastensysteme: mehrere Überschriften der ersten Ebene setzen. Dann ist unklar, worum es auf der Seite eigentlich geht — die erste Ebene ist der Seitentitel, und den gibt es einmal.

4:56 Und der dritte ist der stille: fett formatierte Absätze als Überschriften einsetzen. Optisch ist das eine Überschrift, im Baum ist es ein Absatz. Beim strukturierten Navigieren existiert dieser Abschnitt dann nicht — die Seite wirkt für Screenreader-Nutzende wie ein einziger langer Block.

Listen, Tabellen und strukturierte Inhalte

5:13 Jetzt zu zwei Strukturen, die eine Information mitliefern, an die man nicht denkt. Und diese Information geht beim Nachbau mit Containern verloren — unbemerkt, weil sie unsichtbar ist. Eine Liste sagt an, wie viele Einträge folgen. „Liste mit sieben Einträgen" — das ist eine echte Information, die Sehende aus der Länge des Blocks ablesen und die für andere sonst fehlt.

5:36 Eine Datentabelle mit Kopfzellen, Zuordnungsangabe und Beschriftung leistet noch mehr: Sie erlaubt es, eine einzelne Zelle mit ihren Überschriften vorgelesen zu bekommen — „Preis, vier Euro neunzig". Beides geht verloren, sobald Sie dieselbe Optik mit Containern nachbauen. Und das ist das Tückische: Sichtbar ist es identisch, semantisch ist es leer.

5:57 Kein Screenshot und kein Design-Review wird das je auffallen lassen. Oben die Container-Variante: zwei Werte nebeneinander. Optisch eine Tabellenzeile, im Baum zwei zusammenhanglose Textfetzen. Wer die Zeile hört, hört „sieben Uhr zwölf, vier neunzig" — und weiß nicht, was welche Zahl bedeutet. Unten dieselbe Zeile als echte Tabelle.

6:18 Drei Dinge kommen dazu: eine Beschriftung, die sagt, worum es in dieser Tabelle geht, echte Kopfzellen, und die Zuordnungsangabe, mit der die Technik weiß, welche Kopfzelle zu welcher Datenzelle gehört. Damit wird aus zwei Zahlen ein lesbarer Datensatz. Der Mehraufwand liegt bei einer Minute, der Unterschied bei allem. Der erste Stolperstein ist ein Rückfall in die neunziger Jahre, der immer noch vorkommt: Layouttabellen verwenden.

6:45 Damit täuschen Sie Datenstruktur vor, die es nicht gibt, und der Screenreader liest Zeilen und Spalten an, wo einfach nur ein Layout ist. Der zweite ist der häufigere: Datentabellen ohne Kopfzellen bauen. Dann ist die Struktur da, aber der Bezug fehlt — und der Bezug war der ganze Gewinn. Und der dritte ist eine kleine Nachlässigkeit mit Wirkung: Aufzählungen als Absätze mit Trennstrichen setzen.

7:08 Sieht aus wie eine Liste, ist keine, und die Anzahl der Einträge wird nicht angesagt.

Links und Schaltflächen richtig unterscheiden

7:14 Jetzt der häufigste Fehler in gewachsenem Frontend-Code — und zugleich der am leichtesten zu behebende. Es geht um zwei Elemente, die visuell fast alles gemeinsam haben und funktional grundverschieden sind. Die Regel ist denkbar einfach: Ein Link führt woandershin, eine Schaltfläche löst etwas aus. Und das ist keine Formsache, sondern hat unmittelbare Folgen für die Bedienung.

7:36 Ein Link reagiert auf die Eingabetaste, lässt sich in einem neuen Tab öffnen, in die Zwischenablage kopieren, als Lesezeichen speichern. Eine Schaltfläche reagiert zusätzlich auf die Leertaste, weil sie eben nirgendwohin führt. Und ein Container mit Klickhandler kann von alledem nichts — er ist für Tastatur und assistive Technik schlicht nicht vorhanden.

7:57 Das ist der Fall, den wir seit Modul eins mitschleppen, und hier ist seine technische Erklärung. Diese Tabelle bringt es auf den Punkt. Ein Link mit Ziel: Eingabetaste, fokussierbar, im Kontextmenü in neuem Tab zu öffnen. Eine Schaltfläche: Eingabe- und Leertaste, fokussierbar, kein Ziel — logisch, sie führt ja nirgendwohin.

8:17 Und die dritte Zeile ist die ernüchternde: Container mit Klickhandler, Tastatur gar nicht, nicht fokussierbar, kein Ziel. Dreimal „nichts". Und noch einmal zur Erinnerung: Alle drei sehen auf dem Bildschirm identisch aus, wenn man sie gleich gestaltet. Deshalb wird das im Design-Review nie auffallen und im Tastaturdurchlauf sofort.

8:39 Der erste Stolperstein ist einer der Erwartung: Schaltflächen als Links stylen oder umgekehrt. Menschen lernen aus dem Aussehen, was passiert — ein Link-Aussehen verspricht ein Ziel. Der zweite ist eine technische Feinheit mit großer Wirkung: Links ohne Zieladresse verwenden. Ohne Ziel ist ein Link kein Link mehr — er ist nicht fokussierbar und wird nicht als Link gemeldet.

9:02 Und der dritte ist die halbe Reparatur: einen Container fokussierbar machen und dabei Rolle und Tastenverhalten vergessen. Dann kommt der Fokus zwar an, aber niemand erfährt, was das Element ist, und die Leertaste tut nichts. Halbe Lösungen sind hier oft verwirrender als gar keine.

Native Elemente vor eigenen Widgets

9:19 Damit zu einer Grundsatzentscheidung, die in jedem Projekt fällt — meist nebenbei und ohne dass jemand die Folgekosten aufschreibt. Es geht um nativ gegen Eigenbau. Ein natives Auswahlfeld ist ein erstaunliches Stück Software, das Sie geschenkt bekommen. Es bringt Tastaturbedienung mit, Semantik, und auf jedem Gerät das plattformübliche Verhalten — auf dem Telefon einen Rollenauswähler, am Rechner eine Liste.

9:44 Und es wird gewartet, ohne dass Sie etwas tun. Ein nachgebautes Auswahlfeld muss all das selbst mitbringen, und in der Praxis tut es das selten vollständig. Die Faustregel, die ich Ihnen ans Herz lege: eigene Widgets nur, wenn eine Anforderung nachweislich nicht anders erfüllbar ist. Und „das Aussehen ist nicht anpassbar" ist heute deutlich seltener wahr als noch vor fünf Jahren.

10:07 Die rechte Spalte ist eine Aufwandsschätzung, die in der Entscheidung meistens fehlt. Das Tastaturmuster: vollständig selbst zu bauen, mit allen Pfeiltasten, Pos1, Ende und Suchbuchstaben. Rolle und Zustand: über ARIA zu setzen — und dauerhaft zu pflegen. Das Verhalten auf Touch: je Plattform nachzustellen. Und die vierte Zeile ist die, die ich für die wichtigste halte: Künftige Verbesserungen kommen beim nativen Element mit dem Browser, beim Eigenbau kommen sie nie von allein.

10:36 Ihr Widget von heute ist Ihr Wartungsfall von übermorgen. Das gehört in die Entscheidung, nicht in die Retrospektive. Der erste Stolperstein ist der häufigste Anlass für Eigenbau: ein natives Element ersetzen, weil sein Aussehen nicht anpassbar schien. Prüfen Sie das noch einmal — bei vielen Elementen hat sich in den letzten Jahren einiges getan.

10:57 Der zweite ist ein Plan, der nie aufgeht: den Eigenbau ohne Tastaturmuster ausliefern und es später nachrüsten wollen. Später ist der Sprint voll und die Komponente an dreißig Stellen im Einsatz. Und der dritte ist der kaufmännische: die Wartungslast des Eigenbaus bei der Entscheidung nicht mitrechnen. Ein Widget ist keine einmalige Ausgabe, es ist ein Abonnement.

Accessible Name, Role, State und Value

11:18 Jetzt zu den vier Angaben, die bestimmen, was assistive Technik über ein Element überhaupt weiß. Sie sind der Inhalt des Accessibility Tree — und sie erklären, warum manche Bedienelemente technisch funktionieren und praktisch unbrauchbar sind. Vier Angaben, vier Herkünfte. Die Rolle kommt meistens vom Element selbst — deshalb war das ganze bisherige Modul so wichtig.

11:41 Der Name kommt aus der Beschriftung, aus einem Label-Attribut oder aus einem Verweis auf einen anderen Text. Zustand und Wert kommen aus Attributen. Und jetzt der Fall, um den es hier geht: Eine Symbolschaltfläche ohne Namen wird als „Schaltfläche" angesagt. Punkt. Sie ist technisch bedienbar — der Fokus kommt an, die Taste funktioniert — und praktisch nutzlos, weil niemand weiß, was passiert.

12:05 Das ist die häufigste halbe Barrierefreiheit, die es gibt. Lesen Sie die rechte Spalte als Diagnoseliste. Die Rolle fehlt, wenn ein Container verwendet wird. Der Name fehlt, wenn nur ein Symbol im Element steht. Der Zustand fehlt, wenn er nur in der Gestaltung lebt — das ist der häufigste und subtilste Fall: Eine Klasse macht etwas optisch aktiv, aber im Baum steht davon nichts.

12:29 Und der Wert fehlt, wenn ein Regler nachgebaut wurde. Sie sehen das Muster: Alle vier Lücken entstehen aus derselben Ursache. Die Information existiert visuell und wurde nie in den Baum überführt. Genau diese Übersetzung ist die Arbeit, um die es in diesem Modul geht. Der erste Stolperstein sieht aus wie eine gute Lösung: den Namen aus einem Titel-Attribut beziehen.

12:52 Das ist unzuverlässig, wird nicht überall ausgewertet und auf Touch-Geräten praktisch nie angezeigt. Nehmen Sie eine echte Beschriftung oder ein Label-Attribut. Der zweite ist der eben genannte Klassiker: Zustände nur über Klassen führen und nie als Attribut melden. Wenn Ihr Aufklapp-Panel eine Klasse „offen" hat, muss der Zustand auch im Attribut stehen.

13:13 Und der dritte ist eine Wirkungslosigkeit, die viele überrascht: ein Label-Attribut auf ein Element setzen, das gar keine Rolle hat. Ohne Rolle wird der Name in vielen Fällen nicht gemeldet — das Attribut verpufft.

DOM, Accessibility Tree und visuelle Darstellung

13:26 Drei Darstellungen desselben Inhalts — und sie können auseinanderlaufen. Eine davon sieht der Nutzer, eine hört er, und eine bestimmt, wohin der Fokus springt. Keine korrigiert die andere. Hier lauert eine Falle, die mit modernen Layoutverfahren stark zugenommen hat. Sie können mit einer Anordnungsregel bei Grid oder Flexbox die sichtbare Reihenfolge ändern, ohne die Fokusreihenfolge zu ändern.

13:50 Das ist bequem — man schiebt im mobilen Layout etwas nach oben — und es führt dazu, dass der Tastaturfokus quer über den Bildschirm springt. Für sehende Tastaturnutzende ist das besonders unangenehm, weil das Auge dem Fokus nicht folgen kann. Wer solche Abweichungen sucht, vergleicht schlicht die Tab-Reihenfolge mit dem, was das Auge erwartet. Der Test dauert eine Minute und findet erstaunlich viel.

14:14 Fünf Schritte, und die Reihenfolge ist wichtig. Zuerst notieren Sie die erwartete Reihenfolge — vorher, sonst passen Sie Ihre Erwartung unbewusst an. Dann gehen Sie mit dem Tabulator durch und notieren die tatsächliche. Schritt drei enthält den entscheidenden Hinweis: Abweichungen im Markup suchen, nicht im Stylesheet beheben wollen. Dann prüfen Sie im Accessibility Tree Rolle und Name.

14:37 Und Schritt fünf ist die eigentliche Lehre: die Reihenfolge im DOM korrigieren, nicht mit Fokusindizes überschreiben. Positive Fokusindizes verschlimmern das Problem fast immer — sie beheben es nicht, sie verschieben es an eine andere Stelle, wo es dann noch schwerer zu finden ist. Der erste Stolperstein ist die eben beschriebene Anordnungsfalle: die visuelle Reihenfolge ändern und die DOM-Reihenfolge belassen. Verlockend, weil es so einfach ist.

15:04 Der zweite ist die typische Reparatur, die alles schlimmer macht: Abweichungen mit positiven Fokusindizes geradebiegen. Damit reißen Sie das Element aus der natürlichen Reihenfolge und erzeugen an anderer Stelle einen Sprung — und beim nächsten neuen Element beginnt das Spiel von vorn. Und der dritte begegnet uns zum dritten Mal, weil er so folgenreich ist: den Accessibility Tree nie öffnen und Semantik aus dem Markup vermuten.

15:28 Er ist in jedem Browser zwei Klicks entfernt.

ARIA: wann es nötig ist und wie es schiefgeht

15:31 Jetzt zum am meisten missverstandenen Werkzeug in diesem Feld. Es hat eine offizielle erste Regel, und die lautet — Sie werden es kaum glauben — es nicht zu benutzen. Die erste Regel von ARIA lautet tatsächlich: Benutzen Sie ARIA nicht, wenn ein natives Element dasselbe leistet. Das steht so in der Spezifikation, und es ist gut begründet.

15:53 Denn hier ist der Satz, der alles erklärt: ARIA fügt keine Funktion hinzu. Es ändert nur, was gemeldet wird. Ein Etikett, kein Motor. Wenn Sie einem Container eine Schaltflächen-Rolle geben, meldet er sich als Schaltfläche — und tut trotzdem nichts, wenn jemand die Leertaste drückt. Das Tastaturverhalten müssen Sie weiterhin selbst bauen. Sinnvoll und notwendig ist ARIA bei Live Regions und bei zusammengesetzten Widgets, für die es kein natives Element gibt.

16:22 Vier Fehler, die ich in fast jedem Projekt finde. Eine Schaltflächen-Rolle auf ein Schaltflächen-Element: überflüssig, die Rolle ist schon da. Ein Label-Attribut auf einem Container ohne Rolle: wird oft gar nicht gemeldet. Ein Element für assistive Technik ausblenden, das fokussierbar bleibt: Der Fokus landet dann im Nichts — dagegen hilft, es zusätzlich inaktiv zu setzen.

16:45 Und ein Verweis auf eine Id, die es nicht gibt: Der Name bleibt leer, und niemand merkt es, weil das Attribut ja dasteht. Alle vier sehen im Code nach Sorgfalt aus. Im Baum sind sie wirkungslos oder schädlich. Der erste Stolperstein ist der Kern des Kapitels: ARIA einsetzen, um fehlendes Tastaturverhalten zu kaschieren. Das Element meldet sich dann als bedienbar und ist es nicht — das ist schlechter als gar keine Semantik, weil es ein falsches Versprechen macht.

17:14 Der zweite ist eine Fleißfalle: Rollen doppeln, weil das Attribut hilfreich aussieht. Mehr ARIA ist nicht besser. Und der dritte ist hochaktuell: generierten ARIA-Code übernehmen, ohne den Accessibility Tree zu prüfen. KI-Werkzeuge neigen besonders zum Übermaß an ARIA — es sieht gründlich aus und ist häufig falsch. Darauf kommen wir in Modul neunzehn ausführlich zurück.

Übung — ein div-Gerüst in semantisches HTML überführen

17:38 In der Übung machen Sie genau das, worum es in diesem Modul geht — und mit einer Nebenbedingung, die den Lerneffekt trägt: Optisch darf sich nichts ändern. Sie bauen eine Fahrtwind-Detailseite semantisch neu auf. Geübt wird, sichtbar gleiche Oberflächen semantisch korrekt umzusetzen und den Unterschied im Accessibility Tree nachzuweisen.

17:57 Erfolgreich sind Sie, wenn die Seite unverändert aussieht, kein Container mit Klickhandler mehr enthalten ist und der Vergleich der Bäume für jedes Bedienelement Rolle und Namen zeigt. Die Nebenbedingung mit der unveränderten Optik ist Absicht: Genau daran merken Sie, dass Semantik kein Gestaltungsthema ist. Nichts, was Sie hier tun, kostet Sie einen einzigen Pixel. Wer früh fertig ist, prüft die Fokusreihenfolge gegen die sichtbare Reihenfolge und notiert jede Abweichung.

18:25 Fünf Schritte, und beachten Sie die Einschränkung in der Fußzeile: keine ARIA-Attribute in dieser Übung. Wer eines zu brauchen glaubt, notiert die Stelle — das ist Material für Modul zwölf. Sie beginnen mit dem Tastaturdurchlauf und notieren, was unerreichbar ist. Dann setzen Sie Landmarks und ordnen die Überschriften. Dann ersetzen Sie jeden klickbaren Container durch eine echte Schaltfläche oder einen Link mit Ziel.

18:50 Dann ergänzen Sie Namen, wo nur Symbole stehen. Und zum Schluss vergleichen Sie die Bäume vorher und nachher. Dieser Vergleich ist der eigentliche Ertrag — er macht sichtbar, was Sie gerade gewonnen haben. Der erste Stolperstein macht den Nachweis unmöglich: das Aussehen mitverändern. Dann können Sie hinterher nicht mehr zeigen, dass Semantik nichts mit Gestaltung zu tun hat — und im echten Projekt haben Sie eine Änderung, die durch die Designabnahme muss.

19:17 Der zweite ist der Rückfall in die Abkürzung: Rollen per ARIA setzen, statt das passende Element zu wählen. In dieser Übung ausdrücklich verboten, und im Alltag fast immer die schlechtere Wahl. Und der dritte ist ein Prüfumfangsfehler: nur die sichtbaren Bedienelemente prüfen und versteckte auslassen. Gerade in aufklappbaren Bereichen schlummern die interessanten Fälle.

19:39 Vier Punkte. Landmarks und Überschriften bilden Struktur ab, nicht Schriftgrößen — die Größe gehört in eine Klasse. Ein Link führt woandershin, eine Schaltfläche löst aus, und das ist keine Formsache, sondern entscheidet über Tastaturbedienung. Rolle, Name, Zustand und Wert entscheiden, was assistive Technik über ein Element weiß — vier Angaben, die Sie prüfen können.

20:02 Und die erste ARIA-Regel lautet, ARIA nicht zu benutzen. Der Satz, den ich Ihnen am liebsten mitgeben würde, steht in der Fußzeile: Sichtbar identisch heißt nicht semantisch gleich. Der Unterschied steht nur im Accessibility Tree — schauen Sie hinein. Als Nächstes geht es um Tastatur und Fokus.