Testing Web Accessibility

Last updated April 8, 2025

Use this guide get started with testing interactive websites and web applications for accessibility and assistive technology support.

Quick tips

1. Learn the fundamentals

You need to follow the same core steps for accessibility regardless of your content’s format. This fundamentals guide gives you the basics to get started.

Fundamentals guide

2. Learn the best practices for web accessibility

Make your websites and apps accessible so everyone can use them easily. Focusing on accessibility from the beginning creates digital experiences that more people can use.

Website and web app accessibility guide

3. Test with automated tools

Page scanners and site crawlers can help identify common types of barriers and areas that could use further investigation.

4. Perform required manual testing

Manual accessibility testing helps discover functional barriers that automated checkers can’t identify. Get started on testing for keyboard, screen reader, and screen magnification support.

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
Site crawlers

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.

“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.

Screen reader navigation

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

What to test for screen magnification
How to test for 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.

The Center for User Experience

At the Center for User Experience, we are committed to working with you to make digital spaces more accessible, usable and inclusive for all students, faculty and staff at UW–‍Madison. We help the university follow its Digital Accessibility Policy by offering free evaluation and consultation services to all UW–‍Madison community members.

Get in touch

Meet with us: Book a quick chat with one of our team members to ask any questions you have.
Start a project with us: We support accessible design and development. Fill out our Let’s Connect form to begin working with us on your project or to request an accessibility evaluation.
Email us: Not sure if you’re ready to meet? Email us to start talking and figure out what to do next.

Cookie Notice

Testing web accessibility