Manual Accessibility Testing

Automated accessibility tools catch roughly 30% of WCAG issues in real-world audits. The remaining 70% require a human tester who can evaluate context, intent, and usability. Any automated WCAG ratings reflect automated testing coverage only and do not guarantee full WCAG conformance. Manual accessibility testing is not optional — it is the only way to achieve genuine accessibility. This lesson covers the essential manual testing techniques every quality engineer should master.

Why Manual Testing Is Essential

Automated tools are excellent at detecting structural problems: missing attributes, incorrect ARIA usage, and contrast ratio violations. But accessibility is ultimately about whether real people can use your product. Many critical aspects of accessibility require human judgment:

• Is the alt text meaningful? An automated tool knows the alt attribute exists, but only a human can evaluate whether it conveys the right information.
• Is the tab order logical? Does pressing Tab move focus through the page in an order that makes sense, or does it jump around unpredictably?
• Can a keyboard user complete every task? Are there interactions (drag-and-drop, hover menus, swipe gestures) that have no keyboard equivalent?
• Is dynamic content announced? When content changes on the page (a form error appears, a notification slides in, search results update), is the change communicated to assistive technology users?
• Is the experience understandable? Can someone with a cognitive disability follow the flow, understand error messages, and recover from mistakes?

Keyboard-Only Navigation Testing

Keyboard accessibility is one of the most important aspects of accessibility because it underpins screen reader usage, switch device usage, and voice control. If your site works with a keyboard, it is much more likely to work with assistive technologies.

How to Test

1. Put your mouse aside. Unplug it or move it out of reach. You must resist the temptation to click.
2. Start at the top of the page. Press Tab to move forward through interactive elements. Press Shift+Tab to move backward.
3. Verify focus is visible. Every time you press Tab, you should be able to clearly see which element has focus. If the focus indicator disappears, that is a failure.
4. Check every interactive element. Links, buttons, form inputs, dropdowns, menus, modals, tabs, accordions — every element a user might interact with must be reachable and operable via keyboard.
5. Test activating elements. Press Enter to activate links and buttons. Press Space to toggle checkboxes and activate buttons. Press arrow keys to navigate within radio groups, tab panels, and menus.
6. Check for keyboard traps. A keyboard trap is when focus enters a component and cannot leave. This is a critical WCAG violation (2.1.2). Common traps: embedded videos, modal dialogs without close mechanisms, rich text editors.
7. Verify skip links. Press Tab as the first action on a page. A "Skip to main content" link should appear (usually visually hidden until focused). Activating it should move focus past the navigation to the main content area.

Zoom to 200% Testing

WCAG 1.4.4 (Resize Text) requires that text can be resized up to 200% without loss of content or functionality. WCAG 1.4.10 (Reflow) requires that content reflows at 320 CSS pixels wide (equivalent to 400% zoom on a 1280px viewport) without requiring horizontal scrolling.

How to Test

1. Zoom to 200% using your browser's zoom function (Ctrl/Cmd + +)
2. Check that no content is cut off — text should not overflow its containers or be hidden behind other elements
3. Verify no horizontal scrolling is required to read text content
4. Test all functionality — forms, navigation menus, modals, and interactive components should still work correctly
5. Check text spacing — increase line height to 1.5x, paragraph spacing to 2x, letter spacing to 0.12em, and word spacing to 0.16em (WCAG 1.4.12). Content should still be readable with no loss of information.

Checking Focus Order

Focus order refers to the sequence in which elements receive focus when a user presses Tab. WCAG 2.4.3 (Focus Order) requires that the focus order preserves the meaning and operability of the page.

What to Check

• Does focus follow a logical top-to-bottom, left-to-right order? (For left-to-right languages.) The DOM order should match the visual order.
• Are there elements with tabindex greater than 0? Positive tabindex values override the natural DOM order and almost always create confusing focus sequences. They should be avoided.
• Is focus managed correctly in dynamic content? When a modal opens, focus should move to the modal. When the modal closes, focus should return to the element that triggered it.
• Are off-screen elements excluded from the tab order? Hidden menus, collapsed accordions, and off-canvas panels should not receive focus until they are visible.

Testing with Browser Extensions Disabled

Some browser extensions can mask accessibility issues or create false positives. For the most accurate manual testing:

