WCAG 1.3.6: Identify Purpose

Introduction to WCAG 1.3.6 Identify Purpose

WCAG 1.3.6 Identify Purpose is a Level AAA success criterion introduced in WCAG 2.1. It states that the purpose of user interface components, icons, and regions can be programmatically determined. This criterion aims to provide a more tailored and efficient experience for users, particularly those with cognitive disabilities or users who rely on specialized assistive technologies (AT) or input methods.

By making the purpose of UI elements explicit and machine-readable, assistive technologies can present information more effectively, offer customized displays, or provide simplified interfaces. For instance, an AT could automatically fill in common form fields, provide a visual cue for a ‘search’ region, or allow users to navigate directly to a ‘main content’ area by its identified purpose.

Why WCAG 1.3.6 Matters: Accessibility Impact and User Groups

Ensuring the purpose of UI components is programmatically determinable significantly enhances the user experience for various groups:

• Users with Cognitive Disabilities: Identifying the purpose of common components (like input fields for ‘name’ or ’email’) can reduce cognitive load, aid comprehension, and minimize errors, especially for complex forms or unfamiliar interfaces. Browser extensions or AT can re-label or simplify such fields based on their known purpose.
• Users with Low Vision: For users who magnify content, understanding the purpose helps them quickly identify and interact with controls, as AT could highlight or simplify common actions.
• Users with Motor Disabilities: Those using speech input, switch controls, or other alternative input methods can benefit greatly. If a button’s purpose is clear, a speech command like "click email address" or "activate search" can directly target the intended element, making interaction faster and less error-prone than relying solely on visible labels or positional cues.
• Users of Assistive Technologies: Screen readers, voice control software, and other browser extensions can leverage this programmatic information to present enhanced semantics to the user, offer custom navigation options (e.g., "jump to main content"), or provide an alternative user interface optimized for specific tasks.
• Users of Input Method Editors (IMEs) and Customization Tools: Tools that allow users to customize their browsing experience can use this information to adapt the UI, for example, by adding custom labels, changing styling, or reordering elements based on their identified purpose.

Success Criteria and Requirements for 1.3.6

The core requirement of WCAG 1.3.6 is that the "purpose of user interface components, icons, and regions can be programmatically determined." This means:

• User Interface Components: This refers to controls like buttons, links, form fields, and widgets. Their purpose could be an action (e.g., ‘submit’, ‘cancel’), or to collect specific data (e.g., ‘name’, ’email’, ‘phone number’).
• Icons: Visual representations that convey meaning or trigger actions. Their purpose should be determinable.
• Regions: Distinct areas of content on a web page, such as a navigation bar, main content area, search section, or footer.

The most common way to satisfy this criterion is by using appropriate semantic HTML5 elements and attributes, particularly the autocomplete attribute for form inputs, and WAI-ARIA roles and attributes where native semantics are insufficient.

For common input purposes, WCAG 2.1 references a predefined list of input purposes. By using the correct autocomplete values (e.g., autocomplete="email", autocomplete="tel", autocomplete="name", autocomplete="street-address"), browsers and assistive technologies can identify the data type expected in that field.

Practical Guidelines for Compliance

1. Utilize Semantic HTML5 Elements

Always prioritize native HTML5 elements that inherently convey purpose.

• Use <nav> for navigation regions.
• Use <main> for the main content area.
• Use <aside> for complementary content.
• Use <footer> for footer content.
• Use <header> for introductory content or a group of navigational links.
• Use <form> for forms, <button> for buttons, <a> for links.

2. Employ the autocomplete Attribute for Input Fields

For input fields requesting common types of user information, use the autocomplete attribute with appropriate tokens.

• autocomplete="name"
• autocomplete="email"
• autocomplete="tel"
• autocomplete="organization"
• autocomplete="street-address"
• autocomplete="postal-code"
• autocomplete="cc-number" (for credit card number)
• autocomplete="bday" (for birth date)
• … and many more listed in the HTML Standard Autocomplete Section.

3. Use WAI-ARIA Roles and Properties Appropriately

When native HTML semantics are not available or sufficient, use ARIA to explicitly state the purpose.

• Regions:
• role="search" for search regions.
• role="banner" for site-wide headers.
• role="contentinfo" for site-wide footers.
• role="complementary" for sidebars (equivalent to <aside>).
• Components:
• aria-label or aria-labelledby for custom components or icons that represent a specific purpose (e.g., a button with only a magnifying glass icon for search).
• role="button", role="link", role="checkbox" for custom controls built with generic elements.

