Dies ist der 3. Beitrag in einer kleinen Serie, die wir zum Thema Formularzugänglichkeit erstellt haben. Wenn Sie den zweiten Beitrag verpasst haben, schauen Sie sich „Managing User Focus with :focus-visible“ an. In diesem Beitrag werden wir uns die Verwendung eines Screenreaders bei der Navigation durch ein Formular und einige Best Practices ansehen.
Hinweis der Redaktion: Im gesamten Artikel wurden Änderungen in Bezug auf einige Best Practices und Ergänzungen von Codebeispielen vorgenommen. Wenn Sie Ideen und Feedback haben, um diesen Beitrag zu erweitern, lassen Sie es uns bitte wissen!
Was ist ein Screenreader?
Sie haben vielleicht schon den Begriff „Screenreader“ gehört, während Sie sich im Web bewegt haben. Möglicherweise verwenden Sie gerade einen Screenreader, um manuelle Barrierefreiheitstests für die von Ihnen erstellten Erlebnisse durchzuführen. Ein Screenreader ist eine Art von AT oder assistive Technologie.
Ein Screenreader wandelt digitalen Text in synthetisierte Sprache oder Braille-Ausgabe um, wie sie häufig mit einem Braille-Lesegerät zu sehen ist.
In diesem Beispiel werde ich Mac VO verwenden. Mac VO (VoiceOver) ist in allen Mac-Geräten integriert; iOS, iPadOS und macOS. Je nach Gerätetyp, auf dem macOS läuft, kann das Öffnen von VO unterschiedlich sein. Das Macbook Pro, auf dem ich dies schreibe und das VO ausführt, hat keine Touch Bar, daher werde ich die Tastenkombinationen gemäß der Hardware verwenden.
VO auf macOS starten
Wenn Sie ein aktuelles Macbook Pro verwenden, sieht die Tastatur Ihres Geräts ungefähr so aus wie auf dem folgenden Bild.
Sie halten zuerst die cmd-Taste gedrückt und drücken dann dreimal schnell auf Touch ID.

Wenn Sie ein MBP (MacBook Pro) mit Touch Bar haben, verwenden Sie die Tastenkombination cmd+fn+f5, um VO einzuschalten. Wenn Sie eine herkömmliche Tastatur mit Ihrem Desktop oder Laptop verwenden, sind die Tasten gleich, oder Sie müssen VO in den Bedienungshilfen-Einstellungen aktivieren. Sobald VO eingeschaltet ist, werden Sie mit diesem Dialog und einer gesprochenen Einführung in VO begrüßt.

Wenn Sie auf die Schaltfläche „VoiceOver verwenden“ klicken, sind Sie auf dem besten Weg, VO zum Testen Ihrer Websites und Apps zu verwenden. Eine Sache, die Sie beachten sollten, ist, dass VO für die Verwendung mit Safari optimiert ist. Stellen Sie daher sicher, dass Safari der Browser ist, den Sie verwenden, wenn Sie Ihren Screenreader-Test durchführen. Das gilt auch für das iPhone und iPad.
Es gibt zwei Hauptmöglichkeiten, VO von Anfang an zu nutzen. Ich persönlich navigiere zu einer Website und verwende eine Kombination aus den tab, control, option, shift- und Pfeiltasten, um mich effizient durch die Benutzeroberfläche zu bewegen. Mit diesen Tasten allein kann ich die Benutzeroberfläche effizient navigieren.
Eine weitere gängige Methode zur Navigation ist die Verwendung des VoiceOver-Rotors. Der Rotor ist eine Funktion, die dazu dient, direkt zu der Stelle zu navigieren, an die Sie in der Anwendung gelangen möchten. Durch die Verwendung des Rotors vermeiden Sie es, sich durch die gesamte Website zu bewegen. Betrachten Sie es als ein „Wählen Sie Ihr eigenes Abenteuer“.
Modifikatortasten
Modifikatortasten sind die Art und Weise, wie Sie die verschiedenen Funktionen in VO verwenden. Die Standard-Modifikatortaste oder VO ist control + option, aber Sie können sie in die Feststelltaste ändern oder beide Optionen auswählen, um sie austauschbar zu verwenden.

