Developer friendly AAA accessibility testing process

Accessibility is becoming ever more important and a standard for many pages (hopefully more to come). But there are many different ways of testing whether sites and apps are accessible. There is no set way, as long as the testing passes all the requirements on the WCAG 2.1 guidelines, it will be sufficient. Below I am outlining a simple process that I follow to get the biggest “offenders” out of the way.

Accessibility is not simply passing automated testing and calling it a day, a lot of it is based on actually using the page with the different limitations in place and the tools that people would be using, however this process should get you most of the way there.


  • Google Chrome installed

1) Quick automated scanning / testing (on every page)

2) Valid HTML

Scan the page with the W3’s HTML validator. This is the most basic check and many issues can simply come from having invalid HTML. You can either “view source” on the page and copy/paste the content into the validator, or simply give it the URL to validate (if it’s public). Do this for every page. Think about variations where there’s dynamically added content.

3) Hierarchy – Headings

The page should have only 1 H1 tag, all the following H tags need to be in a logical order, i.e.
H1 > H2 > H3 > H4, etc. compared to H1 > H3 > H2.

Use headings to define the page structure!

H tags should be used to title sections of the content. H tags are often used instead of navigation as screen readers allow users to quickly jump between them. This helps users find the relevant section of the page and directly skip to it.

A good tool to test with is:
Chrome: Headings Map

Or you can also use the:

Chrome: WAVE Evaluation Tool

By going to the “Outline” tab

4) Contrast

We are looking for a contrast ratio of around 7:1 for any text size to pass AAA.

Chrome: WCAG Contrast checker

Not as useful, but helps

NB: You will have to test hover states (on buttons, links, etc.) separately. (Hint: you can set the hover state as on in the Chrome developer tools)

5) Keyboard accessible navigation through the page / “Skip to content” / Focus order

  • The user must be allowed to skip the navigation (that should be consistent on every page). This is so that they don’t have to tab through all the links on every page refresh.
  • The focus order needs to be logical and run through the page in the most semantic way, i.e. not jump from the header to the footer and then to the top navigation and then to the middle of the content. Normally, this is achieved by a logical structuring of the HTML that is not different from the design.

6) Focus visible

  • Focus highlighting must always be clearly visible (standard is a bright sky-blue colour, but any can be used as long as it has sufficient contrast). Any element on the page that is focus-able must have that highlight. This includes form elements, links, buttons or even content in some cases.
  • Make sure focus is also visible transferred if a modal is opened on the page. The focus must move to the modal and its content. Once the modal is closed, the focus must move back to the element that triggered the modal opening in the first place.
  • All of this is necessary so that the user always know where they are on the page when navigating and tabbing through the content.

Bad example:

Good example:

7) Text resizing

Using CMD+ (CTRL+) or CMD- (CTRL-) make sure the text resizes and the page keeps it’s layout without breaking. All the text must maintain a reasonable ratio between the different sizes (i.e. paragraphs and headings should not be massively different and should scale at the same ratio).

8) Text for images (or presentation only specified)

Make sure all images have alt=”” text specified or role=”presentation” if they are to be ignored. Step 1 above should catch any of these issues.

9) Forms – Input labels / error identification / error prevention (help texts)

[to be added]





Leave a Reply

Your email address will not be published. Required fields are marked *