WCAG 1.3.6: Identify Purpose
Personalization tools can replace buttons with familiar symbols, strip away distractions, and keep “search” looking identical on every site — but only if the markup tells them what each thing is for. This AAA criterion asks that the purpose of UI components, icons, and regions be programmatically determinable.
The success criterion, in full
In content implemented using markup languages, the purpose of User Interface Components, icons, and regions can be programmatically determined.
The scope is markup languages — HTML above all. Purpose must be readable by software, not merely inferable by a human looking at the pixels.
AAA context: from input fields to the whole interface
WCAG 2.1 introduced a pair of criteria about machine-readable purpose. At Level AA, 1.3.5 Identify Input Purpose covers one well-standardized slice: form fields that collect data about the user, solvable today with autocomplete tokens. 1.3.6 is the ambitious AAA generalization: every user interface component, icon, and region should expose its purpose.
It sits at AAA partly because the tooling is still evolving. Landmarks and accessible names are mature; a standardized vocabulary for “this button’s purpose is compose message” is the mission of the W3C’s WAI-Adapt specifications, which are not yet widely implemented. You can still make real progress today with semantics that already exist — and that progress is exactly what this criterion rewards.
Who this helps
People who use symbols to communicate
Users of AAC symbol sets can have tools overlay familiar symbols onto controls — but only when the control's purpose is exposed in the markup.
People with memory or attention limitations
Personalization agents can hide non-essential regions (promos, secondary nav) and surface only the functions the user needs, reducing cognitive load.
People who depend on consistency
When purpose is machine-readable, a user's tools can render 'search', 'home', and 'help' identically on every website, instead of each site's bespoke iconography.
Screen reader and switch users
Landmarks let users jump straight to navigation, search, or main content; well-named controls make scanning and voice control reliable.
The three targets: components, icons, regions
- User interface components — buttons, links, inputs, and widgets must expose what they do. Accessible names that state function ('Search', 'Add to cart'), correct roles, and autocomplete tokens on user-data fields all contribute.
- Icons — every meaningful icon needs a programmatic purpose, usually via its accessible name. Name the function, not the picture: 'Delete', not 'trash can'. Purely decorative icons should be hidden from the accessibility tree.
- Regions — each area of the page should declare its purpose through landmarks: banner, navigation, search, main, complementary, contentinfo. All content should live inside a landmark so software can filter or reorganize the page.
✓ Passes
- A page fully structured with landmarks; nothing floats outside them.
- Icon buttons whose accessible names state their function.
- User-data inputs carrying correct autocomplete tokens.
✗ Fails
- A div-only layout where no region declares any purpose.
- Icon-only controls with no accessible name, or names describing appearance.
- Purpose conveyed exclusively by position and visual styling.
Code examples
1. Regions: landmark every area of the page
<header> <!-- role: banner -->
<nav aria-label="Primary"> <!-- role: navigation -->
…
</nav>
<search> <!-- role: search (or role="search") -->
<form action="/search">…</form>
</search>
</header>
<main> <!-- role: main -->
<article>…</article>
<aside aria-label="Related links">…</aside> <!-- complementary -->
</main>
<footer>…</footer> <!-- role: contentinfo -->2. Components and icons: purpose in the accessible name
<!-- ✗ Icon-only, purpose locked in the pixels -->
<button><svg viewBox="0 0 24 24">…</svg></button>
<!-- ✓ Function exposed programmatically -->
<button aria-label="Search">
<svg viewBox="0 0 24 24" aria-hidden="true">…</svg>
</button>
<!-- ✓ Input purpose exposed with autocomplete (also 1.3.5) -->
<label for="email">Email address</label>
<input id="email" type="email" autocomplete="email" />
<label for="tel">Phone number</label>
<input id="tel" type="tel" autocomplete="tel" />3. Going further: WAI-Adapt personalization attributes
The W3C WAI-Adapt (Content Module) drafts define attributes that annotate elements with standardized purposes and symbol codes, letting user agents swap in each person’s own vocabulary. Support is experimental — treat it as progressive enhancement on top of the semantics above.
<!-- Draft WAI-Adapt syntax: standardized purpose + symbol code -->
<button type="submit" adapt-purpose="send">Send message</button>
<span adapt-symbol="13621">cup of tea</span>
<!-- Distraction marking lets tools simplify the page -->
<aside adapt-distraction="sensory">…autoplaying promo…</aside>How to test for 1.3.6
- 1
Map the landmarks
Use a screen reader's landmarks list or a browser extension (e.g. Accessibility Insights, the Landmarks extension) to view the region structure. Every visible area should belong to a landmark whose type matches its purpose, and repeated landmark types need distinguishing labels.
- 2
Walk the accessibility tree for controls and icons
In browser DevTools, inspect each interactive element. Confirm it has an accessible name that states its function, and that decorative graphics are hidden. An icon named after its appearance rather than its action is a finding.
- 3
Audit autocomplete tokens
For every field collecting the user's own data, verify a valid, correct autocomplete token is present (this is also the 1.3.5 test). Automated tools such as axe flag invalid tokens.
- 4
Try purpose-driven navigation
With a screen reader, jump by landmark and by form control. Ask at each stop: does the announced role, name, and region type tell me what this is for without looking at the screen?
- 5
Simulate a personalization pass
Thought experiment (or a real tool if you use one): could software reliably hide everything except navigation and main content, or replace every control with a symbol, using only your markup? Wherever the answer is no, purpose is not programmatically determinable.
Common failures
- Div-and-class layouts with no landmarks, so no region exposes any purpose to software.
- Icon-only buttons with no accessible name — the purpose exists only in the visual design.
- Accessible names that describe appearance ('hamburger', 'magnifying glass') instead of function ('menu', 'search').
- Missing or wrong autocomplete tokens on fields that collect the user's name, email, address, or phone.
- Multiple nav landmarks with no aria-label to distinguish primary navigation from breadcrumbs or footer links.
- Meaningful content left outside every landmark, where region-based filtering tools will lose it.
Frequently asked questions
What does WCAG 1.3.6 Identify Purpose require?
It requires that, in content implemented using markup languages, the purpose of user interface components, icons, and regions can be programmatically determined. In other words, machines — browsers, assistive technologies, personalization tools — must be able to work out not just what an element is (a button, a link) but what it is for (search, save, navigation, advertising). It is a Level AAA success criterion introduced in WCAG 2.1 alongside 1.3.5 Identify Input Purpose.
How is 1.3.6 different from 1.3.5 Identify Input Purpose?
1.3.5 (Level AA) is narrow: it applies only to input fields that collect information about the user, and it is satisfied by the HTML autocomplete attribute using its fixed token list (name, email, tel, and so on). 1.3.6 (Level AAA) generalizes the idea to the whole interface: buttons, links, icons, and page regions should all expose their purpose programmatically. Meeting 1.3.5 is a prerequisite step; 1.3.6 extends the same machine-readability to everything interactive plus regions and iconography.
Why does exposing purpose matter — who uses it?
The target beneficiaries are people with cognitive and learning disabilities who rely on personalization. When purposes are machine-readable, a browser extension or user agent can swap familiar symbols in for buttons (crucial for people who use AAC symbol sets), hide everything except the functions the user needs to reduce distraction, relabel controls with vocabulary the user knows, and keep the same icon for 'search' or 'home' identical across every site the user visits. None of that is possible when purpose lives only in visual design.
What concrete techniques satisfy 1.3.6 today?
Three layers: first, semantic HTML and ARIA landmarks — header, nav, main, aside, footer, role=search — so every region's purpose is exposed. Second, autocomplete tokens on user-data inputs, plus clear programmatic names on all controls and icons (aria-label, alt text) that state function rather than appearance. Third, where you want to go further, metadata vocabularies designed for personalization, such as the W3C WAI-Adapt (formerly 'personalization semantics') attributes, which can annotate elements with standardized purposes and symbol codes. WAI-Adapt is still maturing, so landmarks plus autocomplete plus good accessible names are the practical core.
Does every icon need special markup under 1.3.6?
Every meaningful icon needs a programmatically determinable purpose. Often that is simply a good accessible name: an SVG magnifier inside a button labelled 'Search' already exposes its purpose. Decorative icons should be hidden from the accessibility tree (aria-hidden="true" or empty alt) so they do not add noise. The failure case is an icon-only control with no accessible name, or one named after its appearance ('magnifying glass') instead of its function ('search').
Is 1.3.6 testable with automated tools?
Partially. Tools can verify that landmarks exist, that all content sits inside a landmark, that autocomplete tokens are valid, and that controls have accessible names. What they cannot judge is whether the exposed purpose is correct and complete — whether the region marked navigation really is navigation, or whether an icon's name states its function. That review is manual: walk the accessibility tree and ask, for each component, icon, and region, 'could software act on this purpose?'
Related Success Criteria
Information, structure, and relationships can be programmatically determined.
Content can be presented in a meaningful sequence without losing meaning.
Instructions don't rely solely on sensory characteristics of components.
Content does not restrict its view to a single display orientation.
The purpose of input fields can be programmatically determined.