Accessibility Testing – QA Checklist

Accessibility bugs rarely show up in a standard functional pass — the happy path works fine with a mouse and 20/20 vision. But ship a form a screen reader can't parse, a modal that traps keyboard focus, or text that fails contrast, and a real share of your users are locked out of a flow that "passed QA." This is the checklist I run against on real projects: what accessibility testing actually means, why it matters commercially and legally, and a full section-by-section pass any QA engineer can execute without being a certified accessibility auditor.

What is Accessibility Testing?

Accessibility testing verifies that a product can be used by people with a wide range of abilities — not just the default case of a sighted user with a mouse and a keyboard. That includes people who:

• Have low vision, color blindness, or are fully blind and rely on screen magnification or screen readers
• Cannot use a mouse and navigate entirely by keyboard or switch device
• Are Deaf or hard of hearing and depend on captions and visual alternatives to audio
• Use assistive technology such as NVDA, JAWS, or VoiceOver to hear and navigate the page
• Have cognitive or motor differences that make dense layouts, tight timers, or small tap targets hard to use

The goal is simple to state and easy to underestimate: no one should be blocked from completing a core task because of how they perceive or interact with the interface. Accessibility testing is how QA proves that goal is actually met, rather than assumed.

Why Accessibility Testing Is Important

• Better UX for everyone — clear focus states, readable contrast, and sensible heading structure improve usability for all users, not only those using assistive technology
• Legal and compliance exposure — ADA, Section 508, the EU's EN 301 549, and similar regulations increasingly apply to commercial web and mobile products, and lawsuits over inaccessible sites are common
• Inclusion and reach — a meaningful percentage of any user base has a permanent, temporary, or situational disability; excluding them is excluding paying customers
• WCAG as the shared standard — the Web Content Accessibility Guidelines give teams an objective, testable bar (Level A/AA/AAA) instead of a subjective "looks fine to me"

How I Use This on Real Projects

I don't run a full audit on every ticket. I map this checklist onto the same critical journeys I already test functionally — login, search, checkout, settings, and any form the business depends on — and run the relevant sections against those flows before release. Anything found gets triaged like any other defect: severity, evidence, and a clear expected-vs-actual, so it competes fairly with functional bugs instead of getting quietly deprioritized.

QA Accessibility Testing Checklist

1. Keyboard Accessibility

• Every interactive element is reachable via Tab / Shift+Tab in a logical, predictable order
• A visible focus indicator appears on every focusable element — never removed via outline: none without a replacement
• No keyboard traps: modals, dropdowns, and custom widgets can always be exited
• Enter and Space activate buttons and custom controls the way a mouse click would
• A skip-to-content link is available before repetitive navigation blocks
• Custom widgets (tabs, accordions, sliders, menus) support arrow-key interaction per standard ARIA patterns

2. Screen Reader Compatibility (NVDA, VoiceOver)

• Each page has a clear, descriptive document title
• Headings follow a logical hierarchy (h1 → h2 → h3) so screen reader users can navigate by heading
• NVDA (Windows, with Chrome or Firefox) announces every interactive element with the correct role, name, and state
• VoiceOver (macOS and iOS Safari) announces the same controls and content correctly
• Reading order matches visual order — no confusing jumps caused by CSS positioning or tab index overrides
• Content hidden from sighted users only when intended is marked with aria-hidden, not left ambiguous

3. Images & Icons

• Meaningful images have concise, descriptive alt text
• Purely decorative images use alt="" so screen readers skip them instead of reading a filename
• Icon-only buttons and links have an accessible name via aria-label or visually hidden text
• Complex images — charts, infographics, diagrams — have a text alternative or an adjacent long description
• SVG icons used as interactive controls carry the correct role and aria attributes

4. Color & Contrast

• Text meets WCAG AA contrast ratios (4.5:1 for normal text, 3:1 for large text)
• Color is never the only signal for meaning — errors, status, and links all have a second visual cue
• Dark mode and high-contrast display modes remain fully readable, if supported
• Focus indicators have sufficient contrast against their background in every theme
• Content stays legible and usable when the page is zoomed to 200%

5. Forms & Input Fields

• Every input has a visible label programmatically associated with it (not just placeholder text)
• Required fields are marked both visually and for assistive technology
• Validation errors are announced to screen readers and linked to the relevant field, not just shown as color
• Related inputs (radio groups, checkbox sets) are grouped with fieldset/legend or an equivalent pattern
• Autocomplete attributes are set for common fields such as name, email, and address
• Field-level help text is associated with its input via aria-describedby

6. Buttons & Links

• Buttons and links have clear, descriptive accessible names — never bare "Click here" or "Read more" out of context
• Links that open a new tab or trigger a download warn the user before it happens
• Disabled state is communicated to assistive technology, not only through visual styling
• Icon-only buttons include a text alternative
• Custom-styled controls use the correct semantic element (button, a) or an equivalent ARIA role rather than a bare div or span

7. Navigation & Structure

• Landmarks — header, nav, main, footer — are used correctly and consistently across pages
• Heading structure reflects the actual content hierarchy, not just visual size
• Breadcrumbs and menus are fully keyboard- and screen-reader-navigable
• The page language is declared correctly via the lang attribute
• Primary navigation stays consistent from page to page so returning users (and assistive tech users especially) aren't relearning the layout

8. Mobile Accessibility

• Touch targets meet minimum size guidance (roughly 44×44px) with adequate spacing
• VoiceOver (iOS) and TalkBack (Android) can operate every core flow, not just static screens
• Content reflows correctly at large system text sizes and under pinch-zoom
• Orientation lock (portrait/landscape) never blocks a required task
• Gestures have an accessible alternative — no swipe-only or long-press-only interactions

9. Audio & Video Content

• Videos include accurate captions or subtitles
• Pre-recorded audio has a transcript available
• Auto-playing audio or video can be paused, stopped, or muted immediately
• Player controls (play, pause, volume, captions) are fully keyboard-accessible
• No content flashes more than three times per second (seizure risk)

10. Alerts, Errors & Messages

• Success, error, and warning messages are announced to assistive technology via aria-live or role="alert"
• Toasts and banners stay visible long enough for a screen reader to announce them before they auto-dismiss
• Error messages explain what went wrong and how to fix it — not just "Invalid input"
• Status is never conveyed by color or icon alone

11. Dynamic Content & Modals

• Modals trap focus while open and return focus to the triggering element on close
• Modals are dismissible via Escape and a clearly labeled close control
• Dynamically loaded content (infinite scroll, live updates, async results) is announced appropriately rather than silently appearing
• Tooltips and popovers are reachable and dismissible via keyboard
• Loading and busy states are communicated to assistive technology, not shown only as a visual spinner

12. Automation (Support Check Only)

• Automated scanners (axe, Lighthouse, WAVE) run as a fast first pass and are wired into CI where possible
• Automated findings — missing alt text, contrast failures, ARIA misuse — are triaged and fixed, not just logged
• Flagged issues are confirmed manually before reporting, since scanners produce false positives and false negatives
• Automated coverage is tracked as a baseline, not treated as proof the product is accessible

Used consistently, this checklist turns accessibility from a vague compliance worry into a concrete, testable part of release readiness — the same way a functional or regression checklist does. Run it against your critical journeys, log what you find with the same rigor as any other defect, and treat automation as a helpful first filter rather than the finish line.