Knowledge base WCAG Guidelines WCAG Success Criteria

WCAG 5.2.4: Only Accessibility-Supported Ways of Using Technologies

Introduction to WCAG Conformance Requirement 5.2: Only Accessibility-Supported Ways of Using Technologies

For a web page to conform to the Web Content Accessibility Guidelines (WCAG) 2.0 or 2.1, it must satisfy all conformance requirements. Conformance Requirement 5.2, often summarized as "Only Accessibility-Supported Ways of Using Technologies," states that all information and functionality must be provided in ways that are accessibility-supported.

This means that any technology relied upon to meet WCAG Success Criteria must be used in a manner that is known to work with users' assistive technologies (AT) and the accessibility features of web browsers. It's not enough for content to merely pass automated checks; it must actually be usable by people with disabilities through their chosen tools.

Why This Conformance Requirement Matters

This requirement is fundamental to ensuring a truly accessible web experience. Its impact is profound for several reasons:

Ensures Practical Accessibility: Without accessibility-supported technologies, even if a website technically meets Success Criteria, users of assistive technologies may find the content or functionality unusable. For example, a custom JavaScript widget might visually appear correct, but if its interactive states (like focus or selected) aren't communicated to a screen reader, it fails to be accessible in practice.
Promotes Predictability and Reliability: When developers stick to widely supported technologies and their accessible patterns, users have a more consistent and reliable experience across different websites and assistive technologies. This predictability reduces cognitive load and frustration.
Impact on Diverse User Groups: This requirement directly benefits a wide range of users, including:
- Users with visual impairments: Who rely on screen readers or screen magnifiers to interpret and interact with content.
- Users with motor impairments: Who depend on keyboard navigation, speech input, or switch controls to operate web pages.
- Users with cognitive disabilities: Who benefit from predictable interactions and clear communication from assistive technologies.
- Users with hearing impairments: Who might use captions or transcripts delivered via accessibility-supported media players.

Understanding "Accessibility-Supported" Technologies

The term accessibility-supported is a specific and crucial definition within WCAG. A technology (or a specific use of a technology) is considered accessibility-supported if:

Supported by Users' Assistive Technologies (AT): The way the technology is used must be supported by the assistive technologies (e.g., screen readers, voice input software) that users in the target audience are likely to use. This implies that the technology correctly exposes its semantic information and interactive states to the accessibility APIs of the operating system.
Accessibility Features in User Agents are Turned On: The accessibility features of user agents (web browsers like Chrome, Firefox, Edge, Safari) must be turned on. Modern browsers generally have these enabled by default.
Accessibility Features in ATs are Turned On: The accessibility features of the assistive technologies themselves must be turned on. Users typically configure their ATs for optimal accessibility.
Widely Available: The technology must be widely available to users. This generally means the user agent (browser) or assistive technology must be broadly distributed or downloadable without prohibitive costs.

It's important to differentiate between a technology being available and being accessibility-supported. For instance, while a specific JavaScript library might be available, its custom components might not expose the necessary accessibility information to ATs unless specifically designed to do so (e.g., using WAI-ARIA).

Examples of Generally Accessibility-Supported Technologies:

Standard HTML5 elements (<p>, <h1>-<h6>, <a>, <button>, <form> elements, etc.) when used correctly.
CSS for styling, particularly for visual presentation that doesn't convey critical information exclusively.
WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) attributes, when used correctly to augment native HTML semantics or provide semantics for custom widgets that lack native equivalents.
Standard JavaScript DOM manipulation that respects HTML semantics and ARIA, ensuring keyboard operability and correct state changes.

Practical Guidelines for Compliance

To ensure your web content relies only on accessibility-supported ways of using technologies, consider the following guidelines:

Prioritize Native HTML: Whenever possible, use native HTML elements for their intended semantic purpose (e.g., <button> for buttons, <a> for links, <h1>-<h6> for headings, <input type="checkbox"> for checkboxes). These elements inherently come with built-in accessibility features like keyboard operability and semantic roles that are widely supported by ATs.
Leverage WAI-ARIA When Necessary: When native HTML does not provide the required semantics (e.g., for complex UI components like tabs, carousels, or custom dropdowns), use WAI-ARIA roles, states, and properties to convey the necessary information to assistive technologies. Remember the first rule of ARIA: If you can use a native HTML element or attribute with the semantics and behavior you require, instead of re-purposing an element and adding an ARIA role, state or property, then do so.
Test Thoroughly with Assistive Technologies: Do not assume compliance. Regularly test your content with a variety of screen readers (e.g., NVDA, JAWS, VoiceOver), keyboard-only navigation, and other relevant ATs. This is the most reliable way to verify actual accessibility support.
Provide Accessible Alternatives for Non-Supported Technologies: If you must use a technology that is not accessibility-supported (e.g., an older plugin, a niche custom framework), you must provide a conforming alternative that offers equivalent information and functionality. This alternative must meet all WCAG Success Criteria using accessibility-supported technologies.
Avoid Over-reliance on JavaScript for Basic Functionality: While JavaScript is essential for dynamic web content, ensure that core functionality remains accessible even if JavaScript fails or is not fully supported by an AT. Use progressive enhancement and provide a robust non-JS fallback where appropriate.
Stay Updated: The landscape of accessibility support evolves. Keep abreast of best practices, browser updates, and new versions of assistive technologies.

