Accessibility ≠ Overlay: ARIA does not magically fix poorly built HTML
After semantic HTML comes a common misconception: adding ARIA attributes does not automatically turn a poorly built component into an accessible one. ARIA communicates semantics to assistive technologies, especially in dynamic interfaces and custom controls, but it does not replace behaviour, keyboard support, focus management or sound HTML.
ARIA matters, but it is not a repair layer
WAI-ARIA communicates roles, states and properties to assistive technologies, especially for dynamic content and advanced controls. It complements or extends HTML; it is not a universal repair patch.
First rule: use native HTML when you can
W3C recommends maximising native semantic HTML. If an HTML element already provides the needed semantics and behaviour, it is usually more robust than rebuilding it with a generic element and ARIA.
A role is a promise
W3C states an essential principle: “a role is a promise”. <div role="button"> promises button behaviour, but the role itself does not add the keyboard interaction of a native button.
ARIA communicates semantics; it does not create behaviour
ARIA can expose that something is a button, expanded or selected. It does not automatically implement Tab, Enter, Space, arrow keys, focus management or JavaScript logic. Semantics and behaviour must agree.
Name, role, state and value
WCAG 4.1.2 requires programmatically determinable names and roles and relevant states, properties and values. Standard HTML controls already provide much of this when used correctly.
Incorrect ARIA can make the experience worse
Incorrect ARIA is not neutral. W3C warns that “No ARIA is better than Bad ARIA”. Wrong semantics can misrepresent the visual interface to someone relying on a non-visual experience.
ARIA needs real testing
ARIA Authoring Practices examples warn about support differences across browser and assistive-technology combinations and recommend testing before production.
What does this have to do with overlays?
The same lesson applies to overlays. A layer may modify attributes after load, but accessibility depends on semantics, interaction, keyboard, focus and states working together. External ARIA does not automatically repair a defective interface.
What about Blind Reader?
Blind Reader belongs on the user-assistance side. It can help a person work with content, but should not be presented as automatically fixing ARIA or HTML or as proof of WCAG conformance. The website remains responsible.
The idea to remember
ARIA is powerful when needed and implemented correctly. First use native semantic HTML where possible; then ARIA where necessary; always implement correct behaviour, keyboard access, focus and assistive-technology testing.