Users should be able to understand the purpose of controls, icons, and regions, not just what they are. In WCAG 1.3.6, purpose refers to the intended function of a user interface component (for example, search, login, checkout, or navigation), expressed in a way that software can recognise.
When the purpose of interface components is programmatically identifiable, assistive technologies and personalisation tools can adapt the interface in ways that are more familiar, predictable, and cognitively supportive for users.
WCAG Success Criterion
This requirement corresponds to Success Criterion 1.3.6 Identify Purpose (Level AAA).
In markup-based content, the purpose of user interface components, icons, and regions must be programmatically identifiable.
This criterion goes beyond identifying an element’s role (such as “button” or “link”) or its label. It focuses on identifying why the component exists and what it is meant to do.
What “Purpose” Means in Practice
In WCAG 1.3.6, purpose is distinct from role and name:
- Role: what the element is (button, link, region)
- Name/label: what the element is called (“Search”, “Menu”)
- Purpose: what the element is for (searching content, navigating home, checking out)
Purpose identification allows software, not just humans, to recognise common interface patterns and adapt them for users who need cognitive support or personalisation.
What Proper Purpose Identification Looks Like
Purpose is identified correctly when:
- Common controls, icons, and regions expose semantic information about why they exist
- User agents or personalisation tools can extract that purpose programmatically
- Users can substitute vocabulary, symbols, or layouts that are meaningful to them
This enables scenarios such as:
- Replacing unfamiliar icons with a user’s preferred symbol set
- Simplifying navigation by highlighting key regions
- Reducing cognitive load by hiding or reordering non-essential controls
Why This Matters
Some users, particularly users with cognitive and learning disabilities, may not understand a control’s purpose from its visible label, wording, or icon alone.
When purpose information is available programmatically:
- Interfaces can adapt to users instead of forcing users to adapt to interfaces
- Familiar symbols and terminology can be reused across different websites
- Cognitive effort is reduced when navigating complex or unfamiliar layouts
This success criterion is about interoperability: enabling consistent understanding across tools, platforms, and experiences.
Examples (Conceptual)
Example 1: Regions
A page identifies its main content region programmatically. A user agent allows the user to focus only on that region, reducing distraction.
Example 2: Navigation Controls
Navigation controls expose their purpose (for example, “search” or “home”). A personalisation tool replaces default icons with the user’s preferred icon set.
Example 3: Symbol-Based Interfaces
Interface icons expose purpose metadata so users who rely on symbol-based communication can substitute their own familiar symbols across websites.
What Actually Works Today (Important Context)
Success Criterion 1.3.6 is AAA and represents an aspirational goal. Real-world support is currently limited.
In practice:
- ARIA landmarks help identify page regions, but they primarily support structure, not full purpose identification
- ARIA labels and roles are necessary but not sufficient to meet 1.3.6
- Microdata and personalisation vocabularies referenced by WCAG are not widely supported by mainstream browsers or assistive technologies
- Many “personalisation tools” described in WCAG documentation are research-level or experimental
This does not make the criterion invalid, but it does mean implementation should be approached with realistic expectations.
Common Techniques (Normative and Advisory)
Techniques associated with this criterion include:
- Programmatically indicating the purpose of common UI components and regions
- Using ARIA landmarks to identify structural regions (for example, navigation, main content)
- Applying recognised metadata vocabularies referenced in WCAG Techniques
Labels, roles, and ARIA attributes alone do not fully satisfy this criterion unless they expose purpose in a way that software can reliably interpret.
What Does Not Count
The following do not satisfy Success Criterion 1.3.6 on their own:
- Visual styling or icon shape alone
- Human-readable labels without programmatic purpose metadata
- Generic ARIA roles without purpose semantics
- Placeholder text used instead of meaningful markup
These approaches may help usability, but they do not make the purpose programmatically identifiable.
Who Is Affected
This success criterion primarily benefits:
- Users with cognitive and learning disabilities
- Users who rely on personalised iconography or simplified interfaces
- Users who need reduced cognitive load and predictable interaction patterns
The Algorithm
- Identify user interface components, icons, and regions
- Determine their intended purpose (not just role or label)
- Add markup or metadata that allows software to recognise that purpose
- Verify that assistive technologies or personalisation tools can extract it
- If the purpose cannot be determined programmatically, the criterion fails
Wrapping Up
Identify Purpose (Level AAA) is about enabling interfaces to adapt to users’ cognitive needs through programmatic meaning. While tooling support is still limited, the criterion defines an important direction for inclusive design, one where familiar symbols, simplified navigation, and personalised interaction become possible across the web.
This is an aspirational requirement, but understanding it helps teams design interfaces that are clearer, more predictable, and better aligned with cognitive accessibility needs.
