Skip to content
Malouf Developer Docs

The Guide to performing a WCAG Audit

An Introduction

Hello there, and welcome to the guide for running a WCAG audit. Whether you’re reading this for the first time or the 100th time, I imagine not much has changed in the WCAG requirements*.

*At the time of writing this, we will be using WCAG 2.2 recommendations.

By this time I hope you are familiar with WCAG and how we can work towards being compliant before and during our development process. Now we can jump into the exciting world of ensuring our finished work is WCAG compliant.

Be sure to take lots of screenshots to document changes that need to be made. Everything should be put into box so you can hyperlink to it in your PDF later.

What We’re Looking For

Something you might have asked yourself is “how do I know if something is compliant?” I can copy and paste all of the criteria that we need to look at while doing an audit but, I’ll let you look at it yourself. The WCAG 2.2 Level AA Checklist is provided by DigitalA11Y. It gives a little summary of the criteria, some points to ponder, and links each criteria to its own page for more information. This checklist is what we’ll be referring to, to preform the audit. Every page on our site will need to pass this criteria for us to be compliant up to level AA.

One of the first things that you might notice, in the checklist, is in the “Level” column. Some of the criteria has “A” and some has “AA.” This is because to be AA compliant, the site needs to pass all Level A requirements. If we were to move to Level AAA compliance then the same would be true for Level AA. We would need to meet all of the criteria in Level AA to start auditing for Level AAA.

It’s worth noting that another great, and a bit more thorough tool, has been made by W3. This can be used as a, not so quick, reference tool to make sure you’re on the right track with Level AA compliance.

Tools to Get Started

To start off, we will want to ensure that we are set-up properly. For this let’s make sure we have the right tools installed. Here, you can find a list of free automated tools recommended by Harvard University, however, these are the tools that I recommend and will be using:

You may not need all of these tools but it will be easier to install them first then go back and try to find them later.

Some Context Before Testing

For testing content, WCAG 2.2 recommends using a “hybrid” approach, which combines two types of audits:

  1. Automated Tests: “scan through content to find common accessibility barriers.”
  2. Manual Tests: “are performed by humans who have experience with screen readers and other assistive technologies (AT).”

We will be implementing this approach with a small tweak. Our goal is to catch as much as possible, since none of the tools are perfect, we’ll be using multiple to ensure accuracy.

  1. Automated Tests
  2. Auto-Manual Tests
  3. Manual Tests

It should also be worth noting that, depending on what tool you use, you will get different results. Stick closely to the W3 checklist and if needed, use multiple automated tools. This could give you better results.

Time To Test (Automated)

Now that we’re set-up, we are ready to start testing. For the rest of this doc, the automated test tool that I’ll be using is Siteimprove Accessibility Checker.

(I tested many different tools and chose the one that I liked the most. You are more than welcome to use a different tool and still get some awesome results.)

Test 1: Automated Scan

To run a report in Chrome, using Siteimprove, install the extension and click on it. Once Siteimprove Accessibility Checker is installed you can use it right away. A new window will pop up with the test results. I’d recommend clicking on the refresh button in the top left to ensure we have the most current results.

With the report ran and loaded, we can take a gander at what it’s telling us. Every page will have a different report so the best advice I can give you is to follow its suggestions and see how much you can take care of. Screenshot every page of the report to put into box. If it highlights something in pink on your page take screenshots of that too. We will be putting everything into one PDF to make fixing these issues easier.

Test 2: Page Structure (Automated)

For the second of our automated tests, we’ll be ensuring the hierarchy of the page.

To do this, we will use 2 different tools. The first one will be ARIA DevTools. This tool looks like it gets rid of the page but it is replaced with a visual hierarchy. Breaking the page down in this way gives us a good idea of what is paired together and how screen readers will read the page top to bottom.

Another great tool to check the hierarchy is the WAVE Evaluation Tool. When this tool is enabled, you’ll see that it highlights everything on the page. There are a couple of sections within this tool that will be helpful for checking hierarchy.

  • Order: This again will give you an idea of how the screen reader will see it. WAVE says “Order, role, and accessible name (what is read by a screen reader) for all navigable page elements are listed. Elements that do not have a function should not be listed.”
  • Structure: This will show more of the general areas and how they’re nested inside of other things. Make sure to look at this closely and ensure everything is semantic.

