Semantisches HTML anhand einer vollständigen Beispielseite
Eine kleine Veranstaltungsseite zeigt, wie Bedeutung, Struktur und Bedienung zusammenpassen. Mit vollständigem Quelltext und einer Checkliste für bestehende Projekte.
Eine Webseite besteht aus mehr als sichtbaren Rechtecken. Hinter einer großen Schrift kann eine echte Überschrift stehen oder ein beliebiger Container mit großer Schriftgröße. Auf dem Bildschirm sehen beide Varianten zunächst ähnlich aus. Für Tastaturbedienung, unterstützende Technologien und die Wartung des Quellcodes können sie sich erheblich unterscheiden.
Dieser Leitfaden entwickelt eine kleine, vollständige Informationsseite für einen fiktiven Reparaturtreff. Das Beispiel benötigt weder Framework noch JavaScript. Es zeigt, wie Inhalt, Seitenregionen und Interaktion zusammenpassen. Anschließend ergänzen wir typische Formular- und Bedienbeispiele. Die Beispiele sind Lehrmaterial und ersetzen keine Sicherheitsprüfung einer produktiven Anwendung.
1. Zuerst den Inhalt verstehen
Bevor ein HTML-Element ausgewählt wird, muss die Funktion des Inhalts klar sein. Eine Gruppe mit Datum und Veranstaltungsort ist eine andere Aufgabe als eine Hauptnavigation. Ein einzelner Reparaturbericht kann für sich stehen. Ein Abschnitt mit Anreiseinformationen gehört dagegen zum übergeordneten Veranstaltungsangebot.
Für die Beispielseite formulieren wir drei Aufgaben: Besucher sollen Termin und Ort finden, den Ablauf verstehen und prüfen, welche Gegenstände geeignet sind. Daraus entsteht die Inhaltsfolge „Nächster Termin“, „So läuft es ab“ und „Was Sie mitbringen können“. Eine zusätzliche Information zum ehrenamtlichen Projekt steht am Ende.
Diese Vorarbeit verhindert, dass semantische Elemente lediglich als neue Namen für gestalterische Kästen benutzt werden. Ein Container wird nicht automatisch zum Artikel, weil er eine eigene Hintergrundfarbe hat. Umgekehrt kann ein sinnvoller Artikel mehrere visuell unterschiedliche Bereiche enthalten. Die Bedeutung folgt dem Zusammenhang und nicht der Anzahl der Rahmen.
Notieren Sie für jeden Bereich einen Satz: „Dieser Bereich dient dazu, dass …“. Ist keine konkrete Funktion formulierbar, fehlt möglicherweise eine klare Aufgabe. Häufig wird dann auch die Überschrift genauer. Aus „Informationen“ wird beispielsweise „Welche Geräte können mitgebracht werden?“. Das hilft bereits vor der ersten Zeile Quellcode.
2. Die wichtigsten Elemente richtig unterscheiden
| Element | Typischer Zweck | Frage zur Auswahl |
|---|---|---|
| header | Einleitung eines Dokuments oder Bereichs | Führt dieser Inhalt in etwas ein? |
| nav | Wichtiger Navigationsbereich | Hilft diese Linkgruppe bei der Orientierung? |
| main | Dominierender Inhalt der Seite | Was ist das eigentliche Seitenthema? |
| article | Eigenständige inhaltliche Einheit | Kann dieser Beitrag für sich stehen? |
| section | Thematischer Abschnitt | Hat dieser Bereich ein eigenes Thema? |
| aside | Ergänzender, abtrennbarer Inhalt | Ist die Information ergänzend zum Hauptzusammenhang? |
| footer | Abschließende Angaben zum zugehörigen Bereich | Zu welchem Dokument oder Beitrag gehören diese Angaben? |
| div | Neutraler Container | Geht es ausschließlich um Gruppierung oder Gestaltung? |
Die HTML-Spezifikation von WHATWG beschreibt die Elemente und ihre vorgesehenen Zusammenhänge. Für die Praxis besonders wichtig: Ein article ist eine grundsätzlich eigenständige Einheit. Ein section gliedert ein Thema. Ein neutrales div bleibt sinnvoll, wenn keine zusätzliche Bedeutung beabsichtigt ist.
Nicht jeder Link braucht ein nav. Ein Quellenverweis innerhalb eines Absatzes ist einfach ein Link. Eine Hauptnavigation oder ein Inhaltsverzeichnis kann dagegen ein Navigationsbereich sein. Ebenso ist ein aside keine pauschale Bezeichnung für alles, was rechts steht. Seine Funktion bleibt ergänzend, auch wenn CSS den Bereich später unter dem Haupttext anordnet.
3. Eine vollständige Beispielseite aufbauen
Speichern Sie den folgenden Quelltext als reparaturtreff.html und öffnen Sie die Datei im Browser. Die Seite funktioniert ohne zusätzliche Dateien. Datum, Ort und Veranstaltungsangaben sind ausdrücklich fiktiv. Die wenigen CSS-Regeln dienen nur einer lesbaren Darstellung. Der Inhalt bleibt auch ohne sie verständlich.
<!doctype html>
<html lang="de">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Reparaturtreff: Termin und Ablauf</title>
<meta name="description" content="Fiktive Lernseite zu Termin, Ablauf und Vorbereitung eines Reparaturtreffs.">
<style>
body { margin: 0 auto; max-width: 68rem; padding: 1.25rem;
font: 1.1rem/1.65 system-ui, sans-serif; color: #202326; }
a { color: #a40000; text-underline-offset: .2em; }
:focus-visible { outline: 3px solid #a40000; outline-offset: 4px; }
nav ul { display: flex; flex-wrap: wrap; gap: 1rem; padding: 0;
list-style: none; }
section { margin-block: 2rem; }
footer { margin-top: 3rem; border-top: 1px solid #777; }
</style>
</head>
<body>
<a href="#inhalt">Zum Inhalt</a>
<header>
<p>Ein fiktiver Treffpunkt für gemeinsames Reparieren</p>
<nav aria-label="Hauptnavigation">
<ul>
<li><a href="#termin">Termin und Ort</a></li>
<li><a href="#ablauf">Ablauf</a></li>
<li><a href="#vorbereitung">Vorbereitung</a></li>
</ul>
</nav>
</header>
<main id="inhalt" tabindex="-1">
<h1>Der Reparaturtreff im Beispielviertel</h1>
<p>Hier lernen Sie die Struktur einer kleinen Veranstaltungsseite kennen.</p>
<section aria-labelledby="termin">
<h2 id="termin">Nächster Termin und Ort</h2>
<p><time datetime="2026-12-05T14:00:00+01:00">5. Dezember 2026, 14 Uhr</time></p>
<p>Fiktiver Veranstaltungsort: Beispielhaus, Musterstraße 1.</p>
</section>
<section aria-labelledby="ablauf">
<h2 id="ablauf">So läuft die Teilnahme ab</h2>
<ol>
<li>Beschreiben Sie den Defekt bei der Anmeldung vor Ort.</li>
<li>Besprechen Sie mit dem Team, ob eine Prüfung möglich ist.</li>
<li>Bleiben Sie während der gemeinsamen Arbeit dabei.</li>
</ol>
</section>
<section aria-labelledby="vorbereitung">
<h2 id="vorbereitung">Was Sie vorbereiten können</h2>
<p>Notieren Sie den Fehler und bringen Sie vorhandene Unterlagen mit.</p>
<details>
<summary>Warum wird eine Fehlerbeschreibung benötigt?</summary>
<p>Sie hilft, das Problem und die mögliche Prüfung einzugrenzen.</p>
</details>
</section>
</main>
<aside aria-labelledby="projekt">
<h2 id="projekt">Über dieses Lernbeispiel</h2>
<p>Die Veranstaltung ist erfunden. Das Beispiel erklärt HTML-Strukturen.</p>
</aside>
<footer>
<p>Semantisches HTML: eigenständiges Lernmaterial der Agentur Zentral.</p>
</footer>
</body>
</html>Der sichtbare Sprunglink führt zum Hauptinhalt. Die Navigation verweist auf vorhandene Abschnittsüberschriften. Das Datum ist lesbar formuliert und zusätzlich maschinenlesbar hinterlegt. Der aufklappbare Hinweis verwendet ein natives Element und benötigt für seine Grundfunktion kein eigenes Skript.
Die Beispielseite enthält bewusst keinen article. Ihr Hauptinhalt ist eine zusammenhängende Veranstaltungsinformation. Ein zusätzlicher, eigenständiger Reparaturbericht wäre dagegen ein guter Kandidat für dieses Element. Semantische Qualität bedeutet nicht, möglichst viele verschiedene Tags unterzubringen.
Vollständige HTML-Beispielseite öffnen oder speichern
4. Überschriften als Inhaltsplan behandeln
Die Überschriften sollten gemeinsam einen brauchbaren Überblick ergeben. Auf die Hauptüberschrift folgen hier drei Abschnitte mit h2. Unterpunkte eines Abschnitts könnten h3 erhalten. Die Größe der Schrift wird anschließend mit CSS festgelegt. Eine kleinere Schrift braucht keine niedrigere Überschriftenebene.
Die W3C-Anleitung zu Überschriften erläutert die Gliederung nach Rangstufen. Beim Öffnen einer Untergliederung sollten Ebenen möglichst nicht übersprungen werden. Beim Schließen einer Untergliederung ist der Rücksprung auf eine höhere Ebene dagegen normal.
Ein typischer Fehler entsteht durch Gestaltungsvorlagen: Ein Kartenbaustein liefert immer h3, selbst wenn er direkt auf die Hauptüberschrift folgt. Der Baustein muss seine Ebene dann aus dem tatsächlichen Kontext erhalten. Diese Entscheidung gehört in die Komponentenschnittstelle und sollte nicht allein durch die gewünschte Schriftgröße bestimmt werden.
Prüfen Sie Ihre Seite deshalb auch als reine Liste ihrer Überschriften. Sind die Aussagen ohne dazwischenliegende Bilder verständlich? Werden unterschiedliche Themen mit identischen allgemeinen Titeln bezeichnet? Fehlt zwischen Hauptthema und Detail eine Ebene? Ein solcher Durchgang findet häufig Probleme, die in einer visuell aufwendigen Gestaltung verborgen bleiben.
5. Links und Schaltflächen nach ihrer Aufgabe wählen
Ein Link führt zu einer Adresse oder einem anderen Dokumentbereich. Eine Schaltfläche löst eine Aktion aus. Diese einfache Unterscheidung verhindert viele unnötige Eigenkonstruktionen. Wenn ein Besucher die Kontaktseite öffnen soll, ist ein Link passend. Wenn innerhalb derselben Ansicht eine Filterauswahl angewendet wird, kann eine Schaltfläche richtig sein.
<a href="/kontakt">Kontakt aufnehmen</a>
<button type="button">Filter anwenden</button>Das zweite Beispiel benötigt natürlich eine zugehörige Funktionslogik. Der Buttontext allein implementiert keinen Filter. Der explizite Typ verhindert außerdem, dass die Schaltfläche in einem späteren Formularkontext versehentlich als Absenden-Schaltfläche behandelt wird. Eine echte Formularübermittlung verwendet dagegen gezielt type="submit".
Die MDN-Dokumentation zum Button beschreibt die Eigenschaften und Typen. Ein klickbares div müsste viele native Eigenschaften zusätzlich nachbilden. Das betrifft beispielsweise Fokus und Tastaturverhalten. Für gewöhnliche Schaltflächen ist das passende native Element die einfachere Ausgangsbasis.
Auch Linktexte gehören zur Semantik. Ein Symbol ohne verständlichen zugänglichen Namen kann seine Aufgabe verbergen. „Termin und Ort“ benennt im Lernbeispiel ein konkretes Ziel. Mehrere voneinander unabhängige Links mit dem Text „Hier“ würden diese Orientierung schwächen.
6. Formulare mit echten Beschriftungen ergänzen
Ein Formularfeld benötigt eine verständliche Zuordnung zwischen Bezeichnung und Eingabe. Ein Platzhalter ist dafür kein verlässlicher Ersatz. Er verschwindet während der Eingabe und kann wichtige Hinweise verbergen. Die sichtbare Beschriftung sollte dauerhaft erklären, welche Information erwartet wird.
<label for="geraet">Welchen Gegenstand möchten Sie beschreiben?</label>
<input id="geraet" name="geraet" type="text"
aria-describedby="geraet-hilfe">
<p id="geraet-hilfe">Zum Beispiel: Tischlampe mit defektem Schalter.</p>Im Beispiel stimmt der Wert von for genau mit der Feld-ID überein. Der zusätzliche Hilfetext wird über aria-describedby zugeordnet. Nach der W3C-Anleitung zur Feldbeschriftung ist eine solche explizite Zuordnung ein geeigneter Standardweg.
Eine produktive Anmeldung benötigt darüber hinaus Eingabeprüfung, Verarbeitung und zutreffende Rückmeldungen. Die HTML-Zuordnung löst nur einen Teil der Aufgabe. Pflichtfelder müssen nachvollziehbar gekennzeichnet sein. Fehlermeldungen sollten erklären, was korrigiert werden muss und mit dem betroffenen Feld verbunden bleiben.
Vermeiden Sie vorschnelle Umbenennungen über ARIA. Wenn der sichtbare Text „Gegenstand“ lautet, der zugängliche Name aber „Produktbezeichnung Ihrer Supportanfrage“ ist, entstehen unnötige Unterschiede zwischen Bedienweisen. Zusätzliche Attribute sollen fehlende Beziehungen erklären und die vorhandene native Bedeutung nicht wahllos überschreiben.
7. Daten und Bilder in ihrem Zusammenhang erklären
Eine Liste mit aufeinanderfolgenden Schritten wird als geordnete Liste verständlich. Eine Sammlung unabhängiger Voraussetzungen passt häufig in eine ungeordnete Liste. Der Unterschied ist inhaltlich: Muss die Reihenfolge erhalten bleiben oder dient sie nur der Darstellung? Eine dekorative Nummer allein beantwortet diese Frage nicht.
Tabellen sind für Beziehungen zwischen Zeilen und Spalten gedacht. Ein Terminplan mit Datum, Uhrzeit und Ort kann eine Tabelle rechtfertigen. Die gesamte Seitenanordnung sollte dagegen nicht als Tabelle aufgebaut werden. In unserem Lernbeispiel ist ein einzelner Termin als Absatz einfacher lesbar.
| Inhalt | Geeigneter Ausgangspunkt | Zu prüfende Beziehung |
|---|---|---|
| Reparaturablauf | ol mit li | Die Reihenfolge ist relevant |
| Mitbringliste | ul mit li | Die Punkte gehören zusammen |
| Mehrere Termine | Tabelle mit Kopfzellen | Spalten und Zeilen bleiben zuordenbar |
| Erklärendes Foto | Bild mit passendem Alternativtext | Die inhaltliche Aussage bleibt verfügbar |
Ein Bild kann in eine figure mit Bildunterschrift eingebettet werden, wenn es eine eigenständige Abbildung im Textzusammenhang ist. Die Bildunterschrift ersetzt den Alternativtext nicht automatisch. Beschreibt sie beispielsweise nur die Quelle, fehlt die Aussage des Bildes weiterhin.
8. Semantik und Gestaltung getrennt prüfen
Entfernen Sie für einen Prüfdurchgang die gestalterischen Regeln. Der Inhalt muss dabei nicht schön aussehen. Entscheidend ist, ob seine Reihenfolge und Bedeutung nachvollziehbar bleiben. Springt eine wichtige Voraussetzung hinter einen unpassenden Bereich, kann die visuelle Reihenfolge zuvor ein strukturelles Problem verdeckt haben.
Eine zweite Prüfung betrachtet ausschließlich die Bedienung. Gehen Sie mit Tab durch die Seite, aktivieren Sie Links und öffnen Sie den Hinweis. Kehren Sie anschließend zurück. Native Elemente bieten eine Ausgangsbasis, aber individuelle CSS-Regeln oder zusätzliche Skripte können ihr Verhalten trotzdem beeinträchtigen.
Eine dritte Prüfung erfolgt in der Zugänglichkeitsansicht der Browserwerkzeuge. Dort lässt sich untersuchen, welche Rolle und welcher Name für ein Element berechnet werden. Das ersetzt keinen Screenreader-Test, macht aber manche Fehlzuordnung unmittelbar sichtbar. Prüfen Sie jeweils das konkrete Element statt aus dem gewählten Tag pauschal auf den Erfolg zu schließen.
Das Lernbeispiel ist absichtlich klein. Bei einer größeren Anwendung müssen dieselben Fragen auch in Dialogen, dynamischen Ergebnissen und Fehlerzuständen beantwortet werden. Eine korrekte Grundseite garantiert nicht, dass eine nachträglich eingefügte Komponente ebenso verständlich ist.
Eine semantische Änderung anhand einer Besucheraufgabe prüfen
Für eine praktische Gegenprobe können Sie eine konkrete Frage an die Beispielseite stellen: Welche Leistung wird angeboten und wie lässt sich dazu eine Anfrage beginnen? Lesen Sie zunächst nur die Überschriften. Danach betrachten Sie die zusammengehörigen Absätze und schließlich den vorgesehenen Kontaktweg. Diese Reihenfolge macht sichtbar, ob die Gliederung den Inhalt trägt oder lediglich Namen für gestalterische Flächen liefert. Eine Überschrift sollte den nachfolgenden Abschnitt beschreiben, sodass ein Leser seine Entscheidung über das Weiterlesen darauf stützen kann.
Vergleichen Sie anschließend die sichtbare Gliederung mit dem tatsächlichen HTML. Eine rot hinterlegte Fläche ist nicht allein wegen ihrer Farbe ein eigener thematischer Abschnitt. Umgekehrt kann ein sachlich eigenständiger Abschnitt dieselbe Hintergrundfarbe wie seine Umgebung besitzen. Entscheidend ist die Beziehung zwischen den Inhalten. Begründen Sie deshalb bei einem neuen Abschnitt kurz, welche zusammengehörige Aussage dort beginnt und woran ihr Ende erkennbar ist. Wenn sich diese Frage nicht beantworten lässt, ist eine zusätzliche strukturelle Unterteilung möglicherweise unnötig.
Bei einem Kontaktbaustein hilft eine zweite Frage: Welche Bedienung wird hier tatsächlich angeboten? Ein Verweis auf eine eigene Kontaktseite hat eine andere Aufgabe als eine Schaltfläche, die eine vorhandene Auswahl absendet. Die Bezeichnung und das gewählte Element müssen zu dieser Aufgabe passen. Prüfen Sie außerdem, ob die sichtbare Beschriftung auch ohne den umgebenden Absatz verständlich genug bleibt. Ein knappes Wort wie Weiter kann in einem bekannten Formularablauf genügen, auf mehreren voneinander unabhängigen Karten aber zusätzliche Unklarheit schaffen.
Dokumentieren Sie bei einer Überarbeitung, welche Inhalte gleich bleiben und welche Beziehungen sich ändern. Die Beispielseite kann etwa weiterhin dieselben Leistungen enthalten, während deren Gruppierung klarer wird. Das ist eine andere Änderung als das Hinzufügen einer neuen Leistung. Für die Kontrolle sollten deshalb nicht nur Screenshots verglichen werden. Lesen Sie den Inhaltsplan erneut und gehen Sie den tatsächlichen Bedienweg durch. Eine unveränderte Optik belegt noch keine unveränderte Struktur, ebenso wenig beweist eine neue Optik eine bessere semantische Grundlage.
Diese Gegenproben sind redaktionelle Prüfschritte und keine Behauptung eines durchgeführten Nutzertests. Sie ergänzen die Prüfung des Markups um eine nachvollziehbare Aufgabe. Werden später echte Nutzungsschwierigkeiten beobachtet, können Sie die betreffende Stelle damit genauer beschreiben: fehlende Orientierung im Inhaltsplan, unklarer Zusammenhang oder eine unpassende Bedienhandlung.
9. Checkliste für ein Code-Review
- Das Hauptthema ist über eine verständliche Hauptüberschrift erkennbar.
- Überschriften bilden die tatsächliche Untergliederung ab.
- Seitenregionen entsprechen ihrer inhaltlichen Funktion.
- Article und section werden nach Zusammenhang statt Hintergrundfarbe gewählt.
- Links führen zu Zielen und Schaltflächen lösen passende Aktionen aus.
- Formularfelder besitzen eindeutige Beschriftungen und erforderliche Hinweise.
- IDs sind eindeutig und alle internen Verweise finden ihr Ziel.
- Listen und Tabellen bilden die gemeinten Beziehungen ab.
- Die Lesereihenfolge bleibt ohne CSS sinnvoll.
- Tastatur und unterstützende Technologien wurden im tatsächlichen Ablauf geprüft.
Dokumentieren Sie gefundene Probleme mit einem konkreten Auslöser. „Semantik verbessern“ ist zu unbestimmt. „Die Anmeldung verwendet einen Link ohne Ziel als Absenden-Steuerelement“ benennt dagegen die betroffene Funktion und erlaubt eine gezielte Korrektur.
10. Einen bestehenden Baustein schrittweise verbessern
Bei vorhandenen Projekten ist eine vollständige Neufassung nicht immer nötig. Beginnen Sie mit einem klar begrenzten Baustein. Ein typisches Beispiel ist eine Leistungskarte, deren gesamte Fläche einen Klick auslöst. Zuerst wird untersucht, ob sie tatsächlich zu einer anderen Seite führt oder innerhalb der aktuellen Ansicht eine Aktion startet. Erst danach steht fest, ob ein Link oder eine Schaltfläche gebraucht wird.
Dokumentieren Sie vor der Änderung die vorhandenen Zustände. Dazu gehören die normale Ansicht, Tastaturfokus und gegebenenfalls ein aufgeklapptes Detail. Wenn der Baustein in einer Liste verwendet wird, müssen auch mehrere Instanzen geprüft werden. Doppelte IDs oder unpassende Überschriftenebenen fallen oft erst in dieser wiederholten Verwendung auf.
Ändern Sie anschließend das Element und passen Sie die Gestaltung gezielt an. Ein nativer Button besitzt beispielsweise Browserstandardwerte, die sich von denen eines Containers unterscheiden. Diese Werte dürfen bewusst gestaltet werden. Das Entfernen eines sichtbaren Fokus ohne Ersatz würde aber aus einer semantischen Verbesserung ein neues Bedienproblem machen.
Danach wird die Funktion erneut geprüft. Bei einem Link umfasst das auch das tatsächliche Ziel und die Bedienung über das Kontextmenü. Bei einer Schaltfläche gehören die auslösende Aktion und mögliche Fehlerzustände dazu. Prüfen Sie außerdem, ob vorhandene Ereignisbehandlung jetzt doppelt ausgeführt wird oder ob alte Tastaturhilfen für den früheren Container entfernt werden müssen.
Ein gutes Review beschreibt schließlich den beobachtbaren Unterschied: Das Bedienelement ist jetzt mit seiner tatsächlichen Aufgabe benannt und über die erwartete Bedienweise nutzbar. Die Aussage „Wir haben semantische Tags eingebaut“ wäre weniger hilfreich, weil sie nur eine Umsetzungstechnik benennt. Der Nutzen entsteht durch den funktionierenden Zusammenhang.
Für die weitere Pflege sollte die korrigierte Variante als gemeinsamer Baustein dokumentiert werden. So wird das Problem bei der nächsten Seite nicht erneut eingebaut. Ein Beispiel mit zulässiger Überschriftenebene, verständlichem Namen und geprüftem Tastaturverhalten ist dafür meist hilfreicher als eine lange Liste abstrakter Verbote.
Häufige Fragen zu semantischem HTML
Ist div grundsätzlich schlecht?
Nein. Ein neutraler Container ist passend, wenn lediglich eine gestalterische oder technische Gruppierung benötigt wird. Problematisch wird es, wenn damit eine bereits vorhandene Bedeutung wie Schaltfläche oder Überschrift nachgebaut wird.
Macht semantisches HTML eine Seite automatisch barrierefrei?
Nein. Es ist eine wichtige Grundlage. Kontraste, Fokusführung, verständliche Texte und die tatsächliche Bedienung müssen zusätzlich stimmen.
Ist jeder Abschnitt eine zusätzliche Seitenregion?
Die ausgegebene Bedeutung hängt auch von Kontext und Benennung ab. Deshalb sollten sichtbare Überschriften und Beziehungen sinnvoll gewählt und anschließend geprüft werden. Zusätzliche Regionen sind kein Selbstzweck.
Verbessern mehr semantische Elemente automatisch das Ranking?
Ein solcher Automatismus ist nicht belegt. Eine verständliche Struktur unterstützt die Verarbeitung und Nutzung des Inhalts. Sie ersetzt weder hilfreiche Inhalte noch technische und redaktionelle Qualität.
Quellen und nächste Schritte
Grundlagen: HTML Living Standard von WHATWG sowie die verlinkten Dokumentationen von W3C WAI und MDN. Geprüft am 9. November 2026. Der Reparaturtreff ist ein eigens entwickeltes fiktives Lernbeispiel. Prüfen Sie zunächst die Überschriften und Bedienelemente einer eigenen Seite und führen Sie danach einen vollständigen Tastaturdurchgang aus.
Den übergeordneten Planungsrahmen erläutert unser Leitfaden Was eine professionelle Unternehmenswebseite leisten muss. Die rechtliche Einordnung ergänzt der Beitrag Barrierefreie Webseite und BFSG.
