How to Test Accessibility Manually

Automated scanners will not tell you whether a keyboard user can finish checkout or whether focus vanishes inside a modal. How to test accessibility manually closes that gap by verifying real people can complete real tasks with keyboard, screen reader, zoom, and reduced motion, not only that markup rules pass.

This guide shows how to test accessibility manually with a practical QA workflow: prepare scope, run keyboard sessions, check structure and forms, use screen readers, sample visual access, write strong defects, and avoid false confidence. You will get checklists, tables, example test cases, and a common mistakes section you can apply on product teams.

What Manual Accessibility Testing Is (and Is Not)

Manual accessibility testing is structured, hands-on evaluation of product behavior using human judgment and assistive technology. It focuses on barriers in journeys, not only on rule violations in markup.

It is not:

• Random clicking with good intentions and no notes
• Only running axe and pasting the count into Slack
• Only a design color review
• Only a once a year external audit substitute for release testing

It pairs best with:

• Automated scanning for quick wins (automated accessibility testing with axe)
• A durable WCAG accessibility testing checklist
• Specialist audits for high risk legal or enterprise releases

Think of manual work as the functional testing of inclusion: can users complete the job to be done?

Why Manual Testing Still Finds the Expensive Bugs

Automation is strong at:

• Missing form labels in many patterns
• Some contrast failures
• Duplicate IDs
• Certain invalid ARIA patterns
• Obvious image alt gaps

Manual testing is strong at:

• Keyboard traps and focus dead ends
• Illogical tab order
• Invisible focus indicators
• Controls that look clickable but are not keyboard operable
• Screen reader announcements that are technically present and practically useless
• Error messages that appear visually but are never announced
• Modals that leave focus on the page behind
• Custom widgets that pretend to be buttons
• Dynamic carts and filters that update silently
• Tasks that require too many steps or unclear names

Those are the defects that block purchases, signups, and support. They are also the defects that create legal and reputational risk.

Prerequisites and Mindset

Before the first session:

1. Learn the product purpose and critical journeys.
2. Agree on the target standard, commonly WCAG 2.2 AA for many products.
3. Install or enable tools: browser, screen reader, contrast checker, optional bookmarklets.
4. Get test accounts and data that include realistic error states.
5. Decide evidence format: screenshots, short videos, SR output notes.

Mindset rules:

• Test the task, not only the component screenshot.
• Prefer user impact language over tool score language.
• Assume good intent from designers and developers, still report blockers clearly.
• You do not need to be a full time accessibility specialist to run valuable sessions.

Manual WCAG Testing Checklist for QA Sessions

Use this as a session spine. Deep criterion knowledge can grow over time.

A. Setup

• Browser and OS versions recorded
• Extensions that alter pages disabled when possible
• Test account ready
• Journey charter written

B. Keyboard only

• All interactive elements reachable
• No keyboard trap
• Logical focus order
• Visible focus at all times
• Menus, tabs, dialogs, and disclosure widgets operable
• Skip link works if present
• Shortcuts do not break expected browser behavior without alternatives

C. Structure and semantics

• Page has a descriptive title
• Headings outline the content
• Landmarks make sense
• Lists, tables, and links are real semantics when needed
• Decorative vs informative images handled correctly

D. Forms

• Visible labels
• Instructions available before errors
• Required fields identified
• Errors identified in text
• Errors associated with fields
• Error recovery possible with keyboard and screen reader

E. Name, role, value

• Controls expose a spoken name
• Roles match behavior
• States such as expanded, selected, checked are conveyed
• Icons buttons have accessible names

F. Dynamic updates

• Toasts, carts, filters, and async results are announced appropriately
• Focus moves when context changes in a helpful way
• Loading states are understandable

G. Visual access samples

• Text zoom to 200%
• Reflow without loss of essential content where required
• Contrast spot checks on text and key UI
• Information not by color alone

H. Screen reader task completion

• Navigate by headings and landmarks
• Complete the journey with SR
• Confirm forms, dialogs, and errors

For deeper keyboard detail, use keyboard navigation testing. For SR command fluency, use screen reader testing.

How to Test Accessibility Manually Step by Step

Step 1: Write a charter

Example charter:

