Accessibility Jumpstart 7: Dev & Design Tools
Welcome! Last time we covered basic user testing principles to help us understand that user should come first. However there are some workflows and tooling that can help you catch a lot of the little issues before they even become a problem. I’ll list the dev & design tools I personally use, have looked into, or are part of a workflow I currently work with. Let’s begin.
Simple browser tools
The great part about browser-based digital accessibility tools today is that they are incredibly easy to get started with, however they only catch about 30% of actual accessibility issues, so manual review is still required.
The easiest by far is using Google’s dev tool called Lighthouse is built right into your Chromium-based browser. It gives a very simple overview of basic accessibility checks and ties that to a 0 – 100 score.
Another one, aXe by Deque is my personal favorite. I find the errors and issues it uncovers to be more robust, even checking things to see if roles or attributes are on the wrong sorts of elements. Again, easy to use, free, and works in Chromium, Firefox, and Edge (Chromium).
Other browser plugin tools are:
- Landmarks – Allows you to see and navigate by page landmarks
- ANDI – Used by the US Government to check for accessibility issues
- And a very large collection of accessibility testing and checking bookmarklets
Dev and design workflow
Dev
While I haven’t done any JS workflow work in years, I am familiar with some of the tools that can help do your linting. Your mileage may vary.
- aXe Core – Again, made by the lovely folks at Deque
- Tenon.io – One of the industry standards
- eslint-plugin-jsx-a11y – This one’s caught me not adding a VTT file to my video before and a contrast issue I’d missed 🙂
- And there are others as well, but hey, I’m no dev
Design
I’m typically inside of Sketch a lot these days, however I do use two different design tools to check accessibility while I work.
- Stark – Checks contrast of two elements. Works inside of may design tools.
- Sim Daltonism – A system-wide color-blindness emulator.
Other tools
There are a slew of other tools out there to verify various aspects of accessibility. Here are some I’ve used.
- PAC 3 – PDF/UA checker
- Adobe Acrobat Pro DC – Can automatically remediate some PDF accessibility issues, and allows tagging. Really the only editor that can it seems.
- Microsoft Word, LibreOffice Writer, OpenOffice Writer – All can be configured to create accessible docs, though it seems Word is the only stable option currently
Conclusion
A rather short one this time, but I hope it helps some of you do some basic accessibility remediation using these dev & design tools in your workflows. Next time will be the final item in the series, how to stay current with the ecosystem. See you then!