WCAG 1.3.6: Identify Purpose

What This Rule Means

\n

WCAG 1.3.6 — Identify Purpose is a Level AAA criterion under Principle 1 (Perceivable) that extends the existing structure and semantics requirements to a finer level of granularity. Specifically, it requires that the purpose of each user interface component, icon, region, and certain input field can be determined programmatically — meaning the semantic information is exposed in a way that browsers, browser extensions, and assistive technologies can read and act upon it.

\n

The criterion builds directly on 1.3.1 (Info and Relationships) and 1.3.5 (Identify Input Purpose). Where 1.3.5 focuses on common personal-data input fields (name, email, phone, etc.), 1.3.6 broadens the requirement to all user interface regions and components, including navigation landmarks, icons, buttons, and interactive widgets. The core idea is that a user agent or personalization tool should be able to swap out default presentation — replacing text labels with symbols, simplifying a cluttered navigation, or highlighting the most relevant controls — based on machine-readable purpose data embedded in the markup.

\n

In practical terms, a page passes 1.3.6 when it uses HTML5 landmark elements (such as <header>, <nav>, <main>, <aside>, <footer>, and <section>), applies appropriate ARIA landmark roles where landmark elements are not used, exposes the purpose of icons and other non-text UI components via accessible names or roles, and — where applicable — uses standardized purpose tokens such as those defined in the W3C Personalization Semantics specification (formerly known as the COGA Semantics proposal), for example via the aui- attribute vocabulary.

\n

A page fails when its regions are implemented as generic <div> or <span> containers with no semantic role, when icons carry meaning but have no accessible name or supporting semantics, or when interactive components provide no programmatic cue about their function beyond their visible appearance. An official exception applies: the requirement only applies to content that is implemented using technologies with support for identifying the expected meaning. If no supporting technology or specification exists for a particular component type in a given technology stack, the criterion cannot reasonably be applied to that component.

\n\n

Why It Matters

\n

The primary beneficiaries of WCAG 1.3.6 are people with cognitive and learning disabilities, including dyslexia, attention deficit disorders, autism spectrum conditions, memory impairments, and intellectual disabilities. According to the World Health Organization, approximately 1 in 6 people globally — over one billion individuals — live with some form of significant disability, and cognitive disabilities represent one of the largest and most underserved groups. Many of these users struggle with complex navigation structures, dense text menus, and icon-only controls that provide no semantic anchor.

\n

Consider a concrete scenario: a user with severe dyslexia relies on a browser extension that replaces standard navigation labels with personal symbol sets — picture-based icons from a communication board they use in daily life. For this substitution to work, the extension must be able to determine that a particular <div> is actually a navigation landmark, that a star icon represents "add to favorites," and that a circular arrow represents "refresh." Without programmatically determinable purpose, the extension has nothing to hook into and the substitution fails silently, leaving the user with an interface they cannot parse.

\n

Motor-impaired users who rely on switch access or voice control tools also benefit significantly, because purpose-aware tools can generate shortcut overlays or voice command mappings only for controls whose function is machine-readable. Blind users interacting via screen readers gain from clearly labeled landmark regions, which allow them to jump directly to <main> content or skip repetitive navigation. Users with low vision who employ browser zoom or custom stylesheets benefit from landmark structure because it allows the browser to reflow content predictably.

\n

Beyond accessibility, implementing the semantics required by 1.3.6 yields measurable SEO benefits. Search engine crawlers use landmark and schema markup to understand page structure, index content hierarchies, and generate rich results. A well-structured page with meaningful landmark regions is more likely to earn featured snippets and higher relevance scores. There is also a direct usability dividend: pages with clear semantic structure are easier to maintain, test, and extend by development teams, reducing long-term technical debt.

\n\n

Related Axe-core Rules

\n

WCAG 1.3.6 requires manual testing in addition to any automated checks. Automated tools can verify the presence of semantic markup but cannot determine whether that markup accurately and completely conveys the purpose of every component as a human tester would. The following axe-core rules are closely related and serve as automated proxies for aspects of this criterion:

\n

\n
• region — Checks that all content on the page is contained within a landmark region. It flags content that sits outside any recognized landmark element or ARIA landmark role. While this rule does not test the accuracy of purpose identification, it ensures that the structural foundation required by 1.3.6 is present. A fail means significant content is invisible to landmark-based navigation.
\n
• landmark-one-main — Verifies that the page contains exactly one <main> element or element with role='main'. This is foundational to 1.3.6 because the main content area is one of the most critical regions whose purpose must be identifiable. Multiple or absent <main> landmarks make it impossible for personalization tools to isolate primary content.
\n
• landmark-complementary-is-top-level — Checks that <aside> elements or role='complementary' regions are not nested inside the main content area in a way that misrepresents their purpose. Incorrect nesting misleads assistive technology about the relationship between regions.
\n
• aria-allowed-role and aria-valid-attr-value — Flag invalid or inappropriate ARIA role assignments. Since 1.3.6 depends on accurate role semantics, using an incorrect role (e.g., role='navigation' on a button group) actively undermines purpose identification and these rules will surface such mismatches.
\n
• button-name and link-name — Verify that interactive controls have accessible names. Icon-only buttons and links without accessible names are a primary failure mode for 1.3.6, since no purpose can be determined for a control with no name. These rules flag the absence of aria-label, aria-labelledby, or visible text.
\n

