G135Sufficient technique WCAG 4.1.2 Level A Partly scanner-detectable

Expose controls through the platform accessibility API

Not everything is built from markup. Where an interface is drawn by a programming toolkit rather than written as HTML, G135 says use that platform's accessibility API to expose each component's name and role, let users set the properties they are allowed to set, and send notification when something changes. Many toolkits already ship components wired into the API. Your job is to fill in the properties they cannot guess, starting with the name. W3C lists this as sufficient for 4.1.2 Name, Role, Value at Level A, reached through a more specific technique. Three general techniques sit at that rule and they are not interchangeable. One is about picking a technology that supports the API at all, one is about using markup features to expose the information, and this one is about talking to the API directly.

How we find it in an audit

A page scanner reads the DOM, so a canvas or a native toolkit surface is mostly a blank to it. Our reviewers use an accessibility inspector to look at the tree the platform is actually publishing, then compare it against what the interface shows on screen. Every control should appear with a name, a role and a current state. Anything that is a single unnamed graphic in the tree is a control nobody else can reach.

How affected users experience it

A seat picker drawn on a canvas looks like a plan of the theater and reports to the accessibility layer as one image. The user hears a graphic, then nothing. There are no seats, no prices, no selected state, and no way to book. The visual work is all there and none of it was published, which is the specific harm this technique exists to prevent.

Passes vs. fails

Passes: name, role, and state exposed. Fails: a control with no identity.

Passes

Each seat is published to the accessibility layer with a name such as 'Row F, seat 12', a role, a selected state, and a notification when that state changes.

Fails

A canvas-drawn seat picker paints its own buttons, and the accessibility API sees a single unnamed graphic.

How this gets tested

The W3C publishes test rules that define what a checker looks for here.

Image button has non-empty accessible nameA tool can check this
Link has non-empty accessible nameA tool can check this
ARIA attribute is defined in WAI-ARIAA tool can check this
ARIA state or property has valid valueA tool can check this
Element with role attribute has required states and propertiesA tool can check this
Form field has non-empty accessible nameA tool can check this
Role attribute has valid valueA tool can check this
ARIA state or property is permittedA tool can check this
Button has non-empty accessible nameA tool can check this
Element with aria-hidden has no content in sequential focus navigationA tool can check this
Element with presentational children has no focusable contentA tool can check this
Menuitem has non-empty accessible nameA tool can check this
Summary element has non-empty accessible nameA tool can check this
Iframe element has non-empty accessible nameA tool can check this
Iframe elements with identical accessible names have equivalent purposeA tool finds candidates, you decide

Other ways to satisfy this rule

23 guides on this site are filed under 4.1.2 Name, Role, Value. W3C lists this one as sufficient for that rule when it is implemented through a more specific technique, so the condition is part of the test rather than a footnote to it.

This guide is our interpretation of W3C technique G135: Using the accessibility API features of a technology to expose names and … notification of changes. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.