Barrierefreie Webseiten erstellen

Eine barrierefreie Seite ermöglicht es Menschen, mit ihren eigenen Werkzeugen Informationen aufzunehmen und Aufgaben zu erledigen. Dazu können eine Tastatur, ein Screenreader, eine Bildschirmlupe oder Sprachsteuerung gehören. Eine Seite kann fertig aussehen, während ihr Code diese Nutzer noch behindert.

Was assistive Technologien erhalten

Der Browser liest HTML in das DOM, sein Modell des Dokuments, ein. Er leitet daraus einen Barrierefreiheitsbaum ab, der assistiven Technologien bedeutungstragende Objekte beschreibt. Ein Steuerelement braucht eine Rolle, einen Namen und alle relevanten Zustände oder Eigenschaften. Ein Kontrollkästchen kann zum Beispiel die Rolle „Kontrollkästchen“, den Namen „E-Mail-Angebote“ und den Zustand „ausgewählt“ haben.

Ein Screenreader liest Inhalte vor oder gibt sie an eine Braillezeile aus. NVDA und JAWS laufen unter Windows; Narrator ist in Windows, VoiceOver in macOS und iOS und TalkBack in Android integriert. Screenreader können Überschriften, Links und Steuerelemente ansteuern, ohne jede Zeile vorzulesen. Manche können auch Schrift- oder Farbeinstellungen ausgeben. Bildschirmlupen zeigen die vergrößerte sichtbare Seite, daher ist auch eine klare Darstellung wichtig.

Mit Sprachsteuerung kann man den Namen eines Steuerelements sagen, etwa „Klicke auf Suchen“. Schalter können tastaturähnliche Befehle senden. Tastaturunterstützung und genaue Namen helfen daher mehreren Nutzergruppen, nicht nur Menschen, die Sprachausgaben hören.

Beginne mit dem richtigen Element

Vergleiche diese zwei Möglichkeiten, ein Steuerelement zum Speichern zu erstellen:

<button type="button">Save</button>
<div class="btn" onclick="save()">Save</div>

Die Schaltfläche stellt ihre Rolle und ihren Namen bereits bereit. Sie erhält den Fokus mit Tab und reagiert auf Enter und Leertaste. CSS kann die zweite Zeile genauso aussehen lassen, aber ein div hat keines dieser Schaltflächenverhalten. Ein Screenreader kann im Lesemodus möglicherweise den Klick-Handler auslösen, sagt das Element aber nicht als Schaltfläche an. Wer mit Tab navigiert, kann es nicht erreichen.

Semantisches HTML bedeutet, ein Element nach der Bedeutung des Inhalts oder Steuerelements auszuwählen. Steuere seine Darstellung mit CSS. Das gibt dem Browser eine solide Grundlage und erspart es, natives Verhalten mit einem Skript nachzubauen.

Kenne das Ziel

Das W3C veröffentlicht die Richtlinien für barrierefreie Webinhalte, kurz WCAG. Ihre Erfolgskriterien sind überprüfbare Anforderungen, jeweils mit einer Nummer, einem Namen und einer Stufe. Zum Beispiel liegt 1.4.3 Kontrast (Minimum) auf Stufe AA. WCAG 2.2 wurde im Oktober 2023 zu einer Empfehlung und im Dezember 2024 aktualisiert.

Die Konformität auf Stufe AA verlangt jedes Kriterium der Stufen A und AA. Einige bestandene AA-Prüfungen genügen nicht. Stufe AAA ergänzt weitere Anforderungen. WCAG 2.2 ergänzt neun Kriterien gegenüber 2.1, sechs davon auf A oder AA, und entfernt das veraltete Kriterium 4.1.1 Syntaxanalyse.

Barrierefreiheit umfasst auch lesbaren vergrößerten Text, Untertitel für gehörlose und schwerhörige Menschen, klare Anweisungen und hilfreiche Fehlermeldungen. Wenn du diese Funktionen von Anfang an einbaust, musst du ungeeignetes HTML nicht erst nach Fertigstellung des Layouts ersetzen.

Eine hilfreiche Seitenstruktur bietet Menschen mehrere Möglichkeiten, sich zu orientieren. Ein aussagekräftiger Titel bezeichnet die Seite, Orientierungspunkte kennzeichnen ihre Bereiche und Überschriften zeigen die Gliederung. Diese Merkmale brauchen eine echte Bedeutung im HTML, auch wenn das visuelle Design bereits klar aussieht.

Kennzeichne die Seite und ihre Sprache

Lege die Hauptsprache am Wurzelelement fest, zum Beispiel <html lang="en-US">. Screenreader wählen damit die Ausspracheregeln. Kennzeichne einen Sprachwechsel innerhalb der Seite am betreffenden Element: <span lang="fr">bon appétit</span>. Das unterstützt 3.1.1 Sprache der Seite (A) und 3.1.2 Sprache von Teilen (AA).

Gib jeder Seite einen eindeutigen, aussagekräftigen <title>. „Eine Geburtstagstorte bestellen – Green Leaf Bakery“ ist in Tabs, Lesezeichen und Screenreader-Ansagen hilfreicher als „Green Leaf Bakery – Seite 4“. Setze das spezifische Thema an den Anfang, damit Nutzer ähnliche Tabs schnell unterscheiden können.

Teile die Seite in Bereiche

Verwende <main> für den Hauptinhalt, <nav> für die Navigation und <aside> für ergänzenden Inhalt. Ein <header> auf Seitenebene stellt den Orientierungspunkt banner bereit und ein <footer> auf Seitenebene die Inhaltsinformationen. Header- und Footer-Elemente innerhalb von strukturierenden Bereichen werden nicht zu diesen Orientierungspunkten auf Seitenebene.

Verwende ein sichtbares <main>. Gibt es zwei Navigationsbereiche, unterscheide sie durch Namen wie <nav aria-label="Main"> und <nav aria-label="Breadcrumb">. Die Rolle sagt bereits „Navigation“, daher kann die Beschriftung kurz bleiben. Ein <section> oder <form> wird nur mit einem zugänglichen Namen zum Orientierungspunkt.

Erstelle eine Gliederung, bevor du Schriftgrößen wählst

Für die Bestellseite der Bäckerei könnte eine klare Gliederung so aussehen:

<h1>Order a birthday cake</h1>
<h2>Choose a size</h2>
<h2>Choose a flavor</h2>
<h3>Chocolate</h3>
<h3>Lemon</h3>
<h2>Pickup or delivery</h2>

Verwende ein h1 für das Hauptthema, h2 für Hauptabschnitte und h3 für deren Teile. Vermeide es, beim Abstieg Ebenen zu überspringen. Wähle Überschriftenebenen nach der Struktur; passe ihre Größe mit CSS an. Ein fett gesetzter Absatz erscheint nicht in der Überschriftenliste des Screenreaders. Umgekehrt erzeugt eine gewöhnliche Einleitung in einem h2 einen Abschnitt, den der Inhalt nicht hat.

Erhalte Gruppierung und Lesereihenfolge

Verwende <ul> für ungeordnete Einträge, <ol> für geordnete Schritte und <dl> für Begriff-Beschreibung-Paare. Screenreader können die Größe einer Liste ansagen und Nutzern so helfen einzuschätzen, wie viel folgt. Navigationslinks können in einem ul innerhalb von nav stehen. In Safari kann das Entfernen der Aufzählungszeichen mit list-style: none Listenansagen in VoiceOver unterdrücken; role="list" an dieser Liste stellt sie wieder her.

Schreibe das HTML in einer sinnvollen Lesereihenfolge. Flex-order, umgekehrte Flex-Richtung, Grid-Platzierung und absolute Positionierung ändern die sichtbare Darstellung, ohne die DOM-Reihenfolge zu ändern. Eine Zeile, die sichtbar mit „Anmelden“ beginnt, es aber mit Tab zuletzt erreicht, ist schwerer nachzuvollziehen. Korrigiere die Quelltextreihenfolge, bevor du das Layout gestaltest.

Gehe ein Seitengrundgerüst durch

Eine Bäckerei-Website hat ein Hauptmenü und eine zweite Gruppe von Brotkrumenlinks. Gib den Bereichen unterschiedliche Namen und halte beide Linkgruppen verfügbar:

<nav aria-label="Main">
  <ul><li><a href="/bread">Bread</a></li></ul>
</nav>
<nav aria-label="Breadcrumb">
  <ol><li><a href="/">Home</a></li></ol>
</nav>
<main>
  <h1>Order a loaf</h1>
  <h2>Choose your bread</h2>
</main>

Untersuche die Liste der Orientierungspunkte: Main und Breadcrumb kennzeichnen unterschiedliche Navigationszwecke, gefolgt vom Hauptinhalt. Untersuche dann die Überschriftenliste: Sie sollte das Seitenthema und seinen ersten Abschnitt zeigen. Beide Listen bieten unterschiedliche Wege durch dasselbe Dokument; keine hängt von den Farben des Menüs oder der Schriftgröße der Überschrift ab.

Das Element eines Steuerelements sagt Nutzern, was sie erwarten können. Ein Link verspricht ein Ziel, eine Schaltfläche eine Aktion. Native Steuerelemente und Tabellenelemente stellen außerdem Beziehungen bereit, die sich aus gestalteten generischen Boxen nur schwer nachbilden ließen.

Wähle zwischen Navigation und Aktion

Ein a-Element ohne href ist kein normaler, mit der Tastatur fokussierbarer Link. Ein a-Element mit href="#" und einem Klick-Handler zum Öffnen eines Menüs kündigt Navigation an, obwohl es eine Aktion ausführt. Verwende für dieses Menü eine Schaltfläche. Gib Schaltflächen innerhalb eines Formulars, die es nicht absenden sollen, type="button"; sonst können sie das Formular standardmäßig absenden.

