ARIA vs HTML

Using ARIA instead of HTML is generally fine for content, layout, structure, and other static bits of a page. A <div role="heading" aria-level="1"> is the same as <h1> as far users and accessibility APIs are concerned. It is unlikely a user will ever notice the difference unless you use both on a site and your styles don’t match between them.

Fighting use of ARIA just because it is not HTML might be wasted energy. Granted, use of ARIA is mapped to a higher incidence of WCAG violations and accessibility issues, though that is a function of developers’ failure to understand it and the tools needed to test it.

Increased ARIA usage on pages correlated to higher detected errors. The more ARIA attributes that were present, the more detected accessibility errors could be expected. This does not necessarily mean that ARIA introduced these errors (these pages are more complex), but pages typically had more errors when ARIA was present.

Once you use ARIA to replace native HTML interactive bits, it starts to get a little riskier. Sure, you can make <div role="button"> functionally the same as <button> once you strap on the correct event handlers. But do you really know all the interactions to support?

Keyboard interaction note for just one control from the entire panoply of HTML controls:

• A native <button> fires on key down when that key is Enter. If you hold down the Enter key, it continues to fire for as long you hold Enter (or something crashes).
• A native <button> fires on key up when that key is Space. If you do not release the Space, and also press Tab to move away from the control, the control will not fire.

I know I would much rather style an HTML <select> than try to make an ARIA listbox work exactly the same across all platforms and contexts.

On mobile devices you can dismiss a native <select> with a gesture. This is handy when you are perusing options but do not want to select the one that has focus. If you use the same gesture on Google’s Angular mat-select (the only one I tested), then you instead navigate backward in your browser history. Which can be a real bummer in the middle of filling out a form.

Not all HTML controls have great accessibility API support. The built-in <input type="date"> date pickers are all problematic in exciting ways. Then again, most ARIA date pickers are even more of a barrier. A good first step is to evaluate if you are reaching for a widget because you need it or simply out of reflex.

Previously I have relied on plain text inputs as date fields with custom validation for the site, typically using the same logic on the client and the server. For known dates — birthdays, holidays, anniversaries, etc — it has tested well.

Separate from the interactions, consider some platform features and how native HTML brings support for free. For example, an HTML button will get appropriate styles under Windows High Contrast Mode (WHCM) while its ARIA equivalent will not.

[…] Try to ensure custom controls give the appropriate visual cues in WHCM after all the fancy gradients and drop shadows and smells are stripped away.

In this pen I compare the styles of a native <button> to a <div>, and offer WHCM styles (proprietary and standards track) to try to reset them to native styles. I even included hover styles appropriate to the browser.

The point is, unless a developer knows all the interaction patterns across all platforms and all assistive technology, and they know all the system-level features for which they will need to replicate support, then they are creating technical debt by not using native HTML.

That seems like a weird flex.