Technique 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

Applicability

Applies to all technologies that support an accessibility API.

This technique relates to 4.1.2: Name, Role, Value (Failure).

Description

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.

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.

Examples

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.

Other sources

No endorsement implied.

Tests

Procedure

  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

  • If step #1 is false, then this failure condition applies and the content fails this Success Criterion