The other reality layer

ARIA lets authors create an alternate reality that only screen reader users perceive. It is a markup layer that overrides or supplements what the browser would otherwise report about an element. Think of it as sticky notes placed on tools in a workshop: the note doesn’t change the tool itself, but it changes what everyone believes the tool is. A plain div with an image inside can be declared a slider at value 30 of 100. ARIA does not make it function as a slider; it merely instructs the screen reader to describe it that way.

Critically, ARIA has zero effect on visual presentation, mouse behavior, keyboard focus, or tab order. Those are handled by HTML and JavaScript. Only assistive technologies observe ARIA’s influence. This distinction matters when debugging: keyboard problems are almost always bugs in the content’s HTML or script, not in ARIA.

How the layer is applied

When a screen reader requests information about an element, the browser consults any ARIA present and adjusts its response. Common uses include:

  • Modeling components that have no native HTML equivalent, such as autocomplete, tree views, or spreadsheets.
  • Recreating standard elements whose appearance or behavior an author wanted to change—for example, building a custom slider with role="slider" and aria-valuenow instead of fighting <input type="range"> with CSS.
  • Marking live regions so screen readers announce relevant page changes.
  • Defining landmarks—for instance, declaring a container as the main content area or a navigation panel—so users can move through the page efficiently.

ARIA is also useful for refining otherwise working HTML. A form control can point to an error message with aria-describedby, or a text field can declare its specific purpose. These tweaks improve the experience for screen reader users without altering anything else.

Building a menu bar the hard way

Consider a web store that needs a menu bar. The <nav> element exists, but menu bars are frequently assembled from divs, buttons, click handlers, keypress handlers, and ARIA. A mouse user sees styled boxes, hover highlights, and animated submenus—all perfectly usable. A screen reader user sees nothing but generic containers with no meaning.

Keyboard accessibility comes first and requires only HTML and JavaScript, since ARIA does not affect keyboard behavior. The page listens for keystrokes and decides which to consume:

  • Arrow keys change the active menu item, update the visual highlight, and call event.preventDefault() to stop the page from scrolling.
  • Enter triggers the item’s action, just like a click.
  • Unrelated keys, such as Tab, should be returned to the page. This is easier said than done—a menu bar needs arrow keys but not Alt+Arrow or Command+Arrow, which are browser navigation shortcuts. Getting this wrong happens frequently, even before ARIA comes into play.

With keyboard handling in place, the screen reader still has nothing to report. ARIA fills that gap with a series of deliberate declarations:

  • aria-activedescendant points from the focused menu bar to the ID of the active item—for example, aria-activedescendant="settings-menuitem"—so the screen reader treats that item as the focus and reads it aloud or shows it on a Braille display.
  • role="menubar" marks the containing element, role="menu" marks groups of items, and role="menuitem" marks the individual items.
  • aria-expanded="false" on an expandable item signals that a child menu exists but is closed. The parent element should track this state and update it when the submenu opens or closes.
  • role="none" on decorative elements—like a triangle image hinting at a submenu—prevents the screen reader from announcing something redundant.

Where the layer breaks

Keyboard bugs arise when authors overwrite HTML defaults. A checkbox may fail to call preventDefault() on the spacebar, causing the page to scroll while toggling. A modal dialog that traps Tab may forget to allow Control+Tab for opening a new browser tab. A list that responds to arrow keys still needs home, end, page up, page down, and first-letter navigation.

ARIA misuse is similarly common. An author might choose the option role where menuitem is correct, forget to update aria-activedescendant at the right moments, skip aria-expanded, or omit aria-posinset and aria-setsize when a browser–screen reader combination computes wrong item counts. Each pattern in the spec carries a dozen ways to get it wrong, and most authors are not screen reader users. The nuance is too deep to skip real-world verification: ARIA widgets should be tested by actual screen reader users across multiple browser and screen reader combinations before shipping.

The bottom line

ARIA overrides what HTML says about an element, entirely or in small measure. It can make minor adjustments to an accessibility presentation or construct an entire experience from scratch. That dual nature makes it powerful and dangerous at once. When a screen reader asks what is happening, ARIA’s version of the truth is what the user hears. Getting it right requires knowledge, care, and validation with the people who depend on it. (See the Resources section referenced in the original article for a list of authoring patterns.)

Beyond the WAI-ARIA spec

For practical guidance, the W3C's ARIA Authoring Practices is the go-to reference. It details the essential keyboard navigation behavior for each widget pattern and ships with working JavaScript, CSS, and ARIA code. These examples target what works today rather than future-proofing; mobile interactions are not covered.

How assistive technology actually sees your page

The mechanics behind ARIA hinge on the browser's accessibility API—the layer through which screen readers and other assistive software interpret content. Common examples include MSAA, IA2, and UIA. This API has two distinct components:

  • The object tree: A structural hierarchy of containers and their contents—for instance, a document containing paragraphs that in turn hold text, images, and links. Each object carries properties such as role ("what am I?"), a name or label, user-entered values, descriptions, and boolean states like focusable, focused, required, or checked. ARIA can override any of these native values. Screen readers rely on this tree for virtual buffer navigation, so users can say "go to the next heading" and have the AT jump accordingly.
  • Events: Signals fired when something in the tree changes—"focus has moved here"—so the screen reader can announce the update. Important HTML or ARIA changes trigger these events automatically.

HTML maps cleanly onto these accessibility APIs in most cases. When native semantics fall short, ARIA comes in: you add the attributes, and the browser overrides the underlying HTML meaning before pushing the object tree or events out to assistive technology. This override mechanism is both the power of ARIA and its greatest liability, which is why restraint and proper role selection matter far more than sprinkling attributes everywhere in the markup.