Improve the Accessibility of Your Web Application

Last month I attended the NDC Oslo 2020 online workshop Front End Web Fundamentals hosted by Amy Kapernick (@amys_kapers). In my first post on this workshop I wrote about the tools we used and resources that can help you to create better web applications.

Today I focus on accessibility. I am not an accessibility expert, yet the most errors you make are easy to find and do not need much time to fix. It will not replace an accessibility expert when you are required by law to follow certain levels, but it will make their work a lot simpler if the most common mistakes are already fixed.

The main reason to I wrote this post is to remember the different steps I had to take. Your challenges may be different, but if you follow the same structure, you should be able to tackle them as well.

 

Tools to find accessibility problems

The main tools we used in the workshop where:

• Lighthouse is a tool that runs inside Google Chrome and helps you to improve the quality of web pages. It checks your page for accessibility problems, performance problems, best practices and SEO optimization. It is inside your browser and can access all the pages you can browse.
• Pa11y is a Node.js tool that runs on the command line. Like Lighthouse it finds accessibility problems. While you can run it manually, it shines when you run it as part of your CI/CD build.
• Wave is a web site in which you can check your page. It is great to find problems for pages that are accessible by everyone and it has a helpful visualisation to locate the problem on the site.

With those three tools you can find many problems and start improving the experience for your users. I started with Lighthouse, because that was already in my Google Chrome (inside the >> of the developer tools you can access with F12). Wave is great to see where exactly your problems are on the page, what sometimes can be hard to spot in Lighthouse. With Pa11y you can make sure that those problems do not come back. You can install Pa11y with this command:

Be aware, this download may take some time. On my machine it installed Chromium that needs 143 Mb.

 

A minimalistic example

I use my personal page jgraber.ch as a minimalistic example. I found there the same kind of accessibility problems as I did with the applications at work. Please remember, the goal of this post is to explain the actions to fix those problems and for that you do not need a big application.

As I started, my page looked like this:

The accessibility report from Lighthouse had a few problems you most likely will find in your applications as well:

Pa11y found the same problems, but it offers a bit more guidance on what to do:

WCAG2AA stands for Web Content Accessibility Guidelines in the AA conformance level (AAA is the highest level, while A is the lowest). If you google for “WCAG2AA.Principle1.Guideline1_4.1_4_3.G18.Fail” you find summarization pages like WCAG 2.1 Standard: Summary that give you a short description of the problem and how you can fix it. You will see AA and AAA in many places and tools often refer to them to guide you towards more accessibility.

 

Add an alt attribute to your images

On my page I took care of adding an alt attribute to all my images. But when Pa11y finds images without an alt attribute, it creates an error like this one:

The alt attribute should contain a short alternative text that describes the image. Screen readers will take this description and read it out so that visually impaired visitors can understand what this image is about. You should add a description in the alt attribute for all images that are not just design elements. You can do this by adding the alt attribute inside the img tag:

<img data-toggle=”blazy” class=”img-fluid b-loaded” src=”/images/NavigationSpeakers.png” loading=”lazy” alt=”These speakers shared their knowledge with the user group” >

Formulating a useful description is the hard part. It takes time to come up with something good and short. Start with those images you can find a good description without much effort and then come back to those who are harder to describe.

The design-only images can have an empty alt-attribute. In this case the screen reader will say nothing and Pa11y will not report it as an error.

 

Improve the contrast between the foreground and the background

The contrast errors are the ones I find the hardest to fix. I am not a designer and lack the knowledge to come up with better colour combinations. Sites like Who can use are a great help, but it may still take time to find a pleasing solution.

Google Chrome has a build in colour picker, that you may already have seen. There is a little addition, that you only get when you inspect an element that has a color and a background-color CSS property. If you select the color property and click inside the square in that colour, you get an indicator about the contrast level. If you expand it, you can see your current contrast ratio and if it passes the AA and AAA level:

The white line in the colour picker is for the AA level of contrast. If you pick a colour below, you have enough contrast to pass this requirement. Depending on your current values, you may even see two white lines. The second, lower line would be for AAA.

Now starts the hard part in finding colours that work together. When you got the combination right, you see the green check marks next to all contrast ratios (and you should see both white lines):

You now need to update your CSS files, reload your site and run Lighthouse or Pa11y again to see that your change worked.

 

Do not use only icons for links

Icon-only links are a nice design element, but they are not accessible. Thanks to CSS we can add an explanatory text inside our link and display this text outside our viewport – making it invisible yet accessible for screen readers.

We can take this HTML snipped

and add a span tag with the description of what this link is for

Our site now looks a bit off:

We now need two lines of CSS to position this span element outside the visible part of our browser:

This gives us back the layout we want, but now in a more accessible way:

 

The result

The page now looks a little bit different to the beginning. The colour combination for the buttons have changed, the rest looks the same:

The accessibility report now reports no other problems:

Is now everything perfect? No! The site has improved, and Lighthouse is happy. Wave finds minor problems with the headings (there are h4 headings but no h2 or h3) but Pa11y can find no issues:

The minimalistic example for this blog posts now reaches its end. There are probably other errors, but the tools cannot find them. If your first page is fixed, you have to repeat this with all the other ones. This sounds disappointing, but when you reuse your CSS and your components where not constantly reinvented, then your fixes for the first page should help you to fix the problems on the other pages.

If your page must be compliant with the AA or AAA levels, you now should get an expert that can focus on the hard problems that cannot be spotted with the tools.

 

Keep it at this level

It depends on your page how long it takes to reach this level. But it may take only a few changes and you are back where you started. Therefore, it is now a good time to start with automatic accessibility testing with Pa11y. You can install Pa11y in your continuous integration service and use one of the many ways to configure it to check your site. If now a problem pops up, your build fails, and you can fix it with reasonable effort.

The alternative is you check your site manually, but as we all know, new features and bugfixes will have a higher priority and you will not have the time to do it.

 

Conclusion

You can spend an awful lot of time on accessibility to get everything right. However, there are many low-hanging fruits you can fix in a short time that will make your site much more accessible. Try it and help your users to enjoy your web application much more.