Happy Global Accessibility Awareness Day! We see it fitting to announce a nifty little project we’ve been working on. It’s a browser extension called the BarrierBreak CSS Accessibility Extension and you can install it in Chrome right now.
The extension came about as a result of internal conversations we had regarding finding accessibility issues in the CSS files. You see, there are plenty of tools which check for accessibility issues in the HTML code and the generated code in general, but finding one which checked for the actual CSS files linked to in a page were few and far between. Since it’s a bit of an unexplored area, we felt it’s worth contributing to it.
To be clear, this extension checks the actual CSS files (and any internal css style rules) itself, not the generated code. We took this approach because some of the things we needed to check weren’t possible by just checking the generated output (for example, checking if the author has specified font sizes in pixels or not – you can’t with any certainty determine that with just checking the computed code with javascript).
Here is how to use the extension:
- Install the extension in Chrome by going to it’s page in the chrome web store.
- Once installed, open a site in a new tab (or refresh an existing one so that the extension takes effect there)
- Open up the chrome developer tools (either by right-clicking and selecting ‘inspect element’ or by pressing the appropriate keyboard shortcut in your OS to open it).
- Make sure that the devtools is docked inside the browser window, and not a separate window. (we plan to address this issue in further updates)
- Go to the panel in the devtools which says ‘BarrierBreak CSS Accessibility Tool’
- Once there, click on the button which says ‘start investigating’.
Once done, it will give you a summary of the rules (and their associated WCAG level) it has checked and the number of potentially problematic issues it has identified for each of them. You can then individually drill down to see the CSS file and the associated CSS rule which has the problem. You can also optionally export the results in CSV and JSON formats.
Note: It’s important to note that the extension is in alpha right now, and very raw. However, we wanted to release it and get feedback on whether we’re on the right track with this, and what other features you would like in the extension. In further updates, we’ll be working on making it available for other browsers as well.
The rules are sourced from the CSS Techniques for WCAG 2.0 document. In further updates we’ll have more, but for this alpha release, it checks five of the rules listed in there. Let’s go through them.
CSS Background Images
This comes down to Level A section 1.1.1 (Using CSS to include decorative images). It detects any CSS background images defined in your CSS files and just flags them to remind you to check whether those images are really just for decorative purposes only or not.
CSS Background images should only be used for decorative purposes, and if it actually has a meaning or significance beyond just decoration, then its a good idea to not use a CSS background image and use an <img> element (which appropriate alt text) instead.
Relative Font Sizes
There has recently been a lot of debate online on whether it’s fine nowadays to use pixels or not with regards to accessibility. I personally am still in the camp of using relative font sizes. You can read more about it by reading JP de Vries’ excellent medium article on the topic.
Relative container sizes
Using non flexible container sizes are also generally not a great idea. The extension detects whether you have any container sizes in pixels and advises you to take a re-look at them. Ideally they should be in percentages or other flexible container size units.
Text alignment and line spacing
These are AAA level rules but we still wanted to include them in. One is about making sure that the text is not justified and is either right or left aligned instead.
With line-spacing, it checks whether it is between 1.5 and 2, and if not, then it flags them. Right now it checks all text, not just paragraphs (I’m working on improving this so that it only focusses on paragraphs not things like headings etc in the future). You can read more about the reasons underlying both of these rules in the understanding the success criteria document.
Feedback
We’ll really appreciate feedback on the tool. Is this something you’ll find useful? What would you like to add or change in this? We’d love to know. You can send your feedback to innovation@barrierbreak.com
We’ll appreciate all the feedback we can get!
Legal stuff: This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the Creative Commons Attribution NoDerivs (CC-ND) license