ARIA state
aria-checked
Whether a checkbox, radio or switch is on, off, or partly on.
It is the answer to the only question a checkbox exists to raise. Change it and the control announces as checked or unchecked from that moment on. Change the visual tick without it and the two now disagree, and the one people hear is this one.
Which roles may carry aria-checked
- Value
- tristate
- Filed as
- A state, which is how ARIA files it and not a rule about how often it changes.
- Roles that may carry it
checkbox,menuitemcheckbox,option,radio,switch- Roles that inherit it
menuitemradio,switch,treeitem
Those lists are not advice. Browsers are required to ignore a non-global attribute sitting on a role that does not support it, so aria-checked on the wrong element is not weak, it is absent. You can read it in the DOM and nobody using a screen reader can.
Every role above comes from the specification's own list for this attribute, checked name for name. The normative definition stays with the W3C, in the aria-checked section of the ARIA specification.
Keeping aria-checked true
Leaving it out is worse than it looks. A checkbox, radio, switch, menuitemcheckbox or menuitemradio carrying no aria-checked is not treated as unknown, it is exposed as false. So the control announces as present and unchecked with total confidence, whatever the tick mark on screen says. The mixed value has a limit worth knowing as well. Radio, menuitemradio and switch do not support it, and neither does anything inheriting from them, so mixed on one of those is quietly downgraded to false rather than rejected. Update it on every toggle, including the toggles your own code performs without anybody clicking.
How aria-checked gets checked
There are test rules that check an ARIA attribute is one that exists, is allowed on the role underneath it, and carries a value of the right type. What they map to is ARIA's own author requirements rather than any WCAG criterion, so a misplaced attribute breaks ARIA without being a WCAG failure by itself. It becomes one under 4.1.2 Name, Role, Value the moment the missing or wrong value means the control's state cannot be worked out programmatically, which is what usually happens next.
Nothing automated catches the failure this page is about. A stale value is a valid value, on a permitted role, with the right type. It is only wrong about the world.
Attributes you will meet alongside aria-checked
- aria-errormessage Points at the message explaining why this field is invalid. Only meaningful while aria-invalid is set.
- aria-expanded Whether the thing this control opens is currently open.
- aria-invalid Says a field's value has failed validation.
- aria-posinset Which position this item holds in its set, when the markup does not contain the whole set.
- aria-readonly The value can be read but not changed. Unlike disabled, it is still part of the form.
- aria-required Says a field has to be filled in before the form can be submitted.
- aria-selected Whether an option, tab or row is the chosen one.
- aria-setsize How many items the set really holds, when only some are in the markup. Together with aria-posinset this is what makes an infinite list announce as 5 of 200.
Every ARIA state and property · Every ARIA role · ARIA explained