Goal
Enable user agents and assistive technologies to identify the purpose of UI components, icons, and regions.
Success Criterion · WCAG 1.3.6
Identify Purpose
In content implemented using markup languages, the purpose of User Interface Components, icons, and regions can be programmatically determined.
Level AAAWCAG 2.1Perceivable1.3 · Adaptable
Copy button ready
What to do
Use semantic markup, ARIA landmarks, and standardized icons to identify the purpose of interface elements.
Why it matters
Users who rely on symbol-based communication or personalization tools need to understand UI purpose.
Success criterion
What WCAG 1.3.6 requires
Summarized directly from the official Understanding document so teams can quote the requirement accurately.
In content implemented using markup languages, the purpose of User Interface Components, icons, and regions can be programmatically determined.
Intent
Why WCAG created this requirement
- Users who rely on symbol-based communication (AAC devices) need UI purposes identified for symbol substitution.
- Personalization tools can adapt interfaces when they understand what each component does.
- This builds on 1.3.1 (Info and Relationships) and 1.3.5 (Identify Input Purpose) to cover all UI elements.
- Standard semantic markup and ARIA roles help tools identify purposes.
Benefits
Who gains when you pass
- Users who communicate via symbols can have icons replaced with familiar symbols from their communication system.
- Users with cognitive disabilities can have interfaces simplified or annotated based on component purposes.
- Users can apply consistent personalization across sites that properly identify purposes.
- Assistive technologies can provide better context about what components do.
- Users with learning disabilities can receive additional cues about interactive elements.
Why it matters
User impact when this criterion fails
Summaries drawn from the Understanding document help you socialize impact statements with product stakeholders.
Without purpose identification, personalization tools cannot adapt interfaces for users.
Symbol-based communication users cannot substitute familiar symbols for unknown icons.
Users who need simplified interfaces cannot have tools remove non-essential components.
Cognitive accessibility features cannot enhance components without purpose information.
Overview
The purpose of user interface components (buttons, links, inputs), icons, and page regions should be programmatically identifiable so that assistive technologies and personalization tools can present them in ways users understand. This Level AAA criterion enables tools to replace icons with familiar symbols, add labels, or otherwise adapt the interface based on user needs. It relies on semantic HTML, ARIA roles, and consistent patterns that tools can recognize and adapt.
- Use native HTML elements for their semantic meaning (button, nav, main, aside).
- Apply ARIA landmarks to identify page regions (role="banner", role="main", role="navigation").
- Use standardized icon patterns that tools can recognize (magnifying glass for search, etc.).
- Ensure icons have accessible names that describe their purpose.
- Follow common UI patterns that assistive technologies are designed to recognize.
Reference: All summaries and highlights originate from Understanding WCAG 1.3.6 and the W3C quick reference.
Fast facts
- Conformance level
- Level AAA
- WCAG version introduced
- WCAG 2.1
- Principle
- Perceivable
- Guideline
- 1.3 · Adaptable
Examples
Make success tangible for teams
Share pass/fail snapshots to coach designers, engineers, QA, and content authors.
Page regions
Pass
Page uses <header>, <nav>, <main>, <aside>, <footer> elements to identify regions, enabling tools to understand page structure.
Fail
Page uses only <div> elements with no semantic meaning, so tools cannot identify regions.
Icon button
Pass
A settings icon button has role="button" and aria-label="Settings", clearly identifying its purpose.
Fail
An icon button has no accessible name, so tools cannot identify or adapt it.
Search region
Pass
<search><input type="search" aria-label="Search products"><button>Search</button></search> with the HTML search element.
Fail
A search form in a plain div with no role, making it unidentifiable as search functionality.
Navigation
Pass
<nav aria-label="Main navigation">...</nav> clearly identifies this as a navigation region with a specific purpose.
Fail
Navigation links in a div with class="menu" but no semantic role or landmark.
Evidence to keep
Document conformance decisions
Capture artifacts for VPATs, procurement reviews, and regression testing.
- Document the landmark structure of page templates.
- Create an icon library with their purposes and accessible names.
- List UI components with their semantic roles and purposes.
- Include purpose identification requirements in component design specs.
Official resources
Deep dives and supporting material
Keep these links handy when writing acceptance criteria or responding to audits.
Understanding 1.3.6
Official W3C interpretation, techniques, and intent for Identify Purpose.
Quick Reference 1.3.6
Filterable list of sufficient techniques and failures.
ARIA Landmarks
ARIA Authoring Practices guide for implementing landmarks.
Technique ARIA11
Using ARIA landmarks to identify regions of a page.
WAI-Adapt: Symbols Module
W3C specification for symbol adaptation based on purpose identification.
Implementation checklist
Capture progress and blockers
- Use semantic HTML elements (nav, main, header, footer, aside, button, etc.).
- Apply ARIA landmark roles to all major page regions.
- Ensure all icons have accessible names that describe their purpose.
- Use consistent, recognizable icons for common actions (search, home, settings, etc.).
- Follow established UI patterns that assistive technologies recognize.
- Provide programmatic relationships between labels, descriptions, and controls.
- Test with personalization tools or ARIA validators to verify purposes are identifiable.
Testing ideas
Prove conformance with evidence
- Verify semantic HTML elements are used for their intended purposes.
- Check that all page regions have appropriate ARIA landmarks or HTML5 sectioning elements.
- Inspect icons to ensure they have accessible names describing their function.
- Test with screen readers to verify component purposes are announced.
- Use accessibility tree inspectors to verify roles, names, and purposes are exposed.
- Check that common actions use recognizable icons and patterns.
- Test with personalization tools if available to verify adaptation is possible.
Related success criteria