Manual Accessibility Testing: A Step-by-Step Guide

This Manual Accessibility Testing Guide shows practical, repeatable steps to find and report accessibility problems a scanner will miss. Use it alongside automated tools to check keyboard access, screen reader behaviour, labels, focus order and content clarity against WCAG 2.1 and 2.2 levels A and AA.

Why manual accessibility testing matters

Automated tools are fast. They catch simple issues like missing alt text and contrast failures. They miss interaction problems, context, language, and the way assistive tech reads a page. Manual testing finds real user barriers that machines cannot judge.

When to use manual testing vs automated checks

Automated first, manual always

Run an automated scan to get a baseline and a list of clear, fixable items. Then use manual testing to verify results and test what the scanner cannot: keyboard flows, dynamic content, semantic markup and real screen reader output.

What automated tools miss

• Whether an alternative text is meaningful in context
• Correct reading order for complex widgets
• Whether state changes are announced by screen readers
• Form error clarity and recovery for people using assistive tech

Plan your manual accessibility testing

Good testing starts with scope and roles. Decide what pages, components and user journeys to test. Include core tasks such as signing in, searching, completing forms and accessing media.

Define scope and standards

• Target WCAG level(s): usually 2.1 or 2.2 level AA
• List target platforms: desktop browsers, mobile browsers, native apps
• Identify supported assistive tech: NVDA, VoiceOver, JAWS, TalkBack

Choose personas and devices

Pick 3 to 5 representative journeys. Test on at least one desktop and one mobile device. Include keyboard-only and screen reader scenarios for each journey.

Essential manual checks (by principle)

Perceivable

• Images: confirm alt text is present and meaningful for context (WCAG 1.1.1)
• Media: captions for video and transcripts for audio when content conveys information
• Contrast: verify text has sufficient contrast; check large text separately (WCAG 1.4.3)
• Text resize: ensure text can be enlarged without loss of content or functionality

Operable

• Keyboard: navigate every interactive element with Tab, Shift+Tab, Enter and Space (WCAG 2.1.1)
• Focus visible: focus state must be clear and not trapped inside widgets
• Timing: allow users to extend or pause time-sensitive content

Understandable

• Labels and instructions: form fields must have programmatic labels and clear instructions
• Error handling: errors must be identified and suggestions given (WCAG 3.3.1)
• Consistent navigation and predictable behaviour

Robust

• Semantic HTML: headings, lists and buttons used correctly
• ARIA: only use WAI-ARIA where native HTML is insufficient; ensure correct roles and states
• Dynamic updates: confirm live regions or ARIA alerts announce changes

Hands-on test steps: step-by-step examples

Follow these step-by-step tests for common components. Each example shows steps and the expected result.

Example: login form

1. Focus the page using Tab from the top of the page.
2. Tab into the username field. Confirm it receives focus and a visible outline appears.
3. Confirm the username input has a label exposed to assistive tech. If the visual label is separate, verify for=“id” association or aria-label.
4. Repeat for password. Use a screen reader to verify labels announce correctly.
5. Submit with empty fields and with invalid credentials. Confirm errors are announced automatically and the focus moves to the error or field.
6. Ensure keyboard users can submit using Enter and that form is operable with assistive tech.

Example: navigation menu with dropdown

1. Tab to the menu. Confirm the menu button is announced as expanded or collapsed.
2. Open the menu with Enter or Space. Navigate items with arrow keys if design requires it.
3. Close the menu with Escape. Confirm focus returns to the menu button.
4. Check that submenu items are reachable by keyboard and that aria-expanded and aria-controls reflect state.

Sample test cases (table)

Test	Steps	Expected result	WCAG ref
Keyboard navigation	Tab through page; activate controls	All interactive items reachable and operable without mouse	2.1.1
Image alternative text	Inspect image alt attributes; listen with screen reader	Meaningful alt present or image marked as decorative	1.1.1
Form error handling	Submit form with invalid data	Error announced, described and focus moved to error	3.3.1
Color contrast	Check text and icon contrast against background	Contrast meets normal or large text thresholds	1.4.3

Screen reader and assistive tech tests

Test with at least one screen reader and one mobile screen reader. Each behaves differently. Use real interaction rather than relying on what appears correct in developer tools.

Quick tips for common assistive tools

• NVDA: free on Windows. Use it with Firefox or Chrome and test keyboard and reading order.
• VoiceOver: built into macOS and iOS. Test rotor behaviour on iOS for form controls.
• TalkBack: test Android apps and mobile web. Check gestures and focus following navigation.

What to listen for

• Labels read before controls
• Live region announcements when content changes
• Clear descriptions for links and buttons

Common mistakes and how to avoid them

• Using role=“button” on elements that do not behave like buttons. Use native button where possible.
• Relying solely on color to convey information. Add text labels or icons with accessible names.
• Hiding content visually but leaving it in the accessibility tree without clear purpose.
• Incorrect use of aria-live regions that spam screen readers with updates.
• Assuming automated passes mean the UI is accessible. Manual checks still required.

Reporting issues, prioritisation and remediation

Write bug reports that developers can act on. Include steps to reproduce, expected behaviour, actual behaviour, assistive tech used and screenshots or audio where helpful.

Prioritise fixes

• High: keyboard traps, inability to complete a purchase or sign in, major form failures
• Medium: missing labels, incorrect role usage, contrast issues on secondary text
• Low: minor visual focus styling or small wording improvements

Include remediation advice

Suggest concrete fixes. For example, replace div used as a button with button. Add aria-live=“polite” only for important updates. Provide a code snippet when possible.

Checklist: run this on every release

• Automated scan and triage results
• Keyboard-only pass on core flows
• Screen reader pass on core flows
• Contrast and text resize check
• Form error and recovery test
• ARIA roles and live region review
• Mobile accessibility checks including touch targets

Next steps: involve real users and track regressions

Schedule periodic testing with people who use assistive tech. Track accessibility bugs in your backlog and add automated regression checks for items that can be tested automatically.

This guide gives a practical path to spot the issues scanners miss and to create fixes developers can implement. Use it as part of your release checklist and adapt the test cases to your product.