Stop Giving Control Hints to Screen Readers

TL;DR: for standard HTML controls and standard ARIA patterns (widgets), you do not need to add instructions for screen readers on how to use them nor what they are.

When a screen reader encounters an element on the page that invites interaction beyond reading, it typically provides users with instructions how to consume or interact with it. As users get more familiar with the tools, they can skip some of those instructions or disable them altogether.

If in addition to these screen reader defaults you add instructions, then they may conflict, they may be redundant, they may not apply to the form factor, and they will be verbose. If you use aria-label, then they will not translate (excepting some Chrome users).

This also extends to telling users what a control is and, in some cases, telling a user its state. A checkbox with checked tells a user it is checked. A <button aria-pressed="true"> tells a user it is pressed.

Examples I have seen, heavily simplified:

<button aria-label="Click button to mark">[icon]</button>

<fieldset>
  <legend aria-label="Use arrow keys to choose one.">Choose one</legend>
  [… radio buttons …]
</fieldset>

<th aria-sort="ascending">
  Date<span class="visually-hidden">, sorted ascending</span>
</th>

<li role="presentation">
  <a href="#Reviews" role="tab" id="Tab1" onclick="[…]">
    Reviews<span class="visually-hidden"> Tab</span>
  </a>
</li>

When you are using native HTML for its intended purpose, a screen reader will give appropriate instructions. When you are using ARIA patterns (see widget roles) as defined (without folding in your own customizations), a screen reader will give appropriate instructions.

Similarly, avoid naming a specific pattern. Different browser and screen reader pairings can call the same control different things. For example, no user knows what a combobox is (nor do half the developers I speak to, interestingly), so probably do not use that word with users.

To simplify how confusing this can be:

• You say scroll, screen reader says swipe,
• You say sort button, screen reader says sort button button,
• You say press Enter, user is on a touch display,
• You say open combobox, user is a human.

All of this, of course, goes out the window once you start building custom patterns, modifying existing patterns, or rolling your own custom elements. Then you have to not only provide everything but potentially override the defaults.

It’s pretty cool what standard HTML gives you for free.

Code Examples

I put together a page with some of the more common patterns that I see turned into verbose gibberish, but I have excluded the gibberish. If you have a screen reader, play around with them yourself. Hint: you have a screen reader; there is one built into the device you are using right now.

Following this I have videos across some screen reader and browser combinations demonstrating how each is announced.

See the Pen Controls and Widgets by Adrian Roselli (@aardrian) on CodePen.

Videos

Using the example patterns above I recorded some basic interactions across seven screen reader and browser combinations. These are meant to demonstrate how each is announced by default. I am not just pressing the Tab key; in the tables I use table navigation commands, for example.

If you find you are getting different announcements on the example page, that may be a function of verbosity settings (I leave mine at defaults), a different screen reader version, a different browser version, or potentially browser plug-ins that manipulate the DOM.

You may see in the videos another section that I do not navigate and that is not in the sample above. I am saving that for a follow-up post after more testing.

Update: 2 March 2021

Russ Max has put together a resource that details how form elements are announced by screen readers: HTML test cases. There is a Git repo if you want to file or open issues too.

He provides plain text announcements of assorted controls using VoiceOver, NVDA, and JAWS, with the versions of each listed on the first page. He also has some extra test cases for accessible names and required fields.

For US readers, the dates are formatted as day/month/year. So if you look today, 01/03/2021 is not January 3^rd, but is March 1^st.