Role decides what operations a user will expect
Aliases: ARIA role · widget role · control role
What it is
Hear “button,” and the hand goes to press; hear “heading,” and the hand uses it as an index. Role is the contract assistive technology uses to say what kind of thing this is. Once announced, the user operates it by that kind’s conventions. Role is a classification of expected operations, not of appearance.
Why it happens
Each role is bound to a set of actions the user already knows: a button activates, a checkbox toggles and has on/off, a link navigates away, a tab swaps a panel, a heading is for jumping rather than “clicking.” The reader puts the role in the utterance, and the user picks the next command from that, instead of probing whether the pixels look clickable.
A wrong contract is performed with the wrong script. A row of tab-looking labels announced as plain text gets skipped while the user hunts for a real control; announced as buttons, they try to activate and get no panel change. Role decides which keys or gestures will be tried, not how the control is drawn.
Studying it
Build the same visual widget three ways in the tree: correct role, no role, wrong role. Ask experienced reader users to select / expand / switch, and watch whether the first command is that role’s convention.
Independent variables: whether a role is declared, whether the role matches actual behavior. Dependent variables: whether the first command hits the intended operation, number of attempts, whether the object is skipped as static text.
Do not ask “what do you think this is.” Ask “what did you press, and what did you expect to happen.”
Where it stops holding
For mouse users who never touch AT, role never enters the decision — they read appearance and the cursor. Novel roles, or roles the platform has not mapped, collapse to “group” or “text” and the contract fails. A correct role with no response when operated is behavior lagging the contract; “the user doesn’t know the role” is not an excuse.
Applying it
- Give every operable object a role that matches what it actually does: pressable is a button, checkable is a checkbox, navigable is a link.
- Do not put a widget role on display-only text, and do not let a real control appear in the tree as unnamed text.
- How to check: listen to the type the reader announces, then operate once by that type’s convention. Announced as a button but not activatable, or announced as text but pressable, means the contract is broken.