How to Test Your Website for Accessibility: A Practical Guide

Why Does Accessibility Testing Matter?

Accessibility testing is the process of evaluating whether your website can be used by people with visual, auditory, motor, and cognitive disabilities. It's both a legal requirement under laws like the ADA and the European Accessibility Act, and a quality standard that improves the experience for every visitor.

No single testing method catches all issues. The W3C's WCAG-EM methodology recommends combining automated scanning, manual keyboard testing, and assistive technology verification to produce a reliable conformance evaluation. Each method catches a different class of problem, and skipping any one of them leaves significant gaps.

Step 1: How to Run Automated Accessibility Tests

Automated tools scan your HTML and flag common WCAG violations. They are fast and consistent, but they can only catch approximately 30-40% of all accessibility issues — the rest require human judgment.

Recommended Automated Tools

VPATify Scanner — Scans your entire website and maps violations to specific WCAG 2.1/2.2 criteria. Free, with results organized by severity and exportable to VPAT format.

axe DevTools — A browser extension (Chrome/Firefox) that runs an axe-core audit on the current page. Highlights issues directly in the DOM. Use it for quick per-page checks during development.

Lighthouse — Built into Chrome DevTools (Audits panel). The "Accessibility" category runs an axe-based audit with a score out of 100. Useful for CI integration via the Lighthouse CI npm package.

WAVE — The WAVE Web Accessibility Evaluation Tool by WebAIM provides a visual overlay that flags errors, alerts, and structural elements directly on the page. Particularly useful for quickly spotting missing form labels, empty links, and contrast failures.

What Automated Tools Catch

Missing alt attributes on images (WCAG 1.1.1 Non-text Content)
Insufficient color contrast ratios (WCAG 1.4.3 Contrast Minimum)
Form inputs without associated labels (WCAG 1.3.1 Info and Relationships)
Missing ARIA landmarks (WCAG 1.3.1)
Duplicate IDs in the DOM
Empty or non-descriptive link text like "click here" or "read more" (WCAG 2.4.4 Link Purpose)
Missing language attribute on the <html> element (WCAG 3.1.1 Language of Page)

What Automated Tools Miss

Whether alt text actually describes the image meaningfully
Whether a logical reading order is preserved for screen reader users
Complex keyboard traps hidden inside JavaScript components (WCAG 2.1.2 No Keyboard Trap)
Whether error messages are programmatically associated with the failing field (WCAG 3.3.1 Error Identification)
Whether custom ARIA widgets follow the correct WAI-ARIA Authoring Practices interaction patterns
Whether content reflows correctly at 400% zoom without horizontal scrolling (WCAG 1.4.10 Reflow)

Step 2: How to Test Keyboard Navigation

Keyboard testing requires no special tools — just a keyboard. It catches interaction issues that automated scanners cannot detect and directly verifies WCAG 2.1.1 Keyboard — the requirement that all functionality be operable through a keyboard interface.

Detailed Testing Procedure

Disconnect or ignore your mouse. Use only the keyboard for the entire test session.
Press Tab to move forward through interactive elements. Press Shift+Tab to move backward. The focus should follow a logical order that matches the visual layout.
Verify every interactive element (links, buttons, inputs, dropdowns, modals) receives a visible focus indicator — a ring, outline, or other visual change that makes the focused element obvious. This is WCAG 2.4.7 Focus Visible.
Press Enter to activate links and buttons. Press Space to toggle checkboxes and activate buttons. For radio buttons, use Arrow keys to move between options within a group.
For dropdown menus and <select> elements, use Arrow Up/Down to navigate options. For custom dropdown components, verify they follow the WAI-ARIA Listbox or Combobox pattern.
Open any modal or dialog: verify that focus moves into the modal when it opens, that Tab cycles only through elements inside the modal (focus trapping), and that pressing Escape closes the modal and returns focus to the triggering element.
For tab interfaces, verify Arrow Left/Right switches between tabs and Tab moves into the tab panel content.
Check that no part of the page creates a keyboard trap — a state where you can enter a component but cannot exit it without a mouse (WCAG 2.1.2 No Keyboard Trap).
Verify that the focus order does not jump unexpectedly — for example, from the main content to the footer and back to the sidebar (WCAG 2.4.3 Focus Order).

