WCAG 1.3.6 Identify Purpose: Programmatic Purpose for UI Components

What This Criterion Requires

WCAG 1.3.6 requires that the purpose of user interface components, icons, and regions can be programmatically determined. This goes beyond basic semantics by ensuring that assistive technologies and user agents can identify the specific purpose of elements on the page. When the purpose of a component is machine-readable, assistive technologies can present the information in different ways, such as replacing text labels with familiar icons, simplifying the interface to show only essential controls, or providing personalized navigation shortcuts. The most common technique for meeting this criterion is using the HTML autocomplete attribute on form inputs to indicate what type of data the field expects, such as name, email, telephone, or address components. Additionally, using ARIA landmarks to identify page regions, proper heading structures, and semantic HTML elements all contribute to making the page purpose identifiable. This criterion particularly benefits people with cognitive disabilities, language difficulties, and memory impairments by enabling adaptive technologies to present a more familiar and simplified interface.

Why It Matters

People with cognitive disabilities often benefit from personalized interfaces that replace unfamiliar text with symbols, icons, or simplified labels they recognize. For this personalization to work, assistive technologies must be able to identify the purpose of each element programmatically. For example, if a form field is marked with autocomplete='email', an adaptive tool can display a familiar email icon next to the field, helping users who struggle with text labels. Similarly, identifying page regions through landmarks allows assistive technology to hide non-essential content and present a simplified view of the page. This criterion also improves browser autofill accuracy, reducing errors when users complete forms. For people with memory impairments, consistent identification of common components like search fields, login forms, and navigation areas means they can rely on muscle memory and visual patterns even on unfamiliar websites. The practical impact is a web that adapts to users rather than forcing users to adapt to it.

Common Failures and How to Fix Them

<form>
  <label for="name">Full Name</label>
  <input type="text" id="name" name="name">
  <label for="email">Email</label>
  <input type="email" id="email" name="email">
  <label for="phone">Phone</label>
  <input type="tel" id="phone" name="phone">
</form>

<form>
  <label for="name">Full Name</label>
  <input type="text" id="name" name="name" autocomplete="name">
  <label for="email">Email</label>
  <input type="email" id="email" name="email" autocomplete="email">
  <label for="phone">Phone</label>
  <input type="tel" id="phone" name="phone" autocomplete="tel">
</form>

<div class="header">
  <div class="nav">...</div>
  <div class="search">...</div>
</div>
<div class="content">...</div>
<div class="footer">...</div>

<header>
  <nav aria-label="Primary navigation">...</nav>
  <search>
    <form role="search">...</form>
  </search>
</header>
<main>...</main>
<footer>...</footer>

<button class="btn-icon">
  <svg><use href="#icon-share"/></svg>
</button>

<button class="btn-icon" aria-label="Share this page">
  <svg aria-hidden="true"><use href="#icon-share"/></svg>
</button>

How to Test

1. Inspect all form fields that collect personal data and verify they have appropriate autocomplete attribute values from the WHATWG specification.
2. Use browser developer tools or a screen reader to confirm that all major page regions are identified with landmarks (header, nav, main, footer, search, complementary).
3. Check that icon-only buttons and controls have accessible names that describe their purpose, using aria-label or visually hidden text.
4. Use an accessibility audit tool that checks for autocomplete attribute coverage on standard input fields.

CMS-Specific Guidance

This criterion commonly causes issues on these platforms:

• Wordpress Accessibility Checklist
• Shopify Accessibility Checklist
• Squarespace Accessibility Checklist
• Wix Accessibility Checklist
• Webflow Accessibility Checklist

Further Reading

• Accessible Forms Guide
• Wcag Explained Plain English
• Accessible Navigation Guide

Related WCAG Criteria

• WCAG 1.3.5
• WCAG 1.3.1