1.3.6 Identify Purpose

1. What is the goal of this criterion?

Imagine using an app where every icon is unfamiliar, the terms make no sense and the navigation feels like a maze. For many people with cognitive disabilities, that’s everyday digital life – unless websites and apps can be adapted to their needs.

The goal of Success Criterion 1.3.6 is to let users personalise their digital environment. When the purpose of controls, icons and page regions can be determined programmatically, assistive tools can use that information to show familiar symbols, simpler terms or reduced interfaces.

In short: everyone should be able to get an interface they understand – with help from technology.

2. What exactly does it require?

Success Criterion 1.3.6 is about semantic markup at a very detailed level. It requires that in content implemented using markup languages such as HTML, the purpose of the following can be programmatically determined:

User interface components (such as buttons, links, form fields): they must be marked up so it’s clear what they’re for – not just what they are, but what they do.

Icons: icons must be described in a way that lets assistive tools replace them with familiar alternatives.

Page regions: areas such as navigation, main content or sidebar must be identifiable.

The idea: browsers and assistive technologies can use this information to adapt content – with different symbols, simplified language or by hiding less important areas.

Important: this is a Level AAA criterion and goes well beyond the basic requirements. It builds on Identify Input Purpose, which requires the same principle for form fields at Level AA.

3. Why does it matter for accessibility?

Imagine that reading or concentrating is hard for you, and every website looks different, uses different icons and different words. It would be like living in a foreign country whose rules keep changing.

Machine-readable purposes create accessibility because they make the following possible:

• Familiar symbols: people can use their own symbol sets that they understand.
• Simplified interfaces: less important areas can be hidden or shown more calmly.
• Personal vocabulary: difficult words can be replaced with simpler ones.
• Consistent operation: similar functions can be presented the same way on every website.
• Lower cognitive load: less information at once, adapted to individual abilities.

To be honest: for page regions this already works well today – screen readers and browser extensions use landmarks every day. For controls and icons, however, widely adopted standards and tools are still missing. The W3C is working on this under the name WAI-Adapt.

4. How to meet the criterion

Meeting 1.3.6 is more demanding than many other criteria, but there’s plenty you can already do today:

Mark up page regions with semantic HTML:

<header>…</header>
<nav aria-label="Main navigation">…</nav>
<main>…</main>
<aside>…</aside>
<footer>…</footer>

These elements automatically create the matching landmark roles. You only need explicit roles like role="navigation" if you can’t use the elements. If there are several regions of the same type, tell them apart with aria-label.

Give controls and icons clear names: use native elements (button, a, input) with clear names. For icon buttons, the name belongs on the button and the icon itself is hidden:

<button type="button" aria-label="Edit profile">
  <img src="pencil.svg" alt="">
</button>

Watch out: if an element has a visible label, its accessible name should contain it. A link with the visible text “Home” and aria-label="Go to the start page" fails Label in Name.

Add autocomplete to form fields: what you do for 1.3.5 counts towards 1.3.6 too.

Use consistent terms: stick to established labels such as “Search”, “Basket” or “Sign in” so people and tools recognise them.

Standards and tools:

• Use semantic HTML elements consistently
• Follow WAI-ARIA 1.2 and the ARIA Authoring Practices
• Keep an eye on the development of WAI-Adapt at the W3C

Important: since this is an AAA criterion, think of it as a refinement of a website that’s already accessible, not as the basics. The foundation for it is Info and Relationships.

5. Why this criterion matters for businesses

With this advanced AAA criterion too, accessibility and good engineering go hand in hand.

1. Be ready for what’s coming

Personalisation through assistive tools is still in its early days. If you write semantically clean code today, you’ll benefit as soon as browsers and tools make more use of it.

2. Reduce technical debt

Clean, semantic markup makes code more maintainable and robust. What helps assistive technologies also makes automated testing and further development easier.

3. Sharpen your profile

A company that engages with AAA criteria shows that digital inclusion is more than ticking boxes there – a difference customers and job applicants notice.

On the legal side: what the law usually requires is Level AA. The European Accessibility Act has applied since 28 June 2025 – in Germany through the Barrierefreiheitsstärkungsgesetz (BFSG) – and relies on EN 301 549, which refers to WCAG 2.1 Level AA for web content. 1.3.6 isn’t part of the mandatory scope. (General information, not legal advice.)

6. The success criterion in the W3C’s words

Success Criterion 1.3.6 Identify Purpose (Level AAA)

In content implemented using markup languages, the purpose of user interface components, icons, and regions can be programmatically determined.

In short: in content built with markup languages, the purpose of controls, icons and page regions can be determined by machines.