Accessibility Testing: A QA Engineer's Starting Point

I used to think accessibility testing was for specialists with screen readers and WCAG memorized. Then I learned that most accessibility bugs are caught by checks any tester can run in ten minutes.

Start With the Keyboard

Unplug your mouse. Can you complete the core flow using only Tab, Shift+Tab, Enter, and arrow keys?

• Does focus move in a logical order?
• Is the focused element visibly highlighted?
• Can you reach every interactive control?
• Can you escape a modal without a mouse?

Keyboard traps — where focus gets stuck in a widget — are common and completely block some users.

Check Semantic Structure

A screen reader announces the page by its structure. Quick checks:

• Headings go in order (no jumping h1 → h4).
• Buttons are , not clickable
  s.
• Images have meaningful alt text (or empty alt if decorative).
• Form inputs have associated s.

Color and Contrast

The grayscale trick instantly reveals "errors shown only in red" — invisible to colorblind users.

Automated Scans Are a Floor, Not a Ceiling

Tools like axe or Lighthouse catch maybe 30–40% of issues — missing labels, contrast, ARIA misuse. They cannot tell you whether the keyboard order makes sense or whether the alt text is meaningful. Run them, then do the manual checks they can't.

Why a QA Engineer Should Own This

Accessibility bugs are just bugs — a user can't complete a task. That's squarely QA's job. You don't need a certification to file "the submit button can't be reached by keyboard." You just need to try.