Aria-required=true: Einhaltung der WCAG 2 im Vergleich zu bewährten Verfahren

Sailesh Panchang

Von Sailesh Panchang

5. Dezember 2013

Rollstuhl mit nach vorne zeigenden Pfeilen auf blauem HintergrundDa das Attribut „aria-required“ von gängigen Kombinationen aus Browsern und assistiven Technologien unterstützt wird, halten viele seine Verwendung für die einfachste und beste Methode, um anzugeben, dass die Eingabe in ein Feld erforderlich ist. Aus Sicht der strikten Einhaltung der WCAG 2-Richtlinien ist die Empfehlung seiner Verwendung jedoch möglicherweise nicht ganz so eindeutig.

Eine barrierefreie Kennzeichnung, dass die Eingabe in ein Feld erforderlich ist, ist nur dann erforderlich, wenn für das Feld ein entsprechender visueller Hinweis vorhanden ist. Mit anderen Worten: Wenn kein visueller Hinweis auf Pflichtfelder vorhanden ist, finden die WCAG 2 keine Anwendung. Die anwendbaren Erfolgskriterien der Stufe A sind SC 1.3.1 und SC 3.3.2.

Betrachten wir die folgenden vier Fälle:

Fall 1:

Ein Textsymbol (wie ein Sternchen) oder ein Text, der darauf hinweist, dass eine Eingabe erforderlich ist, kann programmgesteuert mit dem Feld verknüpft werden – entweder mithilfe des „label“-Elements (oder „legend“ für eine Gruppe zusammenhängender Steuerelemente), eines „title“-Attributs (wenn kein „label“ vorhanden ist) oder des „aria-labelledby“-Attributs, wenn dieses zur Beschriftung des Steuerelements herangezogen wird.

Ist dies der Fall, sind aus Sicht der WCAG 2-Konformität keine zusätzlichen Maßnahmen erforderlich.

In diesen Fällen bewirkt die Verwendung von „aria-required=true“ Folgendes:

– Trägt dazu bei, die Eigenschaft „required“ zu verstärken, wenn ein Sternchen oder ein anderes Textsymbol verwendet wird … Die Verwendung von „aria-required“ ist optional und kann von Vorteil sein.

– Dies führt zu einer Doppelung, wenn das Wort „required“ bereits mit dem Steuerelement verknüpft ist. Daher wird von der Verwendung von „aria-required“ abgeraten.

Fall 2:

Ein Textsymbol (z. B. ein Sternchen) oder ein Text, der darauf hinweist, dass eine Eingabe erforderlich ist, ist vorhanden, jedoch nicht programmgesteuert mit dem Feld verknüpft.

In dieser Situation könnte man das Symbol oder den Text entweder programmgesteuert als Teil der Feldbezeichnung mit dem Feld verknüpfen. Dies könnte sinnvoll sein, wenn auch der Beschriftungstext für das Feld nicht mit dem Feld verknüpft ist.

Alternativ könnte man „aria-required=true“ verwenden, um anzugeben, dass die Eingabe erforderlich ist, um die WCAG 2 einzuhalten.

Fall 3:

Dass eine Eingabe erforderlich ist, wird ausschließlich durch die Farbe, die Schriftart oder ein nicht-textuelles Symbol (einschließlich CSS) vermittelt.

In dieser Situation wird die Einstellung „aria-required=true“ sicherlich einigen Nutzern helfen, die auf ARIA-fähige Benutzeragenten – also assistive Technologien – angewiesen sind.

Sich allein auf Farben oder visuelle Gestaltungselemente zu verlassen, um erforderliche Eigenschaften zu kennzeichnen, hilft Nutzern nicht, die aufgrund einer Sehbehinderung keine Unterschiede in Farbe oder Gestaltung erkennen können und normalerweise keine assistive Technologie benötigen.

Tatsächlich sollte die alleinige Verwendung von Farb- oder Stilunterschieden zur Kennzeichnung von Pflichtfeldern als Verstoß gegen die WCAG 2 gelten, genauso wie die Verwendung von CSS-Bildern für wesentliche Inhalte (Technik F3).

Fall 4:

Manchmal steht vor (oder hinter) einem Formular der Hinweis, dass alle Felder ausgefüllt werden müssen, sofern sie nicht als optional gekennzeichnet sind. Dies kann eine effiziente Methode sein, um Pflichtfelder zu kennzeichnen, wenn nur ein kleiner Teil der Felder optional ist. Der Text „optional“ ist programmgesteuert mit den Feldern verknüpft, für die keine Eingabe erforderlich ist.