Test 3: Color and Contrast

At this point you should be pretty familiar with Color and Contrast because you definitely read the, “WCAG/ADA - THE COLOR/CONTRAST ONE,” document right??!

*Due to the sheer awesomeness that the previously mentioned dev doc exudes, I won’t be going into much detail for this step.

This is something that Siteimprove might be able to catch but, it’s best to use an extension for this specific task. WCAG Color contrast checker is again, not perfect, but pretty good at showing you things you should look at. Once again, this is something that will be different for each and every page. Look through each item and ensure its accuracy. I have found that, while testing this tool, it can get things wrong but is accurate for the most part.

This tool turned out to be very buggy and would not work reliably on all pages. I ended up using Accessibility Insights’ automatic tool to check for color contrast.

Test 4: Alt Text

Before we get too far, we need to check for alt text. The best tool, I’ve found for this, is Image Alt Text Viewer. It catches if there’s no alt text, if the alt text is too short, and even checks svgs for titles and descriptions. The best way for to show the results of this is to take a full page screenshot. I use Go FullPage - Full Page Screen Capture. It takes a lot of tiny shots and stiches them together. It gives you a choice of either downloading a PNG or PDF. I’ve found that the PNG gets blurry when you upload it to box so I choose to use the PDF version.

Time To Test (Auto-Manual)

With the automated test done and the issues addressed or noted, let’s hop in to the other test, not the other other test. We’ll want to make sure our page is refreshed and at the top.

For the tests in this section, the main tool that I recommend using is Accessibility Insights for Web. I’ll be using the “Quick Assess” portion of this tool to conduct the auto-manual tests.

Quick Assess Scan

Something that’s nice about this extension is that it runs an automated scan and has an assisted manual scan portion. This is a great way to test the accuracy of our results from the automated section. Additionally, I won’t be going through every piece in the assisted scan because there are other tools that check those things a little better. What I will be focusing on are steps 1, 2, 5, 7, 8, 9, and 11. (I’ll be skipping the “Automated checks” tab since I feel it is self-explanatory.)

Keyboard Navigation

The tool does a pretty good job at explaining what to do but, I wanted to add that I will be using the visual helper toggle at the top. If you are new to this whole WCAG Audit thing then this can help a LOT. This step is pretty simple though, it just involves using Tab and Shift + Tab to ensure you can reach everything on the page.

*The Tab key will only go to things that are links.

Focus Order

This portion is pretty similar to the test we just performed but, it’s checking the order of everything. This will help with making sure that everything is in an order that makes sense. For example, we don’t want the tab order to start in the footer. We want the first thing on the page to be a “Skip to Main Content” button.

No Missing Headings

The visual helper for this portion highlights all of the headings. We want everything that looks like a heading to be coded as one. There are some exceptions to this rule like Table headers. The biggest focus here is things should be semantic.

Heading Level

The visual helper for this portion, like the last section, highlights all of the headings. This is checking the actual level of the <h> tags. For WCAG 2.2 the level that is coded is what we should see visually. For example, all h2’s should have the same size and font-family.

Bypass Blocks

What we’re checking for with this test is the ability to skip to the main content of the page. The last thing someone wants is to have to go through the WHOLE menu on every page before they can get to the body.

Reflow

We need to test to make sure our content can grow without breaking the page or flow of content. It’s important to be able to visually see everything even if you have low vision and need content displayed differently. Horizontal scrolling is not good but, some exceptions are made.

Export Result

Now that we’ve gone through each step, we can export the results to put in our PDF. Just click on “Export result” in the top right-hand corner. A pop-up will appear and give you a chance to give your report a description. After you’ve typed your lovely description, you have two options to export. You can export it as HTML or as JSON. Personally, I’ll be exporting everything as HTML and adding it to Box to hyperlink in my PDF.

Time To Test (Manually)

With the automated and auto-manual tests done and the issues addressed or noted, let’s hop into the finale of testing. We’ll want to make sure our page is refreshed and at the top.

Test 1: Page Structure

With the first of our manual tests, we’ll be ensuring the hierarchy of the page. (Yes, it is also an automated test lol)

In this step, we’ll need to open the inspect panel. We’ll want to ensure the use of appropriate headings and landmarks throughout the HTML code. (This might be best to pull up a copy on your local machine but to each their own.) This is a step that can be integrated into the dev process so you can eliminate this later but, until it’s actually integrated it’s best to double-check.

