WCAG 3.3.5: Hilfe

Was diese Regel bedeutet

\n

Das WCAG-Erfolgskriterium 3.3.5 Hilfe (Level AAA) besagt: „Kontextsensitive Hilfe ist verfügbar.“ Das bedeutet, dass überall dort, wo eine Webseite oder Anwendung Nutzer auffordert, Informationen einzugeben, geeignete Hilfe bereitgestellt werden muss, um zu verdeutlichen, was erwartet wird. Die Hilfe muss kontextbezogen sein – das heißt, sie muss sich direkt auf das Feld, die Aufgabe oder den Prozess beziehen, mit dem der Nutzer gerade beschäftigt ist, und darf nicht nur eine allgemeine Hilfeseite sein, die irgendwo in der Navigation versteckt ist.

\n

Das Kriterium gilt für jede Benutzeroberflächenkomponente, die eine Eingabe erfordert: Textfelder, Dropdown-Menüs, Datumsauswahlfelder, Steuerelemente zum Hochladen von Dateien, Kontrollkästchen, Optionsfelder und mehrstufige Formulare. Kontextsensitive Hilfe kann viele Formen annehmen, darunter Inline-Anweisungen, beschreibende Beschriftungen, Platzhalterhinweise, Tooltips, Hilfesymbole, die Erklärungen einblenden, Links zu relevanten Hilfeartikeln oder sogar Live-Chat-Support – solange die Hilfe in der Nähe der Eingabe verfügbar ist, die sie erfordert.

\n

Ein Bestanden wird erreicht, wenn mindestens eines der folgenden Elemente für jede Eingabe vorhanden ist, die zu Verwirrung führen könnte: eine klar formulierte Beschriftung, die die erwartete Eingabe vollständig erklärt; ergänzender beschreibender Text direkt neben dem Feld (nicht nur ein Platzhalter, der beim Tippen verschwindet); ein sichtbarer Hilfelink oder ein erweiterbarer Tooltip, der weitere Erklärungen bietet; oder ein leicht zugänglicher Hilfemechanismus (wie ein Fragezeichen-Symbol), der eine auf den aktuellen Kontext bezogene Anleitung einblendet. Die Hilfe muss nicht für alle Felder identisch sein – die zentrale Anforderung ist, dass überall dort, wo ein Nutzer unsicher sein könnte, was einzugeben ist, tatsächlich Hilfe verfügbar und zugänglich ist.

\n

Ein Nicht bestanden liegt vor, wenn Felder keine Erklärung dazu bieten, was erwartet wird, wenn Hilfe erst nach dem Absenden und einem Fehler verfügbar ist, wenn Tooltips oder Hilfetexte für Tastatur- oder Screenreader-Nutzer unzugänglich sind oder wenn Hilfelinks zu einer allgemeinen FAQ-Seite führen, statt zu Inhalten, die für die konkrete Eingabe relevant sind. Entscheidend ist: Sich ausschließlich auf Fehlermeldungen im Nachhinein zu verlassen, erfüllt dieses Kriterium nicht – Hilfe muss vor oder während der Eingabe verfügbar sein, nicht nur nachdem ein Fehler gemacht wurde.

\n

WCAG 3.3.5 definiert keine strikt vorgegebene Implementierungsmethode. Es wird anerkannt, dass kontextsensitive Hilfe auf viele gültige Arten umgesetzt werden kann, was Entwicklern Flexibilität gibt, aber die Absicht ist eindeutig: Nutzer sollten nie raten müssen, was ein Formularfeld erwartet. Es gibt keine offiziellen Ausnahmen von diesem Kriterium – es gilt überall dort, wo Benutzereingaben angefordert werden.

\n\n

Warum es wichtig ist

\n

Formulare gehören zu den anspruchsvollsten Teilen jeder digitalen Oberfläche. Für Nutzer mit kognitiven Beeinträchtigungen – einschließlich Menschen mit Dyslexie, Aufmerksamkeitsstörungen, intellektuellen Beeinträchtigungen oder Gedächtnisproblemen – können unklare Formularfelder eine unüberwindbare Barriere darstellen. Ohne klare, kontextbezogene Hilfe können diese Nutzer wiederholt daran scheitern, Aufgaben abzuschließen, erhebliche Frustration erleben oder den Prozess ganz abbrechen. Laut Weltgesundheitsorganisation lebt weltweit etwa 1 von 6 Menschen mit einer Form einer erheblichen Behinderung, und kognitive Beeinträchtigungen machen einen wesentlichen Teil dieser Bevölkerung aus.

\n