Mache Ziele deutlich

Ein Screenreader kann die Links der Seite in einer Liste sammeln. Wiederholte „Weiterlesen“-Links sind darin schwer zu unterscheiden. „Mehr über Sauerteigkurse“ benennt das Ziel direkt. WCAG 2.4.4 Linkzweck (im Kontext) (A) erlaubt, dass der nahe Kontext einen Link erklärt, doch aussagekräftiger Linktext funktioniert auch, wenn er für sich allein gehört wird.

Informiere Nutzer im Linktext über einen Download oder neuen Tab: „Preisliste (PDF, 2 MB)“ oder „Buchungsformular (öffnet sich in einem neuen Tab)“. Ein neuer Tab ändert die Funktionsweise der Zurück-Schaltfläche. Verwende nach Möglichkeit eine Beschreibung statt einer langen rohen URL.

Jeder Link und jede Schaltfläche braucht einen zugänglichen Namen. Ein Warenkorblink, der nur ein Bild enthält, braucht Text, der sein Ziel angibt; ein Bild ohne Alternative kann dazu führen, dass der Link keinen Namen hat oder durch einen Dateinamen bezeichnet wird. Die Benennung ist ebenso notwendig wie die Wahl der richtigen Rolle.

Behalte eingebautes Verhalten

Verwende native Kontrollkästchen, Optionsfelder und select-Steuerelemente. Sie bringen Tastaturbedienung und angesagte Zustände mit. Ein einfacher Aufklappbereich lässt sich allein mit HTML erstellen:

<details>
  <summary>Delivery options</summary>
  <p>We deliver within 10 km.</p>
</details>

Das summary-Element erhält den Tastaturfokus, und der Aufklappbereich stellt seinen geöffneten oder geschlossenen Zustand bereit. Bei einer selbst erstellten Zeile mit Dreieckssymbol müssten diese Funktionen gesondert umgesetzt werden.

Verbinde Tabellendaten mit ihren Kopfzellen

Verwende Tabellen für Daten mit Beziehungen zwischen Zeilen und Spalten. Eine Tabellenbeschriftung benennt den Datensatz; th kennzeichnet Kopfzellen; scope teilt dem Browser mit, welche Zellen eine Kopfzelle beschreibt.

<table>
  <caption>Shop opening hours</caption>
  <tr><th scope="col">Day</th><th scope="col">Opens</th></tr>
  <tr><th scope="row">Saturday</th><td>08:00</td></tr>
</table>

Wer zur Zeitzelle wechselt, kann den zugehörigen Tag und die Spaltenüberschrift hören. Ein CSS-Raster aus div-Elementen verliert diese eingebauten Beziehungen. Verwende für das Seitenlayout Flexbox oder Grid; eine Layouttabelle kann eine irreführende Tabellennavigation erzeugen, wo keine tatsächliche Datenbeziehung besteht.

Alternativtext vermittelt die hilfreichen Informationen oder die Funktion eines Bildes an jemanden, der es nicht sehen kann. Entscheide, was das Bild auf dieser konkreten Seite beiträgt, bevor du sein Aussehen beschreibst. Dasselbe Foto kann in unterschiedlichen Kontexten unterschiedlichen Text benötigen.

Wähle nach dem Zweck

Bei einem informativen Produktfoto beschreibt alt="Round sourdough loaf with a dark, cracked crust", was Käufer wissen müssen. Auf einer Seite über Backfehler könnte stattdessen eine verbrannte Kruste wichtig sein. Stell dir vor, du liest die Seite am Telefon vor: Nimm die Informationen auf, die dem Zuhörer sonst fehlen würden.

Für ein rein dekoratives Bild verwende alt="". Eine leere Alternative teilt Screenreadern mit, dass sie das Bild überspringen sollen. Das Attribut wegzulassen ist etwas anderes: Ein Screenreader könnte einen Dateinamen wie „IMG Unterstrich 4032 Punkt jpg“ ansagen. Ein rein dekorativer Hintergrund kann auch in CSS stehen.

Benenne eine Funktion, keine Form

Ist ein Bild der einzige Inhalt eines Links oder einer Schaltfläche, liefert seine Alternative den Namen des Steuerelements. Ein Link zur Startseite kann so aussehen:

<a href="/">
  <img src="logo.svg" alt="Green Leaf Bakery home">
</a>

Verwende für eine Suchschaltfläche „Suchen“, nicht „Lupe“. Nutzer müssen wissen, was beim Betätigen des Steuerelements geschieht. Enthält ein Produktlink bereits die sichtbaren Worte „Roggenbrot“, kann ein Foto im selben Link alt="" verwenden, damit der Linkname nicht wiederholt wird.

Behandle Text und komplexe Grafiken

Eine Schriftgrafik braucht dieselben Worte in ihrer Alternative. Ein Verkaufsbanner mit „Sommerschlussverkauf: 20 % Rabatt auf alle Brote“ braucht diese Worte, nicht „Verkaufsbanner“. Bevorzuge nach Möglichkeit echten HTML-Text, der mit CSS gestaltet wird. Er lässt sich vergrößern, übersetzen und umbrechen; WCAG 1.4.5 Schriftgrafiken (AA) verlangt echten Text, wenn die Technik ihn erlaubt, mit Ausnahmen wie Logos.

Ein Diagramm, Schaubild oder eine Karte enthält oft zu viele Informationen für eine kurze Alternative. Gib eine knappe Bezeichnung und ergänze eine ausführlichere Beschreibung in der Nähe. Zum Beispiel bezeichnet alt="Bar chart of monthly website visitors, January to June" die Grafik. Text in der Nähe kann erklären, dass die Besucherzahl von 1.200 auf 3.000 gestiegen ist, während eine Datentabelle bei Bedarf die einzelnen Werte liefert. Ein <figure> mit <figcaption> kann die Grafik und ihre Erklärung gruppieren.

Überarbeite auf hilfreiche Details

Halte gewöhnlichen Alternativtext auf eine knappe Wortgruppe oder einen Satz begrenzt. Screenreader erkennen ein Bild bereits als solches, daher liefert ein Beginn mit „Bild von“ meist keinen hilfreichen Inhalt. Entferne wiederholte Formulierungen direkt daneben und Suchbegriffe, die nicht zum Verständnis der Seite beitragen.

WCAG 1.1.1 Nicht-Text-Inhalt (A) verlangt einen gleichwertigen Zweck, keine Beschreibung jedes sichtbaren Details. Das title-Attribut ist kein zuverlässiger Ersatz: Es wird nicht einheitlich angesagt und ist bei Tastatur- und Touchbedienung nicht zuverlässig verfügbar. Setze die Alternative eines Bildes in alt und halte längere Erklärungen auf der Seite selbst.

Ein Symbol, ein Diagramm und ein Video brauchen unterschiedliche Arten von Alternativen. Bestimme zunächst die Information oder Aktion, die jedes davon beiträgt. Setze dann die gleichwertige Alternative dorthin, wo sowohl der Browser als auch die Person, die die Seite nutzt, sie finden kann.

Benenne das Steuerelement, zu dem das Symbol gehört

Sichtbarer Text neben einem Symbol ist meist am klarsten. Muss eine Schaltfläche nur ein Symbol enthalten, ergänze visuell ausgeblendeten Text oder eine Beschriftung an der Schaltfläche:

<button type="button" aria-label="Close">✕</button>

Steht ein Symbol neben sichtbarem Schaltflächentext, blende das dekorative Symbol mit aria-hidden="true" aus. Blende nicht die ganze Schaltfläche aus. Ein einfaches span oder div hat eine generische Rolle, deren Benennung verboten ist; aria-label dort anzubringen ist keine zuverlässige Methode, ein Symbol zu benennen.

Visuell ausgeblendeter Text bleibt für Screenreader verfügbar. Eine wiederverwendbare CSS-Klasse kann absolute Positionierung, 1 px Breite und Höhe, ausgeblendeten Überlauf, clip-path: inset(50%) und white-space: nowrap verwenden. Anders als display: none oder visibility: hidden hält sie den Text im Barrierefreiheitsbaum.

Verwende für ein bedeutungstragendes eingebettetes SVG role="img" und einen Namen, zum Beispiel aria-labelledby="rating-title" mit einem Verweis auf <title id="rating-title">Rated 4 out of 5 stars</title> innerhalb des SVG. Dekoratives SVG verwendet aria-hidden="true". Ein über img geladenes SVG erhält seine Alternative wie andere Bilder aus alt. Halte bedeutungstragende Warnungen im HTML; CSS-Hintergründe und generierte Inhalte sind unzuverlässige Orte für wesentliche Informationen.

Wähle die passende Medienalternative

Untertitel für gehörlose und schwerhörige Menschen geben Sprache, wichtige Geräusche und die Benennung der Sprechenden synchron zum Video wieder. Untertitel geben den Dialog für Menschen schriftlich wieder oder übersetzen ihn, wenn diese hören können, aber Hilfe beim Sprachverständnis brauchen. Ein Transkript ist eine separate schriftliche Darstellung; es folgt nicht dem Wiedergabezeitpunkt.

<video controls src="bread.mp4">
  <track kind="captions" src="bread-en.vtt"
         srclang="en" label="English">
</video>

Die WebVTT-Datei enthält zeitlich festgelegte Cues wie 00:00:01.000 --> 00:00:04.000, gefolgt vom Untertiteltext. Prüfe automatische Untertitel vor der Veröffentlichung auf Namen, Fachwörter und Zeichensetzung.