Common Keyboard Failures

Custom dropdown menus that only respond to mouse events and ignore keyboard input entirely
Modals that do not trap focus while open, allowing Tab to reach elements behind the overlay
Modals that do not return focus to the trigger element on close
Sticky headers or cookie banners hiding the focused element (WCAG 2.4.11 Focus Not Obscured)
Carousel arrows and sliders that only work with click handlers, not keyboard events
Skip-to-content links that are missing or non-functional (WCAG 2.4.1 Bypass Blocks)

Step 3: How to Test with a Screen Reader

Screen readers convert page content into synthesized speech or braille output. Testing with a screen reader is the most accurate way to assess the experience for users with visual impairments and verifies WCAG 4.1.2 Name, Role, Value.

Detailed Screen Reader Testing Procedure

Heading structure: Press the H key in NVDA/JAWS to navigate by heading. All headings should form a logical outline — h1 followed by h2, then h3 without skipping levels. This verifies WCAG 1.3.1 Info and Relationships.
Landmark navigation: Press the D key in NVDA (or use the rotor in VoiceOver) to jump between ARIA landmarks (main, nav, aside, footer). Every page should have at least a main and navigation landmark.
Image descriptions: Navigate to images and confirm the screen reader announces descriptive alt text. For decorative images, confirm the screen reader skips them entirely (they should use alt="" or role="presentation").
Form labels: Tab to each form input and confirm the screen reader announces its visible label. Inputs without programmatic labels will be announced as "edit" or "text field" with no context.
Error messages: Submit a form with invalid data. Confirm the error message is announced automatically (via aria-live or focus management) and associated with the correct field using aria-describedby or aria-errormessage.
Dynamic content: Trigger AJAX updates (search results, notifications, shopping cart updates). Confirm changes are announced via aria-live regions — use aria-live="polite" for non-urgent updates and aria-live="assertive" for critical alerts.
Tables: Navigate to data tables and verify the screen reader announces column and row headers. Use Ctrl+Alt+Arrow keys in NVDA to move between cells and confirm header associations.
Link text: Navigate by links (press K in NVDA) and confirm every link makes sense out of context. "Click here" and "Read more" are meaningless without the surrounding paragraph.

What Are the Best Accessibility Testing Tools?

Here is a comparison of the most widely used accessibility testing tools, organized by category.

Automated Scanners

| Tool | Type | Best For | WCAG Coverage | |------|------|----------|---------------| | VPATify Scanner | Cloud | Full-site audits with VPAT export | 2.1/2.2 AA | | axe DevTools | Browser extension | Per-page developer checks | 2.1/2.2 AA | | WAVE | Browser extension / web | Visual error overlays | 2.1 AA | | Lighthouse | Chrome DevTools / CI | Performance + accessibility scoring | 2.1 AA (partial) | | Pa11y | CLI / CI | Automated pipeline testing | 2.1 AA |

Screen Readers for Manual Testing

| Tool | Platform | Setup | |------|----------|-------| | NVDA | Windows | Free download; pair with Firefox | | JAWS | Windows | Commercial; pair with Chrome or Edge | | VoiceOver | macOS/iOS | Built-in; activate via System Settings > Accessibility | | TalkBack | Android | Built-in; activate via Settings > Accessibility |

Color and Contrast Checkers

| Tool | Purpose | |------|---------| | WebAIM Contrast Checker | Verify foreground/background contrast ratios against WCAG 1.4.3 (4.5:1 for normal text) and 1.4.6 (7:1 enhanced) | | Stark | Figma/Sketch plugin for checking contrast during design | | Chrome DevTools color picker | Built-in contrast ratio display when inspecting CSS colors |

What Are Common Accessibility Testing Mistakes?

Even teams with good intentions make testing errors that lead to a false sense of compliance. Avoid these:

Relying solely on automated tools. Automated scanners catch 30-40% of WCAG issues. The remaining 60-70% — including keyboard traps, incorrect reading order, and meaningless alt text — require manual testing. An automated score of 100 does not mean your site is accessible.

Testing only the homepage. Accessibility issues concentrate on interactive pages — forms, checkout flows, dashboards, search results, and login screens. Test every distinct page template, not just the landing page.

