Building an accessible website: Auditing your website for accessibility

The reasons for bringing your website in line with the Web Content Accessibility Guidelines (WCAG) 2.0 are well documented. Whatever your rationale for embarking on this worthy task, you will need to assess your current online presence for compliance.

Upgrading the accessibility of your website typically requires these main steps:

1. Audit: An assessment or audit of the site in its current state with respect to the WCAG.
2. Remediation: The implementation of fixes to address issues discovered by the audit.
3. Maintenance: Clear directives for developers and editors that will maintain the accessibility of the site through ongoing maintenance and future development.

In this post we will be concentrating on the first step. You must first determine the scope of the task ahead by performing an audit. This assessment may also expose issues that need attention even in the absence of an accessibility initiative, such as malformed HTML, which is a failure of both the WCAG and web development best practices.

You can conduct an audit internally, but as web accessibility can be as much an art as it is a science, it may be prudent to outsource this task to a company with experience in web accessibility auditing and remediation. If you decide to forge ahead on your own, here are some tips to guide you along the way.

Before you get started, it’s a good idea to familiarize yourself with the WCAG. Their reference site has the 12 guidelines and 61 success criteria thoroughly documented, and there are also examples of failures to the standard. You can also filter the success criteria for the level of standard you are targeting: A, AA, or AAA. This is valuable as you will need to decide what level of WCAG you are going to pursue before proceeding with your audit. Note that while achieving AAA is a lofty goal, it is virtually unobtainable for all but the most basic and simply formatted sites.

Operating systems and browsers to support

Visitors requiring accessible content use a variety of devices, including personal computers, smart phones, and tablets. These devices support a variety of operating systems including but not limited to macOS, iOS, Windows, Ubuntu, and Android. You should take some time to consider all of these devices and operating systems, but it’s important to decide what to focus on. We recommend choosing one browser per platform to support, otherwise you can complicate the audit and any following remediation. This is perfectly acceptable as long as you provide a page on your site that outlines your accessibility strategy. We like to go with the platforms that are most popular among users and also free to use:

• macOS
  • Safari browser with VoiceOver: Special note that on macOS, you need to enable the accessible tabbing behaviour in Safari > Preferences > Advanced. You can learn more about this in our post about the screen reader experience.
• Windows
  • Firefox browser with NVDA
• Android
  • Firefox browser with Talkback / Voice Assistant

Review the site technically

It is advisable to review the site on two fronts: technically and experientially. Technical tools will parse your pages and produce reports based on the WCAG. This is a very useful starting point, as it represents a way to document issues for subsequent third-party audits that might be required. Here are a couple of online tools to facilitate an examination of the structure of your pages:

1. Wave: This is a Chrome extension you can activate while on a page that will outline errors and alerts - an important distinction as errors are outright failures and alerts are recommended actions. Each error is identified on-screen by an icon that can be expanded to reveal which WCAG success criteria it fails. This tool also recognizes potential contrast issues.
2. AChecker: This online tool lets you submit your page and test it for WCAG and HTML errors. It can filter its results based on the WCAG level you are supporting.

Performing this technically driven review is a good starting point, but these automated assessments are not all-encompassing and will not uncover all accessibility issues. They might also flag issues that later prove to be false positives. In any case, you can’t truly understand how people with disabilities interact with your site without experiencing your site as they do, or at least as much as that is possible (on actual devices with browsers and accessibility tools). If you are not a person with disabilities, you must continually remind yourself to review your content from their perspective. That perspective is not limited to people with impaired vision or impaired hearing. Accessible websites must cater to people with cognitive disorders and physical disabilities as well.

Is your website accessible to people with disabilities?

Get our beginner's guide to website accessibility

Download your FREE copy

Put your CMS to work

You can take different approaches to your audit. You can audit the site by working through the guidelines or success criteria, and this would help the thoroughness of your report, but take note that you will have nothing to report for some of the success criteria. On smaller sites, you could take a page by page approach, but auditing every page of a large site would be a daunting task. On these larger sites, your content management system can help. If your site has thousands of pages, use your CMS to identify the different templates in use. Compile a list of pages that use those templates so you can break the site down to a more manageable subset of pages that are a reasonable representative sample containing one or two pages from each page type. There are always variations and exceptions within each page type, but you should be able to narrow down the list.