Zeigt eine Vorführung eine Ofeneinstellung, ohne sie zu erwähnen, vermitteln Untertitel der Sprache diese Information nicht. Eine Audiodeskription beschreibt wichtige visuelle Informationen in Sprechpausen oder in einer entsprechend beschriebenen Fassung. Eine vollständige Textalternative einschließlich der visuellen Inhalte ist auf Stufe A eine Möglichkeit; aufgezeichnetes Video braucht nach 1.2.5 auf Stufe AA eine Audiodeskription.

Halte die Wiedergabe bedienbar

Verwende native controls für Audio und Video und gib eingebetteten Frames einen aussagekräftigen title, etwa „Karte unseres Ladenstandorts“. Vermeide automatisch startenden Ton. Ton, der automatisch startet und länger als 3 Sekunden dauert, benötigt eine Pause-, Stopp- oder Lautstärkeregelung unabhängig von der Systemlautstärke.

Verbinde den ausgeblendeten Namen und den zeitgesteuerten Text

Halte bei einer kompakten Löschschaltfläche ihre Worte im Dokument:

<button type="button">
  <img src="trash.svg" alt="">
  <span class="visually-hidden">Delete item</span>
</button>

Das Bild wird übersprungen, weil der Text die Aktion bereits angibt. Wende die Klasse zum Ausblenden an, ohne den Text aus dem Barrierefreiheitsbaum zu entfernen:

.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  overflow: hidden;
  clip-path: inset(50%);
  white-space: nowrap;
}

Eine Untertiteldatei verbindet dagegen Worte mit dem Wiedergabezeitpunkt. Ein kleines WebVTT-Beispiel:

WEBVTT

00:00:01.000 --> 00:00:03.000
[Mixer whirring]

00:00:03.000 --> 00:00:06.000
Today we bake rye bread.

Der erste Cue vermittelt ein relevantes Geräusch ohne Dialog. Der zweite gibt Sprache während seines eigenen Zeitintervalls wieder. Sieh dir das Video mit aktivierter Textspur an und prüfe, ob jeder Cue erscheint, wenn sein Ton zu hören ist.

Tastaturnutzer brauchen einen Weg durch die gesamte Aufgabe: ein Steuerelement erreichen, erkennen und bedienen und danach weitergehen. Standard-HTML-Steuerelemente unterstützen diesen Weg bereits. Probleme entstehen oft, wenn Gestaltung oder selbst erstellte Steuerelemente das Verhalten des Browsers beeinträchtigen.

Verwende die erwarteten Tasten

Tab führt durch die interaktiven Elemente vorwärts, Umschalt+Tab rückwärts. Enter folgt Links und aktiviert Schaltflächen. Die Leertaste aktiviert Schaltflächen und schaltet Kontrollkästchen um. In einer Optionsfeldgruppe führt Tab in die Gruppe hinein oder aus ihr heraus, und die Pfeiltasten wechseln zwischen Optionen. Pfeiltasten funktionieren auch in nativen Auswahllisten. Escape schließt Dialoge und viele Menüs.

Links mit href, Schaltflächen, Eingabefelder, Auswahllisten, mehrzeilige Textfelder, summary-Elemente und Medien mit Steuerelementen sind standardmäßig fokussierbar. Absätze, Überschriften, Bilder, generische Container und a-Elemente ohne href sind keine gewöhnlichen Tabulatorstopps. Ein Screenreader hat eigene Lesebefehle für Text, daher verlangsamt es die Tastaturnavigation, jede Überschrift in die Tabulatorreihenfolge aufzunehmen.

Aktiviere unter macOS beim Testen die Tastaturnavigation. Safaris Einstellung „Durch Drücken der Tabulatortaste werden alle Objekte auf einer Webseite hervorgehoben“ steuert, ob gewöhnliche Tab-Navigation Links erreicht; Option+Tab kann sie erreichen, wenn die Einstellung ausgeschaltet ist.

Halte tabindex-Werte einfach

Positive Werte sind schwer zu pflegen, weil sie ein zweites Ordnungssystem schaffen. Schreibe das HTML in einer logischen Reihenfolge und vermeide sie. Eine Überschrift, die nach einer Aktualisierung den Fokus erhalten muss, kann -1 verwenden, ohne bei jedem Durchlauf durch die Seite ein Stopp zu werden.

Prüfe Bedeutung und Verhalten gemeinsam

<div role="button" tabindex="0">Save</div>

Dies stellt eine Schaltflächenrolle bereit und erhält den Fokus, braucht aber weiterhin ein Skript für Enter und Leertaste, eine Aktion und eine sichtbare Fokusgestaltung. Der Ersatz durch <button type="button">Save</button> liefert native Tastaturaktivierung, ohne sie nachzubauen. ARIA allein kann die Interaktion nicht erzeugen.

CSS kann auch die Navigation stören. Ist die Quelltextreihenfolge Logo, Menü, Suche, Anmeldelink, kann CSS mit order: -1 die Anmeldung zuerst anzeigen, während Tab sie weiterhin zuletzt erreicht. Verschiebe Inhalte im HTML, wenn sich die Lesereihenfolge ändern muss. WCAG 2.4.3 Fokusreihenfolge (A) verlangt eine Reihenfolge, die Bedeutung und Bedienbarkeit erhält.

Beseitige Fallen und verborgene Stopps

Teste, ob der Fokus jede Komponente mit der Tastatur verlassen kann. Eine Karte oder ein Player, der den Fokus annimmt, aber keinen Ausweg per Tastatur bietet, erzeugt eine Tastaturfalle, die 2.1.2 Keine Tastaturfalle (A) verbietet.

Ein geschlossenes Menü, das aus dem Bildschirmbereich verschoben oder mit opacity: 0 versehen wurde, kann weiterhin fokussierbare Links enthalten. Verwende hidden, display: none oder inert für Inhalt, der im geschlossenen Zustand nicht verfügbar sein darf. Halte einen außerhalb des Bildschirmbereichs liegenden Sprunglink dagegen fokussierbar: Er hat eine gezielte Regel, die ihn bei Fokus sichtbar macht.

Der Fokus ist die aktuelle Position eines Tastaturnutzers. Ein sichtbarer Ring zeigt, welches Steuerelement mit Enter oder Leertaste bedient wird. Der Ring muss sich weiterhin sichtbar von der Seite abheben und das fokussierte Steuerelement im Blick bleiben.

Halte den Indikator deutlich sichtbar

Browser liefern eine standardmäßige Fokuskontur. Sie mit outline: none zu entfernen, beseitigt ein wesentliches Merkmal, sofern kein geeigneter Ersatz bereitgestellt wird. Verwende :focus-visible, um einen Ring zu zeigen, wenn der Browser ihn für sinnvoll hält, unter anderem bei Tastaturnavigation und in Textfeldern:

:focus-visible {
  outline: 3px solid #1A73E8;
  outline-offset: 2px;
}

Das Blau hat 4,51:1 Kontrast gegenüber Weiß. Prüfe die tatsächlich angrenzenden Farben im Design; ein Ring, der auf Weiß funktioniert, kann auf einer blauen Fläche verschwinden. WCAG 2.4.7 Fokus sichtbar (AA) verlangt sichtbaren Tastaturfokus, während 1.4.11 Nicht-Text-Kontrast (AA) für die visuellen Informationen gilt, die einen selbst gestalteten Zustand kennzeichnen, einschließlich eines selbst gestalteten Fokusindikators, mit 3:1.

Eine Kontur ist eine hilfreiche Wahl für Windows-Kontrastdesigns. Erzwungene Farben können Hintergründe ersetzen und Boxschatten entfernen, während Konturen erhalten bleiben. Ein Schatten allein kann daher in einem Modus verschwinden, auf den jemand angewiesen ist.

Halte das fokussierte Steuerelement sichtbar

Haftende Kopfbereiche, Banner und Chat-Steuerelemente können den Fokus verdecken. Nach 2.4.11 Fokus nicht verdeckt (Minimum) (AA) darf vom Autor erstellter Inhalt die fokussierte Komponente nicht vollständig verbergen. Die gesamte Komponente sichtbar zu halten ist leichter zu bedienen; die Anforderung, dass kein Teil verdeckt ist, gehört zu AAA.

Schaffe für einen 5rem hohen haftenden Kopfbereich Platz zum Scrollen:

html { scroll-padding-top: 5rem; }

Gehe dann mit Tab durch die tatsächliche Seite. Prüfe beide Richtungen und teste auch, wenn ein Cookie-Hinweis vorhanden ist. Die CSS-Regel ist ein Ausgangspunkt; sie muss mit dem tatsächlichen Kopfbereich und den Viewport-Größen der Seite funktionieren.

Gib auch Zeigernutzern Platz

Zielgröße (Minimum), 2.5.8 (AA), verlangt Zeigerziele von mindestens 24 mal 24 CSS-Pixeln, mit Ausnahmen. Ein kleineres Ziel kann bestehen, wenn ein Kreis mit 24 px Durchmesser um seinen Mittelpunkt weder ein anderes Ziel noch den Kreis eines anderen kleinen Ziels schneidet. Ausgenommen sind auch Links innerhalb eines Satzes, unveränderte Steuerelemente mit vom Browser festgelegter Größe und Ziele mit einem gleichwertigen, den Anforderungen entsprechenden Steuerelement auf der Seite. Auch eine wesentliche oder gesetzlich vorgeschriebene Darstellung kann ausgenommen sein.

