Ein Formular fragt nach der Umsatzsteuer-Identifikationsnummer. Neben dem Feld steht ein kleines Fragezeichen, und wer mit der Maus darüberfährt, sieht das erwartete Format. Wer mit der Tastatur arbeitet, sieht nichts. Wer den Zeiger vom Fragezeichen zum eingeblendeten Kasten bewegt, um den Text mit der Bildschirmlupe zu lesen, verliert ihn auf halbem Weg. Und wer den Kasten stehen lässt, findet darunter das Feld verdeckt, das er gerade ausfüllen wollte. Genau diese vier Situationen beschreibt ein einziges Erfolgskriterium der Web Content Accessibility Guidelines: 1.4.13, Inhalte bei Zeigerkontakt oder Fokus. Dieser Beitrag zerlegt den Wortlaut, sortiert die Fundstellen in Norm und Prüfverfahren, geht den Prüfweg mit und zeigt ein Muster, das die drei Bedingungen erfüllt.
Das Wichtigste in Kürze
- Ein eingeblendeter Inhalt muss zugleich ausblendbar, überfahrbar und beständig sein. Fällt eine der drei Bedingungen aus, ist das Kriterium nicht erfüllt (W3C).
- Das Kriterium ist keine Neuerung der Version 2.2: Der Wortlaut steht bereits in WCAG 2.1, deren erste Empfehlung vom 5. Juni 2018 datiert (W3C).
- Die EN 301 549 zieht die Anforderung dreifach nach: für Webseiten, für Dokumente und für Software mit Benutzeroberfläche (EN 301 549).
- Vom Browser gesteuerte Einblendungen wie der Tooltip aus dem title-Attribut sind ausgenommen (W3C). Der HTML-Standard rät gleichwohl davon ab, sich darauf zu stützen (WHATWG).
- Die Bedingung „überfahrbar“ betrifft nur Einblendungen durch den Zeiger. Bei Einblendung durch Tastaturfokus wird sie nicht verlangt (BIK BITV-Test).
- Geprüft wird von Hand: Die EN 301 549 nennt als Verfahren für dieses Kriterium die Inspektion, nicht die automatische Messung (EN 301 549).
Drei Bedingungen, ein Kriterium
Erfolgskriterium 1.4.13 trägt im englischen Original den Namen „Content on Hover or Focus“ und liegt auf Konformitätsstufe AA. Es greift dort, wo das Empfangen und anschließende Entfernen von Zeigerkontakt oder Tastaturfokus dazu führt, dass zusätzlicher Inhalt sichtbar und danach wieder ausgeblendet wird (W3C). Der Auslöser kann ein Symbol sein, ein unterstrichenes Wort, ein Menüpunkt, ein Datenpunkt im Diagramm oder ein Eingabefeld. Der eingeblendete Inhalt kann eine Feldhilfe sein, ein Untermenü, eine Profilvorschau, ein Glossareintrag oder eine Werteanzeige. Entscheidend ist weder der Name der Komponente noch die Technik dahinter, sondern das Verhalten: Erscheint etwas zusätzlich zum Auslöser und verschwindet es wieder, wenn der Kontakt endet, ist das Kriterium anwendbar. Die deutsche Prüfpraxis führt es unter der Überschrift „Eingeblendete Inhalte bedienbar“ (BIK BITV-Test).
Die Norm stellt anschließend drei Bedingungen nebeneinander, die zugleich gelten müssen. Ausblendbar heißt: Es gibt einen Mechanismus, den zusätzlichen Inhalt zu schließen, ohne Zeiger oder Tastaturfokus zu bewegen (W3C). Überfahrbar heißt: Kann der Zeiger den Inhalt auslösen, dann kann der Zeiger auch über den Inhalt bewegt werden, ohne dass dieser verschwindet (W3C). Beständig heißt: Der Inhalt bleibt sichtbar, bis der Auslöser verlassen wird, bis der Nutzer ihn schließt oder bis seine Information nicht mehr gültig ist (W3C). Drei Bedingungen, ein Ergebnis: Fällt eine aus, ist das Kriterium nicht erfüllt. Wer eingeblendete Inhalte plant, arbeitet damit an derselben Nahtstelle wie bei barrierefreien Modals und Overlays und bei Navigationen mit Untermenüs, nur ohne Fokusfalle und ohne erzwungene Entscheidung.
Was „zusätzlich“ ausschließt
Nicht neu in Version 2.2: der Wortlaut steht seit 2018
In Projektgesprächen taucht 1.4.13 regelmäßig als „eines der neuen Kriterien“ auf. Das stimmt nicht. Der Wortlaut steht bereits in WCAG 2.1, deren Empfehlung vom 5. Juni 2018 datiert; die heute veröffentlichte Fassung ist eine Überarbeitung vom 6. Mai 2025 (W3C). WCAG 2.2 wurde am 12. Dezember 2024 als Empfehlung veröffentlicht (W3C) und übernimmt den Wortlaut der Anforderung unverändert; hinzugekommen ist dort eine dritte Anmerkung, die Elemente ohne zusätzlichen Inhalt wie Sprunglinks ausdrücklich ausnimmt (W3C). Wer die neuen Kriterien der Version 2.2 durchgeht, findet 1.4.13 dort folgerichtig nicht. Praktisch bedeutet das: Wer seine Oberfläche in den vergangenen Jahren nach WCAG 2.1 gebaut hat, schuldet das Kriterium bereits. Ein Befund dazu ist keine Folge einer neuen Fassung, sondern eine offene Rechnung.
Für den deutschen Rechtsrahmen ist die Fundstelle wichtiger als die Versionsnummer. Die EN 301 549 verweist in Klausel 9.1.4.13 für Webseiten auf das Erfolgskriterium 1.4.13 der WCAG 2.1 (EN 301 549) und wiederholt dieselbe Anforderung in Klausel 10.1.4.13 für Nicht-Web-Dokumente und in Klausel 11.1.4.13 für Nicht-Web-Software mit Benutzeroberfläche (EN 301 549). Ein Formular-PDF und eine Desktopanwendung unterliegen damit derselben Prüfung wie eine Webseite. Wie diese Norm mit dem Gesetz zusammenhängt, ist an anderer Stelle ausführlich beschrieben: die EN 301 549 als Norm hinter dem BFSG und die daraus abgeleiteten BFSG-Anforderungen. Die Verordnung zum Barrierefreiheitsstärkungsgesetz verlangt zusätzlich, bei der Erfüllung ihrer Anforderungen den Stand der Technik zu beachten, lässt ein Abweichen davon aber zu, wenn die Anforderungen auf andere Weise in gleichem Maße erfüllt werden (Bundesministerium der Justiz). Eine bestimmte Normfassung schreibt sie damit nicht fest.
| Fundstelle | Was dort steht | Was daraus folgt |
|---|---|---|
| WCAG 2.1, Kriterium 1.4.13 | Der vollständige Wortlaut mit drei Bedingungen und Ausnahme | Die Anforderung besteht seit der Empfehlung von 2018 |
| WCAG 2.2, Kriterium 1.4.13 | Derselbe Wortlaut der Anforderung, ergänzt um eine dritte Anmerkung zu Sprunglinks | Ein Umstieg auf 2.2 ändert an der Anforderung selbst nichts |
| EN 301 549, Klausel 9.1.4.13 | Verweis auf WCAG 2.1 für Webseiten | Der Prüfmaßstab für die Website |
| EN 301 549, Klausel 10.1.4.13 | Derselbe Verweis für Nicht-Web-Dokumente | Feldhilfen in Formular-PDF sind erfasst |
| EN 301 549, Klausel 11.1.4.13 | Derselbe Verweis für Software mit Oberfläche | Fachanwendungen und Apps sind erfasst |
| EN 301 549, Anhang C.9.1.4.13 | Art der Bewertung: Inspektion | Der Nachweis entsteht von Hand, nicht im Scanner |
| BITV-Test, Prüfschritt 9.1.4.13 | Zwei Prüfungen: Zeiger-Hover und Tastaturfokus | Zwei Durchläufe je Auslösertyp im Bericht |
Die Tabelle erklärt auch, warum das Thema in Ausschreibungen so oft unterschätzt wird. Wer als Prüfumfang „die Website“ vereinbart, hat Fachanwendung und Dokumentenausgabe nicht mitgekauft, obwohl die Norm für beide dieselbe Anforderung stellt. Und wer den Nachweis über ein automatisches Werkzeug führen möchte, stößt an die Grenze des Verfahrens: Die Norm selbst ordnet diesem Kriterium die Inspektion zu (EN 301 549), also die Prüfung durch eine Person mit Zeiger, Tastatur und Blick auf das, was tatsächlich passiert.
Die drei Tore einzeln gelesen
Das erste Tor, ausblendbar, hat eine Ausnahme, die häufig übersehen wird: Der Mechanismus zum Schließen entfällt, wenn der zusätzliche Inhalt einen Eingabefehler mitteilt oder wenn er anderen Inhalt weder verdeckt noch ersetzt (W3C). Eine Fehlermeldung, die unter dem Feld erscheint und nichts überdeckt, braucht also keine Schließtaste. Ein Erklärkasten, der über dem nächsten Feld liegt, braucht sie. Der BITV-Test benennt die beiden gebräuchlichen Wege ausdrücklich: das Drücken der Escape-Taste oder das erneute Aktivieren des Elements, dessen Fokussierung den Inhalt einblendet (BIK BITV-Test). Beides erfüllt die Bedingung; verlangt ist ein Mechanismus, keine bestimmte Taste.
Das zweite Tor, überfahrbar, ist an den Zeiger gebunden. Es greift dort, wo der Zeiger die Einblendung auslösen kann, und verlangt dann, dass der Zeiger über den eingeblendeten Inhalt geführt werden kann, ohne dass dieser verschwindet (W3C). Bei Inhalten, die durch Tastaturfokussierung eingeblendet werden, wird nicht verlangt, dass der Mauszeiger über sie bewegt werden kann (BIK BITV-Test). Das dritte Tor, beständig, verbietet in der Praxis vor allem eines: den Zeitgeber. Ein Kasten, der nach drei Sekunden von selbst verschwindet, verletzt die Bedingung, denn beendet werden darf die Einblendung nur durch das Verlassen des Auslösers, durch das Schließen seitens der Nutzerin oder dadurch, dass die Information nicht mehr gültig ist (W3C). Wer die Fokusführung ohnehin überarbeitet, findet die angrenzenden Fragen unter Fokus-Management in Single-Page-Anwendungen; die Umsetzung im Markup gehört zur barrierefreien Webentwicklung.
Tor 1: ausblendbar
Ein Mechanismus schließt den Inhalt, ohne dass Zeiger oder Fokus bewegt werden. Üblich sind die Escape-Taste und das erneute Aktivieren des Auslösers. Entfällt nur bei Fehlermeldungen und bei Einblendungen, die nichts verdecken.
Tor 2: überfahrbar
Der Zeiger wandert vom Auslöser in den eingeblendeten Kasten, ohne dass dieser schließt. Das setzt eine lückenlose Fläche oder eine kurze Nachlaufzeit voraus. Gilt nur, wenn der Zeiger die Einblendung auslösen kann.
Tor 3: beständig
Kein Zeitgeber, der die Einblendung von selbst beendet. Sie endet, wenn der Auslöser verlassen wird, wenn die Nutzerin schließt oder wenn die Information nicht mehr gültig ist.
Ausnahme: Browser-Tooltip
Wird die visuelle Darstellung vom Nutzeragenten gesteuert und vom Autor nicht verändert, greift das Kriterium nicht. Der Tooltip aus dem title-Attribut ist das Beispiel, das die Norm selbst nennt.
Ausnahme: Eingabefehler
Teilt der eingeblendete Inhalt einen Eingabefehler mit, entfällt die Pflicht zum Schließmechanismus. Die beiden anderen Bedingungen bleiben bestehen, auch bei Fehlermeldungen.
Abgrenzung: modaler Dialog
Ein modaler Dialog bindet den Fokus und erwartet eine Entscheidung. Er wird über andere Kriterien geprüft. 1.4.13 zielt auf nichtmodale Einblendungen wie Tooltips, Untermenüs und Vorschaukarten.
Die Bedingung, die nur den Zeiger betrifft
Das title-Attribut: Ausnahme und Sackgasse
Die Norm formuliert eine Ausnahme: Wird die visuelle Darstellung des zusätzlichen Inhalts vom Nutzeragenten gesteuert und vom Autor nicht verändert, greift das Kriterium nicht (W3C). Als Beispiel nennt sie ausdrücklich Browser-Tooltips, die über das HTML-Attribut title erzeugt werden (W3C). Der BITV-Test kennt eine entsprechende Ausnahme, formuliert sie aber nicht gleichlautend: Er stellt auf das Verhalten eingeblendeter Inhalte ab, das durch den Nutzeragenten bestimmt wird, und führt die Bedingung einer vom Autor unveränderten Darstellung nicht mit auf (BIK BITV-Test). Rein formal ist der native Tooltip damit der bequemste Weg durch 1.4.13: Er wird gar nicht erst geprüft.
Nur führt dieser Weg nicht weit. Der HTML-Standard selbst rät davon ab, sich auf das Attribut zu stützen, weil viele Nutzeragenten es nicht in zugänglicher Form ausgeben und der Tooltip in der Regel ein Zeigegerät voraussetzt, was Menschen ausschließt, die ausschließlich mit der Tastatur arbeiten, und ebenso jene mit einem modernen Telefon oder Tablet (WHATWG). Wer eine Ausnahme von 1.4.13 dadurch erkauft, dass der Inhalt für einen Teil der Nutzerschaft schlicht nicht existiert, hat das Kriterium umgangen und die Anforderung verfehlt. Wie sich das in der Ausgabe von Sprachausgaben niederschlägt, zeigt der Beitrag zur Screenreader-Optimierung; nachmessen lässt es sich in einem Screenreader-Test.
- Steht die Information nur im title-Attribut, ist sie für Tastatur- und Touchbedienung in der Regel nicht erreichbar (WHATWG). Sie gehört zusätzlich in den sichtbaren Text oder in eine eigene Einblendung.
- Sobald die Darstellung des Browser-Tooltips per CSS oder JavaScript verändert wird, entfällt die Ausnahme, denn diese setzt eine vom Autor unveränderte Darstellung voraus (W3C).
- Ein Symbolknopf ohne Beschriftung braucht einen zugänglichen Namen, unabhängig davon, ob er zusätzlich einen Tooltip einblendet.
- Der Anteil der Seiten, die die Prüfung auf einen zugänglichen Namen für ARIA-Tooltips bestehen, lag 2025 bei 87 Prozent, 2021 waren es 29 Prozent (Web Almanac, 2025) — die Richtung stimmt, der Rest ist Prüfstoff.
- Auf Startseiten wurden 2026 im Schnitt mehr als 133 ARIA-Attribute gezählt, 27 Prozent mehr als im Vorjahr (WebAIM Million, 2026). Jedes zusätzliche Attribut ist ein Zustand, der zum Verhalten passen muss.
- Wer title als Ergänzung einsetzt, verliert nichts; wer es als einzigen Träger einsetzt, verlagert das Problem in die Sprachausgabe.
Ein Tooltip ist kein Ort für Informationen, die man braucht. Er ist ein Ort für Informationen, die helfen. Alles, was zum Ausfüllen eines Feldes erforderlich ist, gehört in den sichtbaren Text daneben — dann entscheidet die Einblendung über Bequemlichkeit, nicht über Zugang.
Der Prüfweg: wie ein Audit 1.4.13 misst
Der BITV-Test zerlegt den Prüfschritt in zwei Durchläufe. Im ersten wird die Einblendung mit dem Zeiger ausgelöst und geprüft, ob sich der Zeiger in den eingeblendeten Inhalt bewegen lässt, ob dieser bestehen bleibt und ob er sich schließen lässt, ohne den Zeiger zu bewegen. Im zweiten wird dieselbe Komponente mit der Tastatur fokussiert und die Prüfung wiederholt, ohne die Bedingung „überfahrbar“ (BIK BITV-Test). Beide Durchläufe gehören in den Bericht, auch wenn nur einer von beiden zu einem Befund führt: Der zweite belegt, dass die Tastaturseite überhaupt betrachtet wurde. Die zugehörige Technik in den WCAG-Materialien beschreibt denselben Gedanken aus der Entwicklungsperspektive: Der zusätzliche Inhalt muss sichtbar bleiben, damit Nutzende Zeit haben, ihn zu lesen und mit ihm zu arbeiten, und der Zeiger muss über ihn geführt werden können (W3C).
Zwei Praxisfragen entscheiden über den Aufwand. Erstens: Was ist ein Prüffall? Geprüft wird typischerweise je Auslösertyp, nicht je Vorkommen. Eine Feldhilfe, die in vierzig Formularen dieselbe Komponente verwendet, ergibt einen Prüffall; verhält sich eine Variante anders, etwa der Werte-Tooltip im Diagramm gegenüber der Feldhilfe im Formular, zählt sie getrennt. Zweitens: Wohin gehört der Befund? In den Bericht gehört die Komponente, nicht die Seite, auf der sie zufällig zuerst auffiel. Wie aus einer solchen Befundliste ein belastbarer Plan wird, zeigt der Beitrag vom Prüfbericht zum Maßnahmenplan. Die Tastaturseite selbst ist ein eigenes Thema, das im Beitrag zur Tastaturnavigation in der Webentwicklung ausgeführt ist.
- Auslöser mit dem Zeiger ansteuern und die Einblendung abwarten. Erscheint sie nur nach Klick und bleibt danach stehen, liegt in der Regel kein Fall für dieses Kriterium vor.
- Zeiger stehen lassen und zwanzig Sekunden zusehen. Verschwindet der Inhalt von selbst, ist Bedingung drei verletzt.
- Escape drücken, ohne den Zeiger zu bewegen. Schließt sich nichts, den Auslöser erneut aktivieren; hilft auch das nicht, ist Bedingung eins verletzt, sofern keine Ausnahme greift.
- Einblendung erneut auslösen und den Zeiger auf direktem Weg in den Kasten führen. Verschwindet er unterwegs, ist Bedingung zwei verletzt.
- Prüfen, ob der eingeblendete Inhalt anderen Inhalt verdeckt oder ersetzt, und ob er einen Eingabefehler mitteilt. Das entscheidet über die Ausnahme zu Bedingung eins.
- Dieselbe Komponente mit der Tabulatortaste fokussieren und die Schritte zwei, drei und fünf wiederholen. Bedingung zwei bleibt hier außen vor.
- Ergebnis der Komponente zuordnen, den Auslösertyp benennen und beide Durchläufe im Bericht vermerken, auch den ohne Befund.
Warum der Scanner hier nichts meldet
Typische Fehlerbilder in Komponenten
Die WCAG-Materialien führen ein eigenes Fehlerbild zu diesem Kriterium. Es beschreibt die Lage, in der Nutzende den Zeiger nur schwer oder gar nicht über zusätzlichen Inhalt bewegen können, der bei Zeigerkontakt erscheint (W3C). In der Praxis entsteht diese Lage selten absichtlich. Sie entsteht durch einen Abstand von wenigen Pixeln zwischen Auslöser und Kasten, durch ein sofortiges Ausblenden beim Verlassen des Auslösers oder durch eine Positionierung, die den Kasten bei jeder kleinen Zeigerbewegung neu berechnet. Alle drei Ursachen liegen in der Komponente, nicht im Inhalt — und genau deshalb wiederholen sie sich über jede Seite, die die Komponente einsetzt. Ein barrierefreies Design-System ist an dieser Stelle die günstigste Reparatur, weil eine Korrektur alle Vorkommen erreicht.
Ein zweites Muster betrifft die Zustandsmeldung. Wird der Kasten sichtbar, ohne dass sich am Auslöser etwas ändert, erfährt unterstützende Technik davon nichts. Die Rolle „tooltip“ ist in WAI-ARIA als kontextbezogenes Aufklappen definiert, das eine Beschreibung zu einem Element anzeigt; Autoren sollen Elemente mit dieser Rolle über aria-describedby referenzieren, und zwar vor oder zu dem Zeitpunkt, an dem der Tooltip erscheint (W3C). Das Zusammenspiel von Rolle, Zustand und Meldung ist im Beitrag zu ARIA-Rollen, Zuständen und Live-Regionen beschrieben. Für Feldhilfen in Formularen kommt die Frage hinzu, ob der Text eine Hilfe oder eine Fehlermeldung ist; die Unterscheidung führt zu unterschiedlichen Anforderungen und ist im Beitrag zu barrierefreien Formularen und Validierung ausgeführt.
- Lücke zwischen Auslöser und Kasten: Der Zeiger verlässt beide Flächen und die Einblendung schließt, bevor sie erreicht ist. Abhilfe ist eine lückenlose Fläche oder eine kurze Nachlaufzeit vor dem Schließen.
- Zeitgeber statt Auslösebindung: Der Kasten blendet sich nach einigen Sekunden selbst aus. Das verletzt die Bedingung „beständig“, gleich wie großzügig die Frist bemessen ist.
- Fehlender Schließmechanismus: Weder Escape noch erneutes Aktivieren beendet die Einblendung, obwohl sie andere Inhalte verdeckt.
- Verdeckte Pflichtangabe: Der Kasten legt sich über das nächste Feld oder über eine Fehlermeldung. Das macht den Schließmechanismus zur Pflicht und stört zusätzlich die Bedienung mit Vergrößerung.
- Nur Maus: Die Einblendung reagiert auf mouseover, aber nicht auf Tastaturfokus. Das ist kein Befund unter 1.4.13, aber einer unter der Anforderung, ohne Maus nutzbar zu sein (BIK BITV-Test).
- Untermenü mit Sprungabstand: Der Weg vom Menüpunkt zum aufgeklappten Bereich führt über eine Fläche, die zu keinem von beiden gehört.
- Werte-Tooltip im Diagramm: Er folgt dem Zeiger und lässt sich deshalb nicht überfahren; hier hilft eine zusätzliche, ruhende Darstellung der Werte, etwa eine Tabelle unter dem Diagramm.
Ein Muster, das die drei Tore passiert
Ein tragfähiges Muster beginnt beim Auslöser. Ein Knopf ist tastaturbedienbar, trägt einen zugänglichen Namen und kann einen Zustand melden; ein Symbol ohne Rolle kann das alles nicht. Der eingeblendete Inhalt bekommt eine feste Kennung, wird über aria-describedby mit dem Feld verbunden und trägt die Rolle tooltip, die WAI-ARIA als kontextbezogene Anzeige einer Beschreibung definiert (W3C). Ein Hinweis zur Einordnung: Das Entwurfsmuster für Tooltips in den ARIA Authoring Practices trägt selbst den Vermerk, dass es sich um eine laufende Arbeit ohne Konsens der Arbeitsgruppe handelt (W3C). Es ist also eine Orientierung, keine Norm — die Norm sind die drei Bedingungen aus 1.4.13.
<div class="feldhilfe">
<label for="ustid">Umsatzsteuer-Identifikationsnummer</label>
<input id="ustid" name="ustid" type="text"
aria-describedby="ustid-hilfe" />
<!-- Auslöser: ein Knopf, kein Symbol ohne Rolle -->
<button type="button" class="feldhilfe__knopf"
aria-expanded="false" aria-controls="ustid-hilfe">
<span class="nur-fuer-sprachausgabe">Hinweis zum Format anzeigen</span>
<svg aria-hidden="true" focusable="false" width="16" height="16">
<use href="#symbol-hinweis" />
</svg>
</button>
<!-- Kein Abstand zum Knopf: der Zeiger kann hinüberwandern -->
<div id="ustid-hilfe" class="feldhilfe__kasten" role="tooltip" hidden>
Format: Länderkennzeichen und neun Ziffern, zum Beispiel DE123456789.
</div>
</div>Die Kennung ustid-hilfe verbindet zwei Dinge zugleich: Sie beschreibt das Eingabefeld dauerhaft über aria-describedby und benennt den Bereich, den der Knopf über aria-controls steuert. Der Klassenname feldhilfe__kasten trägt im Stylesheet die entscheidende Eigenschaft: Der Kasten liegt ohne Abstand am Knopf an, damit der Zeigerweg keine Lücke hat. Wo die Gestaltung einen sichtbaren Abstand verlangt, übernimmt eine unsichtbare, aber klickbare Brücke aus Innenabstand die Aufgabe. Die zweite Hälfte des Musters liegt im Verhalten.
const gruppe = document.querySelector(".feldhilfe");
const knopf = gruppe.querySelector(".feldhilfe__knopf");
const kasten = gruppe.querySelector("[role='tooltip']");
let zeigerImKasten = false;
const zeigen = () => {
kasten.hidden = false;
knopf.setAttribute("aria-expanded", "true");
};
const verbergen = () => {
if (zeigerImKasten) return;
kasten.hidden = true;
knopf.setAttribute("aria-expanded", "false");
};
// Bedingung 1: schließen, ohne Zeiger oder Fokus zu bewegen
document.addEventListener("keydown", (ereignis) => {
if (ereignis.key === "Escape" && !kasten.hidden) {
zeigerImKasten = false;
verbergen();
}
});
knopf.addEventListener("click", () => {
zeigerImKasten = false;
kasten.hidden ? zeigen() : verbergen();
});
// Bedingung 2: der Zeiger darf in den Kasten wandern
kasten.addEventListener("pointerenter", () => { zeigerImKasten = true; });
kasten.addEventListener("pointerleave", () => {
zeigerImKasten = false;
verbergen();
});
// Bedingung 3: kein Zeitgeber, der von selbst beendet
knopf.addEventListener("pointerenter", zeigen);
knopf.addEventListener("focus", zeigen);
knopf.addEventListener("pointerleave", () => {
window.setTimeout(verbergen, 0);
});
knopf.addEventListener("blur", () => {
zeigerImKasten = false;
verbergen();
});Drei Stellen tragen die drei Bedingungen: der Escape-Zweig und der Klick auf den Knopf das erste Tor, die beiden Zeigerereignisse am Kasten das zweite, das Fehlen jedes Zeitgebers das dritte. Der verzögerte Aufruf beim Verlassen des Knopfes ist kein Ausblendezeitgeber, sondern schiebt die Entscheidung um einen Durchlauf, damit das Eintreffen des Zeigers im Kasten zuerst registriert wird. Bleibt eine Aufgabe, die kein Code löst: Das Muster gehört einmal geprüft und dann in die Komponentenbibliothek, damit jede Feldhilfe im Haus dieselbe Bedienung hat. Wer sein Team darauf einnorden will, findet den Rahmen in unseren Schulungen; wer den Bestand messen lassen will, im WCAG-Audit. Verwandte Fragen zur Ausspielung zusätzlicher Inhalte behandelt der Beitrag zur Einbindung von DGS-Videos.
Quellen und Studien
Verwandte Artikel
Barrierefreie Terminbuchung: Kalender ohne Barrieren
Selbstgebaute Datepicker scheitern an Tastatur, Fokus und Zielgröße. So wird die Terminbuchung nach WCAG 2.2 für Screenreader- und Tastaturnutzer bedienbar.
forced-colors: Kontrastmodus richtig unterstützen
Was der erzwungene Kontrastmodus mit Ihrem Design macht, welche Eigenschaften wegfallen und wie Sie forced-colors, Systemfarben und Fokusstile sauber aufsetzen.
Barrierefreie Karten: Filialfinder ohne Sackgasse
Kartenmodule fallen im Audit regelmäßig durch. Wie eine Standortsuche ohne Maus, ohne Farbunterscheidung und mit Screenreader ans Ziel führt: Liste.