Accessible Rich Internet Applications

A screen reader is a program that speaks what's on screen. What it says, and how, comes from the tags the page is built out of. Something built with a button tag is announced as "Confirm, button." Something built with a heading tag is announced as a heading, which is also what lets a listener skim by jumping heading to heading.

That assumption came under strain as the web shifted from documents to applications. Tabs, accordions, autocomplete fields, hand-built dropdowns — parts that paper documents never had — started filling screens, and there is no tag for any of them. Developers stacked meaningless box elements and built the look and the behavior themselves.

To a sighted user that's a finished set of tabs. To a screen reader it's three boxes. Which tab is selected shows only in an underline and a color, so it never reaches audio, and there's no way to learn that arrow keys move between them. A toolbar of icon-only buttons comes out as "button, button, button."

The standards body behind the web published this specification to close that gap, and the name is almost always shortened to ARIA. Rather than inventing new tags, it adds attributes that record role and state on elements that already exist. The box stays a box, with a note attached saying "this is a tab and it's currently selected." Nothing about the visual page changes; the note only travels to assistive technology.

It does four jobs.

1. It announces roles. Put a role attribute on a part built from boxes and a screen reader will read it as a tab list or a dialog. Only then does the user learn that arrow keys work here, and that what just opened sits on top of the page rather than below what they were reading.
2. It announces state. Whether a collapsed section is currently open, whether a checkbox-shaped control is currently on — those get written as attributes. Sighted users read that from an arrow direction and a color, and none of that reaches audio. With the open state recorded, the control reads as "menu, collapsed," and expanding it reads as "expanded."
3. It supplies names. An icon button with no text inside has nothing to read, so it becomes plain "button." A name attribute turns the toolbar into "share button, comment button, delete button," which makes it work like a table of contents.
4. It announces changes. When a whole page navigates, a screen reader starts reading again; when one corner of the page updates, nothing happens at all. Mark the region where "Saved" flashes after a save, or where a result count updates while someone types, and that change reaches audio. Without it, a user who can't see the toast presses save several times, unsure whether it took.

There's a fifth use that ties elements to each other. Connect an input to the error text under it and focusing the field reads "email, edit, that format isn't valid" in one pass. Leave them unconnected and the red text stays on screen only, which is how someone ends up resubmitting the same form three times without ever hearing why it was rejected.

Other tools come first. The specification's own first rule is not to use it when you don't have to.

1. Semantic markup — using the tag that matches the meaning. A button built from a button tag carries its role and name for free, and keyboard navigation and a focus ring come with it. Reproducing all of that on a box takes far more work.
2. Parts the browser already has — dialogs and disclosure widgets now have standard tags. They bend less than something hand-built, but keyboard handling and focus management are already inside.
3. Vetted component libraries — tabs and autocompletes from widely used libraries already handle the attributes. That's safer than building one and applying the specification incorrectly.
4. Simplifying the design — not building the complex part at all is a real option. Lay the items out in sequence instead of behind tabs and no attributes are needed.

Meeting an accessibility standard like WCAG puts this specification closer to a last resort. It's for the places the four options above can't reach, and a review that opens with a list of attributes to add has usually skipped a question about markup that would have removed half of them.

"If that dropdown is hand-built, the open state needs to be exposed as an attribute."

A visual indicator alone never reaches a screen reader.

"None of the icon buttons have names, so they all read as just 'button.'"

The whole toolbar sounds undifferentiated to anyone listening.

"That one can just be a button tag, so we don't need ARIA for it."

Fix the markup before reaching for attributes.

Pagedeck's document editor has a formatting toolbar. Noa's mockup had eight icon-only buttons, and when Theo built it as drawn and listened with a screen reader, he heard "button" eight times. Adding a name attribute to each one made them read as bold, italic, and list — what the icons had meant all along.

The share menu on the same screen had a different problem. It was a hand-built dropdown, so its open state showed only in the direction of an arrow, and opening or closing it produced no audible change. Instead of adding more attributes, Theo swapped it for the disclosure widget the browser already provides, which solved it with no attributes at all.

The most common belief is that more attributes mean better accessibility. Audit tools don't count attributes, but with nothing else to point at, adding more feels like progress. In practice a wrong role is worse than no role. Give a list role to something that isn't a list and the screen reader announces "list, 3 items" while delivering nothing underneath, and the listener assumes they missed something and sweeps the same area again. Attaching an attribute because you can is a different thing from attaching one because it's needed.

The other frequent mistake is expecting a role to bring behavior with it. Put a button role on a box and the screen reader announces a button, so it looks finished. But this specification only communicates; it never creates behavior. Making the element reachable with the Tab key, making Enter and Space activate it, deciding where focus goes afterward — all of that is still code someone has to write. That's how you end up with something announced as a button that does nothing when pressed.