WCAG 1.3.6 Identify Purpose: Why This AAA Criterion Matters for Cognitive Accessibility

"Some people with cognitive disabilities may not understand a control's purpose from the name alone." That single sentence from the W3C Understanding document for 1.3.6 (opens in new window) explains why this criterion exists — and why dismissing it as "just AAA" misses the point entirely.

WCAG 1.3.6 sits at Level AAA, which means it's not a legal floor for most organizations. But the population it serves — people who rely on augmentative and alternative communication (AAC) devices, symbol-based interfaces, and personalization tools — often faces some of the most profound barriers on the web. Understanding what this criterion actually requires clarifies not just a compliance checkbox, but a design philosophy.

THE REQUIREMENT

Success Criterion 1.3.6 Identify Purpose (opens in new window) (Level AAA) requires that the purpose of user interface components, icons, and regions can be programmatically determined. This sits under Guideline 1.3 (Adaptable) — the same guideline that governs structure and relationships (1.3.1) and meaningful sequence (1.3.2).

The core mechanism: semantic markup and ARIA metadata that allow user agents and assistive technologies to extract what something represents, not just what it is. The distinction matters. A button's role tells a screen reader it's a button. Its purpose tells a personalization system it's a "home" link — which allows that system to replace the icon or label with whatever symbol or term the user has configured as familiar.

The one sufficient technique documented for this criterion is ARIA11 — Using role=region to identify regions (opens in new window), which covers landmark identification. But the criterion's intent extends beyond landmarks to icons, controls, and any interface element whose purpose can be semantically encoded.

WHY THIS MATTERS

The W3C's framing here is worth sitting with: "Products for people who are non-vocal often use symbols to help users communicate. These symbols are in fact people's language."

That's not metaphor. For many AAC users, symbol sets — Blissymbols, PCS, SymbolStix — are the primary language through which they communicate and process information. The problem: these symbol sets are proprietary and non-interoperable. A user who learns one symbol vocabulary on their AAC device cannot carry that vocabulary into a web interface built by a different company, because there's no shared semantic layer connecting them.

1.3.6 addresses this directly. When authors encode purpose programmatically — not just visually — personalization tools can map interface elements to the user's own symbol set. The button doesn't have to say "Submit" if the user's system knows it represents "send this form" and can display the familiar symbol they already know.

The excluded population when this fails isn't just AAC users. People with cognitive disabilities who rely on consistent visual cues, users who've configured browser extensions to simplify or reformat interfaces, and anyone using a personalization layer between the web and their perception — all benefit from this semantic richness.

Without it, these users encounter interfaces that are technically operable but cognitively inaccessible. The controls work. The meaning doesn't transfer.

HOW TO MEET IT

The practical implementation centers on two areas:

Landmark regions: Use semantic HTML5 elements (<main>, <nav>, <header>, <footer>, <aside>) or ARIA landmark roles to identify page regions. This allows users to show, hide, or navigate by region type — a meaningful affordance for people who need to suppress distracting content or jump directly to familiar areas.

<!-- Sufficient: named landmark via aria-label -->
<nav aria-label="Primary navigation">
  <!-- navigation content -->
</nav>
<main>
  <!-- primary content -->
</main>
<!-- For supplementary content -->
<aside aria-label="Related articles">
  <!-- sidebar content -->
</aside>

Icons and controls: Where icons convey purpose beyond their visual label, encode that purpose semantically. The autocomplete attribute on form fields (already required under 1.3.5 Identify Input Purpose (opens in new window) at Level AA) is the most concrete implementation — it tells user agents what kind of data a field collects, enabling browsers and tools to substitute familiar icons or autofill appropriately.

<!-- Purpose encoded for personalization tools -->
<input 
  type="email" 
  autocomplete="email" 
  aria-label="Email address"
>
<input 
  type="tel" 
  autocomplete="tel" 
  aria-label="Phone number"
>

Common failures include icon-only buttons with no semantic purpose beyond their ARIA label, navigation regions that lack distinguishing labels when multiple <nav> elements appear on one page, and custom widgets that convey purpose only through visual styling.

APPLYING THIS

Here's the testing reality: automated tools will catch missing landmarks and absent autocomplete attributes. What they won't catch is whether the semantic purpose is accurate — a <nav> labeled "Menu" tells a tool the region is identified, but doesn't tell a personalization system whether it's primary navigation or a utility menu. That distinction matters to users.

As our research on automated vs. manual testing documents, automated tools detect a maximum of 37% of accessibility barriers when measured against comprehensive manual audits. 1.3.6 is precisely the kind of criterion where that gap widens — the semantic structure may be present while the semantic meaning is absent.

For QA teams, the practical checklist looks like this:

• Run an automated scan to flag missing landmarks and autocomplete attributes (axe, Lighthouse, WAVE all cover these)
• Manually verify that every <nav> element has a unique, descriptive aria-label when more than one appears on a page
• Test with a personalization tool — the Morphic (opens in new window) platform or similar — to see whether your interface responds to user preference configurations
• Audit icon-only controls: does each one have an aria-label that describes purpose, not just appearance? "Star" is appearance. "Add to favorites" is purpose.

For design teams, the upstream fix is simpler: establish a semantic naming convention for regions during wireframing, not after development. A navigation element named "Primary Nav" in Figma should carry that label into the component's ARIA annotation.

The compliance framework challenges organizations face often push AAA criteria off the roadmap entirely. That's a defensible resource allocation decision. But teams building for government, healthcare, or education — sectors with higher concentrations of users who rely on personalization tools — should weigh 1.3.6 against their actual user population, not just their legal floor.

CORS PERSPECTIVE

From a Strategic Alignment lens, 1.3.6 presents an interesting case: it's legally optional but practically significant for specific communities. The strategic question isn't "do we have to?" but "who are our users, and do they rely on personalization tools?" Organizations that serve populations with higher rates of cognitive disability or AAC use — special education platforms, disability services portals, healthcare patient interfaces — face a community obligation that exceeds the legal minimum. The operational investment to implement landmark labeling and autocomplete attributes is low; the barrier is awareness, not capacity. That's a gap worth closing regardless of conformance level.