Nutzer mit geringer digitaler Kompetenz oder begrenzter Erfahrung mit Weboberflächen profitieren ebenfalls enorm von kontextsensitiver Hilfe. Ein Erstnutzer eines E‑Government-Portals, eine ältere Person, die online eine Gesundheitsleistung beantragt, oder eine Kleinunternehmerin, die ein Steuerformular ausfüllt, wissen möglicherweise nicht, welches Format für eine Steueridentifikationsnummer erwartet wird, welche Dateitypen für das Hochladen von Dokumenten akzeptiert werden oder worin der Unterschied zwischen zwei ähnlich benannten Feldern besteht. Ohne kontextbezogene Anleitung sind diese Nutzer anfällig für Fehler und die Unsicherheit, nicht zu wissen, was sie falsch gemacht haben.

\n

Betrachten wir ein konkretes Szenario: Eine Nutzerin mit kognitiver Beeinträchtigung beantragt über das Webportal einer kommunalen Verkehrsbetriebe einen subventionierten Fahrausweis. Das Formular fragt nach einer „Referenznummer“ ohne weitere Erklärung. Die Nutzerin hat mehrere Dokumente – ihren Personalausweis, ihre Fahrkarte und eine frühere Antragsbestätigung – jeweils mit unterschiedlichen numerischen Kennungen. Ohne kontextsensitive Hilfe, die angibt, welches konkrete Dokument oder welches Format erwartet wird, wird sie wahrscheinlich die falsche Nummer eingeben, eine Validierungsfehlermeldung auslösen und möglicherweise aufgeben. Wäre ein einfaches Hilfesymbol oder eine Inline-Beschreibung vorhanden gewesen – „Geben Sie die 10-stellige Nummer in der oberen rechten Ecke Ihrer Fahrkarte ein“ – wäre die gesamte Interaktion beim ersten Versuch erfolgreich gewesen.

\n

Für Nutzer, die blind sind oder eine Sehbehinderung haben, ist kontextsensitive Hilfe ebenfalls wichtig. Screenreader können zugeordnete Hilfetexte, aria-describedby-Beschreibungen oder verlinkte Hilfsinhalte ausgeben, aber nur, wenn diese korrekt implementiert sind. Wenn Hilfe ausschließlich visuell vermittelt wird (etwa als Farbindikator oder Symbol ohne zugänglichen Text), werden Screenreader-Nutzer ausgeschlossen. Sicherzustellen, dass Hilfe sowohl vorhanden als auch zugänglich ist, stärkt die Inklusion über verschiedene Behinderungsgruppen hinweg.

\n

Über die Barrierefreiheit hinaus verbessert kontextsensitive Hilfe die allgemeine Benutzerfreundlichkeit und Konversionsraten. Websites mit klarer Formularführung verzeichnen geringere Abbruchraten, weniger Supportanfragen und höhere Formularabschlussquoten. Insbesondere für E‑Commerce‑Sites hat jeder Prozentpunkt Verbesserung bei der Checkout-Abschlussrate direkte Auswirkungen auf den Umsatz. Suchmaschinen belohnen außerdem Seiten mit klaren, strukturierten Inhalten, und gut beschriftete, gut beschriebene Formulare tragen positiv zu Qualitätssignalen einer Seite bei.

\n\n

Verwandte Axe-core-Regeln

\n

WCAG 3.3.5 erfordert manuelle Tests, da die Konformität von der Qualität, Relevanz und kontextuellen Angemessenheit der Hilfsinhalte abhängt – Faktoren, die automatisierte Tools nicht bewerten können. Ein automatischer Scanner kann bestätigen, dass eine Beschriftung existiert oder dass ein aria-describedby-Attribut auf ein reales Element verweist, aber er kann nicht feststellen, ob der Inhalt dieser Beschriftung oder Beschreibung tatsächlich hilfreich, korrekt oder für eine bestimmte Eingabe ausreichend ist.

\n