Verwendung des Rotors
Um den Rotor zu verwenden, müssen Sie eine Kombination aus Ihren Modifikatortasten und dem Buchstaben „U“ verwenden. Bei mir ist die Modifikatortaste caps lock. Ich drücke caps lock + U, und der Rotor wird für mich gestartet. Sobald der Rotor erscheint, kann ich mit den linken und rechten Pfeiltasten zu jedem beliebigen Teil der Anwendung navigieren.

Navigation nach Überschriftenebene
Eine weitere nützliche Navigationsmöglichkeit ist die nach Überschriftenebene. Wenn Sie die Tastenkombination aus Ihren Modifikatortasten + cmd + H verwenden, können Sie die Dokumentenstruktur basierend auf den Überschriftenebenen durchlaufen. Sie können auch nach oben im Dokument navigieren, indem Sie shift in der Sequenz drücken, wie folgt: Modifikatortasten + shift + cmd + H.
Geschichte & Best Practices
Formulare sind eines der mächtigsten nativen Elemente, die wir in HTML haben. Egal, ob Sie auf einer Seite nach etwas suchen, ein Formular absenden, um etwas zu kaufen, oder eine Umfrage einreichen. Formulare sind ein Eckpfeiler des Webs und waren ein Katalysator, der Interaktivität in unsere Erlebnisse brachte.
Die Geschichte des Webformulars reicht bis in den September 1995 zurück, als es in der HTML 2.0 Spezifikation eingeführt wurde. Manche sagen, die guten alten Tage des Webs, zumindest sage ich das. Stephanie Stimac schrieb einen großartigen Artikel auf Smashing Magazine mit dem Titel „Standardizing Select And Beyond: The Past, Present And Future Of Native HTML Form Controls“.
Meiner Meinung nach sind die folgenden Punkte einige Best Practices, die bei der Erstellung eines barrierefreien Formulars für das Web befolgt werden sollten.
- Implizites Labeln ist zu 100 % in Ordnung. Schauen Sie sich den Artikel https://www.w3.org/WAI/tutorials/forms/labels/ an. Wenn der Formularautor die ID nicht kennt, kann sie implizit beschriftet werden. Ich persönlich bevorzuge die explizite Methode.
<!-- Implicit Label -->
<label>
First Name:
<input type="text" name="firstname">
</label>
<!-- Explicit Label -->
<label for="name">Name:</label>
<input type="text" id="name" name="name" required/>
- Wenn ein Feld erforderlich ist, damit das Formular vollständig ist, verwenden Sie das Attribut
required. Stellen Sie sicher, dass es auch eine visuelle Anzeige gibt, dass ein Feld erforderlich ist, denn auch Benutzer ohne Screenreader müssen wissen, dass ein Feld erforderlich ist.
<input type="text" id="name" name="name" required />
- Ein
buttonwird verwendet, um eine Aktion auszulösen, z. B. das Absenden eines Formulars. Verwenden Sie ihn! Erstellen Sie keine Schaltflächen mitdivs. Eindivist ein Container ohne eigene semantische Bedeutung.
Demo
Wenn Sie den Code ansehen möchten, navigieren Sie zum VoiceOver Demo GitHub Repo. Wenn Sie die obige Demo mit Ihrem bevorzugten Screenreader ausprobieren möchten, schauen Sie sich Webformular mit VoiceOver navigieren an.
Screenreader-Software
Nachfolgend finden Sie eine Liste verschiedener Arten von Screenreader-Software, die Sie auf Ihrem Betriebssystem verwenden können. Wenn ein Mac nicht Ihre bevorzugte Wahl ist, gibt es Optionen für Windows und Linux sowie für Android-Geräte.
NVDA
NVDA ist ein Screenreader von NV Access. Er wird derzeit nur auf PCs mit Microsoft Windows 7 SP1 und höher unterstützt. Für mehr Zugriff schauen Sie sich die Download-Seite für die NVDA-Version 2024.1 auf der Website von NV Access an!
JAWS
„Wir brauchen einen besseren Screenreader“
— Anonym
Wenn Sie die obige Anspielung verstanden haben, sind Sie in guter Gesellschaft. Laut der JAWS-Website ist dies im Wesentlichen die Beschreibung:
„JAWS, Job Access With Speech, ist der weltweit beliebteste Screenreader, der für Computernutzer entwickelt wurde, deren Sehverlust sie daran hindert, Bildschirminhalte zu sehen oder mit einer Maus zu navigieren. JAWS bietet Sprach- und Braille-Ausgabe für die beliebtesten Computeranwendungen auf Ihrem PC. Sie können das Internet navigieren, ein Dokument schreiben, eine E-Mail lesen und Präsentationen von Ihrem Büro, Remote-Desktop oder von zu Hause aus erstellen.“
— JAWS Website
Probieren Sie JAWS selbst aus und wenn diese Lösung Ihren Bedürfnissen entspricht, probieren Sie sie auf jeden Fall aus!
Narrator
Narrator ist eine integrierte Screenreader-Lösung, die mit Windows 11 ausgeliefert wird. Wenn Sie diese als Ihren bevorzugten Screenreader verwenden möchten, finden Sie unter dem folgenden Link Unterstützung für die Dokumentation zur Verwendung.
Umfassende Anleitung zu Narrator
Orca
Orca ist ein Screenreader, der auf verschiedenen Linux-Distributionen mit GNOME verwendet werden kann.
„Orca ist ein kostenloser, quelloffener, flexibler und erweiterbarer Screenreader, der über Sprache und aktualisierbare Braille-Ausgabe Zugriff auf den grafischen Desktop bietet.
— Orca Website
Orca funktioniert mit Anwendungen und Toolkits, die die Assistive Technology Service Provider Interface (AT-SPI) unterstützen, welche die primäre Infrastruktur für assistive Technologien unter Linux und Solaris ist. Zu den Anwendungen und Toolkits, die AT-SPI unterstützen, gehören das GNOME Gtk+ Toolkit, das Swing Toolkit der Java-Plattform, LibreOffice, Gecko und WebKitGtk. Die AT-SPI-Unterstützung für das KDE Qt Toolkit wird angestrebt.“
TalkBack
Google TalkBack ist der Screenreader, der auf Android-Geräten verwendet wird. Weitere Informationen zum Aktivieren und Verwenden finden Sie in diesem Artikel auf der Android Accessibility Support Site.
Browser-Unterstützung
Wenn Sie nach tatsächlicher Browserunterstützung für HTML-Elemente und ARIA-Attribute (Accessible Rich Internet Application) suchen, empfehle ich caniuse.com für HTML und Accessibility Support für ARIA, um die neuesten Informationen zur Browserunterstützung zu erhalten. Denken Sie daran, wenn der Browser die Technologie nicht unterstützt, wird der Screenreader es wahrscheinlich auch nicht tun.
DigitalA11Y kann Browser- und Screenreader-Informationen mit seinem Artikel „Screen Readers and Browsers! Which is the Best Combination for Accessibility Testing?“ zusammenfassen.
Danke!
Vielen Dank an Adrian Roselli, Karl Groves, Todd Libby, Scott O’Hara, Kev Bonnett und andere für Klarstellungen und Feedback!
Links
- https://support.apple.com/guide/voiceover/with-the-voiceover-rotor-mchlp2719/mac
- https://www.w3.org/TR/wai-aria/
- https://www.w3.org/WAI/standards-guidelines/aria/
- https://support.google.com/accessibility/android/answer/6283677?hl=en
- https://support.google.com/accessibility/android/answer/6283677?hl=en
- https://css-tricks.de/html-inputs-and-labels-a-love-story
- https://tink.uk/understanding-screen-reader-interaction-modes
- https://www.tpgi.com/required-attribute-requirements/

