In a perfect world web front ends would be built with accessibility front of mind but for a million reasons this is not always the case. In recent months I've worked across a couple of large projects retrofitting accessibility and I've learned a few things along the way. I wanted to share a few simple pointers that hopefully could lift our accessible side and generally make us better developers at the same time.
Stop using classes for states
A super common pattern, let's say you have a set of tabs on a page and you want to indicate when a tab is active, most likely you would programmatically add a class, say is-active and then use CSS to highlight the button in some way. This seems fine but assistive technologies don't read this, instead, use aria-selected="true" (or whatever aria attr is relevant) on the element. You can select these easily in your CSS or JS using attribute selectors and your page semantics are just better. As a rule of thumb, whenever you are adding a class for styling, consider if the class is telling the user anything, if it is there is a chance you can find an attribute that will tell a better story.
Use the correct HTML element
It seems obvious but sometimes it can be tempting to use less opinionated markup such as divs & spans instead of a button or whatever. There are many other examples of this where, as front end devs we strive for pixel-perfect replication of the designs and we stray from semantics. This is probably the most common accessibility issue and fixing it can be challenging, sometimes converting the elements to the "proper" tags can break things if JS or styling relies on a specific tag type. In these cases bloated unnecessary aria and tabindexes have to be sprinkled liberally over the page, it's messy and avoidable!
Put stuff in the right order
I most often see this when an element is absolutely positioned, for most purposes it doesn't matter if your little "X" to close a modal is at the start or end of the markup. When adding absolutely positioned tags just take a sec to think about where logically this should sit in the tab order.
A little testing
I know we have a lot to test for when building a feature or fixing a bug and I hate to add to your to do list so I'll keep it short. I would recommend using a screen reader to verify your feature, chromevox chrome extension if free and easy to set up to do a quick check, run an accessibility scanner such as axe (another chrome extension) to point out any technical errors and finally a common-sense check. It's a matter of minutes to check these things and you can head off 90% of issues before they happen.
Of course, there are plenty of other things that can be done but these were the main issues I've encountered. The more I work with A11y the more I want to encourage people to take it more seriously. I hope you find some use in this, I truly believe that following accessible standards will make you a better all-round developer
Top comments (0)