This is the 3rd post in a small series we did on form accessibility. If you missed the second post, check out “Managing User Focus with :focus-visible
“. In this post we are going to look at using a screen reader when navigating a form, and also some best practices.
Editor’s Note: Edits were made throughout in regard to some of the best practices and code sample additions. If you have ideas and feedback to build on this post, please let us know!
What is a Screen Reader?
You may have heard the term “screen reader” as you have been moving around the web. You might even be using a screen reader at this moment to run manual accessibility tests on the experiences you are building. A screen reader is a type of AT or assistive technology.
A screen reader converts digital text into synthesized speech or Braille output, commonly seen with a Braille reader.
In this example, I will be using Mac VO. Mac VO (VoiceOver) is built-in to all Mac devices; iOS, iPadOS, and macOS systems. Depending on the type of device you are running macOS on, opening VO could differ. The Macbook Pro that is running VO I am writing this on doesn’t have the touch bar, so I will be using the shortcut keys according to the hardware.
Spinning Up VO on macOS
If you are using an updated Macbook Pro, the keyboard on your machine will look something like the image below.
You will start by holding down the cmd
key and then pressing the Touch ID three times quickly.
![MacBook Pro Keyboard with steps on how to start mac voiceover.](png/mbp-keyboardccdc.png)
If you are on a MBP (MacBook Pro) with a TouchBar, you will use the shortcut cmd+fn+f5
to turn on VO. If you are using a traditional keyboard with your desktop or laptop, the keys should be the same or you will have to toggle VO on in the Accessibility settings.. Once VO is turned on, you will be greeted with this dialog along with a vocalized introduction to VO.
![Welcome to VoiceOver dialog when opening up voiceover.](png/welcome-to-vo9059.png)
If you click the “Use VoiceOver” button you are well on your way to using VO to test your websites and apps. One thing to keep in mind is that VO is optimized for use with Safari. That being said, make sure when you are running your screen reader test that Safari is the browser you are using. That goes for the iPhone and iPad as well.
There are two main ways you can use VO from the start. The way I personally use it is by navigating to a website and using a combination of the tab, control, option, shift
and arrow keys, I can navigate through the experience efficiently with these keys alone.
Another common way to navigate the experience is by using the VoiceOver Rotor. The Rotor is a feature designed to navigate directly to where you want to be in the experience. By using the Rotor, you eliminate having to traverse through the whole site, think of it as a “Choose Your Own Adventure”.
Modifier Keys
Modifier keys are the way you use the different features in VO. The default modifier key or VO
is control
+ option
but you can change it to caps lock or choose both options to use interchangeably.
![VoiceOver utility to change the modifier keys.](png/vo-mod-keys18e7.png)
Using the Rotor
In order to use the Rotor you have to use a combination of your modifier key(s) and the letter “U”. For me, my modifier key is caps lock
. I press caps lock
+ U
and the Rotor spins up for me. Once the Rotor comes up I can navigate to any part of the experience that I want using the left and right arrows.
![VoiceOver rotor feature showing the Headings navigation.](png/rotor-headingseb45.png)
Navigating By Heading Level
Another neat way to navigate the experience is by heading level. If you use the combination of your modifier keys + cmd
+ H
you can traverse the document structure based on heading levels. You can also move back up the document by pressing shift
in the sequence like so, modifier keys + shift
+ cmd
+ H
.
History & Best Practices
Forms are one of the most powerful native elements we have in HTML. Whether you are searching for something on a page, submitting a form to purchase something or submit a survey. Forms are a cornerstone of the web, and were a catalyst that introduced interactivity to our experiences.
The history of the web form dates back to September 1995 when it was introduced in the HTML 2.0 spec. Some say the good ole days of the web, at least I say that. Stephanie Stimac wrote an awesome article on Smashing Magazine titled, “Standardizing Select And Beyond: The Past, Present And Future Of Native HTML Form Controls”.
In my opinion, the following are some best practices to follow when building an accessible form for the web.
- Labelling implicitly is 100% ok to do. Check out the https://www.w3.org/WAI/tutorials/forms/labels/ article. If the form author is unaware of the id, it can be labeled implicitly. I personally prefer the explicit way.
<!-- 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/>
- If a field is required in order for the form to be complete, use the required attribute. Be sure to have a visual indication that a field is required, too, because non-screenreader users need to know a field is required as well.
<input type="text" id="name" name="name" required />
- A
button
is used to invoke an action, like submitting a form. Use it! Don’t create buttons usingdiv
’s. Adiv
is a container without semantic meaning by itself.
Demo
If you want to check out the code, navigate to the VoiceOver Demo GitHub repo. If you want to try out the demo above with your screen reader of choice, check out Navigating a Web Form with VoiceOver.
Screen Reader Software
Below is a list of various types of screen reader software you can use on your given operating system. If a Mac is not your machine of choice, there are options out there for Windows and Linux, as well as for Android devices.
NVDA
NVDA is a screen reader from NV Access. It is currently only supported on PC’s running Microsoft Windows 7 SP1 and later. For more access, check out the NVDA version 2024.1 download page on the NV Access website!
JAWS
“We need a better screen reader”
— Anonymous
If you understood the reference above, you are in good company. According to the JAWS website, this is what it is in a nutshell:
“JAWS, Job Access With Speech, is the world’s most popular screen reader, developed for computer users whose vision loss prevents them from seeing screen content or navigating with a mouse. JAWS provides speech and Braille output for the most popular computer applications on your PC. You will be able to navigate the Internet, write a document, read an email and create presentations from your office, remote desktop, or from home.”
— JAWS website
Check out JAWS for yourself and if that solution fits your needs, definitely give it a shot!
Narrator
Narrator is a built-in screen reader solution that ships with WIndows 11. If you choose to use this as your screen reader of choice, the link below is for support documentation on its usage.
Orca
Orca is a screen reader that can be used on different Linux distributions running GNOME.
“Orca is a free, open source, flexible, and extensible screen reader that provides access to the graphical desktop via speech and refreshable braille.
— Orca Website
Orca works with applications and toolkits that support the Assistive Technology Service Provider Interface (AT-SPI), which is the primary assistive technology infrastructure for Linux and Solaris. Applications and toolkits supporting the AT-SPI include the GNOME Gtk+ toolkit, the Java platform’s Swing toolkit, LibreOffice, Gecko, and WebKitGtk. AT-SPI support for the KDE Qt toolkit is being pursued.”
TalkBack
Google TalkBack is the screen reader that is used on Android devices. For more information on turning it on and using it, check out this article on the Android Accessibility Support Site.
Browser Support
If you are looking for actual browser support for HTML elements and ARIA (Accessible Rich Internet Application) attributes, I suggest caniuse.com for HTML and Accessibility Support for ARIA to get the latest 4-1-1 on browser support. Remember, if the browser doesn’t support the tech, chances are the screen reader won’t either.
DigitalA11Y can help summarize browser and screen reader info with their article, Screen Readers and Browsers! Which is the Best Combination for Accessibility Testing?
Thanks!
Thanks to Adrian Roselli, Karl Groves, Todd Libby, Scott O’Hara, Kev Bonnett, and others for clarifications and 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.com/html-inputs-and-labels-a-love-story
- https://tink.uk/understanding-screen-reader-interaction-modes
- https://www.tpgi.com/required-attribute-requirements
I thought the current advice was that you shouldn’t use
aria-required
if you’re usingrequired
? I.e., one or the other but not both?Using
required
is the way to go. I apologize for the confusion. The post has been updated.There’s certainly no need to use both, as far as I know. Screen reader support is very good for native
required
.If you google, there’s been lots of (conflicting) advice over the years.
I personally prefer to use
required
to provide native HTML5 validation, then progressively enhance with JS… turning off native validation with thenovalidate
attribute, and leveraging the Constraint Validation API to provide error feedback on form submit.Example here – https://basher.github.io/Web-UI-Boilerplate/?path=/docs/web-components-or-custom-elements-webui-form-validate–docs
Thanks for the feedback Kev. The post has been updated.
Yeah you shouldn’t, aria-required is only useful for non semantic markup. It’s completely superfluous on an input. The required attribute already provided the necessary information for assistive tech.
<input aria-required>
actually does nothing here.It would need to be
<input aria-required="true">
aria attributes are strings, not typical booleans.
The advice is also wrong. Screenreaders like VoiceOver are able to correctly read out that a form element is required just by providing the
required
attribute. I tested it just now. It reads it just fine.From the MDN article on “aria-required”:
<
div> with a role of checkbox, the aria-required attribute should be included, with a value of true, to indicate to assistive technologies that user input is required on the element for the form to be submittable. The aria-required attribute can be used with HTML form elements; it is not limited to elements that have an ARIA role assigned.
Basically,
aria-required="true"
is intended for non-semantic elements. IE:<div role="checkbox" aria-required="true">
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-required
Readers should bear in mind that VoiceOver on macOS makes up under 10% of desktop screen reader users (per 2024 WebAIM survey). Ideally, start testing in JAWS and NVDA first.
As for the 5 best practice assertions…
How is the
<form>
element more accessible by default? Does using it provide some specific benefit for screen readers?Is
for
/id
somehow better than wrapping the text in the<label>
?Readers should visit Required attribute requirements to better understand
required
andaria-required
.I don’t understand how these focus styles benefit screen reader users in particular (which is the scope of this article). We know not all screen reader users are blind, but are you suggesting those users have an additional benefit from these?
By definition, the
<div>
element is not a divider. You may be thinking of<hr>
. As far as screen readers are concerned, and as conveyed via platform accessibility APIs, the<div>
is a generic element.Thanks for the feedback Adrian. The
form
element does provide context to a screen reader that it is a form, that is why I am using it in the example. The focus styles are there because I covered them previously. I just wanted to show them in general. Adiv
is a division within the page, divider may have been the wrong word.According to Required attribute requirements, the
required
attribute will announce a form element as “required” to screen reader users.Also the MDN page linked in the article says that
aria-required
should be used “when form controls are created using non-semantic elements”. Otherwise therequired
attribute is preferred. (See also the examples on that page.)Do you have any ressources/tests that support your claim that both can (or even should, as this article implies) be used in conjunction?