Somewhere in a backlog right now sits a ticket titled "add accessibility." It's a well-meaning ticket, and it's also a category error. Accessibility isn't a feature you bolt onto a finished interface like a wheelchair ramp screwed onto a staircase after the building's done. It's a property of how the thing was built. Get the structure right and most of it comes for free. Get it wrong and no amount of late-stage patching fully recovers.
The specification says it plainly, and it deserves to be quoted more often than it's followed:
If you can use a native HTML element with the semantics and behavior you require already built in, then do so.
ARIA is a repair kit, not a construction kit. Every attribute you add is a promise you now have to keep in JavaScript — focus management, keyboard behavior, state updates, the works. A native <button> keeps all of those promises for free. A <div role="button"> keeps none of them until you write the code, and you will forget the Enter key, or the space bar, or the disabled state, or all three.
<!-- Fragile: you now own every keyboard and focus behavior -->
<div role="button" tabindex="0" onclick="submit()">Send</div>
<!-- Free: focusable, clickable, keyboard-ready, announced correctly -->
<button type="button">Send</button>The second line is shorter, more robust, and works for people you'll never meet using tools you've never tried. That's the whole argument in miniature.
A genuinely accessible page is often just a correct page. Most of the baseline is unglamorous and cheap:
Notice what's missing from that list: nothing exotic. No special library, no separate "accessible mode." This is just building the page the way the platform intended.
None of this is anti-ARIA. When you build something the platform genuinely doesn't provide — a combobox, a tab set, a live region announcing async results — ARIA is exactly the right tool, and the design patterns for it are well documented. The rule isn't "never use ARIA." It's never reach for ARIA to recreate something HTML already gives you.
The mental shift is small but decisive. Stop thinking of accessibility as a feature with a cost, and start thinking of it as the standard you're already meant to meet. Features are optional. Standards are the floor. When you build to the floor from the start, the ramp isn't an afterthought bolted on at the end — it's just the way in.