This translation has not been editorially reviewed yet. The German version is authoritative. Deutsche Fassung →
Name, role, value, and status messages: what assistive technology reads from the code
Every control must let assistive technology recognise its name, what it is, and what state it's in. And messages that appear without a page change — "saved", "3 results", "error" — must be announced, without moving the focus.
- Anyone using standard elements meets most of this automatically: a <button> reports its role and state with no extra work. Problems arise with homemade elements — a <div> with a click handler has no role, no name, and no state.
- ARIA is both a tool and a source of errors here: wrongly set attributes make things worse than having none at all. An aria-expanded that doesn't track the actual state actively tells the user something wrong.
- Status messages come up most often with search fields that show instant results: the result count changes visibly, but is never announced. Anyone who can't see it never finds out.
FAQ
Is ARIA always better than plain HTML?
The opposite, actually. Standard elements come with role, name, and state built in; ARIA should only add what HTML can't express. Wrong ARIA does more damage than none at all.
What is a status message?
A response that appears without a page change and doesn't receive focus: result counts, save confirmations, loading notices, error summaries.
Why does the check report errors, even though the page looks usable?
Because "looks usable" and "is machine-readable" are two different things. A homemade control works perfectly with a mouse, and is still just a block of text to a screen reader.