G10Sufficient technique WCAG 4.1.2 Level A Partly scanner-detectable

Build custom components on accessibility-supported tech

Custom components have to reach the platform's accessibility API, and G10 is the strategy for getting them there. Build on a technology whose components already talk to that API, fill in the name and the other properties, and the exposure arrives with the toolkit rather than being written by hand. The status carries a condition worth reading. W3C counts G10 as sufficient using a more specific technique, so it names the direction and something concrete does the work, which on a web page usually means native HTML controls. Where no standard component fits what you are building, the obligation does not lift. You then owe the name, the role, the settable properties and the change notifications yourself, in a form the API understands.

How we find it in an audit

The accessibility tree settles this, not the source code. A reviewer opens each custom component in an inspector and checks four things. That it reports a name, that it reports a role, that its value can be set from outside, and that changing the value fires a notification. Anything drawn on a canvas gets the closest look, since a canvas exposes nothing by default. Then the same components get driven with a real screen reader, because an accessibility tree that looks correct and a component somebody can actually use are two different claims.

How affected users experience it

A component that never reaches the accessibility API does not exist for a screen-reader user. The page reads straight past it, so a date picker, a rating widget or a custom select arrives as a silence rather than as a broken control. Nothing marks the gap, which is the hard part. The user has no reason to go looking for a workaround, because they never found out there was anything to work around.

Passes vs. fails

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

Passes

A date picker built from native inputs and buttons, or from full ARIA grid semantics, so name, role, value and updates all reach the API.

Fails

A canvas-drawn date picker looks complete on screen and is absent from the accessibility tree entirely.

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 G10: Creating components using a technology that supports the accessibility … 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.