You’ll want to make sure that there isn’t any mixing and matching of the <h> tags. Contrary to how the design may look, you’ll need to use the actual HTML structure rather than “what looks good.”

*This next point could also be integrated into the development process.

Lastly, we’ll want to create landmarks for easier navigation with screen readers. We will get into screen readers and the web rotor in the next step.

Test 2: Screen Reader Navigation

For the last, and biggest, of our manual tests, we’ll be utilizing a screen reader. This will test any of the changes that have been made so far and see if things are actually in a semantic order.

To begin, I am using the VoiceOver accessibility feature built into Apple’s ecosystem. There are a couple of reasons for this choice, the main one being that it is free. I would also HIGHLY recommend going through the VoiceOver Training before continuing forward, unless you have experience with a screen reader/ VoiceOver.

Brief Overview of VoiceOver

Before turning on VoiceOver, select the window/site that you want to use it on. To turn on/off VoiceOver, use the shortcut Cmd + F5. From there you’ll want to use the VoiceOver Modifier (VO) and the arrow keys to navigate the page. We’ll need to go through the whole page but, we can start by checking the Web Rotor. You can access the Web Rotor by pushing VO + U. This will open up with links and you can navigate the Web Rotor by using the arrow keys. If we keep pushing the right arrow key, we will go through the following Web Rotor menus:

  • Links
  • Headings
  • Form Controls
  • Landmarks
  • Frames
  • Window Spots

We will mainly be using the first four.

  • Links: This Web Rotor menu will have all of the links, that are on the page, inside of it. You can navigate these links by using the up and down arrows and select one by using your VO Modifier + Spacebar.
  • Headings: This Web Rotor Menu will have all of the Headings, that are on the page, inside of it. You navigate these headings the same as the links menu.
  • Form Controls: This Web Rotor menu will have all of the interactive parts, that are on the page inside of it. For example, this would contain the slides that are in a carousel.
  • Landmarks: This Web Rotor menu will have all of the Landmarks, that are on the page, inside of it. For example, this menu will have things like header, navigation, main, etc.

Although the screen reader will be a helpful tool to ensure semantic HTML, the screen reader will also be really helpful when going through the content of a page. The screen reader will read alt text when it lands on an image and if there is no alt text then it will read the entire file name instead. This would be a great way to catch bad or no alt text.

We can also ensure that custom controls on carousels, or things of that nature, are interactive with the screen reader. We do want pop-ups to be seen by the screen reader as well. If a pop-up is not seen by the screen reader then we need to adjust the tab-index to be -1.

Pulling it all Together

With our testing coming to a close there are a few things we need to do. I hope you’ve been gathering your thoughts and screenshots throughout this process. This will make things much easier. Ensure that they’re uploaded to Box inside the ‘WCAG Audits’ folder.

Making your PDF

I recommend making a PowerPoint that you can then export into a PDF. For this I change the theme colors to match the site I’m working on and separate everything into their perspective tests then separate it even more into their respective pages. Organization will be best, especially when making tasks in clickup.

Adding Tasks

To finish up the auditing process, we need to make tasks of all the things. To be honest, we only need to make tasks of things to fix. You can see how I’ve broken down the tasks ehrn creating them in clickup:

  • Lucid
    • Home Page
      • Automated Test Results
      • Auto-Manual Test Results
      • Manual Test Results
    • About Us
      • Automated Test Results
      • Auto-Manual Test Results
      • Manual Test Results
    • Contact
      • Automated Test Results
      • Auto-Manual Test Results
      • Manual Test Results

Conclusion

And with that, the testing can finally come to an end. It’s important to remember that not every way is perfect and neither is every tool. We can still have the high-ground over WCAG! (Until it gets updated…) Your move, young developer.

Other Resources

How to do an Accessibility Review - This is a great resource provided by the team at Google. Watch the video to help you get started with a better understanding of WCAG and how to start preforming an audit.

ARIA landmark role - This will give you more information as to what a landmark is, and the best practices for landmarks.

Accessibile SVGs - There is nothing worse than using a screen reader and being read the entire file name of an image. Or worse, skipping the image due to an empty alt tag. This is a great guide to ensure all of the images on a page have alt text and even gives suggestions as to how to write alt text.