Testing only in Chrome. Screen reader behavior varies across browsers. NVDA + Firefox and VoiceOver + Safari are the combinations your actual users rely on. Chrome-only testing misses browser-specific rendering differences in ARIA support.

Ignoring the mobile experience. Mobile accessibility failures are distinct from desktop failures. Test touch target sizes (WCAG 2.5.8 Target Size Minimum requires at least 24x24 CSS pixels), pinch-to-zoom behavior (do not disable viewport scaling), and VoiceOver/TalkBack gesture navigation.

Treating ARIA as a fix for broken HTML. ARIA should supplement native HTML semantics, not replace them. A div with role="button" and tabindex="0" is always worse than a native button element. Native elements get keyboard behavior, focus management, and form submission for free.

Skipping cognitive accessibility checks. WCAG 3.1.5 Reading Level (AAA) and WCAG 3.3.2 Labels or Instructions (A) exist because unclear language and missing instructions create real barriers. Test whether error messages actually explain what went wrong, whether form fields have visible instructions, and whether complex processes include help text.

Testing once and declaring compliance. Accessibility is not a one-time audit. Every code deployment, CMS content update, and third-party widget change can introduce new violations. Build accessibility checks into your CI/CD pipeline and run periodic manual audits.

Step 4: When Should You Hire an Accessibility Expert?

Automated testing and keyboard/screen reader spot-checks are a strong foundation. For formal VPAT documentation or legal compliance verification, consider:

A professional accessibility audit from a certified expert (CPACC or WAS credentials from IAAP)
User testing with people who have disabilities — lived experience reveals issues tools and testing scripts miss
Remediation services for complex components like data tables, PDF documents, embedded video players, and single-page applications with client-side routing

VPATify's marketplace connects you with vetted accessibility specialists for exactly these needs.

How to Create an Accessibility Testing Checklist

A structured checklist prevents your team from missing the same issues across releases. Organize your checklist by WCAG principle and testing method.

Perceivable (WCAG Principle 1)

[ ] All images have descriptive alt text; decorative images use alt="" (1.1.1)
[ ] Video content has captions; audio content has transcripts (1.2.2, 1.2.1)
[ ] Color contrast meets 4.5:1 for normal text and 3:1 for large text (1.4.3)
[ ] Information is not conveyed by color alone (1.4.1)
[ ] Content reflows at 400% zoom without horizontal scrolling (1.4.10)
[ ] Text spacing can be adjusted without loss of content (1.4.12)

Operable (WCAG Principle 2)

[ ] All functionality works via keyboard only (2.1.1)
[ ] No keyboard traps exist (2.1.2)
[ ] A skip navigation link is present and functional (2.4.1)
[ ] Page titles are descriptive and unique (2.4.2)
[ ] Focus order is logical and predictable (2.4.3)
[ ] Focus indicator is visible on all interactive elements (2.4.7)
[ ] Focused elements are not hidden behind sticky headers (2.4.11)
[ ] Touch targets are at least 24x24 CSS pixels (2.5.8)

Understandable (WCAG Principle 3)

[ ] Language attribute is set on the <html> element (3.1.1)
[ ] Form inputs have visible labels (3.3.2)
[ ] Error messages identify the field and describe the error (3.3.1)
[ ] Help mechanisms appear in consistent locations across pages (3.2.6)
[ ] Previously entered data is auto-populated in multi-step forms (3.3.7)
[ ] Authentication does not require cognitive function tests without alternatives (3.3.8)

Robust (WCAG Principle 4)

[ ] Interactive elements have accessible names, roles, and values (4.1.2)
[ ] Status messages are communicated to assistive technologies via aria-live (4.1.3)

Process Checks

[ ] Run automated scan with VPATify or axe DevTools
[ ] Complete keyboard navigation test end-to-end
[ ] Test with NVDA + Firefox or VoiceOver + Safari
[ ] Verify heading hierarchy (no skipped levels)
[ ] Confirm modals trap focus while open and release it on close
[ ] Test all interactive pages — not just the homepage
[ ] Verify on mobile with VoiceOver (iOS) or TalkBack (Android)