Testing web accessibility
Last updated:
Use this guide to get started with testing interactive websites and web applications for accessibility and assistive technology support.
Learn the fundamentals
There are common building blocks that support digital accessibility across all content types. This fundamentals guide gives you the basics to help you get started.
Automated testing
Automated accessibility tests are good for identifying technical barriers in the code, such as:
- Images without alt text: Automated testing tools can aggregate a list of text alternatives in content and identify images that do not have alt text. Be sure to check that all of the text alternatives are appropriate for the images, and mark images as decorative as appropriate.
- Low contrast text and background combinations: While testing tools can test colors set in the HTML and CSS of a website, such as color of main text or text on buttons. They cannot test for contrast within images on a site. Banner images, flyers, charts, and other embedded images will require manual testing.
- Missing heading levels: Testing tools can build an outline of content based on the heading and paragraph tags within a website. Check the generated outline to make sure it includes all headings and content in a logical order with appropriate nesting.
- Inaccessible form or table formats: The labels for form elements like text fields and checkboxes must be associated with those elements in the code, and automated tools can flag when a label doesn’t have an associated form element, and vice versa. They can also flag common barriers with tables, such as tables missing a table header or overusing spanned cells for layout.
Page scanners work by scanning the HTML, CSS, and JavaScript of a webpage. Scanners identify common code patterns that create accessibility barriers based on the Web Content Accessibility Guidelines (WCAG). These tools scan a page, then share results by applying a visual overlay to the page or generating a summary report to share information about potential barriers.
There are many free websites, browser extensions, and other page scanning tools available that evaluate based on WCAG standards. The main difference in these tools is the level of guidance, from Pass/Fail to highlighting barriers in the code, so feel free to explore different tools and extensions and find what works for you.
Get started with one of the following tools:
WAVE by WebAIM is a free tool that allows the user to conduct web page accessibility testing and provides a detailed overlay displaying the barriers on a page. Test via any browser, or add a Chrome or Firefox extension.
Google Lighthouse is an open-source automated tool for improving the quality of web pages. This tool evaluates web content against a set of best practices and accessibility standards and provides an accessibility audit report.
Axe by Deque is a free accessibility testing tool that allows developers to run a Chrome or Firefox extension. There is also a tool for Android and iOS.
The mechanics behind site crawlers are similar to page scanners, by scanning the code for common barriers. The administrator of a site crawling tool can adjust settings for the number of pages on a website that the crawler will scan, particular types of barriers to surface, or the level of detail included in the final report. While the goal of a single page scanner is to support barrier identification and remediation, the main purpose of using site crawlers is to provide a report on the overall status of the accessibility of a website.
These tools often have a fee for service and are managed at a divisional or institutional level.
Manual testing
Not all critical accessibility barriers are written into the code, and automated testing won’t find them. Manual accessibility testing is required to find functional accessibility barriers, such as:
- Visible indication of keyboard focus
- Logical and comprehensive reading order for screen readers
- Accessible dynamic content and multimedia
- Accessible content layout at high levels of magnification
The following sections of this guide give some information about the types of barriers you can find through manual accessibility testing and how to get started with some common accessibility tools and commands. If this is your first time using a keyboard or screen reader to navigate a website, you may want to practice these commands on this guide page. Additionally, practicing on websites like the W3C Accessibility page, a WebAIM article on Usable and Accessible Form patterns, or trying examples of interactive elements in the ARIA Authoring Practices Guide Patterns page can help you learn the expected behavior when navigating with these tools.
Keyboard navigation
- “Skip to main content” link: Including a link at the top of the page for users to skip past site navigation and other repeated content helps users get to the main information faster.
- Visual indication of focus: When navigating via keyboard, a user must always be able to visually identify their place on the page.
- Navigation order: All interactive content such as buttons, links, and form elements must receive keyboard focus in a logical order, usually matching the visual layout.
- Navigation length and cognitive load: Pages with a lot of information or complicated layouts can be difficult to navigate with assistive technology.
To test for keyboard navigation support, try the following commands on a webpage.
- Tab to all clickable content
- Shift + Tab to go through the same content backwards
- Enter to activate links
- Enter or Space to activate buttons
- Esc to dismiss menus and popups
For more: WebAIM Techniques: Keyboard Testing
Screen reader navigation
- Visual hierarchy matches tagged hierarchy: Headings are tagged in order from h1 to h6, without skipping a level.
- Text alternatives: All images containing key information for the content of the page must have text alternatives, such as alt text or image descriptions.
- Navigation order: All page content, such as text, images, and interactive elements must receive screen reader focus in a logical order, usually matching the visual layout.
- Navigation length and cognitive load: Pages with a lot of information or complicated layouts can be difficult to navigate with assistive technology.
VoiceOver (VO) is the Mac operating system’s built-in screen reader.
VO modifier key: To help prevent conflicts between screen reader navigation and other common keyboard navigation patterns, many screen reader commands use a modifier key, which can be customized by the user. By default, VO uses either Caps Lock or Control-Option as the modifier.
When navigating via VO, content is organized by hierarchy, and items on the same level of the hierarchy are often grouped together. As such, you need to navigate into and out of nested content areas referred to by the screen reader as areas or groups.
Common navigation commands
- Command + F5 starts VoiceOver
- VO + Shift + Down Arrow to enter into a grouped content area
- VO + Shift + Up Arrow to exit a grouped content area
- VO + Left Arrow or Right Arrow moves through groups or content within a group
- VO + Space to activate links and buttons
For more information about using VoiceOver, get started with VoiceOver on Mac.
NonVisual Desktop Access (NVDA) is a free and open source screen reader available for Windows operating systems.
NVDA modifier key: To help prevent conflicts between screen reader navigation and other common keyboard navigation patterns, many screen reader commands use a modifier key, which can be customized by the user. By default, NVDA uses the Insert key as a modifier, and this is commonly changed to Caps Lock during setup. The NVDA modifier key is represented by NVDA in the common navigation commands.
Common navigation commands
- Cntrl + Alt + N starts or restarts NVDA
- NVDA + Q, then Enter exits NVDA
- Shift interrupts announcement. Pressing it again will continue announcement where it left off.
- NVDA + Down Arrow announces all content from the current position
- Up Arrow or Down Arrow announces the current line.
- H and Shift + H move to the next or previous heading
- L and Shift + L move to the next or previous list
- I and Shift + I move to the next or previous list item
- D and Shift + D move to the next or previous landmark
- T and Shift + T move to the next or previous table
For more information about using NVDA, browse the NVDA User Guide.
Screen magnification
- Enough space for content to enlarge: As the user magnifies content, text and other elements must not collide or get pushed off of the screen. For content that normally scrolls vertically, horizontal scrolling must not be introduced.
- High quality images: Images and other visual elements should remain clear as the user magnifies the screen, and not lose focus or become pixelated at higher levels of magnification.
- All content is included in any layout options: If content reflows at higher levels of magnification, or there is a mobile or other alternative layout option for a website, all content must be included in all variations of the site layout.
According to the web standards we strive to meet at UW–Madison, web content needs to be accessible, “without loss of information or functionality, and without requiring scrolling in two dimensions for vertical scrolling content at a width equivalent to 320 CSS pixels.”
Zooming a page to 400% magnification is a reliable way to test for the upper end of reflow and magnification support.
Get help from the Center for User Experience (CUE)
We partner with you to create accessible, usable, and inclusive digital spaces through free evaluations and consultations.