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

Sailesh Panchang

By 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

Test your custom elements and trust the results with Axe-core’s support for ElementInternals

Wilco Fiers 400 × 400 1 300 × 300
August 27, 2026 By Wilco Fiers

If you're a large enterprise organization with accessibility issues resulting from interoperability challenges, moving to ElementInternals is a savvy move. You can standardize, and safely test. And, with Axe-core now supporting ElementInternals, you can test those components and trust the results.

Artikel lesen
A testing flow, depicting a single custom button scanned by Axe-core for React, Angular or Vue frameworks

Deque and Microsoft: Two decades of shaping the future of accessibility

cropped preety kumar400x400 300x300 1 1.jpg
August 25, 2026 By Preety Kumar

What started nearly two decades ago as conversations between two people passionate about improving accessibility across Microsoft's digital experiences has grown into a lasting partnership built on shared learning, mutual respect, and a common belief that accessibility should be built into every stage of software development.

Artikel lesen
Preety Kumar and Jenny Lay-Flurrie conducting an interview, with the Seattle skyline in the background.