Web Accessibility Checkers

Overview

In this lesson, you will learn how to inspect and evaluate websites for accessibility using tools that are built directly into web browsers. You'll explore the accessibility tree, a critical structure used by assistive technologies, and learn how to use browser inspect tools to view and understand it. You will also run automated checks with free and built-in tools like WAVE and Lighthouse and discuss what these tools can and cannot catch when it comes to accessible design.

Goals

You have the following goals for this lesson:

• Identify and use built-in browser tools to inspect the accessibility tree
• Use automated checkers (like Lighthouse on Chrome) to run accessibility audits
• Understand what automated tools can and cannot detect
• Interpret basic accessibility reports and start troubleshooting issues

Warm up

Imagine you have built a multi-page website filled with graphics, icons, and images. You did your best to include alternative text for the images, but with so many elements, it is hard to be sure you caught everything. Also, checking color contrast ratios across the site is tricky, especially with custom themes and colors.

Now imagine that a screen reader user navigates your site, but they can not see your visual elements, they only have access to the information in the accessibility tree. What if the tree is missing descriptions or labels? Would you know how to check?

Consider the tool, Inspect, that allows you to manually evaluate the accessibility tree; it is available on all browsers. And for a quick overview, browser-specific automated checkers like Lighthouse, for Chrome, can quickly scan your page and highlight potential issues.

Vocabulary

You will be learning about the following vocabulary words:

Web Content Accessibility Standards

This lesson covers the following standards:

• WCAG 2.2 - 1.3.1 Info and Relationships
• WCAG 2.2 - 1.4.1 Use of Color
• WCAG 2.2 - 1.4.3 Contrast (Minimum)
• WCAG 2.2 - 1.4.6 Contrast (Enhanced)
• WCAG 2.2 - 1.4.11 Non-text Contrast

Explore

WAVE - Web Accessibility Evaluation Tool

WAVE is a browser-based accessibility checker developed by WebAIM [1] at Utah State University. It overlays visual indicators directly on the web page to show potential accessibility issues, such as missing alt text, skipped headings, and low color contrast. This makes it useful for beginners or anyone looking to quickly understand how a page may be inaccessible to certain users.

To begin using WAVE, navigate to https://wave.webaim.org in your browser. Once there, enter the URL of any public website you want to evaluate and use the arrow button to run the analysis.

WAVE will display an interactive sidebar with a summary of potential accessibility issues, such as missing alternative text, low color contrast, and heading structure problems. It overlays icons on the webpage preview to help you locate each issue in context. Each icon is clickable and provides a brief explanation of the issue and its impact on accessibility, as well as a link to the relevant WCAG criteria.

WAVE is a potentially helpful tool for identifying common problems and learning how they appear in code and design and it provides a score of accessibility (out of 10). This lesson uses the online version for demonstration, however, WAVE is also available as a browser extension for Chrome and Firefox. Installing the extension allows you to test local or password-protected pages and makes accessibility checks more convenient during ongoing development.

Chrome Lighthouse

Lighthouse is a built-in accessibility checker in Chrome DevTools [2] that performs a quick accessibility audit alongside other evaluations such as performance and SEO (Search Engine Optimization). It provides a score of accessibility (out of 100) and a list of common issues found on the page, such as unlabeled buttons or poor contrast.

To run a Lighthouse audit, open Chrome DevTools (F12), navigate to the Lighthouse tab, select the Accessibility category, and select Generate report. Within seconds, it provides a summary along with suggestions for improvement, often linking to the relevant WCAG criteria. While Lighthouse is convenient and easy to use, especially because it is built into Chrome and it does not require any installation, its accessibility audit has limitations. It typically catches surface-level issues and does not deeply analyze interactive behavior or screen reader compatibility. It is best used as a first step in the accessibility testing process, offering a high-level overview that can guide further manual or automated testing.

What can and cannot be caught by automated web checkers?

Web accessibility checkers like WAVE and Lighthouse are great at detecting surface-level issues. These include:

• Text Alternatives and Semantic Info: Missing image descriptions, improper use of HTML landmarks or ARIA roles, and unlabeled buttons. (WCAG 2.2 - 1.1.1, 1.3.1, 4.1.2)
• Color and Contrast: Issues with low contrast between text and background, use of color alone to convey meaning, and text spacing problems. (WCAG 2.2 - 1.4.1, 1.4.3, 1.4.11, 1.4.12)
• Titles, Headings and Labels: Missing or unclear page titles and headings that are not coded properly. (WCAG 2.2 - 2.4.2, 2.4.6)
• Links and Navigation: Links without context or missing skip links for keyboard navigation. (WCAG 2.2 - 2.4.1, 2.4.4)
• Forms and Inputs: Unlabeled form fields, missing instructions, and inputs that do not have accessible names. (WCAG 2.2 - 2.5.3, 3.3.1, 3.3.2)
• Language and HTML Validation: Missing language declarations or code errors that impact assistive technology. (WCAG 2.2 - 3.1.1, 4.1.1)
• Flashing or Motion Content: Content that might trigger seizures due to flashing more than 3 times per second. (WCAG 2.2 - 2.3.1)

