ARIA (Accessible Rich Internet Applications) is a W3C spec that adds roles, states, and properties to HTML so custom widgets can be understood by assistive technology. Where native HTML runs out, the WAI-ARIA specification fills the gap. It doesn't change how anything looks or behaves. It only changes what screen readers, switch software, and voice control hear and report.
ARIA is also the most misused part of the accessibility toolkit. The spec's first rule is: don't use ARIA if a native HTML element will do. That's because ARIA only changes semantics, not behaviour. A div with role="button" still needs keyboard handlers, focus management, and disabled-state logic added by hand. Wrong ARIA is worse than no ARIA. When custom widgets are genuinely unavoidable, the ARIA Authoring Practices Guide documents patterns tested with real assistive technology, though its examples are references, not copy-paste solutions.
Reach for native HTML first. Use ARIA only when nothing native fits, and test custom widgets with a screen reader before shipping. Use live regions sparingly: constant announcements are exhausting.
The web comes accessible out of the box, we just need to know how to use it. With modern advancements in HTML, CSS, and even JS, the tools to build an inclusive experience are more powerful than ever. More accessibility means increased usability for everyone, so let's explore these new tools and best practices, and how they can help us create a better and inclusive web.
ARIA, the Accessible Rich Internet Applications Suite, is a huge topic and full of hard concepts. Learning it becomes even more intimidating when you hear 'the first rule of ARIA is don't use ARIA'. This common adage doesn't mean ARIA will literally never make your webpage more accessible. Let's talk about what it really means.