By the mid-2000s, web developers were building interfaces out of whatever the browser would let them style. A row of tabs might be a few plain <div> elements, generic boxes with no built-in meaning, wired to a script. Sighted users saw tabs. A screen reader, the software that turns a page into speech or braille for blind users, found boxes of text and nothing to press.
ARIA was the repair. It became a standard of the W3C, the web's main standards body, in March 2014, and it lets authors label those homemade parts: role="button", aria-expanded="true". The browser folds these labels, along with what it already knows from the HTML, into the accessibility tree, a structured outline of the page that it hands to assistive software.
A label only describes. A real <button> comes with both meaning and behavior, because the browser supplies both. Mark a div as a button and you have told the screen reader it will respond to Enter and Space; making that true is still your job. The W3C's guide for authors says as much under the heading "No ARIA is better than Bad ARIA", and puts the principle plainly: "A role is a promise."
WebAIM, an accessibility nonprofit, scans the top million home pages every year. Its 2026 count found ARIA on 82.7% of them, not counting landmark roles. Pages with ARIA averaged 59.1 automatically detected errors, against 42 for pages without, though ARIA-heavy pages also tend to be more complicated. A scanner can't say how many of those errors are broken promises of the kind the W3C warns about, or who pays for them. When label and behavior disagree, the cost falls on the person trying to use the page, and nothing in the page reports the failure back to the site.
So the people carrying that cost learned to check. In 2010 researchers documented screen reader users jumping among headings and links, searching for text, and trying another way to activate a control that wouldn't respond. A 2024 review describes users switching browsers, restarting software and, when nothing works, asking a sighted person for help.
Software agents, AI programs that use websites on someone's behalf, now read the same tree. Chrome's debugging protocol exposes it item by item, with role, name and state, and widely used browser-automation tooling hands these "accessibility snapshots" to language models in place of screenshots. The tree is often a cleaner account of a page than a picture of it.
What the agent inherits, though, is the page's description of itself. A screen reader user who presses Enter on a "button" and hears nothing knows the page may be at fault, and has other things to try. An agent that reads role="button" and clicks may have little more than the label to go on. Whether it notices that nothing changed depends on how it was built. If it doesn't, the broken promise lands on someone who never saw the page at all.
The reasons for writing labels are shifting too. When a major AI company launched its browser agent in October 2025, it told site owners that adding ARIA could help the agent work on their sites. Accessibility specialist Adrian Roselli warned that this invites labels written for machines, the way keywords were once stuffed into pages for search engines. For a decade, the main reason to label a control was a disabled user. Now there is a second audience, with commercial weight and no settled habit of checking.
The web already has a tested practice for reading pages skeptically, though nobody wrote it into a standard. It lives in the everyday routines of blind users, and agent builders could do worse than to study it.
