Where markup says what it means, a screen reader just reports it. A <button> element announces itself as a button. A <label> element binds descriptive text to the field it names. Nothing has to be guessed. The interesting history is everywhere else.
Take a <span>, a generic container carrying no meaning at all, styled to look like a button and wired with a JavaScript click handler so it behaves like one. A sighted user sees a button. A screen reader reading the markup sees a <span> that happens to respond to clicks. WebKit's accessibility engineers treated the handler as evidence: if an element listened for clicks and declared no role of its own, VoiceOver announced it as "clickable." A reasonable inference. Also a bet: that whatever listens for a click is what someone is meant to click.
The bet broke when JavaScript frameworks began delegating event handling. A single listener on a container element can manage interactions for dozens of children inside it, which is ordinary and efficient practice. Click events also travel upward through the document tree, so to the heuristic every child of that container looked independently clickable. WebKit's engineers noted that proper and improper delegation were programmatically indistinguishable. They chose to announce too many clickable elements rather than risk hiding a real control. The repair had a direction of failure, and they picked the one that seemed less dangerous.
Table classification ran on the same logic. HTML tables had been widely repurposed for page layout, so browsers needed some way to tell a table of data from a table holding a sidebar in place. Firefox's accessibility engine still maintains an elaborate classifier weighing borders, row counts, alternating row colors, nesting depth, and width relative to the page. Restyle the table and you change what it is taken to be, without changing anything about the information in it.
Form labels were a third version. HTML kept a field's machine-facing name separate from the words shown beside it and left the connection to screen position. A 2010 study found explicit label associations on 11% of the 7,800 form fields it examined. The fallback, reading nearby text as the label, held only while visual layout and source order agreed.
The WAI-ARIA specification was the structural answer. Its 2008 roadmap said plainly that extracting semantics from HTML content and presentation was unreliable, and proposed a declarative vocabulary of author-declared roles, states and properties, so that a custom control could state its purpose rather than leave it to be reconstructed.
Structural answers work when they are adopted, and adoption follows incentives. The WebAIM Million survey in February 2026 found 33% of detected form inputs still lacking a proper label, 31% of home pages containing empty buttons, and 95.9% of the top million home pages carrying automatically detectable accessibility failures. The vocabulary has been available for eighteen years.
So the heuristics stayed. Nothing replaced them; they settled into the browser as standing equipment for a gap no one had much reason to close. Authors don't absorb the cost of the ambiguity they ship. Screen reader users do, and so does every other piece of software that has to interpret the result.