Have you ever done a web accessibility audit? If not, I will help you break down my suggested approach. Understanding the compliance criteria can feel overwhelming if you’ve tried to read through the Web Content Accessibility Guidelines (WCAG). Part of the difficulty many people face when addressing barriers for people with disabilities is that the issue is not often visible to sighted users.
What is a website accessibility audit?
A website accessibility audit examines a website’s usability for people who have a disability or use assistive technologies. The goal is to identify barriers that can be detrimental to the user experience and usually based on standards such as the Web Content Accessibility Guidelines (WCAG).
Why are accessibility audits necessary?
Websites are generally built and tested based on the technology your developer is comfortable with. While many issues are apparent visually or functionally, accessibility testing must be performed using assistive technologies such as screen readers. Web accessibility may also be a legal requirement based on your local laws or required by procurement policies.
Why does web accessibility matter?
Statistics say that about 1 out of every 5 people have some form of disability. Implementing web accessibility will expand your audience while improving usability for everyone. The practices outlined in web accessibility can also benefit users who encounter situational difficulties, such as enhancing colour contrast so mobile device users can read the text in bright daylight or closed captions for users watching a video in a loud office. Additionally, search engines interact with your website like a screen-reader and making your content readable will improve search engine rankings.
Define the scope of the test
Ideally, you would be able to evaluate the entire website for issues, but this isn’t always practical. Websites generally have standardized page-to-page templates with different content but repeated semantic structures.
A few things to consider are:
- Are a few pages going to be evaluated or the entire website?
- Which templates would cover the majority of variations in web elements?
- Will the evaluation be limited to informational or transactional pages such as checkouts, invoices, etc.?
- Will you be solely responsible for the audit, or will you incorporate user testing?
- What conformance level are you trying to achieve (WCAG 2.0/2.1 A, AA, or AA)?
- Are you performing the audit for Section 508 or the Accessibility for Ontarians with Disabilities Act (AODA)?
Answering these questions before starting the audit will help you prioritize your efforts to get the most from the evaluation process.
Conducting an accessibility audit
Let’s get started! Using a combined approach of automated tools to quickly identify the majority of issues and manual testing refine the results. There is no automated tool that can catch every error. Some problems will require the human touch.
Automated testing with the Web Accessibility Evaluation Tool (WAVE) by WebAIM
(Screenshot here)
Scanning a page with the WAVE website or Chrome extension gives you a good baseline to see issues related to colour contrast, missing alternative text, and semantic structure.
Steps to get the most from WAVE
- Inspect the errors in the details tab to see a breakdown of immediate issues. Opening the code preview helps to identify the problematic areas.
- Review the structure tab for content hierarchy. The headings should make sense as a clear table of contents. Avoid skipping heading levels and add headings where missing.
- Skim through the content and see if the HTML elements accurately reflect the presentation.
Many other tools and extensions are on the market, such as axe® by Deque, Siteimprove, and even Google Chrome’s Lighthouse checks accessibility. I find WAVE to be the most useful for me right now.
Manual accessibility testing
Conducting a manual testing process is essential to identify the barriers that your users may face. It will also give you an inside into the usability of your application for users that may interact with your web content in different ways based on their situations.
1) Keyboard accessibility
Most assistive devices emulate a keyboard to navigate through your website. This means using the tab key, arrows, and keyboard shortcuts to move around the website. Many non-disabled users are accustomed to using the tab key to navigate through forms for faster input.
What to test
- Can you use the tab key to navigate interactive elements such as the menu, links, and form fields?
- Does the tab order follow an intuitive flow?
- Can you navigate using the Up and Down arrow keys for elements such as selects, sliders, or menu bars?
- Are you able to interact with elements using the Enter or Space bar?
- Is there a visible indicator of what is in focus?
- Does the focus return to the element that triggered the dialog if pop-ups or modals are used?
- Does the Esc key close the dialog?
- Does the focus get stuck using keyboard-only navigation?
- Is the website clear and understandable with the screen-reader on?
2) Touch screens and gestures
Almost everyone is walking around with a small computer in their pocket. It gives us incredible access to the world of knowledge as soon as the need arrives or something to do at the slightest onset of boredom. Mobile devices are also far more affordable than computers and are preferred by individuals who don’t need a personal computer for home use. It’s no surprise that most online traffic comes from mobile devices.
What to test
- Are the clickable elements large enough to click comfortably?
- Do clickable elements have enough distance between each other?
- Can form inputs be used without relying on gestures?
- Is the screen-reader able to navigate and read the content correctly?
3) Meaning conveyed with colour
Using colour in design helps make websites look attractive. It is also often used to convey meaning, such as clickable links or statuses. This creates a barrier for people who cannot identify the variations in colours.
What to test
- What areas are colours used to communicate meaning or state?
- Is there a text-based method also used to convey the same meaning?
- Would the information still make sense if displayed in black and white?
- Are hyperlinks identifiable with enough visual contrast and/or underlines?
4) Alt text quality
Text alternatives allow assistive devices and search engines to read a description of images. Without a clear text alternative, visitors using screen-readers will not understand the meaning of an image. This is especially problematic when icons are used in place of text-based controls, such as a magnifying glass as a search button.
Tips on writing alt text: The text should not exceed 150 characters and summarize the purpose of the image. An informational image should communicate the key visual, while clickable icons like a magnifying glass for “Search” should indicate the intention. Do not include words like image, graphic, or photo unless it’s necessary for the meaning.
What to test
- Do all images have alternative text?
- Is the alternative text descriptive?
- Is there a text-based alternative if an image represents a graph or complex information?
- Are images being displayed as background images that need alternative text?
5) Audio and video content
Audio and video present different obstacles than traditional web content. Users must be able to understand the content even if they’re unable to see or hear it. This is accomplished through closed captions, transcripts, and audio descriptions.
What to test
- Are audio descriptions or text descriptions of video content available?
- Are closed captions available for videos with audio?
- Is there a transcript available for audio content or video with audio?
- Is there sign language available for pre-recorded videos? (AAA only)
- Does the player support keyboard control and navigation?
- Are the player controls understandable using a screen-reader?
6) Landmarks & Headings
Sighted visitors will quickly skim the website jumping between sections to navigate to the content they’re interested in. Screen-reader users navigate websites using landmarks and headings in much the same way.
What to test
- Does the website correctly use the HTML elements or corresponding attributes for landmarks (e.g. header, nav, main, aside, footer)?
- Do navigation landmarks have unique labels if multiple instances are used?
- Is the structure of the landmarks clear for screen-reader users?
- Are heading elements present on the page starting with an h1?
- Do headings follow an appropriate hierarchy?
- Do the different sections within the page have a headline to introduce them?
7) Links
Links can be obstacles for users because of two significant reasons. The first is that links may not be clearly differentiated from surrounding text or visual elements. The second is links may be unclear when read out of context. An example of this would be tabbing through links on a blog and hearing “read more” repeatedly for links that sent you to different posts.
What to test
- Are links within text distinguishable from surrounding content?
- Ensure HTML hyperlinks are being used instead of other elements such as a span or div with a JavaScript on-click event.
- For images used as a link, does the image alt text describe the purpose of the link?
- Has the page avoided multiple links to the same destination with different text?
8) Forms (Labels & Inputs)
Forms can pose problems for sighted and blind users if the structure of the form and visual representation isn’t organized clearly. Whether we’re evaluating a newsletter sign-up or a checkout page, having your users successfully complete forms is usually a key measure of success for your website.
What to test
- Does the label appear near the input making the connection clear to sighted users?
- Make sure placeholders are not used as a replacement for labels.
- Can the label be understood by assistive technologies such as screen readers?
- Does the label clearly convey the purpose of the form element?
- If an image is used as a label, does the image contain appropriate alt text to describe the purpose of the input?
- Are group labels visible to sighted users and near their form elements?
- Are group labels understood by screen readers as associated with their elements?
- Are the group labels clear in their purpose?
- Are the form or form group instructions visible and appear before users interact with the form elements?
- Are instructions understood by screen readers using aria-describedby?
- Are instructions clear in their purpose?
- Instructions do not rely on sensory characteristics like colour alone. (e.g. fields outlined in red are required)
- Do validation messages appear near the input or clearly indicate which input was invalid?
- Are validation messages clear in communicating what action a user must take?
- Is the validation message read by screen readers immediately after submission?
- Does the form have a clearly understood success message?
- Is the success message clear to screen-reader users?
Reporting & Fixing the Issues
Testing your websites is vital to identify potential barriers for people with disabilities. While this audit may not catch everything, it will allow you to find the most common accessibility issues to implement fixes or create documentation for the development team.