The Contractor's Accessibility Toolkit: What to Run Before Every Deliverable

The Missing Operational Piece

This series has covered the legal deadline, the violations attorneys target, the audit defense log, the PDF blind spot, the demand letter response, and the accessibility statement. What it has not given you is the specific testing workflow — the tools to install, the order to run them, and the manual checks to perform before handing any deliverable to a municipal client.

That gap closes today.

No tool catches everything. Automated scanners detect 30 to 40 percent of WCAG failures. The rest requires human judgment — keyboard testing, screen reader verification, and contextual evaluation that no algorithm can perform. But the combination of the right automated tools plus targeted manual checks covers enough ground to catch the barriers that generate demand letters and eliminates the scan-detectable violations that plaintiff attorneys use to identify targets.

Twenty-five days until the deadline. Here is your toolkit.

Layer 1: Automated Scanning

Automated tools are your first pass. They identify the binary, structural failures — missing alt text, insufficient contrast, absent form labels, empty links, missing document language — that account for 96% of all detected errors across the web. Run at least two of these tools on every deliverable, because different tools use different rule sets and catch slightly different issues.

axe DevTools (Browser Extension)

What it is: A free browser extension built on the axe-core engine — the same engine that powers Google Lighthouse's accessibility audit, Microsoft's Accessibility Insights, and thousands of other testing programs. It is the most trusted automated accessibility testing library in the industry, with a commitment to zero false positives.

What it catches: The free version runs approximately 96 rules covering WCAG 2.0, 2.1, and 2.2 at Levels A and AA. It identifies missing alt text, color contrast failures, missing form labels, empty buttons and links, ARIA misuse, heading hierarchy issues, missing document language, and dozens more structural violations.

How to use it: Install the axe DevTools extension for Chrome or Edge. Navigate to the page you want to test. Open browser DevTools (right-click → Inspect, or Ctrl+Shift+I). Select the "axe DevTools" tab. Click "Scan All of My Page." Results appear grouped by issue type, with severity ratings, affected elements highlighted on the page, and specific remediation guidance for each failure.

Why it matters for contractors: axe-core's zero-false-positive commitment means every issue it flags is a real WCAG failure. When you document these results in your audit defense log, you are recording verified, defensible findings — not noise that needs to be triaged.

WAVE (Browser Extension)

What it is: A free browser extension from WebAIM that provides visual accessibility feedback by overlaying icons and indicators directly on the page. It is the most intuitive accessibility tool available — designed for non-developers and developers alike.

What it catches: Missing alt text, contrast errors, empty links, missing form labels, heading structure issues, ARIA problems, language attributes, and structural errors. It also flags alerts — items that are not necessarily failures but warrant manual review, such as redundant alt text or suspicious link text.

How to use it: Install the WAVE extension for Chrome, Firefox, or Edge. Navigate to the page. Click the WAVE icon in your toolbar. The page reloads with colored icons overlaid on each element: red icons indicate errors, yellow icons indicate alerts, and green icons indicate accessibility features that are correctly implemented. Click any icon to see the specific issue, the relevant WCAG criterion, and remediation guidance.

Why it matters for contractors: WAVE's visual overlay makes it immediately clear where issues are on the page — not just what the issues are. This is invaluable when communicating with non-technical municipal clients who need to see the problems, not just read about them in a report. Screenshots of WAVE results make excellent supporting documentation.

Google Lighthouse (Built into Chrome)

What it is: An open-source auditing tool built directly into Chrome DevTools. It scores pages across five categories: Performance, Accessibility, Best Practices, SEO, and Progressive Web App. The accessibility audit uses axe-core internally but runs a smaller subset of rules.

What it catches: Common WCAG failures including contrast, alt text, form labels, ARIA attributes, heading order, and language. It produces a score from 0 to 100 and lists each failing audit with the affected elements and remediation links.

How to use it: Open Chrome DevTools (Ctrl+Shift+I). Select the "Lighthouse" tab. Check "Accessibility" under categories. Click "Analyze page load." The report generates in about 30 seconds.

Why it matters for contractors: Lighthouse is useful for quick baseline scoring and for clients who respond well to a single number. A Lighthouse accessibility score is not a measure of WCAG conformance — a score of 100 means automated checks found no issues, not that the site is fully accessible. But it is a useful trendline metric: if the score drops between scans, something regressed.

Important caveat: Lighthouse runs fewer axe-core rules than the full axe DevTools extension. Use Lighthouse for quick checks and trend monitoring, but rely on axe DevTools for your comprehensive automated scan.

Layer 2: Contrast Checking

Color contrast failures are the single most common WCAG violation — found on 79% of the top million homepages. Automated tools catch many of these, but manual verification catches the edge cases: text over images, text over gradients, placeholder text, focus indicators, and custom UI components where the automated tool cannot determine the background color.

WebAIM Contrast Checker

What it is: A free online tool where you input a foreground and background color and it instantly reports the contrast ratio and whether it passes WCAG AA and AAA thresholds for normal text and large text.

