Testing & Evaluation:
How to Audit for Accessibility

Start With a Strategy

Too many organizations rely entirely on automated accessibility testing tools. While these tools are valuable, they catch only about 30-40% of real WCAG violations. The gap exists because machines cannot understand context, user intent, or subjective issues like whether heading hierarchy makes sense or whether alt text is accurate.

The gold standard is a three-layer testing approach:

• Layer 1: Automated Testing: Quick, scalable, catches obvious issues like missing alt text or insufficient color contrast
• Layer 2: Manual Testing: Humans check keyboard navigation, focus visibility, semantic structure, and user flows
• Layer 3: Assistive Technology Testing: Real testing with screen readers, voice control, and other assistive tech to catch issues automated and manual tests miss

When you combine all three layers, you catch roughly 80-90% of accessibility issues. This is why organizations serious about WCAG AA compliance budget for testers who specialize in accessibility testing, not just QA generalists running browser plugins.

Automated Testing Tools

Automated tools are the starting point. They run fast, integrate into CI/CD pipelines, and give you a baseline of issues to fix. But treat them as a first pass, not the final word on accessibility.

What automated tools catch: missing alt text, insufficient colour contrast, missing form labels, broken ARIA attributes, keyboard trapping, heading structure errors, and missing language declarations.

What they miss: whether alt text is accurate (an image of a dog marked "image" passes automated tests but fails in practice), focus visibility after CSS changes, reading order problems, and whether custom widgets work with screen readers in real-world scenarios.

Manual Testing Techniques

Manual testing is where most real accessibility issues are found. Here are the core techniques:

Keyboard-Only Navigation

Unplug your mouse (or just hide it). Navigate the entire page using only the Tab, Shift+Tab, Enter, and arrow keys. Check:

• Can you reach every interactive element (buttons, links, form fields)?
• Is the focus indicator visible (a border, outline, or highlight around the focused element)?
• Does focus move in a logical, predictable order?
• Can you escape from dropdown menus and modals using the Escape key?
• Are there keyboard shortcuts documented?

Zoom to 200%

In your browser, set zoom to 200% (Ctrl+Plus / Cmd+Plus). Check:

• Can you still read and interact with the content?
• Does the layout reflow without horizontal scrolling?
• Are buttons and form fields still click/tap-able?

This reveals whether your design is responsive and whether developers hardcoded fixed sizes that break at larger zoom levels.

Colour Contrast Verification

Use WebAIM's Contrast Checker or similar tool. For normal text, WCAG AA requires 4.5:1 contrast ratio. For large text (18pt+ or 14pt bold+), the ratio is 3:1. Check not just text but also:

• Icons and graphics (if they convey information, they need 3:1 contrast)
• Focus indicators (the outline or border showing which element is focused)
• Form field borders and validation states

Reading Order and Heading Structure

Open your browser's Inspector and disable CSS (Developer Tools > Inspector > View > Style Editor, or use WAVE's outline feature). Does the content make sense when CSS is removed? Are headings semantically correct (H1, then H2/H3, not skipping levels)? Is there a single H1 per page?

Form Field Labels and Errors

Every form field must have an associated label. Use the Inspector to check that input elements have matching label elements with correct `for` attributes. When form validation errors appear, are they announced to screen reader users? Is the error linked to the field?

Grayscale Testing

Grayscale testing reveals whether your design relies on colour alone to communicate information. On Windows, go to Settings > Accessibility > Display and toggle Grayscale. On Mac, go to System Preferences > Accessibility > Display > Color Filters.

In grayscale mode, check:

• Are status indicators (error, warning, success) distinguishable without relying on red/green alone?
• Are links still clearly links (are they underlined or styled differently from regular text)?
• Is required/optional status on form fields visible without color cues?

This catches a common accessibility mistake: using color as the only way to indicate state. If your error message is red but has no other distinguishing feature, a colourblind user might miss it entirely.

Screen Reader Testing

Screen reader testing is the most important manual test. It's also the most intimidating for people unfamiliar with screen readers. The good news: you don't need to be a screen reader expert to catch major issues.

Getting Started with Screen Readers

Windows: NVDA (free) is the standard. Download from nvaccess.org. Ctrl+Home to start, Ctrl+End to stop reading, H to jump to next heading, K to jump to next link, F to jump to next form field. Insert+F7 lists all links on the page.

