Identify Purpose
Beyond form fields, the purpose of UI components, icons, and regions must be programmatically identifiable — so adaptive technologies can swap in symbols, simplify the page, or hide non-essential parts.
What it asks
Where 1.3.5 covers form inputs only, 1.3.6 extends the same idea to all UI components, icons, and regions. The intent is that an adaptive tool — a cognitive-support extension, a symbol-overlay app — can identify a “search” region, a “navigation” link, a “delete” button by its role and purpose, then substitute or hide it. The spec is intentionally forward-looking and underspecified.
How to meet it
- Use ARIA landmarks (
role="navigation",role="search",role="main") and HTML5 sectioning elements (<nav>,<main>,<search>) to identify regions. - For icon buttons, ensure the accessible name maps to a well-known purpose (“Search”, “Settings”, “Close”).
- Use
relattributes on links (rel="next",rel="prev",rel="author") to identify link purpose. - Use schema.org or microdata to declare entity types where adaptive tooling can consume them.
- Follow ARIA Authoring Practices Guide patterns so component roles are predictable.
Common failures
- Icon buttons named “Click here” or with no accessible name, no machine-readable purpose.
- Custom search widgets with no
role="search"landmark and no autocomplete token. - A pile of
<div>elements that visually form navigation but carry no landmark role. - Custom “delete” buttons that look distinct but are announced identically to “edit” or “view.”
Why it matters
AAA, and rarely required. The tooling ecosystem that would consume these signals is still maturing, so many teams treat 1.3.6 as aspirational. If you already meet 1.3.5 and use semantic HTML plus landmarks, you’re most of the way there.