Bei drei 16 mal 16 px großen Symbolschaltflächen mit 4 px Abstand würden sich die Kreise überlappen. Ergänzt du an allen Seiten 4 px Innenabstand, wird jedes Ziel 24 mal 24 px groß. Miss die anklickbare Fläche, nicht nur das darin gezeichnete Symbol.

Das Ziel von 44 mal 44 CSS-Pixeln in 2.5.5 und die Anforderung an die Fokusfläche in 2.4.13 gehören zu AAA. Sie sind hilfreiche Verbesserungen, aber halte ihre Stufe bei der Meldung eines Befunds vom AA-Minimum getrennt.

Wiederholte Menüs sollten Menschen nicht auf jeder Seite denselben Weg erneut durchlaufen lassen. Ein Sprunglink bietet einen kurzen Weg zum Hauptinhalt. Ändert eine Interaktion die Seite, hilft auch ein gezielter Umgang mit dem Fokus dabei, die eigene Position zu behalten.

Erstelle und teste einen Sprunglink

Setze den Sprunglink vor die wiederholten Steuerelemente des Kopfbereichs:

<a class="skip-link" href="#main">Skip to main content</a>
<main id="main" tabindex="-1">
  <h1>Order a birthday cake</h1>
</main>

Der Link verweist auf den Hauptbereich, und tabindex="-1" hilft diesem Bereich, den Fokus zu erhalten, ohne einen gewöhnlichen Tabulatorstopp hinzuzufügen. Die Orientierungspunktnavigation eines Screenreaders hilft dessen Nutzern; der Sprunglink hilft auch sehenden Tastaturnutzern, wiederholte Blöcke gemäß 2.4.1 Blöcke umgehen (A) zu überspringen.

Halte den Link für die Tastatur verfügbar, wenn er visuell verborgen ist:

.skip-link { position: absolute; left: -9999px; }
.skip-link:focus { left: 1rem; top: 1rem; }

Verwende weder display: none noch visibility: hidden, da sie den Fokus verhindern. Lade die Seite neu, drücke einmal Tab und prüfe, ob der Link erscheint. Drücke Enter und dann erneut Tab: Die Navigation sollte beim ersten Link oder Steuerelement des Hauptinhalts weitergehen, nicht beim Menü im Kopfbereich.

Gib nach einer Inhaltsänderung eine sinnvolle nächste Position

Verschwinden eine Warenkorbzeile und ihre fokussierte Entfernen-Schaltfläche zusammen, kann der Fokus an den Seitenanfang zurückfallen. Verschiebe ihn gezielt zur Entfernen-Schaltfläche des nächsten Eintrags oder zu einer Warenkorbüberschrift mit tabindex="-1". Wähle eine Stelle, an der sich die Aufgabe fortsetzen lässt. Nur zu einem Bereich zu scrollen stellt nicht sicher, dass der Tastaturfokus dorthin gewechselt ist.

Verwende einen nativen modalen Dialog

Ein mit showModal() geöffneter Dialog verschiebt den Fokus in sich hinein und macht den Rest der Seite inaktiv. Tab bleibt innerhalb des geöffneten Dialogs; Escape schließt ihn. Beim Schließen kehrt der Fokus normalerweise zum auslösenden Element zurück, sofern es noch existiert.

<button type="button"
  onclick="document.getElementById('hours').showModal()">Opening hours</button>
<dialog id="hours" aria-labelledby="hours-title">
  <h2 id="hours-title">Opening hours</h2>
  <p>Tuesday to Saturday, 08:00–17:00.</p>
  <form method="dialog"><button>Close</button></form>
</dialog>

Das einzeilige Skript findet den Dialog anhand seiner ID und öffnet ihn modal. Das Dialogformular schließt ihn ohne weiteres Skript. Seine Überschrift liefert seinen Namen. Bei einer selbst gebauten Überlagerung müssen all diese Interaktionsregeln nachgebildet werden; den Hintergrund dunkel aussehen zu lassen hindert den Tastaturfokus nicht daran, ihn zu erreichen.

Warte auf eine bewusste Aktion

Der Erhalt des Fokus darf weder eine neue Seite öffnen noch anderweitig den Kontext ändern. Auch das Ändern einer Auswahl darf dies nicht unerwartet tun; Nutzer müssen im Voraus informiert werden, wenn dieses Verhalten auftritt. Eine „Los“-Schaltfläche nach einer Zielauswahl gibt Menschen Zeit, ihre Auswahl vor der Navigation zu prüfen und zu ändern. Dieses Verhalten unterstützt 3.2.1 Bei Fokus (A) und 3.2.2 Bei Eingabe (A).

Kontrast misst, wie deutlich sich Informationen im Vordergrund von ihrem Hintergrund abheben. Eine Farbe, die auf einem Bildschirm lesbar aussieht, kann für jemanden mit Sehbehinderung oder bei hellem Licht schwierig zu erkennen sein. Miss das Farbpaar, statt es nach Augenmaß zu beurteilen.

Wende das richtige Minimum an

Großer Text bedeutet mindestens 18 Punkt, entsprechend 24 CSS-Pixeln, oder mindestens 14 Punkt in Fettschrift, etwa 18,7 CSS-Pixel in Fettschrift. Eine 20 px große Überschrift in normaler Schriftstärke braucht weiterhin 4,5:1. Platzhalter-, Fußbereichs-, Hover- und Fokustext sind vom Textkontrast nicht ausgenommen. Für Logos, inaktive Steuerelemente und beiläufigen oder rein dekorativen Text gibt es Ausnahmen.

Verstehe das Verhältnis

Die relative Leuchtdichte drückt Helligkeit auf einer Skala von 0 für Schwarz bis 1 für Weiß aus. Mit der helleren Leuchtdichte als L1 und der dunkleren als L2 lautet das Verhältnis:

Die Extremwerte sind 1:1 für identische Farben und 21:1 für Schwarz gegenüber Weiß. Ein Kontrastprüfer berechnet die Leuchtdichte aus den Farbkanälen und vergleicht das Verhältnis mit dem relevanten Schwellenwert.

Für Grau #767676 hat jeder Kanal den Hexadezimalwert 76, also 118. Dividiere durch 255, um etwa 0,4627 zu erhalten. Da dieser Wert über 0,04045 liegt, rechne ihn in lineares Licht um:

Die drei Kanäle sind gleich, daher beträgt auch ihre gewichtete Leuchtdichte etwa 0,1812. Weiß hat die Leuchtdichte 1. Rundest du die Zwischenergebnisse nicht, erhältst du 4,54:1, was für normalen Text genügt. Verwende für tatsächliche Farbpaare einen Prüfer, damit gerundete Zwischenwerte ein knappes Ergebnis nicht beeinflussen.

Runde ein nicht bestandenes Ergebnis nie zum Bestehen auf

Grau #777777 auf Weiß ergibt 4,48:1. Die Anzeige mit einer Dezimalstelle als 4,5 lässt es nicht bestehen. Ebenso ergibt #949494 auf Weiß 3,03:1 und genügt für großen Text; #959595 ergibt 2,99:1 und genügt für großen Text nicht.

Weiß auf #0066CC ergibt 5,57:1. Auf Bernstein #FFC107 ergibt weißer Text nur 1,63:1, schwarzer dagegen 12,88:1. Ein heller Schaltflächenhintergrund verrät nicht, ob sein Text hell oder dunkel sein sollte.

Prüfe Abgrenzungen und jeden Hintergrund

Ein Eingaberahmen, der zum Erkennen des Feldes nötig ist, muss den Nicht-Text-Kontrast erfüllen. #CCCCCC gegenüber Weiß ergibt 1,61:1 und genügt nicht; #949494 ergibt 3,03:1 und genügt. Dieselbe 3:1-Regel gilt für bedeutungstragende Symbole, Diagrammlinien und selbst gestaltete Fokusindikatoren. Für inaktive und unveränderte Standardsteuerelemente des Browsers gibt es Ausnahmen.

Text über einem Foto oder Farbverlauf muss an der schwächsten Stelle seines Hintergrunds bestehen. Ergänze eine einfarbige oder ausreichend deckende Fläche oder verschiebe den Text. Prüfe die resultierenden Farben mit Entwicklerwerkzeugen oder einem Kontrastprüfer. WCAG 1.4.3 behandelt Text und 1.4.11 Nicht-Text-Informationen; die AAA-Schwellenwerte für Text sind höher, mit 7:1 für normalen und 4,5:1 für großen Text.

Prüfe die Teile einer Schaltfläche getrennt

Angenommen, eine Schaltfläche hat weißen Text in normaler Größe auf #0066CC, liegt auf einer weißen Seite und verwendet einen selbst gestalteten Fokusring in #CCCCCC. Prüfe jede Beziehung:

1. Die Beschriftung gegenüber der blauen Schaltfläche ergibt 5,57:1, über dem Textminimum von 4,5:1.
2. Die blaue Schaltfläche gegenüber der weißen Seite ergibt ebenfalls 5,57:1, sodass ihre Abgrenzung erkennbar ist.
3. Der hellgraue Fokusring gegenüber der weißen Seite ergibt nur 1,61:1. Dieser Zustandsindikator genügt nicht, obwohl die Beschriftung besteht.

Ersetze den Ring durch eine Farbe, die gegenüber ihrem angrenzenden Hintergrund 3:1 erreicht, und miss erneut. Eine Messung der Schaltflächenbeschriftung prüft nicht zugleich jede Abgrenzung oder jeden Interaktionszustand. Prüfe Text, Komponente und selbst gestalteten Zustand als getrennte Farbpaare.

