presentation-role-on-focusable

This fails the run. Where it is wrong about your code, // ramonda-check-ignore <reason> on the line says so, and the reason is printed on every run.

Reported when role="presentation" is written on an element a keyboard can still focus, where the role is ignored.

presentation and none say the element is scaffolding: expose what is inside it, not it. ARIA drops that role when it cannot hold, and a FOCUSABLE element is the case — it keeps its implicit role. So the element stays in the accessibility tree announced as whatever it really is, which is the thing the role was written to prevent.

Two answers, and which one is right is a question about the page rather than the markup:

Take it OUT of the tab order — tabIndex={-1} on a tag that is not focusable on its own, or a plain <div>/<span> instead of a <button>. Scaffolding a keyboard can reach is not scaffolding.

Or keep it focusable and drop the role. If a reader can tab to it, it is a control, and it needs a name and a role that says what it does.

Next

• All rules — the other checks this one runs beside.
• Checking your app — how to run it, and what it proves.