Chrome Accessibility DevTools: How to Test a Website

Chrome DevTools helps you find many accessibility issues, inspect how a page is exposed to assistive technology, and see how it responds to user preferences. Use Lighthouse and the Accessibility and Rendering tools as part of a broader check: automated findings do not establish that a site is accessible. You still need to navigate important flows with a keyboard and try them with a screen reader.

This guide walks through both questions Chrome highlights: can someone navigate the page with a keyboard or screen reader, and are page elements properly marked up for assistive technology? Tool labels and layouts can change between Chrome versions, so use the equivalent controls in your installed version if a label differs.

1. Run a Lighthouse accessibility audit

Open the exact page and state you want to check. For a workflow, navigate to the relevant state first—for example, an expanded menu, a validation error, or a dialog.
Open Chrome DevTools, then open the Lighthouse panel. In versions where the layout differs, use DevTools’ panel menu to find Lighthouse.
Select the Accessibility category and run the report. If the mobile layout differs from desktop, audit that layout too.
Review each finding in context. Open an individual audit for its explanation, locate the affected element, and decide whether it represents a real issue for this page and interaction.
Fix the underlying markup or behavior, then rerun the audit.

A Lighthouse report is a useful starting point, not a complete evaluation. It can flag certain markup and contrast problems, but it cannot establish that every control is operable, understandable, or usable with assistive technology. A report with no findings is not proof that no accessibility problems remain.

2. Inspect the accessibility tree and computed properties

In Elements, select an important element, such as a button, link, form field, image, or dialog.
Open the Accessibility pane for the selected node.
Inspect its place in the accessibility tree, ARIA attributes, and computed accessibility properties. Check the accessible name, role, and state where relevant.
Compare the selected node with its DOM counterpart. If the tree does not expose the name or state you expect, inspect the element’s native semantics, associated label, ARIA, and visibility.

The accessibility tree is the browser’s representation of nodes exposed to assistive technology. It helps explain what a screen reader can encounter, but inspecting it does not replace listening to the page with a screen reader. Prefer native HTML semantics when they express the intended control; add ARIA only where needed to communicate a name, role, or state that native markup does not provide.

Check source order when layout is visually rearranged

If CSS makes the visual order differ from the document order, inspect the sequence with Chrome’s Source Order Viewer. Its numbered elements help you compare source order with the rendered page. Then use the keyboard to verify that focus order still supports the task. A visually attractive arrangement can still be confusing if reading and tab order jump around unexpectedly.

3. Check contrast, color, and user preferences

Use Lighthouse findings and DevTools’ contrast issue reporting or color picker to investigate text and interface contrast. Check actual states too: hover, focus, disabled, error, selected, and any theme variants. Do not infer that a design passes from one sampled color pair if other states use different colors.

In Rendering, use the available emulation controls to review how the page responds to simulated vision deficiencies, forced colors, contrast preferences, dark or light color schemes, reduced motion, and reduced transparency. These modes can reveal fragile choices, such as relying on color alone or hiding an essential cue in animation. They are inspection aids, not substitutes for user testing.

Chrome’s contrast guidance cites WebAIM’s finding that 83.9% of the top million home pages had low-contrast text in February 2022. That is a dated finding, not a current estimate; use it as historical context, not as a measurement of your own site.

4. Check reflow and enlarged content

Use the Device Toolbar to inspect the page at narrow viewport widths and at the breakpoints where the layout changes.
Check that text, controls, and essential content remain available without clipping or unwanted horizontal scrolling for ordinary page content.
Enlarge text or use the browser’s zoom and verify that users can still reach content and operate controls.
Repeat the check on important pages and states, including navigation, forms, dialogs, and error messages.

Resizing is a useful way to find reflow problems, but it is not by itself a conformance verdict. Check that information and functionality remain available, rather than judging only whether the page looks tidy.

5. Test keyboard operation and visible focus

Automated tools cannot answer whether a person can complete the page’s tasks with a keyboard. Tab through the page and exercise its interactive controls using the keys the interface expects, such as Enter, Space, arrow keys, and Escape.

Confirm every control needed for the task can receive focus.
Check that focus is visible and moves in an order that follows the content and task.
Open and close menus, dialogs, and other overlays. Check that focus moves into them appropriately, stays usable while they are open, and returns sensibly when they close.
Complete important form flows, including invalid submissions. Confirm users can reach errors and understand which fields need correction.
Check that custom controls respond to expected keyboard input and do not trap focus.

Chrome’s accessibility reference makes the key distinction directly: “The only way to find errors related to question #1 is to try using a page with a keyboard or screen reader yourself.” That is why a Lighthouse score cannot stand in for interaction testing.

Choose a screen reader available on the operating system and browser your users support. Exact announcements differ by screen reader, browser, settings, and version, so focus on whether the information and operation are clear.