How to use it: Go to webaim.org/resources/contrastchecker. Enter or paste the hex codes for your text color and background color. The tool shows the ratio and pass/fail status for each WCAG level.

When to use it: Whenever you are choosing colors for a municipal site's design system, verifying branded elements against the 4.5:1 threshold, or investigating a contrast failure flagged by an automated scan. Also use it when reviewing custom components where the automated tool reported "needs manual review" for contrast.

Layer 3: Manual Testing

This is the layer that separates defensible compliance from a false sense of security. Automated tools cannot evaluate whether alt text is meaningful, whether keyboard navigation is logical, whether reading order makes sense, or whether interactive components are usable with assistive technology. These require human judgment.

Keyboard-Only Navigation Test

What it tests: Whether every interactive element on the page — links, buttons, form fields, menus, dialogs, tabs, accordions — is reachable and operable using only the keyboard. This covers WCAG success criteria 2.1.1 (Keyboard), 2.1.2 (No Keyboard Trap), 2.4.3 (Focus Order), and 2.4.7 (Focus Visible).

How to do it: Put your mouse aside. Starting from the browser address bar, press Tab repeatedly to move through the page. Every interactive element should receive visible focus in a logical order. Press Enter or Space to activate buttons and links. Use arrow keys to navigate within menus and form controls. Press Escape to close dialogs and menus.

What to look for: Can you reach every interactive element by tabbing? Is there a visible focus indicator on every focused element? Does the focus order follow the visual layout logically? Can you complete every task — filling out a form, making a payment, navigating a menu — without touching the mouse? Are there any keyboard traps — elements that receive focus but will not release it when you press Tab or Escape?

Time required: 5 to 15 minutes per page, depending on complexity.

Screen Reader Spot Check

What it tests: Whether the page content and structure are comprehensible when consumed audibly through assistive technology. This validates alt text quality, heading structure, form label associations, link purpose, and reading order — the issues that automated tools can detect the presence of but cannot evaluate the quality of.

Which screen reader to use: NVDA is free and works on Windows (nvaccess.org). VoiceOver is built into macOS (no installation required — activate with Cmd+F5). Either one is sufficient for a spot check.

How to do it: Turn on the screen reader. Navigate the page using the screen reader's keyboard shortcuts — use H to jump between headings, Tab to move through interactive elements, and arrow keys to read content sequentially. Listen to how the page is announced.

What to listen for: Do headings accurately describe their sections? Does alt text convey the information each image provides? Do form fields announce their labels when focused? Do links describe their destination? Is the reading order logical? When you navigate by headings, do you get a meaningful outline of the page?

Time required: 10 to 20 minutes per page for a spot check. You are not testing every element — you are testing the structure and the high-risk components (forms, navigation, key content areas).

The Pre-Delivery Checklist

Before handing any web page, application, or PDF document to a municipal client, run this sequence:

Step 1: axe DevTools full scan. Open the deliverable in Chrome. Run axe DevTools. Document every violation found. Fix critical and serious issues before delivery.

Step 2: WAVE visual scan. Run WAVE on the same page. Note any issues axe did not catch (different rule sets produce different results). Review WAVE alerts — they may indicate issues that need manual judgment.

Step 3: Lighthouse accessibility audit. Run Lighthouse for the accessibility score. Record the score as a baseline. If it is below 90, investigate the failing audits.

Step 4: Contrast spot check. Verify contrast on branded elements, text over images, placeholder text, and any custom components flagged as needing manual review.

Step 5: Keyboard-only navigation. Tab through the entire page. Verify focus visibility, focus order, and the ability to complete all tasks without a mouse.

Step 6: Screen reader spot check. Turn on NVDA or VoiceOver. Navigate by headings. Check form labels. Listen to link text. Verify that the page makes sense when consumed audibly.

Step 7: Log everything. Record the date, URL, tools used, issues found, issues fixed, and remaining items in your audit defense log. Attach screenshots of scan results. This documentation is your evidence when a demand letter arrives or a contract renewal depends on demonstrating your compliance process.

Total time for all seven steps: 30 to 60 minutes per page, depending on complexity. For a typical municipal site with 10 to 20 key pages, this is one to two days of focused work — a small investment that produces documented, defensible evidence of a professional accessibility review.

What This Toolkit Does Not Replace

Automated scans plus targeted manual checks cover the critical ground. They catch the violations that generate complaints, they produce the documentation that supports your defense, and they establish the baseline for ongoing monitoring.

But this toolkit is not a comprehensive WCAG audit. A full manual audit — testing every success criterion on every page with multiple assistive technologies — requires specialized expertise and significantly more time. For high-risk deliverables, complex web applications, or sites that have never been assessed, a professional accessibility audit from a qualified evaluator is the appropriate investment.

The toolkit described here is your repeatable QA process — the minimum that should happen before every deliverable ships. Build it into your workflow now, and it becomes invisible overhead. Skip it, and the demand letter will remind you.

Twenty-five days.

---

This post is for informational purposes only and does not constitute legal advice. Consult with qualified legal counsel for guidance specific to your situation.