Go to search page
Almost, but not quite site front page
Almost, but not quite a guide to accessibility requirements
1 Perceivable

1.3.6 Identify Purpose

Conformance level: AAA
Criterion released in WCAG version: 2.1

TL;DR: SC 1.3.6 is about personalisation. If regions and controls expose their purpose in markup, users can use tools that adapt the UI (for example, replacing icons or vocabulary). Practically: use landmarks for regions and give icon-only controls clear, purpose-based, accessible names.

Official description of the success criterion

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

What to do?

Ensure that:

  • Regions use programmatic semantics (e.g. HTML landmarks like nav, main, etc., or ARIA landmarks where needed).
  • Interactive components (buttons, links, inputs) have an accessible name that describes their purpose (e.g. “Search”, “Open menu”, “Close dialog”, “Help”).
  • Icons that convey meaning are exposed through the control’s accessible name or adjacent text, not only through visuals.

Why is it important?

This criterion supports personalisation: users can use tools that replace symbols/terminology with alternatives that are more familiar to them (for example, different icon sets or simplified vocabulary). For this, tools need more than “this is a button” — they need to know what it is for.

Common pitfalls
  • Icon-only buttons/links with names like “Icon”, “Button”, “More”, “X”, or “Hamburger”, instead of the actual purpose (“Close”, “Open menu”).
  • Using <div> and click handlers instead of native controls, and then trying to patch accessibility later.
  • Missing/incorrect landmarks, or multiple landmarks of the same type without labels (e.g. two nav regions both just “Navigation”).
  • Treating “decorative” icons as meaningful content (or the opposite).
How to test for it?
  • Regions
    • Check if main page regions are marked with landmarks (header, nav, main, footer, aside) or ARIA landmark roles.
    • If there are multiple landmarks of the same type (e.g. multiple nav), confirm they have clear, distinct labels. (This helps the “purpose” be determinable for users and tools.)
  • Controls / icons
    • For icon-only buttons and links, confirm the accessible name matches the purpose (“Search”, “Open settings”, “Close”, “Download”, etc.).
    • Use the browser devtools Accessibility panel to inspect Role and Name.
    • Spot-check with a screen reader: do the names make sense without seeing the icon?

Related criteria: 1.1.1, 1.3.1, 4.1.2

How to take this criterion into account in design?
  • Prefer text labels for critical actions. If using icons, ensure the same action is always represented with the same wording (consistency helps mapping/personalisation).
  • Define a canonical vocabulary for common actions in your UI (Search, Menu, Close, Settings, Help, Share…).
  • Plan landmark regions: what are your navigations (main nav vs. breadcrumbs vs. local nav), and how will they be labelled?
How to take this criterion into account in development?
  • Put the purpose on the interactive element, not the SVG/font icon.
    • Icon-only:
      • <button aria-label="Search">…</button>
      • <a aria-label="Go to home">…</a>
  • Treat the SVG/sprite/icon-font as presentation:
    • inline SVG: aria-hidden="true" focusable="false"
    • sprite <use>: hide the SVG wrapper; name the parent control
    • icon font: hide the icon span; name the parent control
  • If the icon is meaningful on its own (e.g. status indicator), ensure the meaning is available as text (visible or SR-only).

More about this criterion elsewhere