1.3.6 Identify Purpose

WCAG 2.2 · 1.3.6 AAA Perceivable

What it requires

In content built with markup languages, the purpose of user-interface components, icons, and regions can be programmatically determined. Where 1.3.5 Input Purpose (AA) covers only the autocomplete purpose of fields that collect information about the user, 1.3.6 is broader: it asks you to expose the role and meaning of things like navigation, search, buttons (next, close, help), and recurring regions in a machine-readable way. The goal is to let assistive technology and personalization tools adapt the interface — swapping in familiar symbols, simplifying layouts, or hiding non-essential regions — to a user's specific needs.

  • People with cognitive and learning disabilities who rely on symbol sets or simplified, decluttered views to understand and operate a page.
  • Users of personalization extensions (such as those built on the WAI ARIA / Personalization Semantics work) that need machine-readable purpose to add familiar icons or remove distractions.
  • Screen-reader and other AT users who benefit when regions, controls, and icons carry a programmatically determinable role and purpose rather than relying on visual presentation.

How to detect it

Manual, AT, and automated checks
Check What to look for
Regions Landmarks use native elements or ARIA roles (nav, search, main, complementary) so each region's purpose is exposed.
Controls Common controls expose purpose programmatically — e.g. links/buttons with clear roles and accessible names, fields with autocomplete tokens.
Icons Icon-only controls carry an accessible name and, where supported, semantics that identify their well-known purpose (close, menu, search).
Screen reader Navigate by landmarks/regions: each is announced with a meaningful purpose, not generic "region".
Automated Tools like axe can flag missing landmarks, names, and roles, but cannot fully verify that every component's purpose is identified — manual review is required.

How to fix it

  1. Use native HTML landmarks (header, nav, main, aside, footer) or ARIA roles so each region's purpose is programmatically determinable.
  2. Give icon-only controls an accessible name and an appropriate role so their purpose is exposed, not implied by the glyph alone.
  3. Add autocomplete tokens to inputs that collect user information.
  4. Where you use ARIA/personalization semantics, apply them consistently so personalization tools can map controls to familiar symbols.
<nav aria-label="Primary"> … </nav>

<button type="button" aria-label="Close dialog">
  <svg aria-hidden="true" focusable="false">…</svg>
</button>

<input type="email" name="email" autocomplete="email">

Copy-paste tests

Automated coverage

There is no fully automated axe-core rule for 1.3.6 Identify Purpose: tools can detect missing autocomplete tokens, but only a human can confirm the purpose of icons, regions, and links is programmatically identifiable. Treat this as a manual review using the console check and steps below.

Run this in the browser console

identify-purpose-check.js 
// Read-only: surfaces inputs and icon-only controls for manual review.
const inputs = [...document.querySelectorAll('input, select, textarea')]
  .filter(el => !el.getAttribute('autocomplete'));
const iconControls = [...document.querySelectorAll('button, a')]
  .filter(el => !el.textContent.trim() && el.querySelector('svg, img, [class*="icon"]'));
console.table(inputs.map(el => ({ tag: el.tagName, name: el.name, type: el.type })));
console.log('Icon-only controls (need a purpose label):', iconControls);
[...inputs, ...iconControls].forEach(el => el.style.outline = '2px solid orange');

What to check manually: confirm each outlined input that collects user info carries the correct HTML autocomplete token, and verify icons and regions expose a recognisable name or role so their purpose is programmatically determinable.