Run Lighthouse and axe DevTools, understand their limits, and triage the results.
Why this matters
You cannot check every heading, label and colour pair by eye on every release. Automated accessibility tools scan a page in seconds and catch the mechanical failures: missing alt text, unlabelled inputs, low contrast, duplicate ids, missing page language. They are the cheapest testing you will ever do. They also have a hard limit: they only catch a portion of WCAG issues (estimates usually range from about a third to a little over half, depending on how you count). A clean score does not mean a page is accessible. This lesson teaches you to run the tools, read their results and decide what to fix first.
The main free tools
| Tool | Where | Engine | Good at |
|---|---|---|---|
| Lighthouse | Chrome DevTools, Lighthouse panel | axe-core (a subset of rules) | A quick score in a report alongside performance and SEO |
| axe DevTools (free extension) | Chrome, Edge, Firefox | axe-core | Detailed issues with the element, the WCAG criterion and how to fix it |
| WAVE | Browser extension by WebAIM | Its own | Visual overlay of icons on the page: structure, labels, contrast |
| DevTools Accessibility pane | Chrome, Firefox, Safari | Browser | Each element's computed role, name and state; the accessibility tree |
| Contrast checkers | DevTools colour picker, WebAIM Contrast Checker | Math | Ratio between two colours |
The W3C keeps a list of evaluation tools if you need more.
Running Lighthouse
- Open the page in Chrome, then DevTools (F12 or Cmd+Option+I).
- Choose the Lighthouse panel, tick Accessibility (you can untick the others), pick Mobile or Desktop, and click Analyze page load.
- The report gives a score out of 100 and lists failed audits. Each one expands to show the failing elements.
The score is weighted by how many rules failed, not how badly users are affected. A page can score 100 and still be unusable by keyboard. Treat the score as a smoke alarm, not a certificate.
Running axe DevTools
- Install the free axe DevTools extension and open DevTools; it adds an axe DevTools tab.
- Click Scan all of my page.
- Each issue shows an impact (critical, serious, moderate, minor), the WCAG criterion, the element (click to highlight it), and a "more info" link explaining the fix.
- Rescan after each fix. Scan again with menus, dialogs and error states open: tools only see what is in the DOM at that moment.
Because axe-core is open source, the same rules run in CI. Teams often add @axe-core/playwright or jest-axe checks to their test suites so new violations fail the build.
Triage: deciding what to fix first
A first scan of a real site can list hundreds of issues. Do not work top to bottom. Sort them:
- Group duplicates. Fifty "link has no discernible name" errors are often one icon component. Fix the component once.
- Rank by user impact. Things that block a task (unlabelled checkout button, keyboard trap, missing form labels) beat things that annoy (redundant alt text).
- Weigh by where it is. An issue on the login, checkout or sign-up flow matters more than one on an old blog post.
- Mark false positives with a note. Tools sometimes flag contrast on text over images or gradients they cannot measure; check manually and record your decision.
- Record each fix as a ticket: criterion, page, element, problem, proposed fix, and how to verify.
What tools cannot tell you
Automated checks cannot judge:
- Whether alt text is accurate ("image123" passes; so does the wrong description).
- Whether the focus order makes sense or focus is visible.
- Whether a custom widget actually works with a keyboard and screen reader.
- Whether headings describe their sections, link text makes sense out of context, or error messages are helpful.
- Captions accuracy, reading level, and whether motion or time limits cause problems.
So every audit pairs tools with manual checks: the keyboard walk-through from Module 1, zoom to 200 and 400 percent, a screen reader pass (next lesson), and a look at the page with CSS turned off or in reader mode to check the order. The W3C's Easy Checks is a good manual starter list.
Worked example: triaging a scan
An axe scan of a shop's product page returns: 1 critical "Buttons must have discernible text" on the cart icon (in the header on every page), 12 serious "Elements must meet minimum color contrast" on grey review dates, 3 serious "Form elements must have labels" on the quantity and size fields, and 1 moderate "Heading levels should only increase by one".
Order of work: the quantity and size labels (they block buying), the cart icon name (global, blocks reaching the cart), then contrast (one CSS colour token fixes all twelve), then the heading level. Then a keyboard pass, which finds that the size picker cannot be reached by Tab at all: a bigger bug the tool never flagged.
Common mistakes
- Chasing a Lighthouse score of 100 as the goal.
- Scanning only the home page.
- Scanning only the default state (menus closed, no errors shown).
- Fixing symptoms page by page instead of in shared components.
- Skipping manual testing because "the tool passed".
Quick recap
- Lighthouse and axe both use axe-core; WAVE and the DevTools Accessibility pane add other views.
- Tools catch only a portion of issues; always add manual checks.
- Triage by duplicates, user impact and task importance; fix components once.
- Rescan every state, and consider automated checks in CI.
Try it
Open the Do tab and audit a real page with Lighthouse and axe, then triage the results.