Farbe kann Aufmerksamkeit erregen, darf aber nicht der einzige sichtbare Hinweis auf eine Bedeutung sein. Menschen können eine Farbsehschwäche haben, Graustufen oder Kontrasteinstellungen nutzen oder Inhalte über einen Screenreader ohne Farbangaben hören. Kombiniere Farbe mit Text, Formen, Mustern oder einem anderen deutlichen Merkmal.

Unterscheide zwei Prüfungen

Kontrast fragt, ob sich ein Vordergrund von seinem Hintergrund unterscheiden lässt. Benutzung von Farbe, WCAG 1.4.1 (A), fragt, ob die Information verständlich bleibt, ohne die Farbe zu erkennen. Eine dunkelrote Beschriftung auf Weiß kann den Kontrast erfüllen und dennoch nicht erklären, welches Feld einen Fehler hat.

Beginne mit der Botschaft. Steht auf der Seite „Wähle eine grüne Option“, gib jeder Option auch einen hilfreichen Namen. Bedeutet ein roter Punkt, dass ein Laden geschlossen ist, ergänze daneben „Jetzt geschlossen“. Der Text vermittelt den Zustand, während die Farbe hilft, ihn zu bemerken.

Halte Links erkennbar

Ein Link in einem Absatz lässt sich am einfachsten durch eine Unterstreichung kennzeichnen. Sie gibt auch dann einen Hinweis, wenn Link und umgebender Text in Graustufen gesehen werden.

Ein alleiniger Farbunterschied zum umgebenden Text braucht mindestens 3:1 Kontrast zwischen den beiden Textfarben und bei Hover und Fokus ein zusätzliches Merkmal wie eine Unterstreichung. Der Linktext muss auch den Textkontrast gegenüber seinem Hintergrund erfüllen. Dies sind getrennte Vergleiche; ein Blau, das gegenüber Weiß genügt, kann dem benachbarten dunklen Absatztext zu ähnlich sein.

Erkläre Fehler und Pflichtfelder

Zeige bei einem E-Mail-Fehler neben dem Feld „Fehler: Gib eine E-Mail-Adresse im Format name@example.com ein“. Eine rote Kontur kann als zusätzliches Merkmal bleiben. Der Text benennt das Problem und erklärt die Korrektur, während der Code ihn mit dem Feld verbindet.

Verwende für Pflichtfelder eine Beschriftung wie „E-Mail-Adresse (Pflichtfeld)“. Ein Sternchen funktioniert ebenfalls, wenn am Anfang des Formulars „* bedeutet Pflichtfeld“ erklärt wird. Ergänze das native required-Attribut, damit die Anforderung für assistive Technologie und die Validierung des Browsers verfügbar ist. Roter Beschriftungstext allein liefert weder eine ausreichende sichtbare Erklärung noch eine programmatisch erkennbare Anforderung.

Gib Grafiken eine zweite Art der Vermittlung

Ein Verkaufsdiagramm mit zwei Datenreihen braucht mehr als eine rote und eine grüne Linie. Direkte Beschriftungen, unterschiedliche Linienstile oder Muster lassen Menschen jede Reihe verfolgen, ohne ihren Farbton zu erkennen. Verwende diese Merkmale im Diagramm und in seiner Legende, damit sie übereinstimmen.

Prüfe die Seite mit Graustufen oder der Simulation von Farbsehschwächen in den Entwicklerwerkzeugen. Untersuche Links im Fließtext, Fehler, Pflichtfelder, Diagramme und Verfügbarkeitsanzeigen. Frag dich, welcher sichtbare Hinweis für jede Unterscheidung bleibt. Verschwindet eine Unterscheidung, ergänze ein Merkmal, das ihre Bedeutung nennt oder darstellt; höhere Sättigung allein liefert die fehlende Information nicht.

Das Vergrößern einer Seite sollte ihre Nutzung erleichtern, ohne Steuerelemente zu verbergen oder Sätze abzuschneiden. Menschen können die ganze Seite zoomen, nur Text vergrößern oder eigene Abstände anwenden. Flexible Layouts ermöglichen das Zusammenspiel dieser Einstellungen.

Teste Textgröße und Umbruch

WCAG 1.4.4 Textgröße ändern (AA) verlangt, dass sich Text auf 200 % vergrößern lässt, ohne Inhalt oder Funktionen zu verlieren. Der Browserzoom verwendet Strg und Plus unter Windows oder Cmd und Plus unter macOS. Teste auch eine größere Standardschriftgröße, die Text ändert, ohne alles andere auf dieselbe Weise zu vergrößern.

WCAG 1.4.10 Umbruch (AA) verlangt, dass gewöhnlicher Inhalt bei 320 CSS-Pixeln Breite funktioniert, ohne in zwei Richtungen zu scrollen. Ein 1280 CSS-Pixel breites Fenster bei 400 % Zoom bietet diese effektive Breite. Absätze sollten in eine schmale Spalte umbrechen und alle Funktionen verfügbar bleiben. Für Datentabellen, Karten und andere Inhalte, deren Bedeutung zwei Dimensionen braucht, gibt es Ausnahmen.

Lass das Layout mit dem Text wachsen

Verwende relative Schrifteinheiten wie rem und em, damit Text der eingestellten Standardschriftgröße folgt. Text in CSS-Pixeln reagiert weiterhin auf den Browserzoom, folgt dieser Standardeinstellung aber nicht auf dieselbe Weise. Flexible Container und max-width erlauben Zeilenumbrüche; Breakpoints in em können sich an wachsenden Text anpassen.

Eine feste Höhe kann Inhalt unbemerkt abschneiden:

/* Problem when larger text needs more space */
.card { height: 200px; overflow: hidden; }

/* Content can grow beyond the minimum */
.card { min-height: 200px; }

Lass den Inhalt seine Höhe bestimmen. Ordne bei geringer Breite die Navigation untereinander an oder biete einen barrierefreien Aufklappbereich, statt Links zu löschen. Lass einen übergroßen haftenden Kopfbereich wegscrollen, wenn er zu viel der nutzbaren Ansicht einnimmt.

Halte mobilen Zoom verfügbar

Verwende eine Viewport-Deklaration, die der Gerätebreite folgt:

<meta name="viewport" content="width=device-width, initial-scale=1">

Ergänze weder maximum-scale=1 noch user-scalable=no. Sie versuchen, die Vergrößerung durch Auseinanderziehen zu blockieren, die Menschen mit Sehbehinderung möglicherweise brauchen. Manche Browser ignorieren diese Einschränkungen, aber Nutzer sollten sich nicht darauf verlassen müssen.

Wende die Abstände der Nutzer an

WCAG 1.4.12 Textabstände (AA) verlangt, dass kein Inhalt verloren geht oder sich überlappt, wenn Nutzer die Zeilenhöhe auf das 1,5-Fache der Schriftgröße, den Absatzabstand auf das 2-Fache, den Buchstabenabstand auf das 0,12-Fache und den Wortabstand auf das 0,16-Fache setzen. Dies sind Testeinstellungen, keine verpflichtenden Standardwerte für das Design. Verwende ein Werkzeug für Textabstände und prüfe neben Absätzen auch Beschriftungen, Karten, Menüs und Schaltflächen.

Eine praktische Prüfung kombiniert einen Texttest bei 200 %, einen Umbruchtest bei 320 CSS-Pixeln und die benutzerdefinierten Abstände. Achte auf abgeschnittene Zeilen, überlappende Beschriftungen, horizontales Scrollen von Absätzen und verschwundene Funktionen. Korrigiere den Container oder das Layout, das das Problem verursacht; den vergrößerten Text wieder zu verkleinern nimmt Nutzern den gewünschten Vorteil.

Eine sichtbare Beschriftung sagt, was einzugeben ist, und gibt einem Feld einen zugänglichen Namen. Gruppenbeschriftungen ergänzen die Frage, die mehrere Auswahlmöglichkeiten beantworten. Die Verbindungen müssen im HTML bestehen, auch wenn Beschriftungen und Felder bereits nahe beieinander erscheinen.

Verbinde eine Beschriftung mit einem Steuerelement

Eine explizite Beschriftung verweist mit for auf die eindeutige id des Steuerelements:

<label for="email">Email address</label>
<input id="email" name="email" type="email">

Der Browser kann bei Fokus „Email address“ ansagen. Ein Klick auf den Text fokussiert ebenfalls das Feld und gibt Nutzern ein größeres Ziel. Das name-Attribut kennzeichnet übermittelte Daten; es ersetzt nicht die von der Beschriftung verwendete id.

Eine implizite Beschriftung umschließt ihr Eingabefeld: <label>Email address <input type="email" name="email"></label>. Das funktioniert, wenn beides in dasselbe label-Element passt. Bei getrennten Layoutcontainern ist die explizite Verbindung leichter zu pflegen.

Ein Platzhalter verschwindet beim Tippen und hat oft wenig Kontrast. Halte die Beschriftung sichtbar und setze Beispiele oder Formathinweise in die Nähe. „Feld 1“ ist technisch gesehen ein Name, beschreibt aber nicht den Zweck. WCAG 2.4.6 Überschriften und Beschriftungen (AA) verlangt aussagekräftige Formulierungen.

Halte die sichtbaren Worte im Namen

Eine Person mit Sprachsteuerung kann nach dem Anblick einer Senden-Schaltfläche „Klicke auf Senden“ sagen. Überschreibt aria-label="Submit form" den Text dieser Schaltfläche, enthält ihr zugänglicher Name die sichtbaren Worte nicht mehr. WCAG 2.5.3 Beschriftung im Namen (A) verlangt, dass diese Worte enthalten sind, idealerweise am Anfang. Verwende nach Möglichkeit den sichtbaren Text selbst: <button type="submit">Send message</button>.

