Aller au contenu

Testing accessibility

Accessibility testing is the final step before publishing. Automated tools catch many issues, but they miss about half of all accessibility problems. The combination of automated scanning, keyboard testing, and screen reader testing gives you the most coverage.

Two guiding principles:

  1. Test early and often. Don't wait until the site is "done." Check each page as you build it -- issues are easier to fix before the layout is complex.
  2. Automated tools find code problems. Manual testing finds experience problems. A tool can flag a missing alt text, but only a human can judge whether the alt text actually describes the image well.

Quick checklist before publishing

Run through this list for every page before you publish:

  • [ ] Every image has appropriate alt text (descriptive or empty for decorative)
  • [ ] Color contrast meets WCAG AA (4.5:1 for text, 3:1 for large text and UI)
  • [ ] Heading hierarchy is logical (h1 > h2 > h3, no skipped levels)
  • [ ] Every form field has a visible <label>
  • [ ] The page is fully usable with keyboard only (Tab, Enter, Escape)
  • [ ] Focus indicators are visible on every interactive element
  • [ ] The page language is set in Site settings
  • [ ] Links have descriptive text (no "click here")
  • [ ] No content flashes more than 3 times per second
  • [ ] Multiple <nav> landmarks are labeled with aria-label

Keyboard testing

The simplest and most effective manual test. No tools required.

  1. Open your published page in a browser
  2. Press Tab to move through the page
  3. Check:
  4. Can you reach every link, button, and form field?
  5. Is the focus indicator visible at every step?
  6. Does the focus order match the visual reading order?
  7. Can you activate buttons with Enter or Space?
  8. Can you dismiss overlays or menus with Escape?
  9. Are there any keyboard traps (focus gets stuck and you cannot Tab out)?

If you find issues, see Keyboard navigation and focus for fixes.

Browser extensions

These extensions scan the page and report accessibility issues directly in your browser.

axe DevTools

axe DevTools (by Deque) is the most widely used accessibility testing extension.

  1. Install the axe DevTools extension for Chrome, Firefox, or Edge
  2. Open your published page
  3. Open browser DevTools (F12)
  4. Go to the axe DevTools tab
  5. Click Scan All of My Page
  6. Review the results -- each issue includes:
  7. The affected element (highlighted on the page)
  8. The WCAG criterion it violates
  9. A description of the problem
  10. How to fix it

WAVE

WAVE (by WebAIM) provides a visual overlay showing accessibility issues, alerts, and structural elements.

  1. Install the WAVE extension for Chrome or Firefox
  2. Open your published page
  3. Click the WAVE icon in the toolbar
  4. Icons appear on the page marking errors (red), alerts (yellow), and structural features (green/blue)
  5. Click any icon for details

WAVE is especially useful for visualizing heading structure, landmark regions, and missing alt text.

Lighthouse

Lighthouse is built into Chrome DevTools.

  1. Open your published page in Chrome
  2. Open DevTools (F12)
  3. Go to the Lighthouse tab
  4. Select Accessibility (uncheck other categories to speed up the scan)
  5. Click Analyze page load
  6. Review the accessibility score and individual issues

Lighthouse gives a score from 0 to 100. Aim for 90+, but remember that a perfect score does not mean the site is fully accessible -- Lighthouse only catches automated issues.

Screen reader testing

Screen reader testing reveals what the experience actually feels like for assistive technology users. Even a short test catches problems that no automated tool can find.

Available screen readers

Screen reader Platform Cost
NVDA Windows Free and open source
VoiceOver macOS, iOS Built into the OS
TalkBack Android Built into the OS
Narrator Windows Built into the OS
JAWS Windows Paid (free demo)

Recommendation for first-time testers: Use NVDA on Windows (free) or VoiceOver on macOS (already installed, activate with Cmd+F5).