Ich dachte, die aktuelle Empfehlung sei, dass man
aria-requirednicht verwenden sollte, wenn manrequiredverwendet? Also entweder das eine oder das andere, aber nicht beides?Die Verwendung von
requiredist der richtige Weg. Ich entschuldige mich für die Verwirrung. Der Beitrag wurde aktualisiert.Ich glaube, es gibt keinen Bedarf, beides zu verwenden, soweit ich weiß. Die Unterstützung durch Screenreader ist für natives
requiredsehr gut.Wenn Sie googeln, gibt es im Laufe der Jahre viele (widersprüchliche) Ratschläge.
Ich persönlich bevorzuge die Verwendung von
requiredfür die native HTML5-Validierung und verbessere dann progressiv mit JS ... deaktiviere die native Validierung mit dem Attributnovalidateund nutze die Constraint Validation API, um Fehlermeldungen beim Absenden des Formulars bereitzustellen.Beispiel hier – https://basher.github.io/Web-UI-Boilerplate/?path=/docs/web-components-or-custom-elements-webui-form-validate–docs
Vielen Dank für das Feedback, Kev. Der Beitrag wurde aktualisiert.
Ja, das sollten Sie nicht tun.
aria-requiredist nur für nicht-semantisches Markup nützlich. Bei einem Input ist es völlig überflüssig. Das Attributrequiredliefert bereits die notwendigen Informationen für assistive Technologien.<input aria-required>tut hier tatsächlich nichts.Es müsste
<input aria-required="true">seinARIA-Attribute sind Strings, keine typischen Booleans.
Die Empfehlung ist auch falsch. Screenreader wie VoiceOver können korrekt vorlesen, dass ein Formularelement erforderlich ist, indem sie einfach das Attribut
requiredangeben. Ich habe es gerade getestet. Es liest es einwandfrei vor.Aus dem MDN-Artikel zu „aria-required“
<
Im Grunde ist
aria-required="true"für nicht-semantische Elemente gedacht. Z.B.:<div role="checkbox" aria-required="true">https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-required
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-required
Leser sollten bedenken, dass VoiceOver auf macOS laut der WebAIM-Umfrage 2024 unter 10 % der Desktop-Screenreader-Nutzer ausmacht. Idealerweise sollten Sie zuerst mit JAWS und NVDA testen.
Zu den 5 Best-Practice-Aussagen...
Wie ist das
<form>-Element standardmäßig zugänglicher? Bietet seine Verwendung spezifische Vorteile für Screenreader-Benutzer?Ist
for/idirgendwie besser als das Umwickeln des Textes in<label>?Leser sollten Required attribute requirements besuchen, um
requiredundaria-requiredbesser zu verstehen.Ich verstehe nicht, wie diese Fokusstile insbesondere für Screenreader-Benutzer von Vorteil sind (was der Umfang dieses Artikels ist). Wir wissen, dass nicht alle Screenreader-Benutzer blind sind, aber schlagen Sie vor, dass diese Benutzer zusätzliche Vorteile davon haben?
Per Definition ist das
<div>-Element kein Trennzeichen. Sie denken vielleicht an<hr>. Was Screenreader betrifft, und wie sie über Plattform-Accessibility-APIs kommuniziert werden, ist das<div> ein generisches Element.Danke für das Feedback, Adrian. Das
form-Element gibt einem Screenreader Kontext, dass es sich um ein Formular handelt, deshalb verwende ich es im Beispiel. Die Fokusstile sind da, weil ich sie bereits behandelt habe. Ich wollte sie nur allgemein zeigen. Eindivist eine Unterteilung innerhalb der Seite, „Trenner“ war vielleicht das falsche Wort.Laut Required attribute requirements wird das Attribut
requiredein Formularelement für Screenreader-Benutzer als „erforderlich“ ankündigen.Auch die im Artikel verlinkte MDN-Seite besagt, dass
aria-required„verwendet werden sollte, wenn Formularsteuerelemente mit nicht-semantischen Elementen erstellt werden“. Andernfalls wird das Attributrequiredbevorzugt. (Siehe auch die Beispiele auf dieser Seite.)Haben Sie irgendwelche Ressourcen/Tests, die Ihre Behauptung unterstützen, dass beides zusammen verwendet werden kann (oder sogar sollte, wie dieser Artikel impliziert)?
Ich denke, wir hätten die Tags
fieldsetundlegendfür die Gruppierung der Checkboxen unter „Toppings“ und der Radiobuttons unter „Sauce“ in Betracht ziehen sollen, was semantischer und zugänglicher ist.Siehe Beispiele #2 und #3 in diesem Artikel –
https://www.w3.org/TR/WCAG20-TECHS/H71.html