Ein einzelnes Suchfeld kann eine visuell ausgeblendete Beschriftung haben, wenn eine benachbarte Suchen-Schaltfläche seinen Zweck visuell verdeutlicht. Ausgeblendete Beschriftungen sind kein allgemeiner Ersatz für sichtbare Anweisungen im ganzen Formular.

Gruppiere Auswahlmöglichkeiten unter ihrer Frage

<fieldset>
  <legend>Delivery method</legend>
  <input type="radio" id="pickup" name="delivery" value="pickup">
  <label for="pickup">Pick up in store</label>
  <input type="radio" id="courier" name="delivery" value="courier">
  <label for="courier">Courier delivery</label>
</fieldset>

Die Gruppenbeschriftung stellt die Frage der Gruppe; jedes Optionsfeld braucht weiterhin eine eigene Beschriftung. Screenreader können den Gruppenkontext mit einer Option ansagen. Verwende für sich gegenseitig ausschließende Optionen denselben name und kurze Gruppenbeschriftungen, die auch bei Wiederholung hilfreich bleiben. Zusammengehörige Kontrollkästchen können ebenfalls fieldset und legend verwenden.

Wähle Typen und prüfe Verbindungen

Verwende email, tel, url und date für die passenden Daten. Die Typen für E-Mail und URL bieten eine Formatprüfung; Telefonfelder können eine geeignete mobile Tastatur anbieten, validieren aber keine Telefonnummernformate. Verwende number für Mengen wie die Anzahl der Gäste, nicht für Telefon- oder Kartenkennungen.

Klicke auf jede Beschriftung, um ihre Verbindung zu testen. Erhält das falsche Feld den Fokus, prüfe auf doppelte IDs oder ein nicht passendes for. Untersuche auch den berechneten Namen in den Entwicklerwerkzeugen; räumliche Nähe allein kann eine Beschriftung nicht verbinden.

Anweisungen helfen am meisten, wenn sie vor einem Fehler erscheinen. Ein gutes Formular erklärt die erwartete Eingabe, zeigt Pflichtfelder an und unterstützt die Werkzeuge des Browsers zur Eingabe persönlicher Informationen. Es vermeidet außerdem, dass Nutzer Arbeit unnötig wiederholen müssen.

Verbinde einen Hinweis, ohne die Beschriftung zu ersetzen

<label for="pw">Password (required)</label>
<input id="pw" type="password" required
       autocomplete="new-password" aria-describedby="pw-hint">
<p id="pw-hint">At least 12 characters.</p>

Die Beschriftung benennt das Feld. Der sichtbare Absatz erklärt seine Anforderung, und aria-describedby ergänzt diesen Text als Beschreibung. Screenreader können ihn nach dem Namen ansagen. Für mehrere Beschreibungen liste ihre IDs durch Leerzeichen getrennt auf, etwa aria-describedby="pw-hint pw-error".

Kennzeichne Pflichtfelder sichtbar und mit required. Du kannst „(Pflichtfeld)“ schreiben oder ein Sternchen am Anfang des Formulars erklären. Das native required unterstützt die Validierung des Browsers und assistive Technologie; es braucht kein zusätzliches aria-required="true".

Bestimme den Zweck persönlicher Daten

Nach 1.3.5 Eingabezweck bestimmen (AA) brauchen Felder, die Informationen über den Nutzer erfassen, passende autocomplete-Token. Beispiele sind name, given-name, family-name, email, tel, street-address, postal-code, country-name und bday. Anmeldefelder können username und current-password verwenden; ein neues Passwort verwendet new-password, ein Bestätigungscode kann one-time-code verwenden.

Diese Token ermöglichen Browsern, Passwortmanagern und assistiven Werkzeugen, den Zweck eines Feldes zu erkennen. Verwende das passende Token für den Nutzer, dessen Informationen eingegeben werden. Wenn die Kontaktadresse eines Freundes als automatisch auszufüllende E-Mail-Adresse des Nutzers gekennzeichnet wird, können falsche Angaben eingetragen werden.

Verringere Anforderungen an Gedächtnis und wiederholte Eingaben

Erlaube das Einfügen in Passwort- und Bestätigungscodefelder und unterstütze Passwortmanager. WCAG 3.3.8 Barrierefreie Authentifizierung (Minimum) (AA) erlaubt kognitive Tests bei der Anmeldung nur mit einer geeigneten Alternative oder Unterstützung oder bei festgelegten Ausnahmen zur Erkennung von Objekten oder eigenen Inhalten. Das Blockieren des Einfügens erzeugt eine Barriere, wenn es zum Erinnern oder Abschreiben zwingt und kein geeigneter alternativer Anmeldeweg existiert.

Übernimm bei einer mehrstufigen Bestellung bereits eingegebene Informationen. Eine Auswahl „Rechnungsadresse entspricht der Lieferadresse“ vermeidet erneutes Abtippen. WCAG 3.3.7 Redundante Eingabe (A) erlaubt Ausnahmen, wenn die Wiederholung wesentlich, aus Sicherheitsgründen nötig oder die frühere Information nicht mehr gültig ist.

Biete eine Schutzmaßnahme bei folgenreichen Übermittlungen

Eine Bestellung kann eine finanzielle Verpflichtung erzeugen. Biete vor ihrem Abschluss einen Prüfschritt an, in dem Nutzer Angaben korrigieren können. Nach 3.3.4 Fehlervermeidung (rechtliche, finanzielle und Datenangelegenheiten) (AA) müssen entsprechende Übermittlungen rückgängig gemacht werden können, mit Korrekturmöglichkeit geprüft oder mit Korrekturmöglichkeit überprüft und bestätigt werden. Der Geltungsbereich umfasst auch das Ändern oder Löschen gespeicherter, von Nutzern kontrollierter Daten und das Absenden von Testantworten.

Halte das Formularlayout auch bei Vergrößerung leicht erfassbar: Beschriftungen direkt über den Feldern und eine Hauptspalte verkürzen den Abstand zwischen einer Anweisung und der Stelle, für die sie gilt.

Unterscheide Format und persönlichen Zweck

Der Eingabetyp und das autocomplete-Token beantworten unterschiedliche Fragen. Der Typ bezeichnet die Art des Werts und kann eine Formatprüfung bieten. Das Token bezeichnet die persönlichen Informationen des Nutzers für das automatische Ausfüllen:

<label for="your-email">Your email address (required)</label>
<input id="your-email" name="email" type="email"
       required autocomplete="email">
<label for="guest-email">Guest's email address</label>
<input id="guest-email" name="guest-email" type="email">

Beide Felder akzeptieren E-Mail-Adressen, aber nur das erste fragt nach der Adresse des aktuellen Nutzers. Das zweite sollte für das automatische Ausfüllen nicht als dessen E-Mail-Adresse gekennzeichnet werden. Die sichtbaren Beschriftungen erhalten den Unterschied für Menschen, die die Werte selbst eingeben. Eine Änderung des Tokens ändert nicht, was der E-Mail-Typ prüft.

Eine Fehlermeldung sollte helfen, einen Fehler zu beheben, ohne dass bereits geleistete Arbeit verloren geht. Eine Statusmeldung sollte eine Änderung mitteilen, ohne die Person von ihrer Position wegzuführen. Beide brauchen sichtbaren Wortlaut und die richtige programmatische Verbindung.

Nenne das Problem und eine hilfreiche Korrektur

„Ungültige Eingabe“ hilft wenig. „Fehler: Gib eine E-Mail-Adresse im Format name@example.com ein“ benennt, was beachtet werden muss, und schlägt eine Korrektur vor. WCAG 3.3.1 Fehlererkennung (A) verlangt, erkannte Fehler als Text zu beschreiben; 3.3.3 Fehlerempfehlung (AA) verlangt bekannte Korrekturvorschläge, wenn sie die Sicherheit oder den Zweck des Formulars nicht beeinträchtigen.

<label for="email">Email address</label>
<input id="email" type="email" aria-invalid="true"
       aria-describedby="email-error">
<p id="email-error">Error: Enter an email address in the format name@example.com</p>

Setze aria-invalid="true" erst, nachdem du das Feld geprüft und einen Fehler gefunden hast. Das Attribut meldet den ungültigen Zustand; die Beschreibung erklärt den Grund. Ein roter Rahmen allein liefert weder die Erklärung als Text noch die Verbindung.

Hilf beim Auffinden mehrerer Fehler

Nach dem Absenden kann ein langes Formular oben eine Fehlerzusammenfassung zeigen. Gib ihr eine Überschrift wie „Es gibt 2 Probleme mit deiner Bestellung“ und anschließend Links zu den betroffenen Feldern. Mache die Zusammenfassung mit tabindex="-1" fokussierbar und lass das Skript sie fokussieren. Auch „Fehler: “ am Anfang des Seitentitels hilft, den geänderten Seitenzustand zu erkennen.

Halte Fehlermeldungen auch neben ihren Eingabefeldern und bewahre alle bisherigen Eingaben. Ein Link in der Zusammenfassung führt zum Feld; die Erklärung vor Ort hilft bei der Korrektur. Alle Felder zu leeren zwingt dazu, erfolgreiche Arbeit zu wiederholen.

Native Validierungsattribute wie required, type="email" und minlength können Browsermeldungen bereitstellen. Ein eigenes System kann novalidate verwenden und eigene Meldungen zeigen. In beiden Fällen brauchen Fehler Text, den Nutzer finden und dem jeweiligen Feld zuordnen können.

