accessiBe Announces $12 Million Series A Funding

accessiBe Secures $12m Funding

Read News
Login Start Free Trial Free Trial Get Demo Demo
May 06, 2019

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

Shir Ekerling CEO at accessiBe
  • eye3 478,701

Whether you want to protect your business from web accessibility lawsuits, trying to assess how close you are to ADA compliance, or feeling overwhelmed after reading the official Web Content Accessibility Guidelines (WCAG 2.1) - this guide is for you!

While we won’t be covering all WCAG requirements, we’ll cover the vast majority of them, and, most importantly, the ones that are most essential. We aim to do that in a quick and easy format that anybody can follow, regardless of technical expertise.

By the end of this guide, 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. By following 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 use only with a keyboard, from navigation to operation.
  2. We’ll use a free testing tool called aCe 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 global regulations.

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

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

Users on your site with differing motor skills will make keyboard accessibility an integral part of their navigation.  Users with motor impairments like Parkinson's, Multiple Sclerosis (MS), and people with 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

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

Let’s kick off the testing! From this point forward, all of your site’s major functions should be operable and navigable via the 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.

IMPORTANT NOTE: If you’re using macOS with Safari, Apple turns off keyboard navigation by default, and requires motor-impaired people to turn that on through the Preferences. Make sure to turn it on before continuing with the test.

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 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 pressing 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 a form, and ensure you can navigate to all of 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.

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 popups are accessible:

  1. If you have popups on your site, trigger them open (either by clicking a button or any other method).
  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 hit must navigate within that popup, and you should not be able to escape the popup regardless of how 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 website accessibility level with an automated testing tool

There are several web accessibility testing tools, such as WAVE, Lighthouse, and aCe, available for free website evaluation. aCe is a free web accessibility testing tool developed by our internal engineering team and will be our main focus in this section.

Note: ADA compliance checker tools don't really exist because the ADA did not adopt any specific guidelines, rather, US courts refer defendants to WCAG as the best means of compliance. So, automated testing tools are able to test website accessibility according to WCAG, and not the ADA. This is a technicality, and I don't want to confuse you too much, but it is important for accuracy. Overall, to check website for ADA compliance, you'll need to check if it covers the WCAG.

aCe was initially developed as an internal evaluation tool for accessiBe, our AI web accessibility solution, making it the most accurate web accessibility tool currently available. In order to provide our partners with the most up-to-date accessibility reports, aCe flags various accessibility issues in order to effectively evaluate the compliance standards of a website.

While this guide is essentially about manual accessibility testing, designed for people who want a deeper understanding of the process, aCe makes the entire process fully automated.

Moreover, unlike other testing tools that are built for web developers, aCe was initially designed for end users meaning it provides a clear and simple response regarding whether your website is accessible or not according to the WCAG 2.1 AA standard.

Tools like WAVE and Lighthouse provide you with a general understanding of issues and errors that exist on your site. These errors don’t necessarily mean you’re non-compliant. You can have five or ten errors and still be compliant, as these tools are not entirely accurate, due to the way they check for web accessibility. 

Unlike aCe, which uses AI to emulate real behavior, other tools check for specific predefined accessibility rules. For example, with accessiBe on-site, the accessibility mode is triggered on demand. When a blind person visits a site with accessiBe on it, accessiBe recognizes the screen reader and knows how to explain the website to the screen-reader. Unlike humans or AI, testing tools don’t know how to trigger accessibility modes and will think that the website isn’t accessible. However, if you are using either WAVE or aCe, both will show you results that include accessiBe's adjustments, as we are able to automatically inject them to the test sessions.

The next section will help you understand what aCe flags and its importance. The report provided by aCe not only gives you a clear understanding of issues and errors that exist on your site but also an understanding of the current level of compliance of your site.

How to read the report

After a quick scan of your website, aCe will provide you with a simple answer to whether your website is accessible or not, or in other words, compliant with the WCAG 2.1 AA. The report is divided into 11 sections, based on the WCAG 2.1 AA.

The sections are:

  1. Clickables
  2. Titles
  3. Orientation
  4. Menus
  5. Graphics
  6. Forms
  7. Document
  8. Readability
  9. Carousels
  10. Tables
  11. General

Each section consists of different elements that aCe looks for. If the element exists, you’ll see a green V. If the element is missing, and is a must according to the WCAG 2.1 AA, you’ll see a red X. And, if there are elements that are required by the WCAG 2.1 AA, but they don’t exist on the website, you will see a grey, neutral, circle.

For each element, there is a dropdown that will help you understand the following:

  • How many times the element appeared on your website
  • How many of these elements are defined as needed (success)
  • How many of these elements aren't defined as needed (failure)
  • Requirements according to the WCAG 2.1 AA
  • Code snapshots of failed elements 
  • Code snapshots of successful elements

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

There are different types of visual impairments, such as blindness, partial blindness, or age-related vision loss. Fully blind users use screen readers to operate and surf websites.

Screen-readers not only read content out loud, 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 these lawsuits are due to screen-reader incompatibility, so I’m sure you’ll 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

If you run a screen reader on a site where accessiBe is installed, you’ll be prompted to use Alt+1 to turn the relevant adjustments on. Once in the "Accessible mode", you can start browsing using the screen reader. Important note: This prompts immediately on page load, so make sure to refresh the page if It’s already open on your machine.

Let’s kick off the testing! To get started, download NVDA at

After the quick installation, you can run 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.  Remember, for a user who is blind, the focus ring is less important.

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 most common 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 appears.
  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 made it through! 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:

Thanks for reading!