Is Your Web Site Really Accessible?
Why accessibility matters and how you can check and eventually fix it on your website.
Let me start with a tale: it can happen that one day, while you are developing a website, thinking about design, fixing bugs and working with bundlers, your stakeholder suddenly shows up with this question:
“Wait… Is this website accessible?”
Web trends
The world of the web development is always changing. New trends are out every month, and trends that seems promising become old-fashioned in no time. We all agree that Web Accessibility is not a trend, but rather an inclusive practice. Even so, it is seen as a trend, while at the same time it has strangely become something less trending and interesting than other trends, like Web AR or Service Workers.
This doesn’t mean that no company is working hard for a great accessibility in their website, but rather that it is often not a requirement that stakeholders actually ask to developers. Although this trend may change, anyone can check some web site and understand that the current situation is not good.
This, in my opinion, is a really bad thing. Accessibility is more important than a lot of other “fancy” web trends, as it makes contents available to users that, in other circumstances, can not reach them. Making contents available to every user should not be an optional requirement for a website.
Spoiler: the Web is not so accessible.
Returning to the initial tale of this article, if not already clear, the answer is often: no.
Making a website really accessible is not something that comes with no effort. It takes sensibility about the topic, tools, specific design guidelines and a lot of tests. It covers several sub-topics, like:
- page structure (HTML, XML, etc.) and element attributes
- style guidelines (i.e. colour contrasts)
- keyboard navigation.
- other minor aspects.
Moreover there are a lot of websites that embed tools to enhance the readability of the page, making possible to change contrasts, colours and fonts. While these improvements are surely important, they are not enough to make a website fully accessible. These cases affect the accessibility ecosystem of the web creating even more confusion about what “accessible” means.
We would like to give a little help to the web accessibility ecosystem. We will introduce a set of tools that make easy to check and fix problems of page structure and style guidelines (we have already covered keyboard navigation in another article). This is not enough to make a site really accessible but at least we can make it compliant with several W3C Web Accessibility Guidelines (WCAG).
Let’s start!
The Pa11y project
Pa11y is a project that includes a set of tools to test accessibility of a website. Among W3C Accessibility Tools List it is my favourite for its flexibility that makes possible to use its Javascript APIs as well as its CI tools.
The main interface of Pa11y is the one provided by its Command Line Tool. To have a first look of its potential, you can type on a terminal:
npm install -g pa11yin order to install Pa11y, and then:
pa11y --standard WCAG2AAA --reporter json http://google.com > report.jsonPa11y will test Google website, using the “triple A“ standard of W3C and it will output the report on a JSON file.
You can check all other command possibilities on the Github page or typing
pa11y --helpThe Pa11y CLI shows its potential when used on a Continuous Integration flow. You can run tests, also with different error levels, in different phases of your CI flow. Integrating an automatic accessibility check will make easier to find and eventually fix errors. Pa11y will show, for every error, the associated W3C rule and in some cases, like contrasts errors, the most similar colour in order to fix the error. Last but not least, Pa11y differentiates between three different levels of errors, based on severity: error, warning and notice.
Can we do even more?
As you can see, there are tons of possibilities, but we have also seen a lack of simplicity to check websites and also a lack of an advanced tool for web developers.
This has lead us, as a team, to develop two complementary tools to the Pa11y CLI: a Browser Extension and a Web App. We have also given a name to our new accessibility checking ecosystem: it is called A11ygator.
Meet the A11ygator
First of all, let’s see our A11ygator Browser Extension.
It is a free tool for web developers to check compliance with the WCAG rules. Once the extension has started, it will observe for content changes in the HTML document and it will generate a report with errors, warnings and notices. You can see them on the extension’s popup. This way, you will get a first idea of the accessibility of the current web page, so you can decide whether to inspect more or not.
Thanks to the integration with DevTools, it is easy to inspect elements and quickly update CSS rules or HTML attributes in order to match the required WCAG standard. For a complete report of the page, use the Chrome DevTools section (Elements > A11ygator). You can inspect and live debug accessibility issues.
Last but not least, it is possible to download the JSON report: this can be useful for a developer that wants to make a custom report based on raw results.
At the moment, this extension is freely available for Chrome and Firefox.
The other tool we are pleased to introduce is the A11ygator Web App, that can be found at https://a11ygator.chialab.io.
Its aim is to provide an easy tool for accessibility tests for users that are not developers or just not comfortable using dev tools. It is a simplified dashboard where you can type the URL to check and get the full report.
It uses Pa11y under the hood, and provides a simply interface with a form that lets you choose the WCAG standard and the wait time — the time to wait before A11ygator actually starts to test, useful for websites that may take some seconds to render the content.
Also, you will get a screenshot of the actual page that A11ygator has tested, plus the possibility to download the report in JSON format, same as the browser extension.
A11ygator tells me there are no problems on my website… so it is accessible!
Well… no. We really want you to understand this fundamental aspect of web accessibility.
Keep in mind that even if a website is checked as “accessible” from automated tests, its usability and accessibility has still to be tested from humans, possibly from professional individuals with real disabilities.
But don’t worry, this means that you are on the right track! The automated tests are the first achievement, a very important one. Without that, you can be sure no humans tests can be very gentle with your website. What comes now is tests about usability and accessibility in terms of reaching the contents. Contents on your website are the most important part, and they have to be reachable by any human, regardless of their disabilities.
This will be the most challenging step, but we can assure you, it will be also the more rewarding one.
A11ygator is an open source project by Chialab. If you are a developer willing to help us improve this ecosystem, you can check the repositories here:
- A11ygator web-app: https://github.com/chialab/a11ygator-app
- A11ygator-extension: https://github.com/chialab/a11ygator-extension.
Chialab is a design company. By developing strategy, design, software and content, we generate exciting relationships between brands and people. https://www.chialab.it.
