What actually changes when you write `<a href="/settings" role="button">Settings</a>`, and what stays exactly the same?

## What an explicit role does Every HTML element maps to an implicit role in the **accessibility tree** — the structure the browser exposes to screen readers, voice control and other assistive technology. `<a href>` maps to `link`, `<button>` to `button`, `<div>` to a generic role. Writing `role="button"` replaces the implicit role for that node. That replacement is total but narrow. It is total in that assistive technology now believes the element is a button: it is announced as one, it appears in the screen reader's list of buttons and disappears from the list of links, and the user's mental model of how it should respond is set accordingly. It is narrow in that the accessibility tree is the *only* thing that changed. ## What did not change The browser's own behaviour is driven by the element and its attributes, not by ARIA: - **Activation still navigates.** The `href` is what makes a link navigate; the role does not intercept it. - **Keyboard behaviour is still the link's.** Links activate on Enter. Buttons activate on Enter *and* Space. On this element, Space does what it does on any non-button focusable element — scrolls the page. A user who trusts the "button" announcement and presses Space gets a scroll, not an action. - **Browser affordances stay.** The URL appears in the status bar on hover, the context menu offers "open in new tab" and "copy link address", and middle-click opens a new tab. - **Styling is unaffected.** CSS does not read the accessibility tree; `role` only participates in styling through an attribute selector you write yourself. - **The element is still a link to the rest of the platform** — history, referrer behaviour, and how the page is crawled are all `href` concerns. So the net effect of the attribute alone is a lie plus a missing key handler. ## If you insist on the pattern, you owe the contract ARIA authoring guidance is explicit that a link given `role="button"` must be made to behave like a button, which in practice means adding a Space handler that activates it and cancels the default scroll: ```html <a href="/settings" role="button" onkeydown="if (event.key === ' ') { event.preventDefault(); this.click(); }">Settings</a> ``` Even then the browser affordances remain wrong — "open in new tab" on something the user was told is a button is incoherent. That is the tell that the markup is the wrong shape, not that it needs another attribute. ## Choosing the element instead The decision rule interviewers want to hear: **navigation is a link, action is a button.** If activating the control results in a different URL — a new page, a route change, a jump within the document — use `<a href>`. If it operates on the current page — open a panel, submit, delete, toggle — use `<button type="button">`. Styling is not part of this decision; both elements are fully stylable, and a link can be made to look like a button without ever touching `role`. Two related anti-patterns follow the same logic. `<a>` with no `href` is not a link at all: it has no `link` role and is not focusable, so `<a onclick="…">` is the div-button bug wearing an anchor tag. And `<a href="#">` with a click handler that cancels the default is a link whose destination is a fiction — it pollutes history and breaks middle-click, when a button was wanted all along. ## The override rule that surprises people Explicit roles win over implicit ones in general, but not unconditionally. The presentational roles `role="presentation"` and its synonym `role="none"`, which ask the browser to strip an element's semantics, are **ignored** when the element is focusable or carries a global ARIA attribute — a conflict-resolution rule in the ARIA specification. So `<button role="presentation">` remains a button in the accessibility tree, because silently hiding a focusable control from assistive technology would strand keyboard users on an element that reports nothing. It is a useful thing to know precisely because it shows the platform actively defending against ARIA that would break the user. ## What to say Lead with the one-liner — ARIA changes the accessibility tree, never behaviour — then give the concrete consequence: announced as a button, still activates on Enter only, still navigates, still shows link affordances. Close with the navigation-versus-action rule.