“We ran a scanner and it passed” is one of the most common — and most dangerous — things an organization can believe about its website. Automated tools are a useful first pass, but they catch only a fraction of what WCAG requires. A real audit combines four kinds of testing and ends in a documented, prioritized report. Here is how to run one.
Step 1: Inventory your digital assets
You cannot audit what you have not listed. Catalog your website's key page templates (home, landing, article, form, search results), any mobile apps, and your document libraries (PDFs, Word, PowerPoint). You do not test all 4,000 pages — you test each unique template and a representative sample, plus every high-traffic and service-critical page.
Step 2: Run automated scans
Tools like WAVE, Axe, and Lighthouse quickly flag missing alt text, low contrast, empty links, missing form labels, and structural problems. Run them on every template. But understand their ceiling: automated tools catch only about a third of WCAG failures because most criteria — “is this alt text meaningful?”, “is the focus order logical?” — require human judgment. A clean scan is the floor, not the finish line.
Step 3: Test with the keyboard only
Unplug your mouse. Using only Tab, Shift+Tab, Enter, Space, and arrow keys, try to complete every task on the page. Check that:
- You can reach and operate every interactive element — links, buttons, form fields, menus, and custom widgets.
- The focus indicator is always visible so you can see where you are.
- Focus order follows the visual/logical order of the page.
- You never get trapped (stuck inside a widget or modal with no keyboard way out).
- A skip link lets you jump past the navigation to the main content.
Step 4: Test with a screen reader
Install NVDA (free, Windows) or use VoiceOver (built into Mac and iOS); JAWS is the enterprise standard on Windows. Navigate the page by headings, by links, and by form fields. Listen for: are headings announced in a sensible hierarchy? Do images convey useful information or just read a filename? Are form fields announced with their labels and required state? When content updates dynamically (an error message, a live search result), is the change announced? This is where the majority of real barriers surface.
Don't have the tools, time, or trained testers in-house? We run full Section 508 / WCAG 2.1 AA audits — automated, keyboard, and screen-reader — and deliver a prioritized report your procurement file can stand on.
Step 5: Review documents and media
Your PDFs are web content under the ADA Title II rule. Check a representative sample for tags, reading order, and alt text — our free PDF Accessibility Checker is a fast first pass. For video, confirm accurate (not auto-generated) captions, and audio description where visual information isn't spoken aloud.
Step 6: Write the report
Turn findings into an action plan. For each issue, record: the WCAG success criterion it violates, the severity/user impact, where it occurs, and how to fix it. Then prioritize — fix the barriers that block access to services (online forms, applications, high-traffic pages) first, then work down. A findings list mapped to WCAG is what turns “we should be accessible” into a schedule someone can execute.
Step 7: Remediate, re-test, and keep records
Fix, then verify each fix with the same manual methods — automated re-scans alone won't confirm a keyboard or screen-reader repair. And keep the paper trail: your audit, your plan, your progress. Accessibility is not a one-time project; every new page, PDF, and video is a new opportunity to regress, so bake a check into your publishing workflow. The documented, ongoing effort is exactly what regulators look for.