Testing Web Accessibility

Hi everyone, and let's talk about testing web accessibility today. So first of all, I'm going to introduce myself. My name is Adrián, I'm from Spain. I'm a Team Lead and a Frontend Developer at my company and I'm a huge accessibility advocate. And you can find me almost everywhere under my surname. So, accessibility, I always get the same question about what is this a11y that we see all across the Internet? So, a11y is the international acronym for accessibility and this is because there are 11 letters between the A and the Y in the word accessibility. So, said that I'm going to use these a lot in the presentation. So why is so obvious in the real world that those four situations are completely wrong?

So, in the first two, there is a ramp, very, very steep, there is stairs at the end of the ramp in the third picture, and in the fourth picture, there's a ramp that is totally unusable. So why is this so obvious that this is wrong? Well, for example, a different situation, someone comes with a wheelchair; there is an accessibility button, perfect. This person pushes it, the door opens automatically but surprise, there are stairs. So, it's so obvious that this is wrong. But when we move to the online world, this is not so obvious, so web accessibility is essential for developers to not exclude anyone when we developers develop our applications. That means that our tools, our website, every technology that we use is designed and developed as well for people with disabilities so they can use them.

So, let's see an example. We saw some examples in the real world, let's see something in the online world. So, you go to a website in e-commerce, and you want to check your latest purchases. So, you call the support, and they can help you; the typical answer could be, “You need to click on the button in the top right corner.” Or maybe you want to change your email address, or any settings in your profile, so they can tell you, “You need to click on the button with the engine icon.” But for blind people there's no such as top right corner, there's no such as an icon that look like an engine, so we need to have this in consideration when we develop our applications.

Let me give you some numbers. A couple of years ago we were around 7.6 billion people in the world and more than 1 billion people live with some form of visual impairment. It could be using glasses, it could be color blindness, or it could be a hundred percent, which is totally blind. But when we develop our online businesses, we want to reach as much people as possible, so we cannot forget that this is our audience as well. I'm not going to talk about developing web accessibility today, I had a different talk, it's called “How does your website “sound” like?”, you can find it on YouTube, but I'm going to talk about testing web accessibility. How can we make sure that what we develop is accessible?

Automated tests are very cool, and they can free up your QA team, your testing team, from manual testing every part of your application, but it's not magic. They cannot automatically make your site accessible. We cannot forget that these automated testing can only detect 20 to 50% of the accessibility issues, so we need to treat this automated face as a part of a one bigger testing process as a one-step, and where manual testing is as important as the automated testing.

So, I've created a very simple application in React with three tiny components, which the first one is a button, the second one is a fake button, which is an anchor link with a roll button - sneak-peek, never do that - and the third one is an image. And in the entry point of the application, I put a bunch of errors. So let's see if we can find, and how can we detect those errors with some automated test tools.

So, I divided this presentation in three different blocks; the blocks for me is what I use every day. So I can test while I develop, I can test after I develop, and of course, we are going to talk about these manual tests that I've said before that is as important as automated tests. Let's start with testing while you code.

So, since I'm using a React application to show you some tools, I'm going to use the first one is react-axe. The axe family is a library, it is a family of tools the Deque University or dequelabs created it - developed. You can install it as a developer dependency in your application, you can use NPM or yarn depending on the package management that you use. You need to export this function, this library only if you are using an environment which is not production, that means you exposed these logs. And of course, you use the ReactDOM and you pass it through the axe engine. What is this library doing?

In your browser when you execute your application in the console log of your browser, in this case, I'm using Chrome, I'm going to see all the issues that my application is having, as some kind of features, let's say. So, one is that if you have several times the same issue, it’s going to be grouped; those groups are telling what is the error. So, for example, I said elements must have sufficient color contrast because it's not Double-A or Triple-A, or images must have an alternate test. They are going to give you as well a severity level from minor, moderate, serious and then with critical. So, these will give you more information about the priority of when you need to tackle these issues. It's going to give you as well the information of where is the error; so it's going to give you the HTML element in your code where the error or the issue is appearing. And I think the main feature of this library is that it's going to give you a direct link to the dequeuniversity.com, which is the official documentation from Deque to help you learning more about the issue and helping you as well to fix the issue. So, it's going to give you all information and all details about how to fix this issue.

You can use linters as well. So, for those who don't know what a linter is, a linter is basically a conflict file where you put some rules and you tell, “Let me know that I'm doing wrong when I am doing wrong,” so, let me tell you that I'm making a mistake on this rule. Then you can you use a plug-in for accessibility. So, you need to configure in your ESLint rcjson file in the config file that I was saying before, you need to include it in your plugins in line number 2. And in line number 12, we say extends and extending the recommended rules of the accessibility plugin. Which with this line it would be enough [for] all the rules. I prefer to extend my rules to define some parameters, that's why I have some of the conflict parameters in the rules section. And of course, as every linter, it’s going to show you in the code editor - in my case I use Visual Code. When you have an issue, it's going to show this wavy red underline. When you hover with your mouse, it's going to tell you what is the issue. And as well, it’s going to give you the same information in the terminal when you run the application. So, it's very useful to avoid shipping code that is not accessible during the development process.