• Test in a clean browser profile with no extensions installed
• Alternatively, test in your browser's private/incognito mode where extensions are typically disabled
• This ensures you are testing the actual page behavior, not behavior modified by ad blockers, password managers, or other extensions

Cognitive Walkthrough

A cognitive walkthrough evaluates whether users — especially those with cognitive or learning disabilities — can understand and complete tasks on your site. This technique goes beyond technical compliance to evaluate the actual user experience.

How to Perform a Cognitive Walkthrough

1. Define key tasks. Identify the critical user flows: signing up, making a purchase, filling out a contact form, finding a specific piece of information.
2. Walk through each task step by step. At each step, ask:
   • Will the user know what to do next?
   • Will the user see the correct action available?
   • Will the user understand the feedback after taking an action?
3. Check error handling. Deliberately make mistakes in forms. Are error messages clear and specific? Do they explain what went wrong and how to fix it? Are errors associated with the correct form field?
4. Evaluate language. Is the text clear and concise? Are technical terms or jargon avoided where possible? Is the reading level appropriate for the audience?
5. Check for consistent patterns. Does the navigation work the same way on every page? Are buttons and links styled consistently? Does the site meet users' expectations based on common web conventions?

Testing Forms, Modals, and Dynamic Content

Forms

• Every input has a visible label associated with it (using <label for="..."> or aria-labelledby)
• Required fields are clearly indicated (not just by color)
• Error messages appear near the relevant field and are announced by screen readers
• Form submission errors do not clear the form data
• Success and error states are communicated to assistive technologies

Modals and Dialogs

• Focus moves into the modal when it opens
• Focus is trapped within the modal while it is open (Tab should cycle within the modal, not escape to the page behind)
• The modal can be closed with Escape
• Focus returns to the triggering element when the modal closes
• The background content is hidden from screen readers while the modal is open (aria-hidden="true" on the main content, or using the <dialog> element)

Dynamic Content

• Content that appears or changes without a page reload (search results, notifications, validation messages) should use ARIA live regions to announce changes
• aria-live="polite" for non-urgent updates (search result counts, status messages)
• aria-live="assertive" for urgent updates (error messages, time-sensitive alerts)
• Avoid using aria-live="assertive" excessively, as it interrupts whatever the screen reader is currently reading

ARIA Live Regions in Practice

ARIA live regions are one of the most important tools for making dynamic web applications accessible. When content inside a live region changes, the screen reader announces the change without requiring the user to navigate to it.

<!-- Status message that updates when search results change -->
<div aria-live="polite" aria-atomic="true">
  Showing 42 results for "accessibility testing"
</div>

<!-- Error message that appears during form validation -->
<div role="alert">
  Please enter a valid email address.
</div>

Documenting and Reporting Accessibility Issues

When you find accessibility issues during manual testing, document them clearly so developers can fix them efficiently:

• WCAG criterion: Which specific success criterion is violated (e.g., "2.4.7 Focus Visible")
• Severity: Critical (prevents task completion), Serious (significant difficulty), Moderate (causes frustration), Minor (best practice)
• Location: The specific page URL and element (include a screenshot or DOM path)
• Steps to reproduce: Exactly how to encounter the issue (e.g., "Tab to the third navigation item, then press Enter")
• Expected behavior: What should happen according to WCAG
• Actual behavior: What actually happens
• Suggested fix: If you know the solution, include it

Creating an Accessibility Testing Checklist

A structured checklist ensures consistent testing across your team. Here is a practical checklist you can adapt:

1. Keyboard navigation: Can every interactive element be reached and operated with keyboard alone?
2. Focus visibility: Is focus always visible when tabbing through the page?
3. Focus order: Does the tab order follow a logical sequence?
4. Skip links: Is there a "Skip to main content" link?
5. Headings: Is there a logical heading hierarchy (h1 through h6)?
6. Images: Do all images have appropriate alt text?
7. Color contrast: Does all text meet minimum contrast ratios?
8. Forms: Are all inputs labeled and are errors clearly communicated?
9. Modals: Is focus managed correctly when modals open and close?
10. Dynamic content: Are changes announced via ARIA live regions?
11. Zoom: Does the page work at 200% zoom without loss of content?
12. Text spacing: Is content readable with increased text spacing?
13. Screen reader: Can a screen reader user navigate and understand all content?
14. Landmarks: Are appropriate landmark regions defined?
15. Language: Is the page language set and is the content understandable?