Sage eine Änderung ohne Fokuswechsel an

Eine Warenkorbaktualisierung geschieht oft, während der Fokus auf der Hinzufügen-Schaltfläche bleiben sollte. Verwende eine bereits im Dokument vorhandene Live-Region:

<p role="status" id="cart-status"></p>

Wird ein Artikel hinzugefügt, ändert ein Skript den Text der Live-Region in „1 Sauerteigbrot zu deinem Warenkorb hinzugefügt“. role="status" ist zurückhaltend: Es lässt den Screenreader seine aktuelle Sprachausgabe beenden, bevor die Aktualisierung angesagt wird. Das unterstützt 4.1.3 Statusmeldungen (AA).

Reserviere role="alert", eine unterbrechende Ansage, für dringende Meldungen. Ständige Unterbrechungen erschweren gewöhnliche Einkäufe. Füge die leere Region ein, bevor du ihren Inhalt aktualisierst; werden Region und Meldung zusammen erstellt, wird dies in vielen Kombinationen nicht zuverlässig angesagt. Halte den Fokus bei gewöhnlichen Aktualisierungen auf der Aufgabe und verschiebe ihn gezielt bei Situationen wie einer Fehlerzusammenfassung, die Nutzer prüfen müssen.

ARIA ergänzt Informationen im Barrierefreiheitsbaum, wenn HTML Hilfe benötigt, um einen Namen, eine Beziehung oder einen Zustand auszudrücken. Es erstellt die Interaktion nicht selbst. Prüfe vor dem Ergänzen eines Attributs, was das native Element bereits bietet und was tatsächlich fehlt.

Betrachte eine Rolle als Zusage

WAI-ARIA steht für Accessible Rich Internet Applications. Version 1.2 wurde im Juni 2023 eine W3C-Empfehlung. Ihre Rollen, Zustände und Eigenschaften beeinflussen, was assistiven Technologien mitgeteilt wird. Eine Rolle wie button verspricht Schaltflächenverhalten, erzeugt aber weder Fokussierbarkeit noch Tastaturaktivierung oder Gestaltung.

Ein div mit role="button" braucht weiterhin Tastatur- und Fokusunterstützung. Ein echtes button bringt sie bereits mit. Der Grundsatz des ARIA Authoring Practices Guide „Kein ARIA ist besser als schlechtes ARIA“ warnt davor, dass falsche Informationen Nutzer darüber täuschen können, was ein Steuerelement tut.

Erhalte native Bedeutung

Verwende zuerst native Elemente und Attribute: nav, button, ein Kontrollkästchen-Eingabefeld und natives required. Vermeide die Wiederholung impliziter Rollen wie role="main" an main oder role="button" an button. Eine hilfreiche Ausnahme ist role="list" an einer Liste, deren entfernte Aufzählungszeichen die Ansagen von VoiceOver beeinträchtigen.

Ersetze die Bedeutung einer Überschrift nicht durch eine Schaltflächenrolle. Verschachtle eine Schaltfläche darin:

<h2>
  <button type="button" aria-expanded="false">Shipping</button>
</h2>

Die Überschrift erscheint weiterhin in der Überschriftennavigation und ihre Schaltfläche stellt die Aktion bereit. Das Skript muss dafür sorgen, dass angezeigter Inhalt und aufgeklappter Zustand übereinstimmen.

Setze aria-hidden="true" nie an ein fokussierbares Steuerelement oder ein übergeordnetes Element, das eines enthält. Der Fokus könnte auf etwas landen, das aus dem Barrierefreiheitsbaum entfernt wurde. role="presentation" und role="none" funktionieren anders: Sie entfernen Semantik, nicht den Inhalt. Browser ignorieren diese Rollen an fokussierbaren Elementen, sodass sie einen aktiven Link nicht in einfachen Text verwandeln können.

Finde die Quelle eines Namens

Prüfe bei den hier behandelten gewöhnlichen Steuerelementen die Namensquellen in dieser Reihenfolge:

1. aria-labelledby, das per ID auf Text verweist.
2. aria-label, das eine Zeichenfolge bereitstellt.
3. Die native Quelle, etwa eine Beschriftung, Schaltflächentext oder Alternativtext eines Bildes.
4. title, gegebenenfalls als letzte Möglichkeit.

aria-describedby ergänzt eine Beschreibung nach dem Namen; es legt den Namen nicht fest. Eine Überschreibung kann hilfreichen sichtbaren Wortlaut versehentlich verbergen. <button aria-label="Close dialog">Cancel</button> wird als „Close dialog“ angesagt, obwohl die Person „Cancel“ sieht. Bevorzuge sichtbaren Text oder nimm ihn an den Anfang eines nötigen erweiterten Namens auf.

Einfache Websites brauchen ARIA häufig für Namen wiederholter Orientierungspunkte, Symbolschaltflächen, Feldhinweise und Fehler, Aufklappbereiche, Links zur aktuellen Seite und Live-Aktualisierungen. Eine große Sammlung von ARIA-Attributen ist kein Qualitätsmaß. Untersuche die berechnete Rolle und den Namen und prüfe mit der Tastatur das Verhalten, das die Rolle verspricht.

Verfolge konkurrierende Namensquellen

Betrachte eine Schaltfläche mit mehreren benennenden Attributen:

<h2 id="options-title">Delivery options</h2>
<button type="button" aria-labelledby="options-title"
        aria-label="Choose delivery">Show pickup options</button>

Folge zuerst aria-labelledby: Der referenzierte Text liefert „Delivery options“. Das nachrangige aria-label und der sichtbare Schaltflächentext setzen sich nicht durch. Entfernst du nur aria-label, bleibt der berechnete Name daher gleich.

Damit „Show pickup options“ diese Schaltfläche benennt, entferne beide unnötigen Überschreibungen. Die Schaltflächenrolle bleibt dabei gleich; nur ihre Namensquelle ändert sich. Untersuche den berechneten Namen nach jeder Änderung, damit du erkennst, welches Attribut die Abweichung verursacht hat. Eine zusätzliche Beschreibung würde den falschen Namen nicht korrigieren, weil eine Beschreibung eine separate Information ist.

Eine sich ändernde Oberfläche muss visuell und programmatisch dasselbe mitteilen. Ist ein Bereich geöffnet, aber seine Schaltfläche meldet weiterhin „eingeklappt“, erhält ein Screenreader-Nutzer falsche Informationen. Aktualisiere den Zustand bei jeder Änderung der Oberfläche.

Halte einen Aufklappbereich synchron

<button type="button" aria-expanded="false"
        aria-controls="main-menu">Menu</button>
<ul id="main-menu" hidden>
  <li><a href="/bread">Bread</a></li>
</ul>

Wenn sich das Menü öffnet, entfernt das Skript hidden und setzt aria-expanded der Schaltfläche auf true. Beim Schließen stellt das Skript hidden wieder her und setzt den Zustand auf false. Der Zustand gehört an die Schaltfläche, die umschaltet. aria-controls bezeichnet das betroffene Element; seine Unterstützung variiert, daher kann es den aufgeklappten Zustand oder das tatsächliche Ausblenden nicht ersetzen.

Wähle den zum Steuerelement passenden Zustand

Gestalte beim Link zur aktuellen Seite dasselbe Attribut in CSS, etwa mit fetter Schrift und unterem Rahmen an a[aria-current="page"]. So bleibt die sichtbare Hervorhebung an den angesagten Zustand gebunden. aria-selected gehört zu Widgets wie Registerkarten und Optionen einer Listenbox, nicht zu gewöhnlichen Seitennavigationslinks.

Eine Umschaltfläche kann die Beschriftung „Stummschalten“ behalten und aria-pressed zwischen false und true ändern. Eine andere gültige Gestaltung ändert die Beschriftung einer normalen Aktionsschaltfläche zwischen „Stummschalten“ und „Stummschaltung aufheben“, ohne einen gedrückten Zustand zu verwenden. Kombiniere keine wechselnde Aktionsbeschriftung mit dem Muster für einen Umschaltzustand, da dies zu verwirrenden Ansagen wie „Stummschaltung aufheben, gedrückt“ führen kann.

Unterscheide Ausblenden und Deaktivieren

aria-hidden="true" entfernt ein Element und seine Nachfahrenelemente aus dem Barrierefreiheitsbaum, lässt sie aber sichtbar. Verwende es für dekorative Symbole oder redundanten visuellen Inhalt. Es verhindert keinen Tastaturzugriff. Verwende hidden oder display: none, wenn ein Bereich für alle nicht verfügbar sein soll.

Das native disabled verhindert die gewöhnliche Interaktion mit einem nativen Steuerelement. aria-disabled="true" meldet einen nicht verfügbaren Zustand, blockiert aber weder Klicks noch Tastaturaktivierung. Wird dieses Attribut verwendet, um ein deaktiviertes Steuerelement für eine Erklärung fokussierbar zu halten, muss das Skript seine Aktion verhindern. Bevorzuge auch natives checked und required an nativen Eingabefeldern.

Teste beide Richtungen

Öffne und schließe den Aufklappbereich mit der Tastatur, während du die Attribute in den Entwicklerwerkzeugen beobachtest. Untersuche den berechneten Zustand und höre seine Ansage. Eine erfolgreiche visuelle Änderung allein zeigt nicht, dass der Zustand aktualisiert wurde, und ein geändertes Attribut allein zeigt nicht, dass der Bereich sichtbar oder nutzbar wurde.