However, finding some more complex accessibility issues require manual testing or judgment based on context and are often missed by these automated web tools:

• Reading Order and Visual Flow: Whether content reads logically in screen readers or follows a sensible visual order. (WCAG 2.2 - 1.3.2, 1.3.3)
• Purpose of Inputs and Controls: Whether input fields or buttons clearly indicate their purpose in context. (WCAG 2.2 - 1.3.5, 1.3.6)
• Responsive Layout and Hover Content: Problems with content resizing, overlapping, or disappearing on hover/focus. (WCAG 2.2 - 1.4.10, 1.4.13, 4.1.3)
• Keyboard Navigation and Focus Management: Whether all interactive elements are accessible by keyboard, have clear focus indicators, or maintain correct focus order. (WCAG 2.2 - 2.1.1, 2.1.2, 2.1.4, 2.4.3, 2.4.7, 2.4.11, 2.4.12, 2.4.13)
• Touch, Drag, Gesture Controls: Complex interactions like swiping, dragging, or motion-based triggers that do not offer alternatives. (WCAG 2.2 - 2.5.1, 2.5.2, 2.5.4, 2.5.7, 2.5.8)
• Help, Consistency, and Error Handling: Inconsistencies in navigation, missing help features, or lack of error prevention on critical forms. (WCAG 2.2 - 3.2.3, 3.2.4, 3.2.5, 3.2.6, 3.3.3, 3.3.4, 3.3.7, 3.3.8, 3.3.9)

Accessibility Tree

To access the Accessibility Tree, open your browser’s Developer Tools (usually by right-clicking on the page and selecting Inspect, or pressing F12 or Ctrl+Shift+I), then navigate to the Accessibility panel, which is typically found under the Elements tab in Chrome or Firefox. If it is not immediately visible, look for it under the triple-dot menu in the developer tools panel. Once inside the Accessibility panel, you will see a hierarchical view of the page's semantic structure as interpreted by screen readers and other assistive technologies.

When manually exploring the Accessibility Tree, approach it with an understanding of how screen readers navigate web content. The tree displays headings, landmarks, roles, and name-value pairs in the order they are presented to assistive technology users. Start by identifying the structural regions, such as main, nav, banner, and complementary landmarks, and ensure they are appropriately labeled and nested. Examine interactive elements like buttons, links, and form fields to confirm they include descriptive roles and accessible names. Pay attention to the reading order to verify it matches the intended visual flow. Manual inspection helps detect nuanced issues that automated tools may overlook, such as misapplied ARIA attributes or missing labels that impair usability for screen reader users, and even typos or grammar issues in image alt-text.

Citations

1. WebAIM. WAVE web accessibility evaluation tool. Utah State University. https://wave.webaim.org/
2. Google. Lighthouse. https://developer.chrome.com/docs/lighthouse/overview/
3. Tipainis, J. (2025, January 24). Website accessibility checkers: Use cases, pros and cons. TestDevLab. https://www.testdevlab.com/blog/website-accessibility-checkers-use-cases

Engage

In this lesson, you are going to explore how automated and manual accessibility testing on the web can complement each other. You will use one automated checker (WAVE or Lighthouse) and the browser's Accessibility Tree to evaluate a website and reflect on what kinds of accessibility issues are (and are not) caught by automated tools.

Directions

Do the following for this exercise:

• Pick a website: You may use a website you have built or choose any publicly available website. Try to select a page with at least a few links, headings, images, and some text or forms.
• Run WAVE or Lighthouse: Open the tool and scan the page. Review the errors, contrast issues, structure alerts, and ARIA information. Try to understand why the issues are flagged. Click on a few issues and read explanations. Think critically about how you might fix them.
• Open the Accessibility Tree: In your browser’s Developer Tools, find the Accessibility tab and examine the tree. Look for:
  • Headings (are they structured and labeled correctly?)
  • Buttons and links (do they have accessible names and roles?)
  • Images (do they have alt text? is it actually descriptive?)
  • Any important elements that are missing or not represented in the tree
  • Pay attention to how the tree represents the structure and semantics of the page, not just the visual layout.
• Compare Findings: Make note of anything the checker caught that is also visible in the tree, and anything that was not caught. Ask yourself:
  • What did the automated tool catch?
  • What did only the manual inspection reveal?
  • What might a screen reader user encounter that neither tool made obvious?

Next Tutorial

In the next tutorial, we will discuss Luminance and Color Contrast, which describes how to calculate luminance and color contrast in order to adhere to color rules in WCAG.