Mac: VoiceOver is built in. Command+F5 to toggle it on. Control+Option+Right Arrow to move forward, Control+Option+Left Arrow backward. Control+Option+U opens the Rotor (shows headings, links, form fields, etc.). It takes practice, but it's powerful.

What to test:

• Page title: When the page loads, do you hear the page title? It should be unique and descriptive.
• Heading navigation: Press H (NVDA) or VO+H (VoiceOver). Can you navigate the page by headings? Does the hierarchy make sense?
• Link purpose: Do link texts make sense out of context? "Click here" is bad; "Contact form" is good.
• Form inputs: When you Tab to a form field, does the screen reader announce the label? Does it announce whether the field is required?
• Lists: Do lists (ul, ol) announce their structure? "List with 5 items" tells you there are 5 items; a pile of divs with list-like styling won't.
• Dynamic content: If content updates (autocomplete suggestions, filtered results), do screen reader users get notified?

Quick Wins Under an Hour

If you're starting an accessibility program and feeling overwhelmed, here are five quick wins you can implement immediately:

1. Add Alt Text to Images

Alt text is the single most impactful accessibility improvement. For every image on your page, ask: "If this image disappeared, what would users miss?" Write alt text that answers that question. Decorative images get empty alt: alt="". Meaningful images get descriptive text: alt="Product screenshot showing the dashboard with three charts." Tools like WAVE highlight missing alt text instantly.

2. Fix Colour Contrast

Use WebAIM's Contrast Checker. Target the most critical text first: body copy, labels, focus indicators. Change text color to a darker shade or lighten the background. A quick CSS tweak can fix 90% of contrast issues. Focus indicators (the outline showing which element is selected) are often overlooked; make sure they're visible.

3. Label All Form Fields

Every input, textarea, and select needs an associated label element. In HTML, use `<label for="field-id">` paired with `<input id="field-id">`. This is a 2-minute fix per form and has huge impact on screen reader accessibility.

4. Make Links Descriptive

Don't use "Click here" or "Read more". Screen reader users often navigate by links only, so "Click here" is meaningless out of context. Change it to "Read more about WCAG 2.1 compliance" or "Contact our accessibility team". This is a content win that improves UX for everyone.

5. Verify Keyboard Navigation

Tab through your entire page. Make sure you can reach every interactive element. Make sure focus is always visible. Make sure you can submit forms and close dialogs. This is free and catches a ton of issues. If an interactive element isn't keyboard-accessible, it fails WCAG instantly.

Building a Mitigation Plan

Once you've found accessibility issues, you need a plan to fix them. A mitigation (or remediation) plan documents the issues, prioritizes them, and commits to fix dates.

Step 1: Prioritize by WCAG Level

WCAG has three levels: A (minimum), AA (standard), and AAA (advanced). Fix Level A issues first (they're the most critical). If a feature is completely unusable for people with disabilities, it's Level A. Level AA issues cause significant difficulty but task completion is possible with workarounds. Level AAA is nice-to-have.

Step 2: Categorize by Effort and Impact

Create a simple spreadsheet:

• Issue ID: ACC-001, ACC-002, etc.
• Description: "Form error messages not announced to screen readers"
• WCAG Criterion: 4.1.3 Status Messages
• Severity: High / Moderate / Low (based on user impact)
• Effort to Fix: 1 hour / 1 day / 1 week
• Target Date: Specific date (e.g., 2026-04-30)
• Status: Open / In Progress / Fixed
• Interim Workaround: If applicable (e.g., "Users can call support line for assistance")

Step 3: Set Realistic Timelines

For a VPAT or remediation plan submitted to a procuring agency or legal team:

• Critical issues (blocks core functionality): 30 days maximum
• High issues (causes major difficulty): 60 days
• Moderate issues (causes friction): 120 days
• Low issues (minor annoyance): 1 year or next major release

These timelines show you're serious and realistic. Agencies respect a vendor who commits to 120 days and delivers on time more than one who promises 30 days and misses.

Step 4: Document Sufficient Fixes vs Exceptions

In your VPAT, for each non-conforming criterion, you must state:

• Sufficient fix: "We will implement ARIA live regions to announce form error messages by [date]."
• Documented exception: "Legacy payment gateway is third-party software; we're working with vendor to remediate. Interim workaround: phone orders available."

Procuring agencies understand that complex systems can't be fixed overnight. What they want is transparency and commitment.