4. Ensure Accessible Names for Icons and Controls

Icons acting as controls or conveying important information must have an accessible name that clearly states their purpose. This can be achieved using <span class="sr-only"> text, aria-label, or aria-labelledby.

Examples of Correct and Incorrect Implementations

Correct Implementations

<header>
  <h1>My Website</h1>
  <nav aria-label="Main Navigation">
    <ul>
      <li><a href="/home">Home</a></li>
      <li><a href="/about">About</a></li>
    </ul>
  </nav>
  <div role="search">
    <label for="site-search">Search this site</label>
    <input type="search" id="site-search" placeholder="Enter keywords">
    <button type="submit">Search</button>
  </div>
</header>

<form action="/submit" method="post">
  <p>
    <label for="firstName">First Name:</label>
    <input type="text" id="firstName" name="firstName" autocomplete="given-name" required>
  </p>
  <p>
    <label for="email">Email Address:</label>
    <input type="email" id="email" name="email" autocomplete="email" required>
  </p>
  <p>
    <label for="phone">Phone Number:</label>
    <input type="tel" id="phone" name="phone" autocomplete="tel" required>
  </p>
  <button type="submit">Submit</button>
</form>

<button type="button" aria-label="Add to Cart">
  <span class="icon icon-cart" aria-hidden="true"></span>
</button>

Incorrect Implementations

<div class="header">
  <div class="logo">My Website</div>
  <div class="menu">
    <ul>
      <li><a href="/home">Home</a></li>
      <li><a href="/about">About</a></li>
    </ul>
  </div>
  <div class="search-section">
    <input type="text" id="site-search-bad" placeholder="Search">
    <button type="button"><i class="fa fa-search"></i></button>
  </div>
</div>

<form action="/submit" method="post">
  <p>
    <label for="user-name">Your Name:</label>
    <input type="text" id="user-name" name="userName" required>
  </p>
  <p>
    <label for="contact-email">Your Email:</label>
    <input type="text" id="contact-email" name="contactEmail" required>
  </p>
  <button type="submit">Send</button>
</form>

Best Practices and Common Pitfalls

Best Practices

• Prioritize Semantic HTML5: Always use the most specific and semantic HTML element available before resorting to ARIA. Native HTML elements often have built-in accessibility features and better browser support.
• Use autocomplete Systematically: Apply autocomplete to all relevant input fields, using the most accurate token from the HTML standard.
• ARIA for Augmentation, Not Replacement: Use ARIA roles and attributes to enhance semantics where native HTML is lacking or to create custom interactive components. Never use ARIA to "fix" bad HTML structure.
• Consistent Labeling: Ensure that the visual label, programmatic name (e.g., <label>), and inferred purpose (e.g., autocomplete) are consistent and clearly convey the same meaning.
• Test with Assistive Technologies: Regularly test your implementation with various screen readers (e.g., NVDA, JAWS, VoiceOver), speech input software, and browser extensions that leverage semantic information. This helps confirm that the purpose is indeed programmatically determinable and effectively communicated.

Common Pitfalls

• Over-reliance on <div> and <span>: Using generic elements for interactive controls or significant regions without proper ARIA roles makes their purpose undiscoverable.
• Missing autocomplete: Forgetting to add the autocomplete attribute to common input fields, hindering autofill and AT-driven form assistance.
• Ambiguous Icons: Using icons without an associated text label or aria-label/aria-labelledby attribute, leaving their purpose unclear for users who cannot see or interpret them.
• Incorrect ARIA Usage: Applying ARIA roles or properties incorrectly, which can confuse assistive technologies rather than help them (e.g., role="button" on an element that is not keyboard focusable or clickable).
• Not Considering Custom Components: Building custom UI components (e.g., a custom dropdown or tabbed interface) without carefully defining their roles and states using ARIA.

Conclusion

WCAG 1.3.6 "Identify Purpose" is a crucial criterion for creating truly adaptive and personalized web experiences. By diligently applying semantic HTML5, the autocomplete attribute, and appropriate WAI-ARIA, developers can ensure that the purpose of UI components, icons, and regions is programmatically determinable. This leads to a more efficient, less frustrating, and more inclusive web for everyone, especially those with cognitive or motor disabilities who rely on explicit semantic information to navigate and interact with digital content.