Software Accessibility Checklist

This checklist can be used to check third party or custom application for accessibility compliance.

Overview

The purpose of this checklist is to ensure that all university software systems have been tested for compliance with the following: 

  • Keyboard only controls: Users should be able to navigate the software with exclusive use of the keyboard. This includes Tab or Focus Controls.
  • Screen Reader Compatibility: Screen readers should be able to accurately read, navigate, and interact with the software. This includes: 
    • Alternate text for images: Images and other non-text context need text alternatives so screen readers can convey their purpose 
    • Proper HTML Formatting for headings and lists 
  • Appropriate link text: Link purpose should be clear from the link text or its surrounding context and should never include vague language like "click here."
  • Color Contrast: Text, icons, controls, and meaningful graphics have enough contrast against their background to be easily seen 
  • Video and Audio Accessibility (if applicable): Video or audio content can still be understood by users who may have visual or hearing impairments or by users who prefer consuming content in some other way. This includes:  
    • Alternatives to video and audio only content 
    • Captions for both prerecorded and live videos 
    • Video and audio control, including the ability to pause, stop, or control audio that plays automatically 

Testing Procedure

The following is a step-by-step guideline on how to test software for compliance and documenting those findings. This has been created with web-based software in mind. If you are testing desktop-based software, some of the test criteria may not apply.  

Step One: Microsoft Accessibility Insights for Windows

  1. This software is used for automated and keyboard accessibility testing. 
  2. It is available as a web extension or desktop download. Both versions are available at the following link: Accessibility Insights Downloads 
  3. Upon launching the software (or web extension) click the “Fast Pass” option, this will run an automated test on your web page or software system. 
  4. You should receive a notification once the automated test has been completed. 
  5. Click the “Expand All” to see details about any failed instances.
  6. Record any failed instances. We recommend creating a table for this with two columns, "WCAG Criteria Number" and "Snippet." 
  7. After completing the automated testing, click the “Tab Stops” button on the left sidebar of the accessibility insights software.
  8. Follow the instructions given by accessibility insights to test the tab controls for the software.
  9. Record the results in a table like the one below:

Requirement 

Pass/Fail 

Keyboard navigation: All interactive elements can be reached using the Tab and arrow keys 

 

Keyboard traps: There are no interactive elements that “trap” input focus and prevent navigating away 

 

Focus indicator: All interactive elements give a visible indication when they have input focus 

 

Tab order: The tab order is consistent with the logical order that's communicated visually. 

 

Input focus: Input focus does not move unexpectedly without the user initiating it. 

 

  1. After completing the tab controls test, click the “Needs Review” button on the left sidebar of the accessibility insights software.
  2. Record any instances in a table similar to the one for Step 6.

Step Two: Test tab controls without any accessibility tools

  1. Turn off Microsoft Accessibility Insights for Windows or any other accessibility software.
  2. Try to navigate the software using only tab controls.
  3. Make sure you can access all items on the page using only tab controls.
  4. Make sure there is a clear visual indicator when items receive input focus.
  5. Record your results in a table like the one below:

WCAG Criteria 

What it is 

How to test it 

Conformance Level 

2.4.7 Focus Visible 

Keyboard focus must be visually clear and apparent 

Tab through the interface and confirm every interactive element has a visible focus indicator. 

 

Step Three: JAWS screen reader testing

WCAG Criteria 

What it is 

How to test it 

Conformance Level 

1.1.1 Non Text Context 

Images, icons, buttons, and other non-text content need meaningful text alternatives unless decorative. 

Use a screen reader to confirm images and icon controls have appropriate accessible names or are marked decorative. 

 

1.3.1 Info and Relationships 

Structure and relationships must be programmatically available, such as headings, lists, tables, labels, and groups 

Inspect HTML/semantics and test with a screen reader to confirm structure is announced correctly. 

 

1.3.2 Meaningful Sequence 

Content must be presented in a logical reading order when sequence affects meaning.  

Navigate with a screen reader and keyboard. Confirm the reading and focus order match the visual order and preserve meaning. 

 

2.4.1 Bypass Blocks 

Users must be able to bypass (skip) repeated content, such as headers, navigation menus, or sidebars. 

Check for skip links, landmarks, headings, or other mechanisms that let keyboard and screen reader users move directly to main content. 

 

2.4.2 Page Titled 

 

 

Each page must have a descriptive title that identifies the page’s purpose or topic. 

 