Explore the signup journey on staging with keyboard and NVDA.
Priority risks: focus order, labels, error announcements, password show toggle.
Time box: 60 minutes.
Output: findings list with severity and evidence.

Charters prevent aimless wandering and make results reviewable.

Step 2: Smoke with automation (optional but smart)

Run axe or similar on the starting pages. Fix or log quick wins so manual time targets judgment heavy issues. Do not stop after the scan.

Step 3: Keyboard pass without the mouse

Unplug the mouse or ignore the trackpad.

Typical tab path for signup:

1. Skip link (if any)
2. Logo / home
3. Nav
4. Email
5. Password
6. Show password
7. Terms checkbox
8. Submit
9. Error recovery if forced validation fails

At each stop, ask:

• Can I tell where I am?
• Can I activate this with Enter or Space as expected?
• Does focus move somewhere sensible after activation?
• If a dialog opens, is focus inside it?
• If I press Escape, does it close when expected?

Step 4: Structure pass

Use browser heading/landmark extensions or screen reader heading lists.

Ask:

• Is there one clear main heading for the page purpose?
• Are heading levels nested sanely?
• Can I jump to main content?
• Are sections discoverable without visually scanning?

Step 5: Forms and error pass

Trigger validation:

• Empty submit
• Invalid email format
• Too short password
• Unchecked required terms

Expected accessible behavior examples:

• Errors in text, not color only
• Focus moves to a useful place (summary or first error) according to your pattern
• Screen reader can find the error message
• Fields are programmatically associated with errors

Step 6: Screen reader pass

Pick a supported pair, for example:

• NVDA + Chrome or Firefox on Windows
• VoiceOver + Safari on macOS

Complete the same journey listening first, looking second. Note exact spoken output for key controls and errors.

Step 7: Visual sample pass

• Zoom to 200%
• Check whether essential content and controls remain usable
• Spot check contrast on primary text, errors, and buttons
• Confirm status is not color only (also use text or icons with names)

Step 8: Debrief

Sort findings by user impact. File blockers first. Capture what was not covered so the next session can continue.

Manual A11y Test Cases You Can Reuse

ID	Title	Preconditions	Steps	Expected result
A11Y-KEY-01	Complete login with keyboard only	Valid user exists	Tab to email, password, submit without mouse	Login succeeds; focus never lost; focus visible
A11Y-KEY-02	Modal traps focus correctly	Page has modal trigger	Open modal, tab repeatedly, press Escape	Focus stays in modal cycle; Escape closes; focus returns to trigger
A11Y-FRM-01	Required field errors are announced	SR running	Submit empty form	Errors identified in text and announced or discoverable with field
A11Y-FRM-02	Checkbox label is activatable	None	Click/activate label text	Control toggles; name is clear
A11Y-SR-01	Add to cart announces update	SR running, product page	Activate Add to cart	Cart update is announced via live region or clear focus change
A11Y-VIS-01	200% zoom keeps checkout usable	Desktop browser	Zoom 200%, complete payment fields	No essential clipping; controls operable

These are functional accessibility cases. They belong next to ordinary QA cases, not in a forgotten side spreadsheet.

Severity Guidance for Manual Findings

Severity	Example	Release impact
Blocker	Cannot complete checkout by keyboard	Fix before release of that flow
High	Screen reader cannot associate payment errors	Fix before release or provide temporary alternative path
Medium	Heading levels skip and hurt efficiency	Schedule soon; may not block low risk release
Low	Minor name verbosity	Clean up in backlog
Advisory	Enhancement beyond target level	Product decision

Severity is about task impact and frequency, not about how interesting the bug feels.

Sample Session Script: Checkout

Charter: Keyboard + VoiceOver checkout smoke on staging
Time: 75 minutes

1. Open product page, add item with keyboard.
2. Open cart, change quantity, proceed.
3. Fill shipping fields, trigger validation errors.
4. Fix errors with SR guidance.
5. Open payment modal/iframe path if in scope.
6. Place order or reach review step.
7. Confirm order confirmation structure and focus.

Watchouts:
- Quantity steppers
- Address autocomplete
- Promo code apply button name
- Sticky order summary focus order
- Payment fields labeled only by placeholder

