There is a case for utilising static ARIA roles to help user agents understand semantic elements. Giving a <main> element a role="main" isn’t really required anymore, but it also doesn’t really hurt anyone and will help users that are stuck on very old technology.
A good example of using ARIA roles as a dynamic enhancement is improving the <button> element with an aria-pressed="true|false", where applicable. You also don’t really need a role="button", because it’s an actual button and not a <div>. Enhancing what we get given for free is always going to be better than re-invention and producing an often sub-par experience.
It’s important to consider questions like this—especially if you are a global company with millions of users, like Twitter. It’s also worth considering training your team, rather than tooling your team.
Now, with that solid approach, test your work with assistive technology and with real people. That’ll give you a real, accurate account of how accessible your website or app is, because tools can mislead you.
If you find yourself potentially over-engineering an accessibility problem, or any technical problem in general: step back, take a breathe and think to yourself “how can I simplify this and make the platform do the work for me?”. Low-tech is often the best-tech.
Lastly, remember it’s the people who use our websites and apps that we build for. Not acceptance from our peer group and certainly not our own selfish needs.
Big thanks to Heydon Pickering for providing some valuable feedback for this article.
Hi 👋 I’m Andy, a freelance web designer
I’m currently looking to book web design, training and consultancy projects from November 2019, onwards.