Automatisierte Prüfungen finden schnell viele Codeprobleme auf einer dargestellten Seite. Nutze ihre Ergebnisse, um Barrieren zu finden und Korrekturen zu prüfen. Ihre Regeln können manche Beziehungen und Werte untersuchen, aber ob Inhalt sinnvoll ist, muss weiterhin ein Mensch entscheiden.

Wähle ein Prüfwerkzeug und untersuche seine Befunde

Axe DevTools verwendet die axe-core-Engine. WAVE setzt Markierungen auf die Seite, sodass Befunde im Kontext sichtbar sind. Lighthouse in den Chrome-Entwicklerwerkzeugen vergibt eine Barrierefreiheitsbewertung anhand ausgewählter axe-core-Prüfungen. Accessibility Insights bietet einen weiteren Prüfablauf. Der W3C Markup Validation Service prüft HTML-Probleme wie doppelte IDs und nicht geschlossene Elemente.

Je nach Regeln und Kontext können Werkzeuge fehlende alt-Attribute, unbenannte Steuerelemente, fehlende Feldbeschriftungen, geringen Textkontrast auf einfarbigen Hintergründen, fehlende Seitensprache und ungültiges ARIA erkennen. Manche Probleme mit Überschriftenebenen erscheinen als Warnungen. Lies die Erklärung des Befunds und untersuche das bezeichnete Element.

Ein Prüfhinweis oder ein Ergebnis mit „Prüfung erforderlich“ verlangt eine Beurteilung. Fett gesetzter Text, der als mögliche Überschrift markiert wurde, kann ein echter, als Absatz geschriebener Abschnittstitel sein oder lediglich einen Satz betonen. Untersuche seinen Zweck, bevor du seine HTML-Auszeichnung änderst.

Verstehe, was die Prüfung nicht entscheiden kann

Ein Prüfwerkzeug sieht alt="photo", ohne zu wissen, dass die Alternative nutzlos ist. Es kann nicht zuverlässig beurteilen, ob ein Link klar formuliert ist, Untertitel korrekt sind, die Fokusreihenfolge sinnvoll ist oder eine Fehlermeldung bei der Korrektur hilft. Eine visuelle Überlagerung kann eine Tastaturfalle bilden, die die aktuelle Prüfung nicht erkennt. Auch Text über einem Foto braucht eine manuelle Kontrastprüfung.

Eine Bewertung von 100 bedeutet, dass die getesteten Regeln keine Fehler gefunden haben. Sie ist kein Urteil über WCAG-Konformität. Prüfe weiterhin Aufgaben und Bedeutungen, die diese Regeln nicht beurteilen können.

Teste die genutzten Zustände

Eine Prüfung untersucht den dargestellten Zustand zum jeweiligen Zeitpunkt. Führe Prüfungen für jede Seitenvorlage und erneut bei geöffneten Menüs und Dialogen, nach Formularfehlern und bei geringer Breite aus. Eine geschlossene Komponente kann Probleme verbergen, die erst bei der Nutzung auftreten.

Angenommen, ein Bericht für eine Bäckerei findet ein Hero-Bild ohne alt, ein Newsletter-Eingabefeld ohne Beschriftung und Fußbereichstext #999999 auf Weiß. Entscheide zuerst, ob das Bild informiert oder dekoriert. Ergänze entsprechend eine hilfreiche Alternative oder alt="". Verbinde das E-Mail-Feld mit einer sichtbaren Beschriftung. Das Farbpaar im Fußbereich hat 2,85:1 Kontrast; ersetzt du die Textfarbe durch #595959, erhältst du 7,00:1 auf Weiß.

Behebe Ursachen und prüfe Ergebnisse

Priorisiere Barrieren nach ihrer Auswirkung auf die Aufgabe. Eine Tastaturfalle oder ein unbenanntes Pflichtfeld kann eine Bestellung vollständig verhindern. Repariere ein gemeinsam genutztes Feld oder eine Fußbereichskomponente an der Quelle, damit sich jede Seite verbessert, die sie verwendet. Führe dann die Prüfung im selben Zustand erneut aus und wiederhole den relevanten manuellen Test. Eine geringere Fehlerzahl ist ein hilfreicher Beleg, aber die Korrektur muss auch ermöglichen, die Aufgabe abzuschließen.

Manuelle Tests zeigen, wie sich eine Seite bei einer tatsächlichen Aufgabe verhält. Kombiniere Tastaturbedienung, vergrößerte Ansichten, Screenreader-Prüfungen und die direkte Untersuchung des Baums. Dokumentiere genug Details, damit eine andere Person ein Problem reproduzieren und seine Korrektur bestätigen kann.

Gehe eine Tastaturaufgabe von Anfang bis Ende durch

Lege die Maus beiseite. Beginne in der Adressleiste und gehe mit Tab durch die Seite. Erreiche jeden Link und jedes Steuerelement, verwende Enter und Leertaste, wo es passt, und kehre die Richtung mit Umschalt+Tab um. Prüfe, ob der Fokus sichtbar bleibt und nicht von einem haftenden Bereich verdeckt wird.

Verwende den Sprunglink, öffne und schließe Menüs, schließe einen Dialog mit Escape und prüfe, wohin der Fokus zurückkehrt. Suche nach unsichtbaren Stopps in geschlossenen Komponenten und nach Fallen in eingebetteten Playern oder Karten. Aktiviere auf einem Mac die Tastaturnavigation und Safaris vollständige Tab-Navigation, bevor du übersprungene Steuerelemente als Seitenfehler einstufst.

Vergrößere die Seite und prüfe den Umbruch

Teste bei 200 % Vergrößerung, ohne Text oder Funktionen zu verlieren. Verwende dann ein 1280 CSS-Pixel breites Fenster bei 400 % Zoom, entsprechend 320 CSS-Pixeln verfügbarer Breite. Prüfe Absätze auf horizontales Scrollen, Überlappungen und abgeschnittenen Inhalt. Halte jede Funktion im schmalen Layout verfügbar. Wende die Textabstandswerte mit einem Werkzeug an und untersuche Steuerelemente ebenso wie Fließtext.

Höre Struktur und Namen

NVDA unter Windows verwendet standardmäßig Einfügen als NVDA-Taste; die Feststelltaste ist eine optionale Alternative. Im Lesemodus führt H durch Überschriften, D durch Orientierungspunkte, K durch Links, F durch Felder, T durch Tabellen und B durch Schaltflächen. NVDA+F7 öffnet die Elementliste. Tab führt weiterhin durch interaktive Steuerelemente.

Unter macOS schaltet Cmd+F5 VoiceOver um. Die VO-Zusatztasten sind Control+Option; VO+Pfeil rechts liest das nächste Element vor und VO+U öffnet den Rotor. Auf dem iPhone führt Wischen nach rechts zum nächsten VoiceOver-Element. TalkBack bietet auf Android eine ähnliche Bedienung durch Berührung.

Achte auf einen hilfreichen Seitentitel und eine sinnvolle Gliederung, klare Steuerelementnamen, korrekte Rollen, hilfreiche Bildalternativen und verständliche Feldbeschriftungen. Pflichtfeldzustände, Hinweise und Fehler sollten an den jeweiligen Feldern verfügbar sein. Öffne einen Aufklappbereich und höre seine Zustandsänderung. Füge einen Artikel hinzu und achte auf eine Statusaktualisierung ohne Fokussprung.

Untersuche, dokumentiere und teste erneut

Der Barrierefreiheitsbereich in Chrome und der Barrierefreiheitsinspektor in Firefox zeigen berechnete Rollen, Namen und Zustände. Sie helfen nachzuvollziehen, warum eine Beschriftung falsch ist, noch bevor ein Screenreader gestartet wird.

Ein hilfreicher Bericht nennt Ort, Schritte, beobachtetes Verhalten, betroffene Nutzer, zugehöriges Kriterium und Korrekturvorschlag. Zum Beispiel: „Newsletter-Feld im Fußbereich: Mit Tab zum Eingabefeld gehen; es wird ohne Beschriftung angesagt. Screenreader-Nutzer und Nutzer der Sprachsteuerung können seinen Zweck nicht erkennen. Eine verbundene Beschriftung ‚E-Mail-Adresse‘ ergänzen; 1.3.1, 3.3.2 und 4.1.2 prüfen.“

Teste mit der Methode erneut, die das Problem gefunden hat. Gängige Kombinationen sind NVDA mit Firefox oder Chrome, JAWS mit Chrome und VoiceOver mit Safari. Tests mit Menschen, die täglich assistive Technologie nutzen, können Barrieren aufdecken, die gelegentliche Entwicklertests übersehen.

Mache einen Zustandsfehler reproduzierbar

Ein Bericht für einen Aufklappbereich kann einen vollständigen kurzen Test festhalten:

1. Auf der Brotseite NVDA mit Firefox verwenden und mit Tab zu „Lieferoptionen“ gehen.
2. Einmal Enter drücken. Der Bereich wird sichtbar, aber die Schaltfläche wird weiterhin als eingeklappt angesagt.
3. Die Schaltfläche untersuchen: aria-expanded ist weiterhin false.

Dem betroffenen Nutzer wird mitgeteilt, dass der sichtbare Bereich geschlossen bleibt. Dokumentiere 4.1.2 Name, Rolle, Wert (A) und schlage vor, den Zustand der Schaltfläche bei einer Änderung des Bereichs zu aktualisieren. Wiederhole nach der Korrektur das Öffnen und Schließen mit denselben Tasten und derselben Kombination. Prüfe, ob die Sichtbarkeit des Bereichs und der angesagte aufgeklappte Zustand in beiden Richtungen übereinstimmen; nur den anfänglichen eingeklappten Zustand zu untersuchen würde diesen Fehler übersehen.