Write findings while the session is fresh. Memory is a bad accessibility tool.

How Manual Testing Maps to WCAG Principles

You do not need to recite the entire standard mid session, but mapping helps reporting.

Principle	Manual questions
Perceivable	Can I see or hear the information I need? Captions, contrast, alt, structure?
Operable	Can I run the UI without a mouse? Timing, focus, navigation?
Understandable	Are labels, errors, and consistent navigation clear?
Robust	Does it work with actual assistive tech, not only one browser hack?

When you can, attach a success criterion such as 2.1.1 Keyboard, 2.4.3 Focus Order, 2.4.7 Focus Visible, 3.3.1 Error Identification, 4.1.2 Name Role Value. If you are unsure of the number, still file the user barrier accurately.

Exploratory Testing Techniques for Accessibility

Accessibility exploratory testing works well with classic ET skills.

Tours

• Keyboard tour: no pointing device
• Screen reader tour: listen through a journey
• Zoom tour: 200% and reflow
• Error tour: force every validation
• Mobileness tour: small viewport plus OS SR where relevant

Variability

• Empty states vs filled states
• First visit vs return visit
• Slow network delaying async announcements
• Long translated strings breaking labels or truncation

Oracles

• WCAG target level
• Platform UI conventions
• Consistency with similar components in your design system
• "Would a user understand this with audio only?"

Team Workflow: Where Manual A11y Fits

Suggested integration:

Stage	Manual accessibility activity
Design review	Keyboard and SR concerns on prototypes
Story definition	Acceptance criteria include operable and announced behaviors
PR / feature test	Keyboard smoke + targeted SR on changed UI
Regression	Critical journey a11y pack each release
Audit	Deep manual + automated + specialist review

QA should not be the only line of defense. Developers can unit test names and roles. Designers can specify focus and contrast. QA validates the integrated experience.

Evidence That Gets Bugs Fixed

Include:

1. Environment: OS, browser, AT version
2. URL and user state
3. Steps to reproduce
4. Expected accessible result
5. Actual barrier
6. Impact (blocked task?)
7. Screenshot, clip, or SR transcript
8. Optional WCAG mapping
9. Suspected component (design system button, modal, etc.)

Example SR note:

NVDA 2024.x, Chrome 131, Windows 11
On Submit with empty Email:
Spoken: "Submit button"
Then silence.
Visually, red text "Email is required" appears above the field.
Expected: error announced on submit and/or when focusing Email, with programmatic association.

Common Mistakes in Manual Accessibility Testing

Mistake 1: Scanner only theater

A zero issue axe run can still hide a keyboard trap in a custom widget.

Mistake 2: Mouse assisted "keyboard testing"

If you click to recover focus, you are not testing keyboard reality.

Mistake 3: Testing components in Storybook only

Useful, but integration pages add routing, focus on navigation, and live data issues.

Mistake 4: One screen reader swipe on the homepage

Critical journeys matter more than a marketing hero.

Mistake 5: Filing "not WCAG compliant" without user impact

Engineers need the barrier and the steps.

Mistake 6: Ignoring error states

Many accessibility failures appear only after validation.

Mistake 7: Treating SR verbosity preferences as product bugs

Learn basic commands and default settings; still report clear product failures.

Mistake 8: No regression pack

Fixed modals come back when someone "refactors" focus logic.

Mistake 9: Forgetting mobile and zoom

Desktop keyboard only is not the whole population.

Mistake 10: Waiting for a yearly audit

Manual accessibility testing belongs in regular QA, not only special occasions.

Building Skill Without Burnout

You do not need to learn every screen reader command in a weekend.

Week by week growth plan:

1. Week 1: keyboard only on one journey
2. Week 2: add form error checks
3. Week 3: NVDA or VoiceOver basics on the same journey
4. Week 4: modal and menu patterns
5. Week 5: write a reusable regression pack
6. Week 6: teach another tester your checklist

Competence compounds. Consistency beats occasional heroics.

Practice Path

Manual accessibility judgment improves with deliberate practice. Run a checklist on a real app, then sharpen how you describe barriers and expected results in QABattle battles. If you are building a broader QA practice track across accessibility and other skills, sign up and keep session notes as reusable charters.

Final Manual Accessibility Workflow

