A qualified accessibility auditor uses a small, deliberate set of tools paired with multiple browsers and assistive technologies. The core stack includes a modern browser like Chrome or Firefox, a screen reader such as NVDA, JAWS, or VoiceOver, browser developer tools, and a few targeted inspection extensions. Auditors do not rely on a single automated checker. The work is human-led, with tools acting as inspection aids while the auditor maps each finding to WCAG success criteria.
| Category | Common Picks |
|---|---|
| Desktop browsers | Chrome, Firefox, Safari, Edge |
| Mobile browsers | Safari on iOS, Chrome on Android |
| Screen readers | NVDA, JAWS, VoiceOver (macOS and iOS), TalkBack |
| Inspection extensions | axe DevTools, ARC Toolkit, WAVE, Accessibility Insights |
| Built-in dev tools | Chrome DevTools, Firefox Accessibility Inspector |
| Color and contrast | Colour Contrast Analyser (TPGi), Stark |
| Keyboard and zoom | Native keyboard, OS zoom, browser zoom to 400% |
Why the Auditor Picks the Tools, Not the Other Way Around
An accessibility audit is a human evaluation. The auditor reads markup, operates the interface with a keyboard, listens to screen reader output, and decides whether each WCAG success criterion is met. Tools speed up parts of that work. They do not replace it.
Automated checkers catch approximately 25% of issues. The remaining issues require a person who understands ARIA, semantic HTML, focus order, name and role exposure, and how assistive technology actually announces content. That is why the toolset across qualified auditors looks similar. Different people, same instruments.
Which Browsers Does an Accessibility Auditor Use?
Auditors evaluate across multiple browsers because rendering, focus behavior, and assistive technology pairing all vary. The standard pairings:
NVDA with Firefox or Chrome on Windows. JAWS with Chrome or Edge on Windows. VoiceOver with Safari on macOS and iOS. TalkBack with Chrome on Android.
Pairings matter. A site that works perfectly in NVDA with Firefox can announce something different in JAWS with Chrome. A qualified auditor checks the most common pairings rather than assuming one combination represents the whole picture.
Mobile environments need their own pass. iOS Safari with VoiceOver and Android Chrome with TalkBack are evaluated separately from desktop, since gestures, focus order, and rotor or reading control behavior differ.
Screen Readers in the Auditor’s Workflow
Screen readers are the most important tool an auditor uses. They reveal whether names, roles, states, and properties are exposed correctly to the accessibility tree. They surface issues no visual scan can detect: missing labels, redundant announcements, broken focus management on dynamic components, and incorrect heading semantics.
NVDA is free and widely used in audits. JAWS is the dominant commercial screen reader in enterprise environments. VoiceOver ships with Apple devices and is required for any iOS or macOS evaluation. TalkBack covers Android. A qualified auditor knows the keyboard commands and reading modes for at least two of these and uses them in real audit work, not as a checkbox.
Inspection Extensions and Developer Tools
Browser extensions help auditors work faster on specific checks. They flag obvious issues, surface the accessibility tree, and let the auditor inspect ARIA attributes and computed names without writing code.
axe DevTools for quick rule-based scans during inspection. ARC Toolkit for deeper component-level review. WAVE for visualizing structure and landmarks. Accessibility Insights for guided checks and the FastPass workflow.
Chrome DevTools includes an accessibility pane that shows the computed name, role, and ARIA properties for any element. Firefox has a similar Accessibility Inspector. These built-in views are critical when the auditor is verifying why a screen reader announced something a particular way.
Color, Contrast, and Visual Checks
Contrast checks need a dedicated tool. The Colour Contrast Analyser from TPGi and Stark are common picks. Auditors check text contrast, non-text contrast for UI components, and focus indicator contrast against adjacent colors.
Visual checks also include zoom and reflow. The auditor zooms to 200% and 400% in the browser, confirms content reflows without horizontal scrolling at 320 CSS pixels wide, and verifies that no content is cut off or overlapped.
Keyboard-Only Operation
Every audit includes a keyboard-only pass. The auditor disconnects the mouse or sets it aside and operates the entire interface with Tab, Shift+Tab, Enter, Space, arrow keys, and Escape. Focus order, focus visibility, keyboard traps, and skip links are all evaluated this way.
No extension replaces this step. The keyboard is the tool.
What About AI Tools?
AI can support an auditor’s workflow. It can help draft remediation guidance, summarize patterns across a report, and accelerate documentation. It cannot determine WCAG conformance. A qualified auditor uses AI where it adds efficiency and ignores it where it would replace evaluation work that needs a human.
Do auditors rely on automated scans?
No. Scans are a starting point at most. They identify a fraction of issues and produce false positives that an auditor must verify. The audit itself is conducted by a person mapping findings to WCAG success criteria.
What operating systems do accessibility auditors work on?
Windows and macOS for desktop work, since the dominant screen readers run on those platforms. iOS and Android for mobile audits. Most qualified auditors keep access to all four environments because real audits require all four.
Is there one tool that does everything?
No. Anyone selling a single tool that promises full WCAG conformance is overstating what software can do. The auditor’s value is in interpretation, and the toolset is intentionally varied because no single tool covers every check.
How do I know an auditor is qualified?
Look for hands-on experience with multiple screen readers, fluency in WCAG 2.1 AA or 2.2 AA, the ability to produce a clear audit report mapping issues to specific success criteria, and credentials such as IAAP CPACC or WAS, or DHS Trusted Tester. The toolset follows the qualifications, not the reverse.
The right toolset is a sign of an auditor who knows what they are doing. The audit itself is the work.
Find qualified accessibility auditors and service providers in the Accessibility Base directory.