Testing and Evaluation

No single testing method catches all accessibility issues. A thorough evaluation combines automated scanning (fast, catches ~30–40% of issues), manual keyboard testing, screen reader testing, and user testing with people with disabilities. This page provides practical procedures for each method.

Automated testing tools

Developer

Browser extensions (daily use)

These tools run directly on any web page and provide instant results:

Tool	Browser	Best for
axe DevTools (Deque)	Chrome, Firefox, Edge	Most accurate automated scanner; low false-positive rate
WAVE (WebAIM)	Chrome, Firefox	Visual overlay showing issues in context on the page
ARC Toolkit (TPGi)	Chrome	Detailed WCAG criterion mapping; good for audit documentation
Lighthouse	Chrome (DevTools)	Quick score and top-level audit; built into Chrome

Recommended daily workflow: Install axe DevTools and run it on every page before merging. Address all “violations” (confirmed issues) before treating “needs review” items (possible issues requiring human judgment).

Running axe in DevTools

Open Chrome DevTools (F12)
Navigate to the axe DevTools tab
Click Scan ALL of my page
Review violations — each links to the affected element and explains the fix
Use Highlight to see the element on the page
Use inspect element to jump to the DOM

CI/CD integration

For automated testing in your build pipeline:

// Jest + axe-core example
import { axe, toHaveNoViolations } from 'jest-axe';
expect.extend(toHaveNoViolations);

test('home page has no accessibility violations', async () => {
  const { container } = render(<HomePage />);
  const results = await axe(container);
  expect(results).toHaveNoViolations();
});

// Playwright + axe-core example
import { checkA11y } from 'axe-playwright';

test('home page accessibility', async ({ page }) => {
  await page.goto('http://localhost:3000');
  await checkA11y(page, null, {
    runOnly: { type: 'tag', values: ['wcag2aa', 'wcag21aa'] },
  });
});

Contrast checking

For colour contrast verification outside of axe:

Colour Contrast Analyser (TPGi) — free desktop app; eyedropper tool to sample any pixel on screen; essential for checking contrast in images, gradients, and non-text elements
WebAIM Contrast Checker — paste hex values; reports AA and AAA pass/fail
Chrome DevTools: in the Elements panel, click any colour in the Styles tab to see the contrast ratio against the computed background

Keyboard testing

Developer Designer

Keyboard testing requires no special tools — just set your mouse aside. This is the most direct way to verify that your site is operable without a mouse.

Setup

Use a desktop/laptop (not a touch device)
Set your mouse aside
Use a browser without accessibility extensions that might alter behaviour

The keyboard testing checklist

Work through every page using only:

Tab — move focus forward
Shift+Tab — move focus backward
Enter — activate links, buttons, submit forms
Space — activate buttons, checkboxes; scroll page
Arrow keys — navigate within components (menus, tabs, sliders, radios)
Escape — close modals, dismiss dropdowns

For each interactive element, verify:

The first Tab press reveals a “Skip to main content” link
Tab order follows the visual reading order (top to bottom, left to right)
Every interactive element is reachable by Tab — nothing is skipped
Every interactive element shows a visible focus indicator
Focus does not move to hidden elements (e.g., off-screen menu items)

Interaction

All links activate with Enter
All buttons activate with Enter or Space
All form controls accept input by keyboard
Checkboxes toggle with Space
Radio buttons navigate with arrow keys; Space selects
Select dropdowns open with Space/Enter; navigate with arrows

Components

Dropdown menus: open on Enter/Space, navigate with arrows, close with Escape
Modals: focus moves inside on open; Tab cycles within modal; Escape closes; focus returns to trigger on close
Accordions: toggle with Enter or Space; focus stays on the button
Tabs: arrow keys switch between tabs; Tab moves to tab panel
Date pickers: navigate calendar with arrows; Escape closes

No traps

You can Tab off every element — no elements trap focus permanently
No elements require mouse-only interaction (hover menus, drag-only controls)

Common keyboard failures

Symptom	Likely cause	Fix
Can’t see where focus is	`outline: none` with no replacement	Add `:focus-visible` styles
Focus jumps to unexpected location	Positive `tabindex` values	Use only `tabindex="0"` or `-1`
Focus disappears	Element is hidden with `display:none` but not truly removed	Synchronize `hidden` attribute with display
Modal doesn’t trap focus	No focus trap implemented	Add focus trap with keydown listener
Menu doesn’t open on Enter	Click-only handler	Add `keydown` with Enter/Space handler
Can Tab in but not out	Missing Escape handler	Add Escape key to close/collapse