1. Pick a critical journey and time box a charter.
2. Run a quick automated scan for low hanging fruit.
3. Complete the journey keyboard only.
4. Check structure, forms, and name role value.
5. Repeat with a screen reader on a supported pair.
6. Sample zoom, reflow, and contrast risks.
7. Log impact ordered findings with evidence.
8. Add blocker cases to the regression pack.
9. Retest fixes with the same AT setup.
10. Expand to the next template.

Manual accessibility testing turns inclusion from a slogan into executable QA work. Tools accelerate you. Standards guide you. Manual sessions prove whether people can actually complete the task. That proof is what product quality requires.

If you remember one rule, remember this: if a user cannot complete the journey with keyboard and assistive technology, the feature is not done, no matter how polished it looks with a mouse.

Manual Accessibility Testing for Specific UI Patterns

Once the core journey method is solid, pattern libraries help you move faster. Use these as add on charters when a release touches a familiar widget family.

Navigation and menus

• Top nav items reachable and expandable with keyboard
• Escape closes open menus
• Current page indicated with more than color
• Mobile menu focus moves into the drawer and returns on close
• Skip link appears on focus and jumps to main content

Tables and data grids

• Column headers are real headers
• Row action buttons have contextual names
• Sortable headers expose sort state
• Pagination controls are operable and named
• Horizontal scroll regions remain keyboard usable where required

Date pickers and complex inputs

• Users can type a date without being trapped in a grid only widget
• Calendar popup manages focus
• Selected date is announced
• Invalid date errors are associated and recoverable

File upload

• Upload control has a visible and programmatic name
• Selected file name is announced or otherwise available
• Remove file action is keyboard operable
• Error for wrong type or size is clear in text

Infinite scroll and live feeds

• New content does not steal focus unexpectedly
• Status of loading more items is understandable
• Users can reach footer and important actions without endless tab loops

Document which patterns a release touches, then pick the matching charter. This keeps manual accessibility testing efficient instead of retesting the whole product blindly.

Collaboration Scripts That Reduce Rework

Manual findings land better when you frame them as shared quality work.

With design:

• Ask for focus order sketches on complex pages
• Confirm error placement and wording before build
• Review icon only actions for naming plans

With development:

• Agree on modal focus utilities in the design system
• Prefer native elements in code review checklists
• Add component level accessibility tests for names and roles where stable

With product:

• Put keyboard and screen reader completion into acceptance criteria for high risk stories
• Budget time for a11y sessions in the sprint, not only "if we have time"
• Decide severity policy before release week arguments

When accessibility is only a QA surprise at the end, it becomes a conflict. When it is specified early, manual testing becomes confirmation instead of emergency invention.

Release Gate Example

A practical release gate for a consumer web app might look like this:

Gate item	Required evidence
Critical journeys keyboard complete	Session notes for login, search, checkout
Critical journeys SR complete	NVDA or VoiceOver notes on same journeys
No open a11y blockers	Defect query with severity policy
Automated scan clean for serious issues on changed templates	axe or equivalent report
Contrast and zoom smoke	Checklist sign off on changed UI
Regression pack green for previously fixed traps	Retest log

Gates should be boring and repeatable. If every release invents a new process, barriers slip through.

Measuring Whether Manual Practice Is Working

Track a few signals over quarters:

• Number of accessibility blockers found before production vs after
• Time to fix high severity a11y defects
• Percentage of critical journeys with a recent manual session
• Repeat defects on the same component family
• Team confidence self rating after training sessions

If production keeps revealing keyboard traps that never appear in session notes, your charters are too shallow or too late. If everything is found but nothing is fixed, the problem is prioritization, not tooling.

Closing Encouragement for QA Engineers

You do not need permission to start small. Tomorrow you can pick one flow, remove the mouse, and write three findings with evidence. That single habit teaches more than another unread standard PDF. Over time, your sessions get faster, your defects get clearer, and your product gets more usable for more people.

How to test accessibility manually is ultimately a professional craft of empathy plus rigor: empathy for different ways of interacting with software, rigor in steps, evidence, and retest. Combine that craft with automation and standards knowledge, and accessibility stops being a mysterious specialty ticket and becomes normal quality work.