Guided: Testing Techniques for Web Accessibility

In this lab, you are going to learn about the various testing techniques available for ensuring that your web applications are accessible. Ensuring that your applications are accessible means that you are catering to as many users as possible. Once you have an application that you think is using ARIA principles and accessibility best practices, it’s time to implement accessibility testing techniques.

There are a number of different testing techniques available to you but they can be summed up within two different categories:

Manual Testing: This type of testing is arguably the most important. You shouldn't disregard the manual testing of your website in terms of accessibility. This means using screen reading technologies to manually verify that your website is accessible. It also means conducting regular content and keyboard testing reviews.

Automated Testing: This type of testing includes things like unit tests and accessibility plugins that can test and review your website for you in terms of accessibility.

By the end of this lab, you will be confident when it comes to using manual and automated testing techniques for ensuring that your web applications are accessible to all users.

info> Note: The solution directory contains the final solution. Feel free to view the file in that directory should you get stuck!

This lab is going to focus first on the most important aspect of web accessibility testing – and that is manual testing. Manual testing for web accessibility can be broken down into three, distinct types:

• Content review

• Keyboard testing

• Screen reader verification

In this step you are going to learn how to conduct a proper content review. You will then follow it up with keyboard testing in the next step.The third type of manual testing, screen reader verification, is beyond the scope of this lab but it is an integral part of performing web accessibility testing. Screen readers are essential for people who are visually impaired because they can describe a website in both a verbal and tactile fashion to end users. This lab would be remiss to not mention popular, open-source screen reading technologies available for you to use when conducting manual testing of your web application. Some of these screen reading technologies include:

• NonVisual Desktop Access (NVDA): for Windows.

• Apple VoiceOver: for Mac.

• ORCA: for Linux.

When performing a web accessibility content review, you are really asking the following questions:

• Can you zoom to 200% and still see/interact with all content on your website?

• Are all images on your website properly describable by screen readers?

• Are all form inputs descriptive?

• Does your website have the correct “text-to-background" contrast ratio?

Answering “yes” to all of these questions during a content review means that you are well on your way to an accessible web application. One of the first things to look at when performing an accessibility content review is related to how visible and interactive your site is when a user is zoomed in. It is a best practice to do this portion of the content review zoomed in at 200%. In the Chrome web browser, you can zoom in by pressing Cmd + (or Ctrl + if you are on a PC). In order to ensure your site works well and looks good to users who must zoom in drastically, you can use CSS media queries. Media queries allow you to change the design of your website based upon the aspect ratio of the screen. Another invaluable piece of content review relates to ensuring that screen readers can describe images on your website. For users with impaired vision, it is imperative to add the alt attribute to your img elements. “Alt” text (short for alternative) should be to the point and accurate. You don’t want to be long-winded here! Ensuring that form inputs are described properly is very important for users with screen readers. This can be accomplished with the use of the aria-label attribute. You might have noticed that the text on your website is a bit hard to read. This is because the text-to-background contrast ratio is off. You can access the contrast ratio of any website simply with the WebAIM Contrast Checker. You can enter both foreground and background Hex color vaues to determine what your ratio is. You should aim for a ratio of at least 4.5:1.

In this step, you’re going to get familiar with keyboard testing and accessibility. Ensuring that users can navigate around and interact with your application via the keyboard is a massive step towards improving accessibility. Implementing keyboard accessibility means that motor or vision impaired people can still interact with your site in a meaningful way. Fortunately, the browser does a lot “out-of-the-box" when it comes to keyboard accessibility. Most of the needed functionality is already baked in. In this step, you are going to learn about some HTML attributes that are specific to keyboard navigation and how to use them to improve accessibility. When you are talking about keyboard accessibility you are really just trying to answer the question: Does the website allow you to move forwards and backwards effectively across the page and interact with the site? Moving forwards across interactive or “focusable” elements on the page is done via the Tab key. Moving backwards is accomplished via Shift Tab. Browsers do a great job of ensuring that focusable elements are set up in this way, but sometimes in order to improve accessibility it is necessary to tell the browser how to navigate via the keyboard. One of the ways that you can achieve this is via the tabindex attribute. When it comes to keyboard accessibility, it’s important for input “groups” to have the same name attribute. This ensures that a set of options are grouped together when it comes to the screen reader. One example of this is with radio inputs. Often times it is important to hide elements from a screen reader entirely (and not just focusable elements). A great example of this is a modal dialog. Often times modals are within the DOM element tree on the webpage but are not visible to the user yet. If the inert attribute is not set on these hidden elements, screen readers can still attempt to interact with them when they aren’t relevant. The inert attribute, if used, will entirely hide the element from any screen reader interaction.

Automated web accessibility testing is an integral part of verifying the continued accessibility of a website. This type of testing can guard against subtle regressions in accessibility by ensuring that form inputs have the proper ARIA labels, elements have the right IDs, etc. Automated web accessibility comes in two major forms:

• Unit testing: this type of automated testing requires a manual upfront cost of writing the test but requires very little upkeep. Having a large amount of ARIA-focused unit tests can be an early warning system for your application in terms of guarding against accessibility regressions.

• Third-party library testing: this type of automated testing comes in the form of using a library (usually a JavaScript library) in a programmatic fashion that will run tests against your application and compile a report full of suggested accessibility improvements that can be made. These reports can be run alongside your unit tests to verify accessibility standards.

In this step, you are going to learn how to write unit tests that can be run against your application using the Jest, JavaScript testing framework. You are also going to learn how to quickly run and compile accessibility reports using third party libraries – specifically the jest-axe library. In this task you will write an ARIA-focused unit test! Unit tests are crucial in order to guard your application against accessibility regressions. The jest-axe library is a wonderful way of providing both a reporting and testing mechanism that can help validate the accessibility status of your webpage. The example application that you are running has this library installed – you just have to add a unit test that runs it! You will be using two imports to accomplish this – the axe function and the toHaveNoViolations Jest extension.

Nicely done! You’ve made it to the end of this guided code lab on ARIA Testing Techniques for Web Accessibility.

In summary, you learned:

• How to conduct manual content and keyboard testing reviews for accessibility

• How to write unit tests for web accessibility testing automation

• About various plugins, automated testing libraries and screen reading technologies that can help you further adhere to web accessibility standards

Using browser plugins and third-party website evaluation tools directly is beyond the scope of this particular lab, however, it is good to be aware of different browser plugins/tools that can help you with automated web accessibility testing. Some of the most popular browser plugins/tools include:

• WAVE (Web Accessibility Evalutation Tool

• Accessibility Checker

• ARC Toolkit

• Accessibility Insights

From here, you can confidently use both manual and automated testing techniques for web accessibility. You can further your journey in learning ARIA by exploring video courses and guided code labs here on PluralSight.