Review the site experientially

Since your users are on a variety of devices, operating systems, and browsers, you’ll need to test your site on at least the platforms you decide to support. However, you should be able to perform the bulk of the audit groundwork using one of the major operating systems - macOS or Windows - with the use of some developer tools to simulate mobile devices.

Auditing the site experientially will require you to use the very tools that visitors with accessibility challenges employ, primarily the keyboard and a screen reader. Keep in mind that many people cannot operate a mouse due to some limit of motor control or because they are visually impaired. Therefore, the keyboard will be a valuable tool for auditing the accessibility of your site.

The following will give you an idea of what you should be looking for during your audit. This is not a complete list, but more of a guideline to get you started. Depending on what features you have on your site, there are definitely other things to consider such as text alternatives for maps, how to approach videos that require captions and transcripts, and audio that will require transcripts.  

UI and UX: Start your screen reader. Step through each page that you are examining. Using the tab key, check to make sure that you can access and invoke every link, button, and input field using only the keyboard. All of these elements must also clearly show focus. Document any shortcomings. If you have menu items that fly out, these must all show when the keyboard accesses them. Pay close attention to the screen reader. Are the links clearly described? Are there any ambiguous context links such as “read more” and “click here”?

Content: You must be able to access regular content using the arrow keys on the keyboard. Make sure all content is read by the screen reader when navigating in this way.

Alternative text: Check all images for alt tags. There are some cases where the alt tag can be an empty string, but it is never acceptable for the alt tag to be missing altogether. Sorting out whether or not the alt tag is needed is an involved concept and requires a more detailed explanation.

Forms: Each form input must have a clearly defined label. Required inputs must use the “required” directive and not rely solely on the asterisk that is often used to denote mandatory fields. We have a detailed guide to help make your forms accessible.

Contrast: The Wave tool is a good introduction to where there may be some contrast issues, however it does not measure contrast against images and so may have some false positives or miss some issues. Use the Colour Contrast Analyser to assess the contrast between the text and the background, the text against the links, and any text over any image. Addressing contrast requires a nuanced approach.

Images of text: Identify any text that is displayed using an image but is missed by the screen reader such as in a background.

Pop-ups: Explore all of the pop-ups on your site. Does the focus switch to the pop-up? Is there audible confirmation of this action? If you see a pop-up appear but don’t hear anything from the screen reader, that’s a problem. The new window’s content must also adhere to the WCAG. Finally, users must have a way of exiting the pop-up using the keyboard via a close button or icon that is clearly labelled. Once a pop-up is closed, the focus should return to where the user was already.

Silent actions: Sometimes on a site we will click a button and receive purely visual feedback such as a message. This message must be heard as well as seen.

Upon completion of your audit, you should document your findings with detailed information about each instance, including but not limited to:

• The WCAG criteria that best matches the problem
• The URL(s) where the issue can be found
• Directions for the preferred solution

The above is by no means the only way to approach your documentation. Your organization may have different workflows and priorities. The main goal is to have as complete a reference as possible to support the remediation team, which may or may not be performed from within your organization. You will have to continually update your document to report progress and new issues to your team, so it’s important to stay organized. Your documentation will support your stakeholders’ need for a clear idea of the project scope and progress.

Auditing for future issues

Be prepared to revisit your audit during the remediation of your findings, as fixes in one area might create new problems elsewhere. It’s important to keep a close watch on each fix and update your audit if you find anything new.

Your audit may expose business practices that leave your site open to future WCAG failures. For example, the lack of any directive on the use of in-context links will allow editors to introduce new accessibility issues such as “click here” links. Also, do editors have the ability to use custom text and background colours? They shouldn’t. Rather, they should be given a defined palette from which they can choose their interface elements.

While copy creators and editors need to be schooled to audit new content for accessibility, developers will require clear coding guidelines to avoid creating templates that introduce WCAG failures post audit. For example, no <img> element should ever be created without taking into account what the alt tag will be according to the given parameters. Remember, even if you have ascertained that the alt tag is blank, the attribute must still be included as alt=””.

In the end, your initial audit is only the first big step in an ongoing effort to keep your website accessible to as many people as possible.

Ready to make your website accessible? Sign up to receive a copy of our website accessibility guide or contact us anytime for a free consultation.