WAI-ARIA
WAI-ARIA is a set of HTML attributes that change what assistive technology reports about an element — its role, its state, its relationships. It changes nothing else: no behaviour, no keyboard handling, no styling. That single fact explains most ARIA bugs, because an element given role="button" still does not respond to the keyboard.
The first rule, and the four after it#
- Do not use ARIA if a native element will do. A
<button>,<a href>,<input type="checkbox">or<details>already carries the role, the state and the keyboard behaviour, and carries them consistently across browsers. - Do not change native semantics unless you must.
<h2 role="tab">takes a heading out of the heading list, which is how a page loses its navigable structure. - Every interactive ARIA control must be keyboard-operable. If you build a widget with ARIA, you also write the key handling the native element would have given you.
- Do not put a presentational role on a focusable element.
role="presentation"on something reachable by Tab produces a control with no name and no role — focusable and unidentifiable. - Every interactive element needs an accessible name. An icon-only control with no label is announced as its role alone, which tells a user there is a button and nothing about what it does.
Where ARIA is the right answer#
HTML has no element for several genuinely common patterns, and this is where ARIA stops being redundant and starts being necessary.
| Pattern | Key attributes | The part people omit |
|---|---|---|
| Tabs | role="tablist", tab, tabpanel, aria-selected, aria-controls | Arrow-key navigation between tabs; Tab moves to the panel, not the next tab |
| Live region | aria-live="polite" or assertive, aria-atomic | The region must exist in the DOM *before* the message arrives, or nothing is announced |
| Disclosure | aria-expanded on the trigger | Updating the attribute when state changes; a static aria-expanded="false" lies permanently |
| Modal dialog | role="dialog", aria-modal, aria-labelledby | Trapping focus inside, and returning it to the trigger on close |
| Combobox | role="combobox", aria-expanded, aria-activedescendant | Almost all of it. This pattern is difficult enough to be worth avoiding |
| Progress and status | role="status", aria-busy | Busy state that never clears leaves a screen announced as loading forever |
Note how many of the omissions are about *state that stops being updated*. Static ARIA describing a dynamic widget is the second-largest family of defects after unnecessary ARIA, and it is worse than none: a user is told the menu is collapsed while looking at it open.
Does Connect use ARIA?#
Used sparingly in the application, and essentially not at all in this documentation. The split follows the first rule rather than a policy preference. The documentation pages are static HTML with no script, so every construct on them has a native element — headings, lists, tables, links, and <details> for anything that folds. There is no widget to describe, so there is nothing for ARIA to add.
The application is a different case, because it has real widgets: a queue that updates while you look at it, tabbed Assistant conversations, a virtualised data grid over thirteen sheets. Those are exactly the patterns from the table above, and they need state attributes kept in step with the state they describe.
Ways ARIA makes a page worse#
- Role on the wrong element
role="button"on a<div>announces a button that Enter and Space do not activate. The user is told they can do something they cannot.- Duplicate naming
aria-labelon an element that already has visible text replaces that text for screen-reader users. Voice-control users then say the visible word and nothing happens.- Over-labelling
- Every list item given
role="listitem"and every listrole="list". Redundant, verbose, and one typo away from breaking a structure that was already correct. aria-hiddenon focusable content- The element is hidden from assistive technology and still reachable by Tab. Focus lands somewhere that, as far as the screen reader is concerned, does not exist.
- Invalid attribute values
- A misspelt state is not an error anywhere visible; it is simply ignored, and the widget silently reports nothing.
The measurable version of all of this: an interface with no ARIA and correct HTML is usable. An interface with heavy ARIA and incorrect HTML is often less usable than one with no accessibility work at all, because the false information cannot be worked around.
Questions#
Does adding role="button" make an element keyboard-accessible?
No. It changes only what is announced. You would also need tabindex="0" to make it focusable and key handlers for Enter and Space to make it activate — at which point you have written what <button> provides, with more code and more ways to be wrong.
Is more ARIA better?
The opposite, reliably. Every attribute is a claim that must stay true as the interface changes, and a claim that has gone stale actively misleads. The best-behaved interfaces tend to use very little, concentrated on the few widgets that have no native equivalent.
How do I test ARIA without a screen reader?
Inspect the accessibility tree in the browser's developer tools: it shows the computed name, role and state for each element, which is what assistive technology consumes. That catches missing names and wrong roles. It does not replace operating the page by keyboard, which is where the state-update bugs surface.