close
play4 WATCH DEMO envelop CONTACT SALES
Get Started Now 7-DAY RISK-FREE TRIAL Contact & Get Started 7-DAY RISK-FREE TRIAL

DIY: the full guide to testing your website’s accessibility, WCAG and ADA compliance level

Shir Ekerling CEO at accessiBe

Looking to protect your business from web accessibility lawsuits? trying to assess how close you are to being ADA compliant? Feeling overwhelmed by reading the official Web Content Accessibility Guidelines? (WCAG 2.1). Well, this guide is exactly for you!

While we won’t be covering all WCAG requirements (you’ll never read such a guide, trust me...), we’ll cover the vast majority of them, and the ones that are most essential. We’ll aim to do that in a quick and easy format that anybody can follow, regardless of your level of technical expertise.

By the time you finish reading, you’ll have a solid understanding of your website’s accessibility level, and what issues you should address to ensure WCAG 2.1 and ADA compliance. If you follow this guide carefully and patiently, you’ll be over 90% covered.

Here’s how we’ll be testing your website:

  1. We’ll start by testing how compatible your website is for being used only by a keyboard. From navigation to operation.
  2. We’ll use a free testing tool called WAVE to evaluate various types of common accessibility issues.
  3. We’ll download and test your website with a screen-reader called NVDA, which is an assistive technology software used by blind people. Screen-readers are the central topic in 99% of lawsuits.

Want to skip the reading and just learn what accessiBe does? here's a comprehensive video-demo for you!

This guide will adhere to the WCAG 2.1 (Web Content Accessibility Guidelines) at the AA level, which is the required standard for complying with the ADA, Section 508, AODA, EN 301459, IS 5568 and most other regulations.

Throughout all these stages, we will also explain how to test accessiBe, so let’s dive in!

1. Testing how compatible your website is with keyboard navigation and operation

Users come to your site with different degrees of motor skills that will make keyboard accessibility an essential part of their navigation. Users with motor impairments like Parkinson's, Multiple Sclerosis (MS), or people with other physical disabilities that prevent them from using a mouse, are forced to use a combination of keyboard commands to navigate and operate websites.

Heads up! Keyboard Navigation with accessiBe’s solution

If you’d like to check out accessiBe’s solution, press the Tab key and you’ll be prompted with a button to "Adjust website to Keyboard Navigation". Press it, and once in "Accessible Mode", you can browse using the keyboard.

Let’s kick off the testing! From now on, all of your site’s major functions should be operable and navigable only via a keyboard. Press the Tab key to move forward, and Shift+Tab to move backward. Make sure that while Tabbing, you can always see the "tab focus" or "focus ring", as you move around.

Basic tests for ensuring keyboard navigation compatibility:

  1. Does the movement of the Tab key follow a logical order? If the site’s language is in English, the order should be from left to right and from top to bottom.
  2. Make sure every link and button can receive keyboard focus by tabbing to them, and press Enter to ensure you can activate them.
  3. Ensure the focus ring is always noticeable and easily locatable. If you have lost sight of it, well, that’s a problem.

Advanced tests for ensuring keyboard navigation compatibility:

1) Is there a way to skip to the main content?

  1. Press the Tab key for the first time after the page loads, and make sure a “skip to content” link is revealed at the top. This way you ensure your site provides users a way to skip the header or menu and go straight to the main content.
  2. With accessiBe, by clicking Alt+1 (or hitting Tab for the first time) while in the "Accessible Mode", you’ll notice that instead of a “skip to content” link, we developed a Quick Navigation Menu that works the same way but allows users to reach entire sections and even specific pages in a quick and easy way without having to tediously tab through the entire website or page.

2) Ensure your menus are accessible:

  1. Use the Tab key to reach your main menu, and then use the ←/→ (left-right) arrows to navigate to the next and the previous items in the menu bar.
  2. Using the Enter key, open the dropdown submenu (if not already opened by default) and move the focus to the first item using the arrow-down key. If you don’t have a dropdown, you can obviously skip this part.
  3. Next, with the ↑/↓ (up-down) arrows, try to reach all dropdown items. You should also be able to close the dropdown by hitting the ESC key.
  4. When the dropdown closes, the focus must return to the parent menu item (the one that triggered the dropdown).

3) Ensure your forms are accessible:

  1. Use the Tab key to reach a form, and ensure you can navigate to all Its fields.
  2. Ensure you can check and uncheck boxes using the spacebar.
  3. Radio options should be switchable using the arrow keys (up-down-left-right)
  4. If validations exist, submit the form and ensure your keyboard focus is being automatically taken to the first field with a validation error.