The third one that I want to show you which probably is my favorite is jest-axe, so again we are back to the axe family. And Jest for those who doesn't know them is a JavaScript library to create unit tests. In this case, you can use jest-axe to create accessibility unit tests. So, you need to install this as a developer dependency the same as the other ones, and you can create a simple test. So, the one that I have created import the whole application, so the whole app, from the app.jsx file. I expect not to have any violation obviously, and what I'm doing using the ReactDom server is to transform my whole application into a string, and then I'm throwing the string into the axe engine. And of course, again I'm expecting not to have any violations.
So, when I am going to my terminal and I do NPM run tests or a yarn run test,
I can see the tests running and I can see pretty much the same information that I show in the react-axe in the console. So, I'm going to see what is the error, I'm going to see where is the error in my HTML, it's going to give you a bit of information and of course again this link directly into dequeuniversity.com, which is again the official documentation. So, it's a very good library.

So, those are the applications or the libraries, the tools that I used while I develop. But sometimes you can arrive into a company, a mature product, and they told you we've never done any accessibility work in this one, or maybe you tend to think that you're done with your code so you want to be able to test the whole DOM structure of your application. So in this part, I'm going to show you some tools that you can use in the terminal so you can pass the engines or the testers over a whole HTML or over a whole website. The first one, back to the axe family, they developed a CLI. So you can use this into the terminal, in this case you need to install it globally in your machine with the dash-G, and you can run it easily in the terminal putting axe followed by the URL that you want to test, so in this case I'm testing the Stack Overflow website. It is going to start a chrome headless instance and it's going to perform all the tests for you. What is it going to give you? Well, the typical thing from axe again, what is the error? Where is the error? It's going to give you a trace of the error, and again the link to Deque University, so you can learn a bit more about this.

Very similar tool - Pa11y. Again, the same as before, you need to install it globally in your
Machine. It really works the same as the axe one, so you need to put pa11y followed by the URL that you want to test, and it's going to perform the same test basically. It's going to run a headless browser, I don't know in this case what they used, and it's going to give you what is the error. One more thing that they are giving you is the principle on the WCAG that you are violating, it is going to give you the whole trace in the HTML DOM, and it is going to give you the exact element that is violating this principle. This case of course is not axe, so you don't have a direct link to the documentation; it is your duty to Google it and do your homework and find out how to fix those issues.

And as well you can run this against your localhost, so, you don't need to deploy anything to a test environment or even to a production tool to be able to test this. Pa11y as well has a very interesting feature because sometimes I heard people say, “Look, I have 25 URLs I don't want to go one by one to test all these URLs and I don't want to put this into my processors.” So, you can create a JSON file, a config file with some parameters. So if you see the JSON file that I created I have three URLs. The first one is just a plain URL for Stack Overflow, the second one I pass a timeout of 50 seconds, which is very much actually, and I'm taking a screen capture that I can use for reporting purposes or maybe you have a visually regression test and you can use it to compare screen setups.

But I think the biggest feature of the Pa11y CI is that you can perform actions, so you can click in an element when the element is loaded, and this element you can find it through a CSS class or an ID. In my case, I’m navigating through a different part of the application and I'm taking two screens. In this case, you just need to put pa11y-ci; it’s going to look into the root of your project tool to find this JSON config and it's going to perform the three tests. So, in this case, it is found in three URLs - the first one is going to be very quick, the second one fairly quick, the third one is taking a screen capture then it’s navigating through the other one creating another test and making another screen capture. So, the results in the terminal are going to be pretty similar. Again, what is the error? Where? And what is the element that is violating the principle? You can see in the root the screen captures that it was taken.

Lighthouse. Lighthouse is an application, or a tool created by Google and is included in every Google Chrome browser. But as well, you can use it from the terminal, maybe you want to include this into your releasing pipeline for example or your continuous delivery continuous deployment. So, you can use this as well in the terminal. In this case, again you need to install it globally in your machine and you can pass its parameter which is --view. And with this one what it's going to do is after the test, it’s going to present you their results in the browser directly.

So, in this case, instead of a headless browser it's going to run a full instance of Google Chrome and it is going to do a lot of tests. It's going to do performance tests, it's going to do no JavaScript tests, it's going to do no internet tests, it's going to do accessibility tests, responsive design tests, so it's going to create a full report. At the end, you're going to end up with an HTML report you can click in accessibility, and the same as the other ones, it’s going to give you what was the error, a bit of information on how to fix it, what exactly element is the one who's provoking or causing the failure, and you have some link that leads you to the official Google documentation about accessibility in this case.

So I think I mentioned the main features, in my opinion always, of every tool that I showed you how to test the dom. At the beginning, I said that only 20 to 50% of the issues can be captured via access automated tests so manual test is as important as the automated test. So, I'm going to show you some of the extensions that I use in Chrome, in my case I test in Chrome, on how to test manually the accessibility of the websites that we create. So, those are some of the ones that we use. I'm going to show you one by one.

