Glossary · Accessibility term

Role

A role is what kind of thing an element is, as reported to assistive technology. Button, link, heading, checkbox, navigation. The standard's own wording is that a role identifies the element's function, which is a better way to think about it, because putting role="button" on a <div> does not turn it into a button. It tells assistive technology what the author intends it to do. Native HTML carries one for free, so a <button> element is announced as a button with nobody declaring anything. A clickable <div> is the case people ask about, and it is not quite roleless. Its role is generic, which means a nameless container, and ARIA forbids you to name one of those, so an aria-label on a bare <div> is worse than useless. Give it a role first. Then the name sticks.

In practice

The vocabulary is not WCAG's, and knowing that saves an argument. WCAG requires a role to be programmatically determinable and deliberately declines to say which roles exist. So a finding that says you must use a particular role has to point at ARIA, or at whatever specification governs the technology in front of you, rather than at WCAG. ARIA 1.2 supplies 82 usable names in five groups. Widgets, document structure, landmarks, live regions and windows. It also carries twelve more that are abstract and that authors must not use in content, which is a trap, because role="widget" and role="select" read like real roles, are not allowed, and do nothing at all.

Declaring a role is a promise about behavior rather than a label. Saying role="button" tells a screen reader user this thing responds to Enter and Space, so you now owe it focusability and key handling or the announcement is a lie. Thirty-four roles in ARIA 1.2 go further and require an accessible name by their own definition, so a dialog or a region or an image with no name is incomplete before WCAG even looks at it. Check the specification for the role in front of you rather than a summary of it. A role is a contract, not an attribute.

Setting a role changes what the accessibility tree reports and changes nothing about what the element is or does in the browser, which is exactly why overriding one is so easy to do by accident. Put role="tab" on a heading and the heading stops being a heading to anybody navigating by headings, while the page looks identical. The attribute is an ordinary DOM attribute, so you can find it, style on it and test for it. It also takes a space-separated list, and what wins is the first token that names a real, non-abstract role allowed on that element, so a typo in the first name silently falls through to the second.

Why it matters

A wrong role is usually worse than no role, because it tells somebody confidently what to expect and then does not deliver it. It is also worth knowing which roles are worth your effort. Around a third of the screen reader users WebAIM surveyed say they use landmarks often. Fewer than one in twenty-five reaches for them first on a long page, against seven in ten who go straight to the headings. Landmarks earn their place. Headings are what those respondents actually start with, which is a good reason to spend a limited budget there first.

When you need one

A button built from a <div> needs role="button" on it for a name to be allowed at all, because a bare <div> is a nameless container that ARIA will not let you label. The order you type the two attributes in makes no difference. What matters is that the real role is there when the browser works the name out. A button built from a <button> element already has the role, already takes Enter and Space, and needs nothing from you but words inside it.

Where this shows up on the site

Related terms

Knowing the word is the easy part.

Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.

Run the free scan