In dieser Situation ist die Verwendung von „aria-required=true“ für die Einhaltung der WCAG 2 nicht erforderlich. Wird es verwendet, könnten einige Nutzer dies als hilfreich empfinden, andere hingegen nicht. Das hängt vom jeweiligen Kontext ab.

Wenn das Wort „optional“ nicht mit den nicht obligatorischen Feldern verknüpft ist, besteht die Lösung darin, entweder diese Verknüpfung herzustellen oder bei den Feldern, die eine Eingabe erfordern, das Attribut „aria-required=true“ zu verwenden.

 

 

Fazit:

Hoffentlich hilft das oben Gesagte Autoren dabei, zu entscheiden, wann es einfacher ist, die Technik H90 (Verwendung des „label“- bzw. „legend“-Elements zur Kennzeichnung von Pflichtfeldern) oder „aria-required=true“ zu verwenden, um die WCAG 2 einzuhalten.

Zugegebenermaßen lassen sich Fehler bei der Eingabevalidierung minimieren, wenn Pflichtfelder deutlich gekennzeichnet sind. Dies ist jedoch eine Frage der Funktionalität und Benutzerfreundlichkeit, die vom Autor der Inhalte zu berücksichtigen ist. Zudem ist die Einhaltung von SC 3.3.1 Stufe A (Fehleranzeige) und SC 3.3.3 Stufe AA (Fehlerbehebung) weniger aufwendig, wenn es weniger Eingabefehler gibt. Diese SC befassen sich jedoch nicht mit der ordnungsgemäßen Kennzeichnung von Pflichtfeldern.

 

Quellenangaben:

Sailesh Panchang ist leitender Berater für Barrierefreiheit bei Deque Systems

 

Sailesh Panchang

Sailesh Panchang

Als einer der ersten Mitarbeiter von Dequeverfügt Sailesh über umfassende Erfahrung in der Durchführung von Barrierefreiheitsprüfungen für Webinhalte und Software unter Verwendung einer Kombination aus automatisierten und manuellen Testverfahren, einschließlich Code-Reviews. Darüber hinaus unterstützt er die Kunden von Deque dabei, den Einstieg zu finden und die Tools von Dequeeffektiv zu nutzen. Sailesh verfügt über umfassende Kenntnisse in der Anwendung von Barrierefreiheitstechniken für HTML und WAI-ARIA zur Einhaltung von Section 508, den WCAG und Gesetzen wie dem Air Carrier Access Act (ACAA). Sailesh nutzt selbst assistive Technologien und ist auf Bildschirmleseprogramme wie JAWS, NVDA, VoiceOver und TalkBack angewiesen.

Erhalten Sie Blog-Beiträge direkt in Ihren Posteingang

Kein Geschwafel, sondern echte Erkenntnisse zum Thema Barrierefreiheit von qualifizierten Experten.

Sie erklären sich damit einverstanden, dass Deque Informationen gemäß den Bestimmungen in DequeDatenschutzerklärungbeschrieben, Informationen von Deque entgegennimmt, nutzt und weitergibt. Sie können Ihre Einwilligung jederzeit widerrufen, indem Sie uns kontaktieren.

Mehr zu diesem Thema

Damit Ihr Unternehmen im Zeitalter der agentenbasierten KI erfolgreich sein kann, sollten Sie Barrierefreiheit als grundlegenden Bestandteil Ihrer KI-Strategie betrachten.

Preety Kumar 100 x 150
29. Juli 2026 Von Preety Kumar

Barrierefreiheit muss bereits von der ersten Eingabe an in die Art und Weise integriert werden, wie KI Code schreibt – sie darf nicht erst im Nachhinein behoben werden. Und da die Behindertengemeinschaft seit Jahrzehnten die Mensch-Computer-Interaktion für verschiedene Eingabe- und Ausgabemodalitäten perfektioniert, ist ihr Fachwissen nicht nur moralisch wichtig, sondern auch technisch unverzichtbar für die Entwicklung einer robusten, zuverlässigen KI, die tatsächlich funktioniert.

Artikel lesen
Abbildung im Stil eines Flussdiagramms, die den Barrierefreiheitsbaum und dessen Einfluss auf die menschenzentrierte und die KI-Agenten-zentrierte Barrierefreiheit veranschaulicht.

Warum digitale Barrierefreiheit für HSBC eine strategische Priorität ist

Logo von Deque
28. Juli 2026 Von Deque Systems

Mali Fernando, Leiterin des Bereichs „Digital Experience and Accessibility“ bei HSBC, erläutert die Rolle der digitalen Barrierefreiheit bei der Schaffung besserer Bankerlebnisse, der Stärkung der Kundenbeziehungen und der Förderung des langfristigen Geschäftserfolgs.

Artikel lesen
HSBC-Logo