Can accessibility testing be fully automated?

No. Automated scanners catch machine-checkable issues like missing alt text, low contrast, and missing form labels, but they can't judge whether alt text is meaningful, whether focus order is logical, or whether a screen reader announces a control correctly. Plan on a manual keyboard and screen-reader pass for anything user-facing.

What is the WCAG contrast requirement?

WCAG 2.1 Level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt, or 14pt bold), plus 3:1 for UI components and graphical objects. Remember to check text over images and the hover, focus, and disabled states, not just the default state.

Which screen reader should I test with?

Start with the free options: NVDA on Windows and VoiceOver on macOS and iOS. If your users skew enterprise, add JAWS. Pair each screen reader with a browser it works well with — NVDA with Firefox or Chrome, VoiceOver with Safari.

How do I file an accessibility bug so it gets fixed?

Name the specific WCAG success criterion, the assistive technology and browser you used, the exact steps, and what you expected the tech to announce or do versus what it actually did. Capturing the DOM and console state alongside the report removes the guesswork for the developer.

How to Test for Accessibility Bugs: A Practical Checklist

To test for accessibility bugs, work through a fixed checklist covering keyboard operation, color contrast, focus visibility, text alternatives, form labels, and screen-reader output. This matters because most accessibility defects produce no console error and no visible breakage — they only surface when you deliberately check for them against the WCAG 2.1 AA success criteria. The passes below take a trained tester a few minutes per screen and catch the issues automated scanners cannot.

What counts as an accessibility bug?

An accessibility bug is any defect that prevents someone using assistive technology — a screen reader, keyboard-only navigation, voice control, or screen magnification — from completing a task that a mouse-and-monitor user can. Unlike a functional bug, it rarely throws an exception. The button still works with a mouse; it just can't be reached with a keyboard, or its purpose is never announced to a screen reader.

That invisibility is exactly why accessibility issues slip through normal QA. Your team tests with a mouse, sees the happy path work, and moves on. To find these bugs you have to change how you drive the product, not just what you click.

The accessibility testing checklist

Run these passes in order on every user-facing screen. Each maps to real WCAG criteria, so a failure gives you a citable reference for the bug report.

Keyboard-only pass. Put the mouse away. Using only Tab, Shift+Tab, Enter, Space, Escape, and arrow keys, complete the primary task on the page. Every interactive element must be reachable, operable, and free of keyboard traps (a place you can Tab into but not out of). Menus, modals, date pickers, and custom dropdowns are where this most often fails.
Visible focus pass. As you Tab, confirm you can always see where focus is. A focus indicator that is invisible, or removed with outline: none and never replaced, is a failure — the most common one on custom-styled sites.
Contrast pass. Check text and UI colors against WCAG AA: at least 4.5:1 for normal text and 3:1 for large text (18pt, or 14pt bold), plus 3:1 for meaningful icons, borders, and form-field outlines. Don't forget placeholder text, disabled states, and text sitting over background images.
Text-alternatives pass. Every image that conveys information needs a meaningful alt attribute; purely decorative images should have an empty alt="" so screen readers skip them. Icon-only buttons need an accessible name via aria-label or visually hidden text.
Form-labels pass. Every input, select, and textarea must have a programmatically associated label (a <label>, or aria-label/aria-labelledby). Error messages must be tied to their field and announced, not shown only as red text.
Structure pass. Confirm headings are real heading elements in a logical order (no jumping from h1 to h4), that landmarks like nav and main exist, and that content order in the DOM matches the visual order. Screen readers and keyboard users follow DOM order, not CSS position.
Screen-reader pass. Turn on NVDA or VoiceOver and complete the task by listening. You are checking that each control announces its name, role, and state — "Submit, button" or "Remember me, checkbox, not checked" — and that dynamic updates (validation errors, loading states) are spoken via live regions.
Zoom and reflow pass. Zoom the browser to 200% and confirm nothing is clipped or overlapping; WCAG also expects content to reflow without horizontal scrolling at narrow widths. Check that prefers-reduced-motion is honored for animations.

Which accessibility tests to automate vs. do manually

Automated scanners such as axe or Lighthouse are the right first step, but they only detect the machine-checkable subset of problems: missing alt attributes, low contrast, missing labels, and invalid ARIA. They cannot tell you whether alt text is accurate, whether focus order makes sense, or whether a screen reader announces a widget correctly. Treat automation as a fast filter for obvious regressions, and reserve human time for the keyboard and screen-reader passes above.

A practical split:

Automate in CI: per-page axe scans on your critical routes, so a newly shipped contrast or missing-label regression fails the build immediately. If you already drive end-to-end flows with a tool like AutoSim, add a keyboard-navigation assertion so a broken tab order is caught as a test failure, not a support ticket.
Do manually each release: a keyboard-only run and a single screen-reader pass through your top three user journeys. These change slowly, so a short scripted checklist keeps them cheap.

How to write an accessibility bug report that gets fixed

Accessibility bugs get bounced back as "works for me" more than any other kind, because the developer reproduces it with a mouse and sees nothing wrong. Close that gap by giving them everything needed to reproduce it the way you did.

Name the WCAG criterion. "Fails WCAG 2.1 SC 2.1.1 Keyboard" turns a subjective complaint into a standard the fix can be verified against.
State the assistive tech and browser. "NVDA 2024.x on Firefox" — behavior differs across screen-reader and browser pairings, so the combination matters.
Give the exact interaction. Which key you pressed, where focus was, and what you expected to be announced or to happen versus what actually happened.
Attach the state. A screenshot shows a visual issue, but keyboard and screen-reader bugs live in the DOM and the accessibility tree. Capturing the page's DOM, console, and network state at the moment you hit the bug — which is exactly what Klavity Snap does from a right-click — lets the developer inspect the same markup instead of guessing.

For the broader format that applies to any defect, see our guide on writing a bug report developers will act on.

Where to start if you've never tested accessibility

Don't try to audit everything at once. Pick your single most-used flow — sign-up, checkout, or the core action of your product — and run just the keyboard-only pass on it today. It requires no tools, takes minutes, and almost always surfaces at least one real bug. Add the contrast and screen-reader passes next week, then wire an automated axe scan into CI so you stop reintroducing the issues you just fixed. Consistency on one flow beats a one-time audit of the whole app that never gets repeated.