Skip to main content
WCAGrules
Quick navigation

Fixes by subject · 63 techniques

How to Fix ARIA and Custom Widgets

ARIA changes what gets announced and adds no behavior of its own. Used well it makes a custom widget work. Used badly it lies with total confidence.

The first rule of ARIA is not to use it. Where a native HTML element already gives you the semantics and the behavior, use that instead. A real button brings role, focus, keyboard activation and state for free, and none of those can drift out of step with each other. Home pages that use ARIA average more detected errors than home pages that do not, 59 against 42. That says as much about the kind of page that reaches for ARIA as it does about ARIA, and it is still worth knowing before you start. Automated testing will not catch you here either. The rules behind 4.1.2 test that a control has a name rather than that the name is right, so a button called button passes every one of them. Where HTML genuinely has no element for what you are building, the techniques below are the documented ways to do it. They cover roles, accessible names, widget state, page regions, and announcing changes through live regions.

All 63 techniques

They run in technique order, and each one carries a tag. Sufficient techniques satisfy a rule. Advisory ones help without being required. Failures document a specific way of getting it wrong. None of them is mandatory, because W3C publishes techniques as documented ways of meeting a criterion rather than the only ways, so your own approach conforms as long as it meets the criterion.

More on ARIA and custom widgets

The other 13 subjects

Knowing the technique is not the same as knowing you need it.

The free scan checks 10 pages in a real browser and maps every machine-checkable failure to the exact fix guide that clears it.

Run the free scan

Go somewhere useful

Find tools, resources and your workspace.

29 destinations