\n
• Manuelle Prüfung – Vorhandensein kontextsensitiver Hilfe: Automatisierte Tools können nicht beurteilen, ob Hilfetext die voraussichtlichen Fragen des Nutzers zu einem bestimmten Feld wirklich beantwortet. Ein Tool kann erkennen, dass ein <label>-Element existiert, aber nicht beurteilen, ob „Geben Sie Ihre Nummer ein“ für ein Feld, das eine formatierte USt‑IdNr. erwartet, ausreichend beschreibend ist. Manuelle Tester müssen bewerten, ob jede Eingabe, die Verwirrung stiften könnte, von einer Anleitung begleitet wird, die diese Verwirrung spürbar reduziert.
\n
• Manuelle Prüfung – Zugänglichkeit der Hilfe: Selbst wenn Hilfe visuell vorhanden ist, erkennen automatisierte Tools möglicherweise nicht, wenn diese Hilfe für unterstützende Technologien unzugänglich ist. Ein Tooltip, der nur bei Maus-Hover ausgelöst wird und kein tastaturzugängliches Pendant hat, besteht viele automatisierte Prüfungen, scheitert aber bei echten Nutzern. Tester müssen sicherstellen, dass alle Hilfemechanismen – Tooltips, ausklappbare Bereiche, Hilfelinks – per Tastatur erreichbar und bedienbar sind und von Screenreadern korrekt ausgegeben werden.
\n
• Manuelle Prüfung – Platzierung und Nähe der Hilfe: Automatisierte Scans können nicht bewerten, ob Hilfetext nah genug am relevanten Feld platziert ist, um sinnvoll damit verknüpft zu sein. Ein Hilfetext am unteren Seitenrand oder in einem Modal, das mehrere Interaktionen erfordert, mag technisch existieren, verfehlt aber den Sinn kontextsensitiver Hilfe. Die manuelle Prüfung muss bestätigen, dass Hilfe am Punkt des Bedarfs verfügbar ist.
\n
• Manuelle Prüfung – Vollständigkeit bei komplexen Formularen: Komplexe, mehrstufige Formulare bringen zusätzliche Herausforderungen mit sich. Automatisierte Tools prüfen einzelne Felder isoliert, können aber nicht beurteilen, ob die kumulative Hilfe über einen mehrstufigen Assistenten hinweg ausreicht, um einen Nutzer durch einen komplexen Prozess zu führen. Manuelle Durchläufe sind notwendig, um Lücken in der Anleitung zu identifizieren, die erst sichtbar werden, wenn man das Formular als Ganzes erlebt.
\n

\n\n

Wie man testet

\n

\n
1. Führen Sie einen automatisierten Barrierefreiheitsscan als Ausgangspunkt durch. Verwenden Sie axe DevTools (Browser-Erweiterung oder CLI), Lighthouse in den Chrome DevTools oder den IBM Equal Access Checker auf der Seite, die das Formular enthält. Diese Tools werden zwar keine Verstöße gegen 3.3.5 direkt kennzeichnen, aber sie machen verwandte Probleme sichtbar, wie fehlende Beschriftungen (label-Element nicht mit einer Eingabe verknüpft), fehlende aria-describedby-Ziele oder unzugängliche Tooltip-Implementierungen. Wenn diese grundlegenden Probleme zuerst behoben werden, ist sichergestellt, dass kontextsensitive Hilfe, sobald sie hinzugefügt wird, auch technisch zugänglich ist.
\n
2. Prüfen Sie jedes Formularfeld manuell auf verfügbare Hilfe. Fragen Sie sich für jedes Eingabefeld: (a) Erklärt die Beschriftung allein vollständig, welche Eingabe erforderlich ist, einschließlich etwaiger Formatvorgaben? (b) Gibt es ergänzenden Hilfetext, der sichtbar direkt neben dem Feld steht? (c) Gibt es ein Hilfesymbol, einen Tooltip oder einen ausklappbaren Bereich, der weitere Hinweise bietet? (d) Gibt es einen Link zu relevanten Hilfsinhalten? Wenn die Antwort auf all dies nein ist und das Feld irgendeine Mehrdeutigkeit aufweist, liegt ein Verstoß gegen 3.3.5 vor.
\n
3. Testen Sie die Tastaturzugänglichkeit aller Hilfemechanismen. Navigieren Sie mit der Tabulatortaste durch das Formular, ausschließlich mit der Tastatur (ohne Maus). Vergewissern Sie sich, dass jeder Tooltip, jedes Hilfesymbol, jede ausklappbare Beschreibung oder jeder Hilfelink per Tastatur erreichbar und aktivierbar ist. Tooltips sollten bei Fokus ebenso erscheinen wie bei Hover. Hilfeschaltflächen sollten mit Enter oder Leertaste ausgelöst werden. Jeder Hilfemechanismus, der nur mit der Maus erreichbar ist, fällt bei diesem Test durch.
\n
4. Testen Sie mit NVDA + Firefox. Navigieren Sie mit Tab zu jedem Formularfeld. Hören Sie, was NVDA für jedes Feld ausgibt – wird die Beschriftung angesagt? Wird eine zugehörige Beschreibung (über aria-describedby) angesagt? Aktivieren Sie Hilfesymbole oder Tooltips und prüfen Sie, ob deren Inhalt ausgegeben wird. Versuchen Sie, verlinkte Hilfsinhalte zu erreichen, und vergewissern Sie sich, dass sie sich auf das aktuelle Feld beziehen.
\n
5. Testen Sie mit VoiceOver + Safari (macOS oder iOS). Verwenden Sie VoiceOver, um durch das Formular zu navigieren. Unter macOS nutzen Sie Tab, um zwischen Feldern zu wechseln, und hören Sie sich die vollständige Ausgabe für jedes Feld an. Unter iOS verwenden Sie Wischgesten zur Navigation. Stellen Sie sicher, dass alle mit Eingaben verknüpften Hilfsinhalte vorgelesen werden und dass Hilfsauslöser (Schaltflächen, Links) zugänglich und von VoiceOver korrekt beschriftet sind.
\n
6. Testen Sie mit JAWS + Chrome. Verwenden Sie den JAWS-Formularmodus (aktivieren Sie ihn mit Enter, wenn Sie sich auf einem Formularelement befinden). Navigieren Sie mit Tab zwischen den Feldern und prüfen Sie, ob JAWS zugehörige Anweisungen und Beschreibungen vorliest. Nutzen Sie den virtuellen Cursor von JAWS, um sicherzustellen, dass Hilfsinhalte, die außerhalb der Standard-Label-Verknüpfungen platziert sind, ebenfalls erreichbar sind.
\n
7. Führen Sie einen kognitiven Walkthrough durch. Bitten Sie eine Person, die mit dem Formular nicht vertraut ist (oder simulieren Sie dies, indem Sie das Formular nach einer Pause erneut prüfen), zu versuchen, es ohne externe Hilfe auszufüllen. Notieren Sie jeden Punkt, an dem sie zögert, eine Frage stellt oder aufgrund unklarer Erwartungen einen Fehler macht. Jeder dieser Punkte ist ein Kandidat für verbesserte kontextsensitive Hilfe im Sinne von 3.3.5.
\n