Check the browser tab, HTML <title> element, and screen reader announcement to confirm the title is unique and descriptive. 

 

2.4.4 Link Purpose (In Context) 

The purpose of each link must be clear from the link text or its surrounding context. 

(No links that just say: “Click Here”) 

Review links with a screen reader and visually on the page. Confirm vague links such as “Click Here” or “Read More” make sense in context. 

 

2.4.6 Headings and Labels 

 

 

Headings and labels must describe the topic, purpose, or function of the content or control. 

 

Review page headings and form/control labels. Confirm they are clear, descriptive, and match the content or action they identify. 

 

3.3.2 Labels or Instructions 

Forms and inputs must provide labels or instructions when users are expected to enter information. 

Inspect each input, dropdown, checkbox, and form field. Confirm visible labels, required field indicators, format instructions, and error-prevention guidance are provided where needed. Confirm these can be discovered and announced by screen readers 

 

4.1.2 Name, Role, Value 

User interface components must expose their accessible name, role, state, and value to assistive technologies. 

Test with a screen reader. Confirm buttons, links, menus, dialogs, tabs, and form fields announce correct names, roles, states, and values. 

 

4.1.3 Status Message 

Status messages must be announced to screen readers without moving focus, such as errors, confirmations, or loading updates. 

Trigger status messages and test with a screen reader. Confirm updates are announced using appropriate live regions or programmatic status messaging without forcing focus changes. 

 

Step Four: Colour Contrast Analyser (CCA)

  • Colour Contrast Analyzer is a small program used to test the color contrast of websites and desktop software.  
  • “Colour Contrast Analyser” is available for download at the following link:  Colour Contrast Analyser (CCA) - Vispero 
  • While using “Colour Contrast Analyser,” test the following criteria for compliance: 

WCAG Criteria 

What it is 

How to test it 

Conformance Level 

1.4.1 Use of Color 

Color cannot be the only way information is conveyed. 

Check links, errors, charts, and status indicators to confirm information is also conveyed by text, icons, patterns, labels, or through some other method besides color 

 

1.4.3 Contrast (Minimum) 

Text must meet minimum contrast requirements against its background. 

Use a contrast checker to verify normal text is at least 4.5:1 and large text is at least 3:1 

 

1.4.11 Non-text Contrast 

UI components and meaningful graphics must have sufficient contrast. 

Check buttons, form borders, icons, focus indicators, and charts for at least 3:1 contrast 

 

Step Five: Manual testing for audio and video (if applicable)

Identify any video and audio content in the software and test the following criteria for compliance: 

WCAG Criteria 

What it is 

How to test it 

Conformance Level 

1.2.1 Audio-only and Video-only (Prerecorded) 

Alternatives must be available for prerecorded audio-only or video-only content 
(Audio only = sound only, no video) 

(Video only = video only, no sound) 

For video-only content, confirm that an equivalent text or audio description of visual information is available. For audio-only content, confirm that an accurate text transcript is available. 

 

1.2.2 Captions 

Prerecorded video with audio must include captions for spoken dialogue and important sounds. 

Play prerecorded videos with sound. Check that captions are available, synchronized, accurate, complete, and include meaningful sound cues such as music, laughter, or alarms. 

 

1.2.3 Audio Description or Media Alternative (Prerecorded) 

Prerecorded videos with audio must provide either an audio description or a text based alternative when visual information is needed to understand the content. 

Review videos for important visual-only information. Confirm that an audio description or equivalent written alternative describes key actions, text on screen, scene changes, and other meaningful visuals. 

 

1.2.4 Captions (Live) 

Live videos with audio must provide captions in real time. 

Review live streams or real-time video events. Confirm live captions are present, reasonably accurate, synchronized, and available to users during the live presentation. 

 

1.2.5 Audio Description (Prerecorded) 

Prerecorded videos with audio must provide an audio description when visual information is needed to understand the content. 
(Same as 1.2.3 except an audio description is required, text-based alternatives are not enough) 

Review videos for important visual-only information. Confirm that an audio description describes key actions, text on screen, scene changes, and other meaningful visuals. 

 

1.4.2 Audio Control 

If audio plays automatically for more than three seconds, users must be able to pause, stop, or control the volume independently from the overall system volume. 

Check any pages or systems where audio starts automatically. If it plays for more than three seconds, confirm there is an accessible pause, stop, mute, or volume control that can be operated by keyboard and assistive technology.