\n

Manual testing is required because automated tools cannot assess whether the chosen purpose tokens or semantic roles accurately represent the component's true function within the application's context. A button could have an accessible name and a valid ARIA role but still fail 1.3.6 if the name is misleading or the role does not reflect what the control actually does.

\n\n

How to Test

\n

\n
1. Run an automated scan with axe DevTools or Lighthouse. Open the page in Chrome, activate the axe DevTools extension, and run a full-page scan. Filter results by the rules listed above: region, landmark-one-main, button-name, and link-name. Note any violations and their impact ratings. In Lighthouse, run an Accessibility audit and review the landmark and ARIA sections. Document all failures as a baseline, but understand these represent only a subset of 1.3.6 compliance.
\n
2. Inspect landmark structure manually using browser developer tools. Open DevTools, navigate to the Accessibility Tree panel (Chrome) or the Accessibility Inspector (Firefox), and verify that the page exposes a coherent landmark hierarchy: one <header> at the top level, one <main>, at least one <nav> (with a distinguishing label if multiple are present), and a <footer>. Confirm that no meaningful content region is wrapped only in a generic <div> or <span>.
\n
3. Test with NVDA and Firefox. Launch NVDA, open the page in Firefox, and press D to cycle through landmarks. Verify that each landmark is announced with a meaningful role and, where multiple landmarks of the same type exist, a unique label. Navigate to each icon-only button using the Tab key and confirm NVDA announces a descriptive accessible name — not an empty string, filename, or generic label like "button."
\n
4. Test with VoiceOver and Safari (macOS/iOS). Enable VoiceOver (Cmd+F5 on macOS). Use the Rotor (Vo+U) to open the Landmarks list and verify all expected regions appear. Tab through interactive controls and listen for meaningful descriptions. On iOS, use a three-finger swipe to navigate by headings and landmarks and confirm the purpose of each region is announced correctly.
\n
5. Test with JAWS and Chrome. Open the page in Chrome with JAWS running. Press R to navigate regions and confirm each region's role and label are accurate. Use the JAWS Virtual Cursor to read through icon buttons and verify their purpose is conveyed. Use the JAWS List of Links (Insert+F7) to audit all link names for meaningfulness.
\n
6. Test personalization semantics (if implemented). If your page uses the W3C Personalization Semantics vocabulary (e.g., data-purpose or aui- attributes), use the Personalization Semantics test tool or a compatible browser extension to verify that purpose tokens are correctly applied and machine-readable by user agents that support the specification.
\n
7. Conduct a component-by-component purpose audit. For every interactive component and icon on the page, ask: can the purpose of this component be determined without visual context? If removing all CSS and images still leaves the component's purpose clear from the DOM and ARIA attributes alone, it passes. If the purpose is only conveyed visually, it fails.
\n

\n\n

How to Fix

\n\n

Generic div regions without landmarks — Incorrect

\n

<div class='site-header'>\n  <div class='logo'>Accsible</div>\n  <div class='main-nav'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </div>\n</div>\n<div class='main-content'>\n  <p>Welcome to our platform.</p>\n</div>\n<div class='sidebar'>\n  <p>Related articles</p>\n</div>\n<div class='site-footer'>\n  <p>© 2025 Accsible</p>\n</div>

\n\n

Generic div regions without landmarks — Correct

\n

<!-- Use native HTML5 landmark elements so browsers and AT\n     can programmatically identify the purpose of each region -->\n<header>\n  <a href='/' aria-label='Accsible home'>\n    <img src='logo.svg' alt='Accsible' />\n  </a>\n  <nav aria-label='Primary navigation'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </nav>\n</header>\n<main>\n  <p>Welcome to our platform.</p>\n</main>\n<aside aria-label='Related articles'>\n  <p>Related articles</p>\n</aside>\n<footer>\n  <p>© 2025 Accsible</p>\n</footer>

\n\n

Icon-only button with no accessible name — Incorrect

\n

<!-- An icon button whose purpose cannot be determined\n     programmatically — it has no accessible name at all -->\n<button class='btn-icon'>\n  <svg viewBox='0 0 24 24' width='24' height='24'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

Icon-only button with no accessible name — Correct

\n

<!-- aria-label gives the button a programmatically determinable\n     purpose; the SVG is hidden from AT since the label covers it -->\n<button class='btn-icon' aria-label='Add to favourites'>\n  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

Multiple navigation landmarks without distinguishing labels — Incorrect

\n

<!-- Two nav elements with identical roles but no labels:\n     screen readers cannot distinguish their purpose -->\n<nav>\n  <a href='/home'>Home</a>\n  <a href='/about'>About</a>\n</nav>\n\n<nav>\n  <a href='/page1'>Chapter 1</a>

(Content truncated due to token limit — please retry this article.)