When I getting into accessibility, of course one of the first things I learned about was Accessible Rich Internet Applications or ARIA. I thought this was a magic bullet you always had to use. Not could use, not might use. Had to use. After all, how can you make a <button> accessible if not with ARIA roles and attributes.
Sprinkling attributes over every interactive piece would make everything I touched accessible like magic. It took time, and some uncomfortable feedback from people, to realise that every extra role or property carried a cost.
I now treat ARIA with much greater care. Honestly, I can safely say I am sometimes afraid of using it. I never really know when the right time to use it is and when to stick to the basics. Maybe that's because I still had to learn the basics. But no, even now when I have a much better grasp on the basics, I still try to avoid ARIA.
The Web Almanac's section on ARIA provides some insights into why myself along with others fear this thing.
ARIA is both essential and risky. You can use it to fill gaps that HTML can't cover. But you can also overuse it and steadily make your site harder to use.
If I can reach for a plain <button> or a proper <nav> element, I do that and avoid ARIA entirely. Native elements give me keyboard support, semantics and predictable behaviour for free.
I've also learned to be suspicious of "quick fixes" or hiding weird content like icons with aria-hidden="true". Those tricks might satisfy a code linter, but they often leave someone using a screen reader stuck or confused.
Sometimes, I do need ARIA. Maybe I'm after a custom dialog, a tab interface or live updates. I add only what the pattern requires and I make sure the visible text and accessible name actually match.
I know all this. And I take great care.
And I still mess it up!
I imagine many others don't pay that much attention and reaching for aria-label is second nature. That's why the use of ARIA roles and attributes rose across the board in 2025. All the things I am scared of like aria-role, presentation, aria-label, aria-labelledby (which I so often misspell to just aria-labeledby), aria-hidden, aria-expanded and aria-live all saw increased usage year over year.
Developers add the button role to non-semantic elements or redundantly to real buttons. This suggests many sites are papering over weak markup instead of fixing it. Many are labelling more controls programmatically, with many buttons using only aria-label and no visible label. Unfortunately, this creates a mismatch between what sighted and non-sighted users perceive.
My turning point came when, in a user testing session, a person who was blind tried to use a dropdow menu I had built. They paused, then said, "I can hear something is there, but I can't tell what it is meant to do." They couldn't select anything in that menu.
That moment hurt.
So I don't use ARIA more than I have to. If that.
But not a day goes by, honestly, when someone doesn't ask me about ARIA. And not a day goes by without me learning something new about it. As scared as I am of it, I have to learn it and I have to use it. I couldn't answer any of those questions if I didn't.