Techniques for WCAG 2.0

Skip to Content (Press Enter)

This document is a draft, and is designed to show changes from a previous version. It is presently showing added text,changed text,deleted text,[start]/[end] markers,and Issue Numbers.

Hide All Edits   |   Toggle Deletions  |   Toggle Issue Numbers   |   Toggle [start]/[end] Markers   |   Show All Edits

Changes are displayed as follows:


F15: Failure of Success Criterion 4.1.2 due to implementing custom controls that do not use an accessibility API for the technology, or do so incompletely


Applies to all technologies that support an accessibility API.

This failure relates to:


When standard controls from accessible technologies are used, they usually are programmed in a way that uses and supports the accessibility API. If custom controls are created, however, then it is up to the programmer to be sure that the newly created control supports the accessibility API. If this is not done, then assistive technologies will not be able to understand what the control is or how to operate it or may not even know of its existence.


Failure Example 1

A music player is designed with custom controls that look like musical notes that are stretched for volume, tone etc. The programmer does not make the new control support the Accessibility API. As a result - the controls cannot be identified or controlled from AT.


Resources are for information purposes only, no endorsement implied.

(none currently listed)



  1. Using the accessibility checker for the technology (or if that is not available, inspect the code or test with an assistive technology), check the controls to see if they support the accessibility API.

Expected Results