E1.16.2screen reader announces roledesignresearch

Screen readers speak link and button roles, not only the label

Aliases: role announcement · rotor · name plus role

What it is

A screen reader’s full utterance for a control is name + role (plus state): “Save, button,” “Profile, link.” Role chooses the next strategy: a link means prepare to navigate, maybe jump the links rotor; a button means prepare to activate, maybe hunt the button list. A correct label with a wrong or missing role is the right noun with the wrong verb. Speaking role separately is not polish. It is the premise of classed lookup.

Why it happens

Skilled reader users rarely listen linearly. They jump by role with rotors and shortcuts. If the role is group or text, the object drops out of the jump table even when the name says Save. Role button but actually navigates, and they will not use open-in-new-tab. Role link but actually submits, and they may save it for a later batch-open, submitting early. Two controls with the same name (“Next”) are told apart by role: navigate-next versus submit-next. Visible chrome cannot help this channel. Speech puts role after name, and people decide after hearing it, so a wrong role rewrites the decision.

Studying it

List all buttons and all links on the page in the reader; see whether the target sits in the right table. Then listen to the linear focused utterance. Compare correct role, missing role, reversed role.

Independent variables: DOM role, whether names collide, whether the person uses a rotor. Dependent variables: reaching the target by role-jump, whether the decision matches true consequences, time.

A sighted facilitator watching the screen will patch role with their eyes. Cover the screen, or have a blind user do the classed lookup.

Where it stops holding

Some readers let role speech be turned off; if a user did that, the name must be self-contained, but the product must not be built on “users hide role.” An icon-button name that already says “Save button” stacks into “Save button, button.” PDF readers’ role support is uneven; the same DOM assumptions do not travel.

Applying it

  • Make sure navigation appears in the link list and actions in the button list; do not only check that linear speech contains the words.
  • Do not put “button” or “link” in the name; leave role to the reader.
  • When the same copy is used in two roles, role must distinguish them, and both must be jumpable in tasks.
  • Verify with the rotor’s button list and link list. Save should be only among buttons, Profile only among links. Missing from both, or present in both, means roles were not spoken apart.

Related

  • Within the group: E1.16.1 Links activate with Enter; buttons respond to Enter and Space · E1.16.3 Open-in-new-tab in the context menu is meaningful only for links · E1.16.4 Visited state belongs to links; buttons have no visited concept
  • Adjacent: E1.08 Links versus buttons · J5.10 Name, role, and state · J5.01 Screen readers
  • Search terms: role announcement · screen reader rotor · name role state

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E1.16.2