So, you want to use Tailwind CSS as the framework for your application - but is it Accessible? A11y (accessibility) is an essential way to connect ALL users to your site. Both people with and without disabilities can benefit from A11y. It will also widen the net of users. Not to mention a fully accessible site will help improve SEO as well.
If you are used to frameworks like Bootstrap, Foundation or Material Design with built in components and A11y elements, you might assume Tailwind is similar. At first glance in the documentation, it can very easily seem that way but Tailwind is much more flexible!
What is Tailwind CSS?
Tailwind is a utility-first framework that uses a pre-defined design system using classes. You can easily create custom components right in your HTML.
Some benefits are:
- Use less custom CSS overall.
- Making any changes to styles is much safer across large applications.
- More freedom with how your site looks compared to other frameworks that have pre styled components.
With this flexibility there are some drawbacks when thinking of A11y. One of the key things to note is that Tailwind is not fully accessible in the same way these other frameworks are.
Lets talk about what Tailwind has to offer
Two A11y classes Tailwind provides for us are ‘sr-only’ and ‘not-sr-only’. These classes tell the screen reader to either read the element and visually ignore it (‘sr-only’) or show the element both visually and to the screen reader (‘not-sr-only’).
‘sr-only’ can be added as a class to hide the element visually but still get read by a screen reader. This is really helpful in situations where you need to give instructions to people who cannot access the site visually.
For example, if you have a design with a search bar that has no label or directions in order to make it accessible to a screen reader, you will want to add a hidden label that uses the class‘sr-only’ to clue the user in on what it’s for.
<input type="text" id="search" name="search">
<label for="search" class="sr-only"></label>
‘not-sr-only’ will un-hide the element to the user.
Another example where you can use these is on a “Skip to content” or “Skip to Main” button that only visually shows when tabbed into it and otherwise visually hidden. The class ‘not-sr-only’ needs to be added once tabbed into the element to make it visually seen. An easy way to do this is conditionally to a different state which Tailwind lets you do. It might look something like this:
<a href="#main" class="sr-only focus:not-sr-only">Skip to Main Content</a>
New Tailwind CSS A11y additions
As of Tailwind CSS v3.2 Beta 2 there are new variants for aria-* attributes. These can be used to conditionally style things based on if the aria attribute state is true.
Wait - what are ARIA Attributes?
Accessible Rich Internet Applications (ARIA) is a set of roles and attributes to make websites more accessible to people with disabilities. ARIA attributes can bridge the gap some native HTML elements may lack.
The addition of these variants for aria-* attributes is a huge improvement and a big step forward to make Tailwind accessible.
In the example here, btn2 is using aria-pressed. This lets the user know that there is an element, a button, that has not been pressed but has the opportunity to be pressed. We are using the variant aria-pressed:ring-2. This means that when the button is pressed it will add the Tailwind CSS class ring-2. This will add a border around the button. Without using this Tailwind variant like in btn1, you might have to do something with an event listener and add the class using JavaScript.
<button id="btn1" aria-pressed="false"></button>
<button id="btn2" aria-pressed="false" aria-pressed:ring-2></button>
You can even create custom aria variants yourself within the tailwind.config.js
Check out the Announcements for the complete list of new ARIA additions Tailwind CSS will offer.
So whats missing from Tailwind?
Other frameworks you may have used in the past might contain designed components that rely on event listeners —such as modal dialogs, dropdown menus etc. to work for touch, mouse, and keyboard users out of the box. Since Tailwind CSS is so customizable, as a developer you need make sure you are adding the necessary things to your components with the provided tools Tailwind gives you, or on your own with JavaScript.
While these new additions really take care of a lot, Tailwind CSS still takes manual work to make your website fully accessible.
It's important to do the work as a developer to really understand how someone with a disability may use your site. Test out your site using a screen reader, or try browsing a site without the mouse. Continue to educate yourself on the latest A11y rules. A11y can sometimes be a puzzle to figure out but hopefully the tips here can jump start the process for you when using Tailwind!
Free A11y tools:
A11y Info:
Tailwind CSS:
Top comments (7)
dev.to/philw_/tying-tailwind-styli... has a bit more info on other ways of tying Tailwind to ARIA attributes, including the approach to use prior to v3.2, or for more complicated selectors than the built in ARIA support can handle.
Сongratulations 🥳! Your article hit the top posts for the week - dev.to/fruntend/top-10-posts-for-f...
Keep it up 👍
Thank you!!
Wouldn't you just put the
aria-tags onto your React components?You would definitely want to do that when you can. Sometimes accessibility can be a puzzle. You don't want to confuse the screen-reader by adding too many things or not enough. Sometimes if you're using a framework there are built in accessibility and other times it's your job to add it, so it's important to understand how it all works together!
Been a dev for 15+ years and a11y never gets easier. Just feels to me like an AI-enhanced screen reader is what will turn the tide. Realistically, it's just too complicated to expect small budget sites to get right.
Great article, Ashley.