Basic screen reader test

  1. Turn on the screen reader
  2. Navigate to your published page
  3. Listen as the screen reader reads the page from top to bottom
  4. Check:
  5. Are images announced with useful descriptions?
  6. Are headings announced with their level (h1, h2, h3)?
  7. Are form fields announced with their labels?
  8. Can you understand the page structure from audio alone?
  9. Are landmarks announced ("navigation," "main," "footer")?
  10. Try navigating by headings (H key in NVDA/VoiceOver), by landmarks (D key in NVDA), and by links (K key in NVDA)

Automated vs. manual testing

What automated tools catch What only manual testing catches
Missing alt text Whether alt text is actually descriptive
Contrast ratio failures Whether color alone conveys meaning
Missing form labels Whether labels are clear and helpful
Missing page language Whether content in other languages is marked
Heading level skips Whether heading text matches the content structure
Missing landmark roles Whether landmarks are meaningfully labeled
ARIA syntax errors Whether ARIA is used appropriately

Use both. Run an automated scan first to catch the obvious issues, then do keyboard and screen reader testing to catch the rest.

Practical example: auditing a page with Lighthouse and keyboard

You have built a portfolio page and want to check its accessibility before publishing.

  1. Publish the page to get a live URL (or use the browser preview)

  2. Run Lighthouse:

  3. Open the page in Chrome
  4. DevTools > Lighthouse > Accessibility > Analyze

  5. Result: score 78. Issues found:

    • 2 images missing alt text
    • 1 form input missing a label
    • 1 contrast failure (light gray on white)

  6. Fix the automated issues:

  7. Add alt text to the images (or set empty alt for decorative ones)
  8. Add a <label> to the form input with a matching for attribute

  9. Darken the text color to meet 4.5:1 contrast ratio

  10. Run Lighthouse again: Score 95.

  11. Keyboard test:

  12. Tab through the page. Discover that a portfolio card is a styled Div acting as a link -- it is not reachable by keyboard.

  13. Fix: wrap the card content in an <a> element or change the Div's tag to <a> and set the href.

  14. Screen reader test (optional but recommended):

  15. Turn on VoiceOver (Cmd+F5 on macOS)
  16. Navigate through the page. Discover that two <nav> elements both announce as "navigation" with no distinction.
  17. Fix: add aria-label to each nav via the Attributes section.

Common mistakes

  • Only running automated tools. They catch about 30-50% of accessibility issues. Keyboard testing and screen reader testing are essential.
  • Testing only on desktop. Mobile screen readers (VoiceOver on iOS, TalkBack on Android) behave differently. If your audience is mobile, test there too.
  • Treating 100 Lighthouse score as "accessible." It means no automated issues were found. Many accessibility problems require human judgment.
  • Testing only once at the end. Test as you build. A contrast issue caught on page 1 might repeat across every page.
  • Skipping keyboard testing. It takes 2 minutes per page and catches critical issues (focus traps, unreachable elements, missing skip links).

Learn more

Quiz

Q1: You run Lighthouse and get a 100 accessibility score. Is your site fully accessible?

  • A) Yes, 100 means all issues are resolved
  • B) No, automated tools miss about half of accessibility problems
  • C) Yes, but only for screen reader users
Answer

B) No, automated tools miss about half of accessibility problems -- Lighthouse checks code patterns (missing alt, bad contrast ratios) but cannot judge whether alt text is descriptive, whether focus order makes sense, or whether the page is understandable when read aloud.

Q2: You are keyboard-testing a page. You press Tab and focus moves to an element, but you cannot see where the focus is. What is the likely cause?

  • A) The browser has a bug
  • B) Focus outlines have been removed with CSS (outline: none)
  • C) The element is hidden
Answer

B) Focus outlines have been removed with CSS -- This is a common accessibility mistake. Restore or restyle the focus indicator. See Keyboard navigation and focus.

Q3: Which testing approach catches the most accessibility issues?

  • A) Automated tools only (axe, Lighthouse)
  • B) Manual testing only (keyboard, screen reader)
  • C) Both automated and manual testing combined
Answer

C) Both combined -- Automated tools are fast and catch code-level issues. Manual testing catches experience-level issues. Together they provide the best coverage.

Edit this page on GitLab