These steps provide a high-level view of a recommended way to test a website for accessibility issues. The following process is a condensed version of the full Cornell Web Accessibility Review Methodology; please head to that document for more detailed and updated testing process. 

Step 1: Siteimprove & Other Automated Tools

Siteimprove is the university’s accessibility monitoring software. To use Siteimprove, you will need to set up an account and request access to a website. The IT Service Desk will help you get access to the sites you need to monitor and can help you add sites that are not already in Siteimprove. Once you have access to those sites, you can view information about their latest scans in the Dashboard and dive more deeply into individual modules (web accessibility, quality assurance, usability, SEO, and more) to get additional information about the page.

Note that the main Siteimprove Dashboard is a great way to monitor the accessibility of a public-facing site over time, but it cannot scan pages that are behind a login and it cannot identify every accessibility problem; many of the most critical accessibility barriers can only be identified via direct manual testing.

For sites that are behind a login, you can check the accessibility of individual pages using Siteimprove’s browser extension. To use this and other accessibility browser tools (such as Axe DevTools, WAVE, and ANDI), you need to load the page you want to check and activate the tool. The tool will then give you information about the page including information about accessibility problems.

Step 2: Manual Testing

The first step for manual testing is to create a list of pages on the site that you will test directly. At minimum, these should be the home page for the site and any top-level navigation landing pages, as well as administrative site pages linked in the footer (privacy policy, accessibility help, etc.). You can also head to the Siteimprove QA module and review the Priority Pages function in the Summary section, which can help you identify pages that are high-traffic or would benefit from a closer review for other reasons. Ideally, your testing scope should include at least one of every page template used on the site as well as having examples of all of the different kinds of functionality.

Once you have determined your scope, you can begin testing. Record your test results as you go; if you like, you can make a copy of Custom Web Development’s WCAG Checklist to guide you through different tests and record what you find.

Keyboard Navigation and Functionality

Keyboard usability is one of the most important items to test. Many, many people use keyboard-primary or keyboard-only navigation and input for one reason or another. To test with the keyboard, put your mouse to the side and try to move through the page using only the Tab key and arrow keys (note that Mac users may have to enable keyboard navigation in their OS and browser settings).

The Tab key should allow you to jump from one user interface (UI) component (links, buttons, menus) to the next. If the Tab key does not work on a component, see if the arrow keys let you move through it (this will be the case with some submenus and with radio buttons. You should be able to move to all UI components on the page without having to use your mouse or touchpad.

Next, check to see if you can activate all those components using just the keyboard. You should be able to activate any UI component with the Enter key, whether it’s a link, button, menu, etc. Buttons and submenu flyouts should also be activated by the space bar.

Use of Color

Start by skimming through the page and looking for any spots where the automated testing might not have been able to analyze the colors. This will be areas with color gradients, text that is placed over an image, and dynamic text (text that appears on the page after you do something, such as an error message). Also look for UI components like buttons that show their use via a symbol.

Sometimes, it will be easy to look and determine that the contrast level is probably fine. If you’re not sure, though, use a tool like TPGi’s Color Contrast Analyzer to check the contrast between the foreground and background. Ideally, all text will have at least a 4.5:1 contrast against its background and all non-text UI components will have at least a 3:1 contrast.

Also look through the page to see if there are any items where a change in color alone is used to indicate status or functionality. This often shows up in forms, where sometimes a form field will turn red if it has an error. Make sure that any color changes are also reinforced by information in text, a change in shape, or some other non-color indicator. UI components like links should also be shown by more than just different-colored text; an underline is the most common "backup" indication for a link.

Page Structure

For a webpage to be accessible, the page structure that is shown visually needs to also be included in the HTML markup—this allows assistive tech like screen readers to identify and read out the structure as well as the text itself. Page structure includes elements like headers—text on the page that is meant to show where a new section begins and what’s in that section—and lists. If a piece of text looks like a header or list, it needs to be formatted that way in the HTML too.

Structure can be a little trickier to check if you’re not comfortable with HTML, but there are tools such as WAVE and ANDI (linked above) that, when turned on, will visually mark on the page what a piece of text is. Those tools can be a big help in confirming that the page structure is both visual and programmatic (i.e., in the HTML).

Media supports

Ensuring that all media—images, video, audio—on the page has appropriate supports is also important. All images should have either a text alternative that describes the information communicated by the image, as related to the rest of the page content, or be marked as decorative so that screen readers and other assistive tech will know to skip it. Videos and audio need to have supports such as captions, a transcript, and possibly audio description. The Accessibility and Embedded Videos page gives more in-depth information about these supports.

Screen Reader Testing

Screen reader testing is one of the more complicated testing methods as you have to learn how to use the screen reader first. It can, however, make it easier to quickly identify problems that might take more time if you have to look into the HTML. Screen readers communicate both page content and page structure, so you can, for instance, hear via the screen reader whether or not an image has appropriate alt text (or alt text at all!) and whether or not that text that looks like a heading is actually formatted as a heading.

What screen reader you will use depends on your operating system. On Windows, you will use NVDA (Non-Visual Desktop Access) or JAWS (Job Access With Speech). On a Mac you will use VoiceOver, Apple’s built-in screen reading utility. If you are testing on a mobile device, you will use the native screen reader for that device. If you decide to test with a screen reader, give yourself time to learn how to use the screen reader—don’t try to adapt quickly! Also keep a list of screen reader keyboard shortcuts at hand. Deque University’s Screen Reader Keyboard Shortcuts and Gestures is an invaluable resource and does have PDFs that you can print out.

Additional Areas to Review Manually

If you have time, you can also check how the page behaves when you increase the text size or zoom in on the content and how it reflows if you change it to a mobile device view. You can also check documents that are linked to the page (such as PDFs) to make sure that they are accessible.

Need Help?

Web accessibility testing can be time consuming and a bit daunting, so if you feel overwhelmed or just want some hands-on training with an experienced tester, please get in touch with the Web Accessibility team. We’re happy to answer questions and schedule a training session to help you get more comfortable with the process.