There’s an ongoing contradiction in SonarQube’s guidance around accessibility roles in HTML elements. Specifically:
- SonarQube recommends using native semantic elements like
<button>for interactive components, as the preferred accessible pattern. - However, it also acknowledges that when native elements aren’t feasible, developers may apply ARIA roles such as role="button” to non-semantic tags like
<div>or<span>, provided proper keyboard and interaction handlers are implemented.
Here’s the issue: when we follow that fallback approach and use role="button” on a <div>, it still fails SonarQube checks in our CI pipeline, reporting role=‘’ as a violation.
This inconsistency creates confusion. If the fallback is acceptable, then the rule engine should not penalise it by default. Ideally, the rule should:
- Recognise ARIA roles used appropriately as a fallback
- Offer guidance on when the role is misused (e.g., missing keyboard handlers)
- Avoid flagging it altogether if implemented with supporting accessibility logic
This would help enforce best practices without obstructing valid implementations.
Screenshots attached for reference. Let us know if this is a rule configuration oversight or something that needs clarification on the rule definition side.
Environment:
- Frontend Framework: React 18+
- Language: TypeScript (strict mode enabled)
- Build Tool: Vite
- ECMAScript Target: ES2022