Developer

Screen readers interpret the accessibility tree and speak or braille the content to users who are blind, have low vision, or have reading disabilities. They are the most comprehensive manual test because they reveal how your page is actually experienced without vision.

NVDA + Chrome (Windows, free)

Download: nvaccess.org — free, open source.

Basic NVDA commands

Task	Key
Start/stop NVDA	Ctrl+Alt+N (toggle)
Read from cursor	NVDA+Down (Insert+Down)
Stop reading	Ctrl
Next heading	H
Previous heading	Shift+H
List all headings	NVDA+F7 (Elements list)
Next landmark	D
Next link	K
List all links	NVDA+F7, then select Links
Next form field	F
Next button	B
Next table	T
Read table cell	Ctrl+Alt+Arrow
Next list	L

NVDA testing procedure

Open Chrome, navigate to the page under test
Start NVDA (Ctrl+Alt+N or from taskbar)
Press H to navigate through headings — verify the heading hierarchy makes sense out of context
Press NVDA+F7 → Links — verify all link text is descriptive
Press D to navigate through landmarks — verify all major regions are present and labelled
Press Tab to navigate through interactive elements — verify every element is announced with a meaningful name, role, and state
Navigate to each form — verify every field is announced with its label and any instructions
Activate a modal dialog — verify focus moves in, Escape closes it, and focus returns to trigger
For dynamic content (search results, errors, status messages) — verify the update is announced without moving focus

VoiceOver + Safari (macOS, built-in)

Enable: System Settings → Accessibility → VoiceOver → Enable.

Basic VoiceOver commands

Task	Key
Toggle VoiceOver	Cmd+F5
Read next item	VO+Right (Control+Option+Right)
Read previous item	VO+Left
Activate item	VO+Space
Open rotor	VO+U
Navigate headings in rotor	Left/Right to select “Headings”, Up/Down to navigate
Navigate landmarks	Left/Right to select “Landmarks”
Navigate links	Left/Right to select “Links”
Navigate form controls	Left/Right to select “Form Controls”
Move into web content	VO+Shift+Down

The VoiceOver Rotor (VO+U) is essential — it provides a list of all headings, links, landmarks, and form controls, allowing you to quickly audit a page.

VoiceOver testing procedure

Open Safari, navigate to the page
Enable VoiceOver (Cmd+F5)
Press VO+U to open the Rotor
Check Headings — is the hierarchy logical?
Check Links — are all link names descriptive?
Check Landmarks — are all page regions present?
Check Form Controls — do labels match what is visually displayed?
Tab through interactive elements verifying names, roles, and states
Test dynamic content for appropriate live region announcements

What to listen for

Every interactive element should announce:

Name: what it is called (“Submit button”, “Email address field”)
Role: what it is (“button”, “text input”, “checkbox”)
State (where applicable): “expanded/collapsed”, “checked/unchecked”, “required”, “invalid”

Common screen reader failures:

What you hear	Problem	Fix
”button” (no name)	Button has no accessible name	Add `aria-label` or visible text content
File name or URL	Image missing alt text	Add `alt` attribute
”image”	Image has empty alt but should be informative	Write descriptive alt text
Long URL as link text	Link text is the URL, not description	Replace with descriptive text
Form field announced without label	`<label>` not associated with input	Add `for`/`id` association
Nothing announced after submit	Error not in live region, focus not moved	Add `role="alert"` or move focus
”group” with no name	`<fieldset>` missing `<legend>`	Add `<legend>`

iOS VoiceOver (touch gestures)

For mobile testing:

Task	Gesture
Read next item	Swipe right
Read previous item	Swipe left
Activate selected item	Double tap
Scroll	Three-finger swipe
Open rotor	Two-finger rotate
Navigate by heading	Rotor → Headings, then swipe up/down

TalkBack (Android)

Enable: Settings → Accessibility → TalkBack.

Task	Gesture
Read next item	Swipe right
Activate	Double tap
Scroll	Two-finger swipe
Navigate by heading	Local context menu (swipe up then right) → Headings

Colour and visual testing

Contrast verification

For a methodical contrast audit:

Use the Colour Contrast Analyser (TPGi): eyedropper to sample foreground and background colours in any application
Check every text colour / background colour combination in your design system
Check all interactive component states: default, hover, focus, active, disabled
Check dark mode separately — contrast ratios differ from light mode

Greyscale test

Verify that colour is not the only means of conveying information (WCAG 1.4.1):

macOS: System Settings → Accessibility → Display → Colour Filters → Greyscale
Windows: Settings → Ease of Access → Colour filters → Greyscale
In Chrome DevTools: Rendering → Emulate vision deficiency → Achromatopsia

View the page in greyscale and verify:

All form states (error, success, required) are distinguishable
Chart series are distinguishable
Linked text is distinguishable from non-linked text (underline or other non-colour indicator)

Low vision simulation

Chrome DevTools → Rendering → Emulate vision deficiency:

Blurred vision: tests readability with reduced acuity
Protanopia / Deuteranopia / Tritanopia: tests colour blindness accessibility
Achromatopsia: full greyscale

Text spacing test

Apply the WCAG 1.4.12 text spacing bookmarklet to verify layouts do not break when users override:

Line height to 1.5× font size
Letter spacing to 0.12× font size
Word spacing to 0.16× font size
Paragraph spacing to 2× font size

Bookmarklet available on the W3C Understanding 1.4.12 page.

Zoom and resize testing

Set browser zoom to 200% — all content and functionality must remain usable
Set browser zoom to 400% — content must reflow to a single column without horizontal scrolling (WCAG 1.4.10)
Set browser default font size to 24px (browser settings) — all text should scale; no overflow or clipping

In Chrome: Settings → Appearance → Font size → Very Large (20px) or Huge (24px).

Reduced motion testing

Verify that animations respect prefers-reduced-motion:

macOS: System Settings → Accessibility → Display → Reduce Motion
Windows: Settings → Ease of Access → Display → Show animations (turn off)
Chrome DevTools: Rendering → Emulate CSS media feature → prefers-reduced-motion: reduce

With reduced motion enabled, verify:

CSS transitions are suppressed or simplified
Carousels do not auto-advance
Parallax effects are disabled
Page transitions are instant or simple fades

Conducting an accessibility audit

Everyone

A structured accessibility audit produces a report suitable for compliance documentation, remediation planning, and tracking progress over time.

Audit scope

Define what is in scope:

Which pages or templates (audit representative pages, not every page — if the homepage template has an issue, all homepage-template pages likely have it)
Which user flows (registration, checkout, contact form, search)
Which WCAG version and level (typically WCAG 2.1 AA for Canadian compliance)

Audit methodology

Automated scan: run axe on all pages in scope; document violations
Keyboard walkthrough: complete each user flow by keyboard alone; document failures
Screen reader walkthrough: navigate representative pages with NVDA+Chrome; document issues
Manual checks: colour contrast (visual states), reading order, heading hierarchy, landmark structure, form labelling
Responsive check: 320px viewport, 200% zoom, 400% zoom

Issue severity classification

Severity	Definition	Example
Critical	Blocks a user from completing a task	Modal with no close mechanism
Serious	Significantly impedes task completion	Form errors not associated with fields
Moderate	Creates friction but user can work around it	Missing heading level
Minor	Best practice not followed	Redundant alt text

Conformance statement

After remediation, publish an accessibility conformance statement on your website. At minimum, include:

Which WCAG version and level you target
Known limitations (issues you are aware of but have not yet fixed)
Contact information for reporting accessibility issues
Date of last assessment

Many organizations use the VPAT (Voluntary Product Accessibility Template) or its Canadian equivalent to document conformance in detail for procurement contexts. See Procurement for guidance on accessible procurement.

Testing schedule

Accessibility is not a one-time audit — it degrades as content and features are added. Build testing into your ongoing workflow:

When	What to test
During development	axe DevTools on new components; keyboard test new interactions
Before each release	Full keyboard walkthrough of changed flows; axe scan of new pages
Quarterly	Screen reader walkthrough of top user flows
Annually	Full audit by internal or external accessibility specialist
After major redesign	Full audit before launch

Development Practices — implementing the techniques that these tests verify
Design Principles — contrast, focus states, and motion to test
Vision Disabilities — understanding screen reader user experience
Mobility and Dexterity Disabilities — keyboard navigation requirements