See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how they relate to the normative WCAG 2.0 success criteria. The Applicability section explains the scope of the technique, and the presence of techniques for a specific technology does not imply that the technology can be used in all situations to create content that meets WCAG 2.0.
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.
Note: For technologies that support it, WAI-ARIA can be used to expose a custom control's role, name, value, states, and properties via the accessibility API for the technology.
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)
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.
If step #1 is false, then this failure condition applies and the content fails this Success Criterion