Navigate through the page and important flows using screen-reader navigation as well as ordinary keyboard movement.
For each key control, check that the announced name, role, and state match what the control does and what is visible.
Check headings, landmarks, form labels, instructions, link purpose, image alternatives, and status or error messages.
Exercise state changes: expand and collapse controls, validation messages, dialogs, and dynamic updates. Confirm the change is discoverable and users can continue.
Record the specific step and announcement that caused confusion, fix it, and repeat the workflow.

Testing only a static initial page can miss problems introduced by interaction. Include the states users actually need to complete their tasks.

7. Use an optional automated scanner carefully

Deque’s axe DevTools browser extension is an optional scanner. Its free extension provides basic page-by-page automation; paid plans add features such as guided tests or broader workflow integrations. Treat scanner results as leads to review in context. Automated scans do not replace keyboard and screen-reader checks.

8. A practical issue log

For each finding, record enough detail to reproduce and verify it:

Page, viewport, browser version, and relevant interaction state.
The user task and steps that exposed the problem.
The affected element and its DOM and accessibility-tree properties.
What happened, what you expected, and any screen-reader announcement.
The fix and the automated and manual checks repeated afterward.

This keeps a scan finding connected to the user impact and makes regression checks repeatable.

Or skip the browser setup

For a clean screenshot of the page you are reviewing, ScreenshotNeo provides a website screenshot API and MCP server. A screenshot can help document a visual state alongside an accessibility issue, but it does not test keyboard or screen-reader usability and cannot establish accessibility.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

Node.js:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

See the ScreenshotNeo API documentation for request options. ScreenshotNeo accepts consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing status. Its MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs.

The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots. Every feature is on every plan. Visit ScreenshotNeo for product details, or sign up free for 1,000 screenshots a month with no card.

Common problems and fixes

Symptom	Likely cause	What to do
Lighthouse shows no accessibility findings, but users report problems.	The issue needs keyboard or screen-reader interaction, or the tested state did not expose it.	Reproduce the user flow and test it manually. Audit each relevant state and viewport.
The Accessibility pane does not show the expected name or role.	The element lacks a suitable native semantic, label, or state, or is hidden from the accessibility tree.	Compare the DOM and tree. Correct the HTML and associated labels first, then add or adjust ARIA only as needed.
Focus seems to disappear or jumps unexpectedly.	Focus styling is missing, DOM order conflicts with visual order, or a custom interaction mishandles focus.	Tab through the task, inspect source order, restore visible focus, and correct focus management for the interaction.
A contrast warning seems inconsistent with the design.	The warning may concern another state, an overlapping background, or a different rendered color.	Inspect the specific element and state with the contrast tools and color picker, then check every relevant theme and interaction state.
The emulated preference does not change the page.	The site may not implement that preference, or the preference affects a different state than the one being viewed.	Confirm the site supports the preference and inspect the relevant content or interaction while emulation is active.
A narrow viewport looks fine, but enlarged text clips.	Fixed heights, hidden overflow, or inflexible layouts may prevent reflow.	Test zoom or enlarged text as well as viewport width; allow content to wrap and containers to grow.
Screen-reader output is verbose or unclear.	Repeated labels, inappropriate ARIA, missing names, or unclear control purpose may be contributing.	Inspect the tree and DOM, simplify redundant announcements, and verify name, role, and state during the real flow.

Performance and repeatability

Run audits on representative pages and states instead of treating one homepage scan as site coverage.
Check desktop and mobile layouts where they differ, and repeat after meaningful markup, style, or interaction changes.
Keep manual checks focused on important tasks. A short, reproducible flow is easier to repeat after a fix than an informal browse.
Record Chrome and assistive-technology versions when reporting issues, since browser tools and announcements can vary by version.
Use automation to find candidates efficiently, then spend review time confirming user impact and checking the paths automation cannot exercise reliably.

Chrome DevTools and Lighthouse are built into Chrome, so this workflow does not require a paid scanner or physical testing device. The main cost is the time needed to review findings and perform manual checks. An optional axe extension can add another automated workflow, but its scan still needs human interpretation.

FAQ

Does a perfect Lighthouse accessibility score mean my site is accessible?

No. It means the audit did not report those automated findings for the tested page and state. Keyboard operation and screen-reader interaction still need manual checks.

Can I test accessibility in Chrome without an extension?

Yes. Chrome DevTools includes Lighthouse and inspection and emulation tools for the workflows described here. An extension such as axe DevTools is optional.

No. It shows the browser’s accessibility representation. Actual announcements depend on the screen reader, browser, and user settings, so test the supported combinations directly.

Should I use ARIA to fix every warning?

No. First check whether native HTML semantics and labels solve the problem. ARIA can communicate missing names, roles, or states when needed, but incorrect or redundant ARIA can make information less clear.

How often should I repeat the checks?

Repeat relevant automated and manual checks after changes to markup, styles, or interaction behavior, and include the important page states in routine review.