WCAG 1.3.6 Identify Purpose: How to Make User Interface Components Accessible

WCAG 1.3.6: Identify Purpose — short definition

WCAG 1.3.6 requires that the purpose of user interface components be programmatically determinable. That means assistive technology and platform features can tell what a control or region does without relying on visuals alone. This article explains how to meet WCAG 1.3.6 in real interfaces.

What the success criterion covers

The criterion applies to interactive controls and structural regions. Examples include buttons, links, checkboxes, sliders, search fields, navigation regions and landmarks. Purpose must be discoverable through the accessibility API or semantics in the HTML or ARIA layer.

Why programmatic identification matters

When purpose is programmatically available, assistive technologies can offer features such as control lists, switch control, voice commands and custom styling. It also helps automated tools and platform accessibility services give consistent behaviour across devices.

How to make a component’s purpose identifiable

1. Prefer native HTML elements

Native elements carry built-in semantics. For example use <button> for actions, <a> for navigation, <input type=“checkbox”> for binary choices and <input type=“range”> for sliders. Native elements are exposed automatically to accessibility APIs.

2. Use ARIA only when native semantics are not possible

Give a non-semantic element a role when you cannot use a native element. For example role=“button” on a clickable div. When you add a role you must also provide the keyboard behaviour and state updates that native controls provide.

3. Provide a clear accessible name that includes purpose

Controls need accessible names that reflect what they do. Use visible text where possible. Use aria-label or aria-labelledby when visible text is not available. The name should not be ambiguous. For example, label a search field “Search products” rather than “Search” if the site has multiple search contexts.

4. Expose state and properties programmatically

If a control has a state use appropriate attributes so the state is available to assistive tech. Examples include aria-checked for custom checkboxes and aria-expanded for disclosure controls. Keep the attribute values in sync with visual changes.

5. Mark up regions with landmarks or roles

Use semantic elements and ARIA landmark roles to identify regions. For example use <nav> or role=“navigation” for the main navigation, <main> for content, and role=“search” for a search block. Landmarks make the purpose of page areas programmatically discoverable.

6. Avoid relying on visual cues

Colour, position and icons alone do not convey purpose to assistive tech. Ensure textual labels or programmatic semantics exist. If an icon is the only label, provide an accessible name via aria-label or hidden text.

Practical checklist for developers

• Use native controls where they match the required behaviour.
• When using ARIA, give the correct role and keep state attributes in sync.
• Give every control a clear accessible name that includes its purpose.
• Use landmark elements or roles for structural regions.
• Test with keyboard only and with a screen reader.
• Validate the accessibility tree in browser dev tools or Accessibility Insights.

Testing WCAG 1.3.6

Automated tools help find missing roles or attributes but they do not prove usability. Combine automated scans with manual checks.

Quick manual test

1. Open the page in a browser.
2. Inspect the accessibility tree or Accessibility pane to see exposed roles, names and states.
3. Navigate to controls with the keyboard. Verify focus and expected keys work.
4. Use a screen reader such as NVDA or VoiceOver and listen for the control purpose and state.

Tools to use

• Browser devtools Accessibility pane to view roles and names.
• Accessibility Insights or axe for automated checks.
• NVDA on Windows or VoiceOver on macOS for screen reader testing.

Common mistakes and fixes

• Mistake: Using <div> or <span> for interactive controls without role or keyboard handlers.
  Fix: Use native element or add role plus keyboard support and accessible name.
• Mistake: Visual label only, no accessible name.
  Fix: Add visible text or aria-label/aria-labelledby that conveys purpose.
• Mistake: Adding role=“button” but failing to update aria-pressed or aria-checked when state changes.
  Fix: Update ARIA state attributes in the same code path that changes the visual state.
• Mistake: Using a link for an action that performs a change on the page.
  Fix: Use <button> for actions. If a navigation is intended, use <a> with an href.

Decision framework for implementation

Use this short sequence when building a component.

1. Can a native element deliver the behaviour? If yes use it.
2. If not, add the correct ARIA role and provide a clear accessible name.
3. Implement keyboard support and update ARIA state attributes on all state changes.
4. Test the result in the accessibility tree and with a screen reader.

Examples

Component	Preferred markup	Why
Action control	<button>Submit</button>	Button has built-in role name keyboard handling
On/off switch	<input type=“checkbox”> or role=“switch” with aria-checked	Exposes state to assistive tech
Slider	<input type=“range”>	Range inputs expose value and keyboard handling
Search region	<form role=“search”> with labelled input	Landmark helps users find search quickly

Final notes

Meeting WCAG 1.3.6 is mostly about using the right semantics and keeping accessible names and states accurate. Build with native elements first. When ARIA is required follow the rules for role, name and state. Always verify with the accessibility tree and a screen reader.