In the previous article, we've discussed accessibility and how to place yourself into the minds of those who need extra effort from our side to make their lives easier.
Let's take the next step and see what we can do to make your website better. Sure, you can read Web Content Accessibility Guidelines (WCAG) and fix the issues you find, but are we programmers or not?
Fortunately, we have an impressive variety of accessibility tools we can use. These could be plugins and online services or software applications, open-source or enterprise, so you have an extensive choice. Here are some examples of software available for free:
WAVE
WAVE, developed by WebAim, is a set of tools for assessing web content accessibility for people with disabilities. It visually represents accessibility issues within a web page and explicitly covers accessibility problems with images, headings, labels, and colour contrast. Enter a URL online, install the browser extension, or use the API service.
AChecker
AChecker is an open-source web accessibility checker created to ensure websites are free of accessibility problems. The tool allows users to set their own guidelines to evaluate HTML content by entering a web address, uploading an HTML file, or pasting a complete HTML source code from a web page.
Google's Accessibility Developer Tools
Google Chrome is the most popular browser. And a considerable number of accessibility tools are Chrome plugins. ADT is one powerful example of a Chrome web accessibility checking tool, but there are many more.
Tanaguru
As mentioned in the previous article, many WCAG compliances are driven by laws and government policy. Each country will have its own rules. Tanaguru is one of the tools giving you a perspective not only on WCAG but also on RGAA (the French General Accessibility Reference Framework for Administrations).
Pa11y
Pa11y presents a range of open-source web accessibility tools helping to test and improve accessibility. The Pa11y dashboard can automatically test and monitor web pages for accessibility issues daily and create graphs to help track improvements and regressions over time. You can use UI to interact with Pa11y or integrate it into your code.
These are just a few tools you can use, and you'll find many more free or enterprise solutions with broad functionality available.
What tool to choose?
If you have a budget and dedicated team, you can go all-in with n expensive enterprise solution, but you can start with baby steps. We have selected Pa11y, as it appeared easy to use and integrate into our development processes, involving only one developer from the beginning.
Installing PA11y is straightforward. Just run one command in your node environment:
npm, install -g pa11y.
Out of the box, Pa11y provides everything you need. You can test a local file using pa11y ./path/to/your/file.html. Or run a default audit with one command, pa11y http://example.com. You can compile a .CSV file using the --reporter flag or opt for the in-terminal report to print out to you on-screen.
Pa11y utilises WCAG sources in the reports. You will see a list of the WCAG guideline for each error. Users can check that feedback and read the guideline success criterion within the WCAG standard documentation.
The report can be a little difficult to understand at first, but you'll get used to it. For example, if the error lists this "WCAG2AA.Principle1.Guideline1_1.1_1_1.H37", the guideline error is WCAG 2.0 AA Principle 1, Guideline 1.1, Success Criterion 1.1.1.
It's good to start with, but obviously, you will not run it manually, especially on huge websites. Therefore it's time for tool number two, Pa11y-CI. As the name suggests, Pa11y-CI comes in handy when working with continuous integration. Built with Pa11y, it runs accessibility tests against multiple URLs. You can run it automatically through all your website on every PR, before it gets merged, ensuring that no accessibility errors make it to production.
You can find more details on the Pa11y integration process if you are ready to get to practice. I find this article to be covering pretty much what we need at this step: https://webdesign.tutsplus.com/tutorials/web-accessibility-testing-via-the-command-line-with-pa11y--cms-34538.
When you first run it, though, you'll probably get a lot of errors, so it might be not a good idea to enable it right away in full power and stuck in a situation where nobody will be able to merge their PRs. So you can mute it with --threshold <number> flag, initially setting the number of errors you have at the moment. Like this, you'll still be able to get reports, but be sure not to increase the amount of errors. And while others are working on their tasks, you would be able to continue fixing all the accessibility issues. With time you'll minify the threshold until you come to zero and never have those accessibility problems tracked by Pa11y in production ever again.
And once you get everything set up, make Pa11y check a mandatory step on every PR prepared to be merged into your code, set the threshold to zero, and you'll see how every change might affect accessibility.
It is worth mentioning that you should not be working on the problem alone. Tell your colleagues about your significant work, and make them involved. Otherwise, you'll get stuck with fixing issues forever while the others continue creating them. So share this article, explain why this process is fundamental and explain what the errors mean and how to think about potential problems before they appear. An excellent place to start educating your colleagues might be the free Udacity course on Web Accessibility: https://www.udacity.com/course/web-accessibility--ud891.
You have everything you need to initiate this helpful routine right now. So make it work. And when everybody starts to care about needs of the others, your product will become much better. And don't stop on one tool. It covers some things, helping you cope with potential complaints, but if you really want to make a change, test your product on real users with disabilities or arrange a third-party assessment to evaluate your website accessibility professionally. Don't wait until you are officially informed. You must have a look at web accessibility.
So if you have not done it yet, start now with simple steps and switch off your trackpad.
Top comments (0)