4) Ensure your pop-ups are accessible:

  1. If you have popups on your site, trigger them open (either by clicking a button or any other method you’ve implemented).
  2. When a popup appears, the keyboard focus should lift off the main page and land back down within the popup itself. The next Tab you’ll hit must navigate within that popup, and you should not be able to escape the popup regardless many times you press the Tab key.
  3. Ensure the popup can be closed by hitting the ESC key.
  4. Ensure the "focus ring" goes back to the previously focused element after closing the popup.

2. Evaluating your accessibility level with WAVE, a web accessibility testing tool

In this section, we will use WAVE, a free testing tool created by WebAIM (2001). When running the test, WAVE flags various accessibility issues which will help us evaluate the compliance level of your website. This section will help you understand these flags and their importance.

Important to note: the report provides you with a general understanding of issues that exist on your site. These errors don’t necessarily mean you are incompliant. You can have 5-10 errors and still be compliant, as WAVE and other tools are not fully accurate. Having said that, if you found dozens of issues, you most definitely have accessibility issues.

Heads up! WAVE with accessiBe’s solution

accessiBe is a session-based tool that adjusts your site’s accessibility on demand. So, If you are testing with WAVE’s chrome extension instead of their website, make sure to first press Tab on the keyboard, and then click the “Adjust website to Keyboard Navigation and Screen reader” button in order for WAVE to evaluate your website in the “Accessible Mode”.

Please note: if you are seeing errors even though accessiBe is installed, there is probably a conflict between your page and accessiBe that prevent WAVE from picking up accessiBe's remediations. This happens from time to time and we are still trying to figure out why. In such a case, don't worry, it doesn't mean that accessiBe doesn't work on your site, just that WAVE specifically cannot pick up its modifications. Please contact us if that happens to you.

To kickoff the testing, visit http://wave.webaim.org, enter your website’s domain name and hit Enter. Wait 20-30 minutes and WAVE will generate the report for you. If you are using accessiBe, please make sure to accept the popup message stating “This website implements an accessibility system”.

Here's what to look for with WAVE

Right at the top of the report, you’ll notice a summary of errors and alerts WAVE has found. We will only focus on the errors, as alerts are usually tips WAVE believe are noteworthy.

Click on the “Errors” tab, and we’ll explain the 5 most common ones:

  1. Missing form labels: this means that a form field does not have a corresponding text label associated with it. These labels are used by screen readers to understand the function or purpose of a given form field.
  2. Missing alternative text: this means that an image is missing an alternative text description, or an alt attribute, which means the image’s content is unavailable to screen reader users.
  3. Empty links/buttons: this means that a link/button is empty, and a screen-reader cannot interpret its purpose. Developers usually use empty links to create entire clickable sections.
  4. Broken ARIA reference: this means either your developer or your template implements faulty accessibility-related HTML attributes and tags.
  5. Empty heading: this means you have heading elements (h1, h2, h3, etc) that are basically empty and will confuse screen-readers and blind users.

How does accessiBe take care of these accessibility issues?

accessiBe’s Background Application utilizes AI to analyze your website’s components top to bottom, remediating all accessibility issues automatically and making your website fully operable using screen-readers and keyboard navigation.

For example, it provides accurate form labels, descriptions for actionable icons like social media icons, search icons, cart icons, and others, and defines element roles such as buttons, menus, pop-ups, and more.

Additionally, accessiBe scans all of the website's images and provides an accurate, meaningful image-object-recognition-based description as an alt text (Alternative Text) tag using I.R.I.S technology, and It also extracts texts that are embedded within the image, using O.C.R (Optical Character Recognition).

3. Testing your WCAG and ADA compliance level using a screen-reader

Users will present different types of visual impairments, such as blindness, partial blindness, or age-related vision loss. Blind users use screen readers to operate and surf websites.

Screen-readers not only read content outloud, but also add additional functionality that helps blind users navigate and operate websites using special keyboard and voice commands.

Please note that while this test is the hardest one in the guide, 99% of the lawsuits are basically due to screen-reader incompatibility, so I’m sure you understand how important this one is.

For this test, we will use the NVDA screen reader, which is a reliable and free open-source software created by NVAccess. By running the NVDA, we’ll be checking how compatible your HTML structure is for blind users.

Note that NVDA is for the Windows operating system only. If you are using a MAC, you already have the VoiceOver screen-reader installed by default.

Using a screen reader with accessiBe’s solution