Examples of Correct and Incorrect Implementations

Correct Implementations:

Correct: Semantic Button

Using a native HTML <button> element is inherently accessibility-supported. It's keyboard focusable, announces its role to screen readers, and is operable by various input methods.

<button type="submit">Submit Form</button>

Correct: Custom Checkbox with ARIA and JavaScript

When creating custom interactive elements, ARIA can be used to provide the necessary semantic information. This example uses role="checkbox" and aria-checked to convey state, along with JavaScript to ensure keyboard interaction and state changes.

<div class="custom-checkbox" role="checkbox" aria-checked="false" tabindex="0">
  <span class="checkbox-icon"></span>
  <span>Agree to terms</span>
</div>

.custom-checkbox {
  display: flex;
  align-items: center;
  cursor: pointer;
  padding: 4px 0;
}
.checkbox-icon {
  width: 18px;
  height: 18px;
  border: 2px solid #333;
  margin-right: 8px;
  display: inline-block;
  box-sizing: border-box;
}
.custom-checkbox[aria-checked="true"] .checkbox-icon {
  background-color: #007bff;
  border-color: #007bff;
}
.custom-checkbox[aria-checked="true"] .checkbox-icon::after {
  content: '✔';
  color: white;
  display: flex;
  justify-content: center;
  align-items: center;
  font-size: 14px;
  line-height: 1;
}

document.querySelectorAll('.custom-checkbox').forEach(checkbox => {
  checkbox.addEventListener('click', () => {
    const isChecked = checkbox.getAttribute('aria-checked') === 'true';
    checkbox.setAttribute('aria-checked', String(!isChecked));
  });
  checkbox.addEventListener('keydown', (e) => {
    if (e.key === ' ' || e.key === 'Enter') {
      e.preventDefault();
      const isChecked = checkbox.getAttribute('aria-checked') === 'true';
      checkbox.setAttribute('aria-checked', String(!isChecked));
    }
  });
});

Incorrect Implementations:

Incorrect: Div as a Button Without ARIA and Keyboard Support

Using a generic <div> element with a JavaScript click handler, without adding role="button", tabindex="0", and keyboard event listeners (for Space/Enter), makes it inaccessible to screen reader users and keyboard-only users. It lacks semantic meaning and interactive capabilities for ATs.

<div onclick="doSomething()" style="cursor: pointer; padding: 10px; border: 1px solid #ccc;">Click Me</div>

Incorrect: Reliance on Non-Supported Plugin Without Alternative

Embedding Flash content that contains critical information or functionality without providing an HTML-based accessible alternative would violate this requirement if Flash is not accessibility-supported for the target audience (which is generally the case for modern web accessibility).

<object type="application/x-shockwave-flash" data="my_flash_content.swf" width="400" height="300">
  <!-- No accessible alternative provided for the Flash content -->
</object>

Best Practices and Common Pitfalls

Best Practices:

Design with Accessibility in Mind from the Start: Integrate accessibility considerations into every phase of design and development, choosing technologies and patterns known for their accessibility support.
Use Semantic HTML First: Leverage the inherent accessibility of native HTML elements before resorting to custom components. They are robust and widely supported.
Apply ARIA Thoughtfully: Use WAI-ARIA to enhance semantics when native HTML is insufficient, but avoid overusing it or using it incorrectly (e.g., changing the native semantics of an element unnecessarily).
Ensure Full Keyboard Operability: All interactive elements must be focusable and operable using only the keyboard. This is a baseline for many assistive technologies.
Test Early and Often: Conduct manual accessibility testing with screen readers, keyboard-only navigation, and other ATs throughout the development lifecycle to catch issues early.
Provide Clear Instructions: For complex interactions or custom widgets, provide explicit instructions on how to use them with various input methods if the interaction is not intuitive.

Common Pitfalls:

Assuming Browser/AT Support: Believing that if a feature works in one browser, it's automatically accessibility-supported across all ATs and user agents. Verification is key.
Ignoring Keyboard Navigation: Creating interactive elements that can only be activated by a mouse, effectively excluding keyboard-only users and many AT users.
Over-Reliance on Visual Cues: Conveying information solely through color or visual position without semantic meaning or text alternatives.
Incorrect ARIA Usage: Misapplying ARIA roles, states, or properties, which can sometimes make elements less accessible than if ARIA were not used at all.
Lack of Fallbacks: Using advanced or non-standard technologies without providing an equivalent, accessible alternative for users whose browsers or ATs don't fully support them.

Conclusion

Conformance Requirement 5.2, "Only Accessibility-Supported Ways of Using Technologies," is a cornerstone of effective WCAG conformance. It shifts the focus from theoretical compliance to practical usability, ensuring that the technologies used to build web content are genuinely compatible with the tools people with disabilities rely on. By prioritizing standard, semantic, and thoroughly tested implementations, developers can build a web that is truly inclusive and accessible to everyone.

WCAG Conformance Levels

WCAG Success Criteria