\n\n

Wie man es behebt

\n

Mehrdeutiges Textfeld ohne Erklärung – Falsch

\n

<!-- No help provided for an ambiguous field expecting a specific format -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input type='text' id='tc-kimlik' name='tc-kimlik'>

\n

Mehrdeutiges Textfeld mit Inline-Hilfe – Richtig

\n

<!-- Inline description associated via aria-describedby gives format guidance before the user types -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input\n  type='text'\n  id='tc-kimlik'\n  name='tc-kimlik'\n  aria-describedby='tc-kimlik-help'\n  autocomplete='off'\n  maxlength='11'\n>\n<p id='tc-kimlik-help'>\n  Nüfus cüzdanınızda yer alan 11 haneli TC Kimlik Numaranızı giriniz.\n  (Enter your 11-digit Turkish National ID number as shown on your ID card.)\n</p>

\n\n

Hilfesymbol-Tooltip für Tastaturnutzer unzugänglich – Falsch

\n

<!-- Tooltip only shown on mouseover; keyboard users and screen reader users cannot access it -->\n<label for='iban'>IBAN <span class='help-icon' title='What is IBAN?'>?</span></label>\n<input type='text' id='iban' name='iban'>

\n

Hilfesymbol-Tooltip für alle Nutzer zugänglich – Richtig

\n

<!-- Button with aria-expanded controls a help panel; accessible via keyboard and screen readers -->\n<label for='iban'>IBAN</label>\n<button\n  type='button'\n  aria-expanded='false'\n  aria-controls='iban-help'\n  class='help-toggle'\n  aria-label='Help: What is an IBAN?'\n>\n  ?\n</button>\n<input type='text' id='iban' name='iban' aria-describedby='iban-help'>\n<div id='iban-help' hidden>\n  <p>\n    IBAN (International Bank Account Number) is a 26-character code starting\n    with "TR" used to identify your Turkish bank account. You can find it\n    in your bank's mobile app under Account Details.\n  </p>\n</div>\n<!-- JavaScript toggles aria-expanded and the hidden attribute on button click/keypress -->

\n\n

Komplexes mehrstufiges Formular ohne schrittweise Anleitung – Falsch

\n

<!-- Step 2 of a 4-step application with no explanation of what documents are needed -->\n<h2>Step 2: Upload Documents</h2>\n<label for='doc-upload'>Upload File</label>\n<input type='file' id='doc-upload' name='doc-upload'>

\n

Komplexes mehrstufiges Formular mit kontextueller Schritt-Hilfe – Richtig

\n\n

(Content truncated due to token limit — please retry this article.)