If you run a screen reader in a site where accessiBe is installed, you’ll be prompted to use ALT+1 to turn on the adjustments on. Once in the "Accessible mode", you can start browsing using the screen reader. Important note: this prompt fires right on page load, so make sure to refresh the page if It’s already opened for you.

Let’s kick off the testing! To get started, download NVDA at https://nvaccess.org/download

After the quick installation, you can start running it by clicking on the NVDA icon that appeared on your desktop or by pressing CTRL+ALT+N. For this test to be effective, remember to use only the keyboard commands, as screen reader users do not use a mouse. 

Navigating using a screen-reader is done by hitting the ↑/↓ (up-down arrows) keys. The arrow-down will take you to the next element, while the arrow up to the previous. This method of navigation provides much more context than the Tab key, which is only used by blind users in forms.

Please note: unlike standard keyboard navigation, screen-readers navigate a much broader set of elements, so you will not always see the focus ring, and that is completely OK as long as the screen-reader reads out the content in a logical order as displayed on-page.

Here's what you should look out for:

  1. Proper navigation: Make sure while navigating through the site all focused elements like titles, headings, buttons, forms, and links are (a) reachable, and (b) being read out by the screen reader.
  2. Proper readouts: Elements should be read out with their proper role. Here are the readouts you should expect:
    1. Buttons (elements that are clickable and trigger some change in the page itself without loading a new one) should be read out “(button text), button”.
    2. Links should be read out “(link text), link”.
    3. Menus should read out “navigation region”.
    4. Menu items with dropdowns should read out “submenu collapsed/expanded”
    5. Lists should read out “list of X items”.
    6. Tabs should read out “Tab Panel”.
    7. And the list goes on, those are the popular elements and their proper readouts.
  3. Proper popup handling: Ensure that when a popup appears, all standard keyboard navigation functionality is applied (as explained above in the keyboard navigation section), but this time, also ensure the screen reader reads out “modal dialog” as soon as the popup appear.
  4. Proper title hierarchy: ensure that all headings follow a hierarchy, from bigger to smaller. Press the H key to move between the headings. NVDA identifies heading levels so h1, h2, and h3 should be read consequently as “Heading level 1”, “Heading level 2”, “Heading level 3”, and so on up till 6 (you don’t have to have all levels in your pages).
  5. Proper image descriptions: Check that every image has a correct textual description. Press G to move to the next image and listen to how NVDA describes it. The readout should be descriptive enough for visually impaired users to understand the objects and the text that is embedded within the (that is, if there is text at all). For example, an image featuring a shoe model with the text “50% OFF on all shoes”, should be described as “Woman, Model, Shoes, 50% OFF on all shoes”, or similar to that.
  6. Proper form fields descriptions and validations:
    1. Press the F key to find the next form, and start navigating within it using the Tab key. As explained above, blind users with screen-readers use the Tab key in forms instead of the arrow keys.
    2. Ensure all form fields read out the following information
      1. Their purpose (phone, email, name, etc)
      2. If they are required (or nothing if aren’t)
      3. If they are invalid (or nothing if valid)
      4. For example, an empty, required email field should read out “Email required, invalid entry”. After adding a correct email, it should read out the same, but without the “invalid” part.
    3. Use Space to select and deselect checkboxes, and ↑/↓ to switch between radio options. Make sure to focus those first using the Tab key.
    4. If the information submitted was incorrect, ensure that the screen reader informed you about the error with the proper guidance to understand and fix it. Also, make sure that the focus moved to the first field you should modify.

Final Takeaways

Phew, we are finally done and you survived all the way! you deserve a cyber thank you.

The purpose of this guide is to provide quick and easy instructions for checking your website’s accessibility level using three different methods: manual testing using keyboard navigation,WAVE’s testing tool, and using the NVDA screen-reader.

We aimed to write the guide in the simplest way we could, so with a little patience, anybody, regardless of their technical know-how, can assess their accessibility compliance level in a comprehensive way. I hope we succeeded!

Anyway, as mentioned at the start, the guide does not cover all of the WCAG requirements, only the most common and essential ones. The requirements we tested easily cover over 90% of compliance issues, so if your test came out close to our explanations, you are probably covered. For a full, 100% test, we suggest following the WCAG 2.1 guidelines clause-by-clause: https://www.w3.org/TR/WCAG21

Thanks for reading!

Did you like the article?
thumbs-up3 14
thumbs-down3 1
Any Questions? Ask Us Below!
  • 2 Months Ago

    The most comprehensive ADA and WCAG compliance guide on the internet. Keep it up!

You are reading: DIY: the full guide to testing your website’s accessibility, WCAG and ADA compliance level