Four simple accessibility improvements to apply today
Posted on 04/02/2024
One of the topics I've gotten the most interested in when I first started branching off to front-end development is accessibility. It's sweet to see that it's been getting more and more traction these last few years, but many websites and web apps are still largely unstructured to support proper usage by folks who rely on screen readers and/or keyboard navigation only.
It takes great intentionality and active studying to learn all the little accessibility tweaks available to us in modern HTML and CSS, even more so to apply them systematically on a project. So, to ease that a little bit and maybe, who knows, help you make your website a bit more accessible, I thought of sharing a couple of the techniques I applied to mine.
Every interactive element on the UI should have an accessible name. If we're talking about text-based buttons, the DOM automatically uses the string on it as its accessible name through the
aria-labelledby attribute. However, when it's a case of a button without a string, we must intentionally add a name for them by using the
aria-label attribute. That's what I did with the nav bar's dark and light mode toggle.
Folks navigating through your website using just the keyboard need to know which element they’re currently in visually. We allow them to know that by adding
focus-visible styles to all interactive elements. You can apply any valid CSS under this pseudo-class, but the
outline property is the most common.
"Jump to content" button
If you get into my website, or actually any, and start pressing the
To ease that, we can add a “Jump to content” button as the first or second focused item if you start tabbing right after the site has loaded. This button will jump to whatever element you deem “content”, skipping the navigation items.
I've done that by simply adding an
id to the element I wanted to jump to and adding it to the
href of the button (which is actually being rendered as an
Be aware of nested interactive elements
What made me think of this last one is the card component that renders as a tag, which I have in many places on my site. Note how, in several instances of it, there's usually a call to action reading “Read the story” or something similar. These elements are added using the Button component I showed how to build in my previous post.
Technically speaking, the main issue here is that you shouldn't nest two interactive elements, as that's considered to be invalid HTML.
However, no visible error will happen if you do it. The accessibility-related implication is that interactive elements have the same
tabindex level of 0, meaning they will be focused. In this specific situation, the button doesn't do anything, given it's the whole card that's clickable.
To solve this, I did a super light implementation of “component polymorphism”. This Button component of mine is just rendered as an actual button if I pass the
button prop, otherwise, it's rendered a div, which is not interactive by default, therefore, not focusable.
Quick note about polymorphic components
Polymorphic components is a considerably more complex subject than just what I mentioned here, especially if you're using TypeScript. To not sidetrack this post too much, I highly recommend giving a jump to Sandro Roth's article about it!
I’m learning more about accessible HTML and CSS more and more every single day, and I highly recommend you to look into it as well! It will not only help you to make more accessible web products, as well it will teach you a lot about design systems, component API, and generally speaking, the importance of using the tools correctly.