Techniques for WCAG 2.0

On this page:

-

# 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 failure relates to:

- Success Criterion 4.1.2 (Name, Role, Value)
  - How to Meet 4.1.2 (Name, Role, Value)
  - Understanding Success Criterion 4.1.2 (Name, Role, Value)

## 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.

## Examples

### 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

Resources are for information purposes only, no endorsement implied.

- Active Accessibility Checker (AccExplorer)

- JAVA Accessibility Helper

## Related Techniques

(none currently listed)

## 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

- Top
- Contents
- Intro
- Previous: Failure F14
- Next: Failure F16