The solution
Rich web apps broke a quiet contract. A button made from divs and JavaScript might look right, but assistive technologies could not know what it was or whether it had changed.
The blunt solution was to wait for new native HTML controls. WAI-ARIA instead created an overlay: authors declared roles, states and properties, and user agents mapped them to the accessibility APIs already used by desktop software.
W3C published WAI-ARIA 1.0 as a Recommendation on March 20, 2014, explicitly framing it as a specification for making dynamic, interactive web content accessible.
The genius was compatibility. ARIA let teams repair existing widgets and build new ones without abandoning HTML, while later HTML and SVG work could absorb the same semantic vocabulary.
What it achieved
Patch semantics, not widgets
Why it worked
It met developers where they were: custom controls already existed and needed a repair path.
It gave browsers and assistive tools a shared mapping target instead of per-site hacks.
It separated visual behavior from accessibility semantics, so design systems could remain flexible.
What can be applied
When a platform is already everywhere, the winning accessibility layer may be the smallest semantic overlay that old content can adopt.
Aftermath
ARIA became part of the everyday web accessibility toolkit and a dependency for complex design systems. It did not remove the need for native semantic HTML, but it gave dynamic interfaces a standard bridge to screen readers and other assistive technologies.
FOLLOW THE EVIDENCE