Use the arrow keys to navigate between menu items.

Real talk: Your HTML sucks

3 minutes read

I've seen too much code where the developers treated ARIA like duct tape. Slap a role="button" here, an aria-label there, then stand up and proclaim the site accessible.

Just because you put a "Push to Open" sticker on a brick wall doesn't make it a door.

But I added ARIA!

Cool, you had one issue, now you have five.

The problem is that you think ARIA is a quick fix. But it won't fix anything if your HTML sucks!

ARIA can't replace semantic HTML

A div is not a button! You can add your onclick and your role="button" to it. It's still not a button. You know what's a button?

A button!

The button HTML element is focusable, works with a keyboard and announces itself as a button to screen readers. All by default!

And it's not just buttons! Here are three more examples I've seen just this week.

  1. If you add role="checkbox", your div still won't magically become a real checkbox.

You still need to:

  • handle Space key presses
  • manage aria-checked state
  • manage focus
  1. If you add role="application, your website doesn't magically become a desktop application.

You just actually made things worse. This is because when you use the application role, you become completely responsible for handling everything the browser did for you. This means all keyboard input and focus management. You can't just assume the browser and assistive technologies will do any magic for you.

  1. If you add aria-pressed="true", it doesn't mean the button is now pressed.

You thought you need to add it when the user presses the button. Useless! You don't need to indicate that to a screen reader. This ARIA attribute turns the button into a toggle button, changing its expected behaviour. You can use it for showing something is active or inactive, like the "Bold" toggle in a rich text editor. Not that a page is active! There's aria-current for that, should you really need it.

Why do this?

Here's what I think.

First problem. You don't read the manual. You go by ear. If it's sounds like what you want, you slap it on there and move on.

Second problem. You don't bother to test with a screen reader. Because if you did, you'd notice something doesn't sound right.

Bottom line, if your HTML is garbage, no amount of ARIA will fix it. Garbage in, garbage out.

So fix your HTML first. Then consider only using ARIA when HTML won't cut it. When you do use it, read the manual. And then test with actual screen readers.

Did you enjoy this bite-sized message?

I send out short emails like this every day to help you gain a fresh perspective on accessibility and understand it without the jargon, so you can build more robust products that everyone can use, including people with disabilities.

You can unsubscribe in one click and I will never share your email address.