A role is a promise
ARIA changes what a control is announced as and nothing else — no keyboard behaviour, no focus management, no styling — so every role you add is a promise to hand-write the behaviour the native element would have given you for free.
Somewhere in the review gate there is a div with a role on it. Probably several. The confidence chip that had to be a span because a native element would not take the styling. The field picker that grew out of a dropdown menu. The approve control that started as a button and became a div the day someone needed it to contain two lines and an icon.
Each of those roles did exactly one thing: it changed what the control is announced as. It did not make anything focusable, it did not bind a key, and it did not draw a focus ring. Whatever behaviour a native element would have supplied, you now owe by hand, and the role is the note you signed saying you would supply it.
The sentence the whole module rests on
The Authoring Practices Guide states it in its opening guidance: “Unlike HTML input elements, ARIA roles do not cause browsers to provide keyboard behaviors or styling.” Two things named, both absent: keyboard behaviour and styling.
This course adds a third to that list, and it is worth being precise about where the third comes from. An added role does not put the element in the tab sequence, because tab order comes from tabindex and from native focusability, neither of which a role touches. It does not move focus anywhere when the widget opens or closes. That is a direct consequence of the quoted sentence rather than a second quotation, and it is this course reasoning from the first fact to the second, not the APG adding focus management to its own list. Say it that way when you cite it.
The same page carries the maxim the rest of the guide hangs from: “No ARIA is better than Bad ARIA”. A wrong role is not a partial credit. A div with no role is announced as nothing in particular, which is bad. A div with role=“button” that cannot be reached by Tab is announced as a button that is not there, which is worse, because the screen reader user has now been told something false and will spend time looking for it.
Four rules, and the status of the document they live in
The formulation most people quote comes from Using ARIA, and there are four rules, not five. Verbatim:
- “If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.”
- “Do not change native semantics, unless you really have to.”
- “All interactive ARIA controls must be usable with the keyboard.”
- “Do not use role=‘presentation’ or aria-hidden=‘true’ on a focusable element.”
Rule three exists because of the sentence at the top of this lesson. Nothing supplies keyboard operation for you, so the rule has to be written down as an obligation.
Now the part that matters for a course about citing accurately. Using ARIA is published as a W3C Discontinued Draft, dated 24 February 2026. Quote it for its formulation, which is clear and widely recognised, and do not present it as a live standard, because it is not one. If a claim needs to rest on normative text, it rests on WAI-ARIA itself.
Where people get burned
The most common citation error in this subject is treating the Authoring Practices Guide as the specification. It is not. The APG is guidance about applying a normative spec; WAI-ARIA is the spec. The practical difference: a pattern page can tell you that Escape closes a dialog, and that is a recommended implementation you should follow, not a requirement any conformance claim can be written against. When you write a finding, cite the WCAG criterion for the obligation and the APG for the implementation, and keep the two in different sentences.
The ledger: what each role costs you
Here is the useful mental move. Every time you type a role, write down the behaviour a native element would have handed you for that role, and treat that list as work in your sprint. Four examples you will actually hit in an agentic surface:
| Role you added | What you now owe by hand |
|---|---|
role=“button” | A tab stop (tabindex=“0”), activation on both Enter and Space, a visible focus indicator, and a disabled state that both looks disabled and reports as disabled. |
role=“checkbox” | A tab stop, Space toggling the state, and aria-checked kept truthful on every path that changes the value, including the ones your code does not initiate. |
role=“dialog” | An accessible name, focus moved into the dialog on open, the tab sequence kept inside it while open, and focus returned when it closes. |
role=“tree” | One tab stop for the whole widget, arrow-key navigation between and across levels, expand and collapse state on every parent, and a decision about how the active node is tracked. |
The tree row is four items long and none of them are optional. That is the honest cost of the role, and it is the reason the next lesson exists: the guide has already written the keystroke tables, so the cost is knowable in advance rather than discovered halfway through.
Where this lands in the conformance note
4.1.2 Name, Role, Value, Level A is the criterion this lesson serves, and the criteria lesson deferred to here for a reason: it is invisible in a screenshot. Its own Understanding document notes that it is primarily for authors who script their own components, because standard HTML controls satisfy it when used to specification. ARIA is how you satisfy 4.1.2 on a component you wrote yourself. A role that is wrong, or a role whose behaviour was never written, is how you fail it while looking fine.
Rule three of ARIA use has a criterion number behind it too: 2.1.1 Keyboard, Level A. A control that announces as a button and cannot be operated from the keyboard fails 2.1.1 as well as 4.1.2. Two Level A failures from one div, which is a useful thing to be able to say out loud in a prioritisation meeting.
Check your recall
Answer from memory — no scrolling back.
Retrieval check
Without looking: state what an added ARIA role does not give you, and name the two Level A criteria a role-without-behaviour typically fails.
Check your answer
A role changes what the control is announced as. Quoting the APG, it does not cause browsers to provide keyboard behaviors or styling. Adding to that by reasoning rather than by quotation: it does not add a tab stop, and it does not move focus.
The two criteria: 4.1.2 Name, Role, Value, Level A when the role misdescribes the control or its state is not programmatically determinable, and 2.1.1 Keyboard, Level A when the control cannot be operated from the keyboard at all.
If you reached for 2.4.7 Focus Visible here, that is a real neighbouring failure but a different one: 2.4.7 is about whether an indicator exists once focus arrives, and the problem in this lesson is that focus never arrives.
Hands on
Inventory every role in the review gate
Done when: You have a list of every ARIA role in the review gate, and beside each one a plain-English note saying which native element was ruled out and what behaviour you wrote to replace it. At least one entry says “nothing was written” and has a criterion number and a cost attached.
- Grep the review gate’s components for
role=,aria-andtabIndex. Do it across the whole feature, not just the gate’s own file, because the chip and the picker probably live in shared components. - For each role, write the native element you would have used instead. If the honest answer is that a native element would have worked, that is a finding on its own and rule one of ARIA use is the citation.
- For each role, list what you owe: tab stop, key bindings, state attributes kept truthful, focus movement. Use the ledger table above as the starting shape and extend it for roles it does not cover.
- Tab through the gate with the mouse pushed out of reach and confirm each roled element is actually reachable and actually operable. Every one that is not becomes a row: 2.1.1 Keyboard, Level A, with a cost.
- Add the rows to
CONFORMANCE.md. Mark the provenancehuman, because no scanner told you any of this. Leave the accessibility-supported field as it stands; nothing in this lesson earned the right to change it.
What this does not cover
This lesson says you owe behaviour and does not say what the behaviour is. The four-patterns lesson is where that gets specific: combobox, disclosure, dialog and tree, each against its APG pattern page, down to which key does what and which attribute has to stay truthful while it happens. It also works through the choice the tree row above left open, between a roving tabindex and aria-activedescendant.
The dialog row is deliberately thin here. The full focus contract for an overlay, and the one WCAG criterion people reliably misread when they argue about it, is the focus-in-an-overlay lesson. And the interoperability testing the APG says is essential is the screen-reader lesson, which is also the first point in this course where the accessibility supported line in the conformance note can stop saying “none verified” honestly.
Read this next — primary source
ARIA Authoring Practices Guide: Read Me FirstW3C Web Accessibility Initiative — free. Guidance about applying the ARIA specification, and explicitly not the specification itself.
Four screens long and the highest-value four screens in the whole guide. It states the two things this lesson is built on: that ARIA roles do not cause browsers to provide keyboard behaviors or styling, and that testing assistive technology interoperability is essential before shipping anything from the guide. It also frames the guide as guidance rather than specification, which is the distinction that keeps a citation honest. Read it before the pattern pages, because every pattern page assumes you already have.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.