Identify Purpose
The purpose of a component has to be identifiable in the code, not only visible on screen. Purpose is not the same as role. Role says what a thing is, which is a button. Purpose says what it represents, which is the link to the home page. That difference is the whole criterion, and it means a control can carry a perfect accessible name and still not satisfy this rule.
Why it matters
The story behind this one is about people who communicate in symbols. Somebody who is non-vocal uses a device whose symbol set is their language, and those symbol sets are copyrighted and do not talk to each other, so the person is locked to one vendor's device and one vendor's content. Marking a component's purpose in code lets a user agent swap in the symbols that person already knows. Same page, their language. It also lets somebody strip a page down, hiding or highlighting regions by role so there is less to hold in mind at once.
Who this rule protects
People with cognitive and learning disabilities benefit most, and W3C names four kinds of need in particular. Memory, focus and attention, language, and executive function.
How to check it yourself
- Check that regions use landmark roles or native sectioning elements rather than plain divs.
- Ask of each icon and control whether the code says what it represents, not only what it is.
- Try hiding everything outside the main landmark, the way a simplifying user agent would, and see whether the page still works.
- Look for autocomplete values on personal-detail fields, which is the related rule at Level AA and the one that is enforceable today.
Failures we see most often
- Regions get built from plain divs with no landmark role, so nothing can hide or highlight them.
- A control's purpose is carried by its position on the page and by nothing in the markup.
- Icons are baked in with no way for a user agent to substitute a symbol set the reader actually knows.
Who this one is for
Read from this rule's own note above, so the grouping and the note cannot disagree.
- Cognitive and learningpeople for whom the difficulty is understanding, remembering, or staying with it
How to fix it
- Use native landmarks. Header, nav, main, aside and footer alone satisfy the only written technique this criterion has.
- Add WAI-Adapt purpose attributes where that vocabulary already covers what your control does.
- Add autocomplete values to personal-detail inputs, which meets the Level AA rule next door and moves you toward this one.
Step-by-step fix guides (1)
Passes vs. fails
Passes
The same toolbar sits inside a nav landmark, with each control's purpose stated in markup as well as drawn on screen.
Fails
A toolbar of glyph buttons sits in a plain div, so a user agent has nothing to hide, nothing to highlight, and no way to swap in symbols the reader knows.
In audits and lawsuits
This is Level AAA, and the criterion whose supporting vocabulary is still being written, which is why almost nobody has implemented it. The vocabulary is WAI-Adapt, not ARIA, and there is no ARIA attribute for component purpose. Only the Symbols Module has reached Candidate Recommendation so far, and the Content Module that would carry control-purpose terms is a Working Draft describing itself as draft ideas. Of the three sufficient techniques W3C lists, one is unnumbered prose, one is a placeholder marked as a future link, and only the landmarks technique is actually written. It covers regions. Landmarks cost nothing today, so put them in and you are ready for the rest when it lands.