Going back to Deque, to the axe family, they developed a Chrome extension; you can find it under the development tools in your browser. You just need to click on “Analyze” and it is going to perform a full analysis of the website, in this case again Stack Overflow, and it's going to give you the information that they were giving you in the terminal - what is the error, it's going to be grouped by the issues. And in this case, it's going to give you this information that you can get in the Deque University directly in the extension. Of course, you have this “Learn more” link that leads you to the Deque University, but you can see almost everything now from the browser.

Very similar extension is the ARC Toolkit; you can find it as well under the development tools. It's going to do quite similar so you can perform these [threat 18:35] tests, you can see the families that they are going to perform so, in this case, I'm clicking in “Images” and I can see what images, for example, doesn't have an alt - alternate test. I can go directly to the element and it's going to highlight it in the window so I can easily see what images are the ones that they don't have alt property.

Accessibility Insights: this is a really good extension. One feature that I'm going to show you now is they will give you a map of the tab indexes on your website. Why is this so important? Because normally, people who are visually impaired don't use a mouse, they normally navigate through their website using the “tab” key. So, the tab order of your website needs to be consistent with the content of your website, you cannot jump from one place to another one. So, you need to be sure that the order is the correct one. So, with this application, you can build this map and you can see if it's consistent or not. So you can keep on tabbing and it's going to create this map of the tab order, so you can see if you jump around, or you can [say], “Look to see if this element is out of the order,” or “We need to skip this element because it's not really relevant.” So, I think it's very beneficial to finally get a full map and check it before syncing the website to production.

WAVE. WAVE is probably the most complete extension so far that I’ve found. It's very quick. It's not found under the developer tools; I think you can find it on the extension bar. It has its own icon you can click and immediately you have the test already done. You can see directly in the window all the images that don't have an alt, the ARIA controls every role that is not a correct one, you can see the structure of the headings for SEO as well is very useful, you can see the contrast or the issues with the contrast if it's failing the Double-A or Triple-A you can deactivate all the styles, you can see if the DOM structure, the HTML is really consistent, and as well, you can inspect the code, jump more into the HTML code. So, I think it's quite complete, this tool.

But not all the time we want to pass tests, sometimes we want to put ourselves in the shoes, in the skin of someone who's visually impaired. So, I think NoCoffee it's a vision simulator and I think it’s a very valuable extension so you can simulate how those people who are visually impaired will see your website. So, you can simulate different kinds of impairments. So, for example, you forgot your glasses at home, maybe someone will see it like this, or maybe someone has some glare in the eye - you can see some snow in the eye. Or maybe color blindness or protanopia, so the colors will completely change, or not even colors, so you cannot rely always on red is danger or bad, and green is good, you need to as well give some information. You can, as well, simulate some real disabilities like central vision or side vision, or glaucoma, so, I think it is a very nice application to simulate how everyone will see your website.

So, those are the tools that I normally use while I develop when I do my work. There are more, and I think this is your turn now to dig and research about new tools. And if you find some that are valid and they are really nice, please send me a tweet with them because I really want to test them. The application that I created for the first part of the presentation is under my GitHub, so you can find it there and then you can clone it and play around with it. All the slides of this presentation and any other presentation that I did are under speakerdeck.com slash my surname Bolonio, you can find it there. If you don't like to rewatch the presentation again and you prefer to read it, I wrote a three-article series in my blog so you can read it there and you can see the code and you can click some links and play around with it.

I want to take advantage and recommend you a really cool course. It's not a technical course, it’s an introduction to web accessibility to everyone and it's official but the W3C is under edX, and I think they extended the period until September. So I think is a very nice introduction to the accessibility world so you can do it. And it's for free, so please I encourage you to do this. And I want to leave with a couple of sentences that I think are very important, a couple of thoughts.

Trenton Moss said one day, "It's not just about disabled user being able to access your website, it's about everyone being able to access your website." You don't know if you forgot your glasses today, if you don't have your mouse with you, if you have kids and you have your kid in one hand and you need to use a website with one hand only with the tab key. Some months ago I dropped my computer so my laptop was completely black and I needed to perform some actions to buy some tickets. So in this case, when you're not a disabled user but you are situationally disabled, you realize how inaccessible websites are.

So, when you develop your application, your websites, please be aware that you're not developing only for one set of people, you should be able to develop for the whole audience. Everyone needs to be able to access your website because accessibility is not a feature. Disability is not an option, so we cannot treat accessibility as a feature, as a post-process, we will do it later, because later never happens. So we need to treat accessibility as part of our development process the same as we do with UX review, the same as we do with testing, with Selenium test, end-to-end test, the same as we do with specification, it needs to be inside of our daily process. Because it doesn't take long to include an aria-label into a button with a non-meaningful name. It takes you 15 seconds to create a meaningful text in an alt property in an image, it takes you 10 seconds to describe what would you see in the image. So, if you have an image with a person using a computer, it takes you 10 seconds to say, “A person using a computer.” So it is not a matter of time, it’s not a matter of cost, it doesn't cost anything. HTML provides everything you need, everything is standardized, the W3C is doing an amazing job here so it's free, is quick, and it needs to be done, should be a must. So, just keep this in mind when you're developing your applications.

Thank you.