Manual Testing for Accessibility

Automated accessibility tools are a useful first step, but they can’t catch every issue—particularly those affecting keyboard navigation, screen reader behavior, or overall user experience for people with disabilities. That’s where manual testing becomes essential.

By manually testing your content—using keyboards, screen readers, and other assistive technologies—you gain valuable insight into how real users interact with your site. This ensures your website is not only compliant with accessibility standards, but also inclusive and truly user-friendly.

Keyboard

Some users interact with technology using only a keyboard—no mouse.

Under WCAG 2.1 2.1.1 – Keyboard (A), 2.4.3 – Focus Order (A), and 2.4.7 – Focus Visible (AA), all functionality must be operable from the keyboard, and focus must move logically and remain visible.

Test your interface the same way: put the mouse aside and navigate using just the keyboard. Use these keys to move through all interactive elements (links, buttons, menus, and form fields):

  • Tab – To move forward
  • Shift + Tab – To move backward
  • Enter/Return – Follows a link, activates (presses) a button
  • Spacebar – Toggles checkbox values, activates buttons
  • Arrow Keys – Scrolls content, moves/selects radio buttons within a group, sometimes moves between interactive menu items or tab panels.

What to Look For

  • Can you see where the focus is?
    • Each element should show a visible focus indicator (like a border or color change) when selected.
    • Is the indicator easy to see and does it have good contrast with the background?
  • Can you reach everything?
    • All interactive elements—links, buttons, menus, and form fields—should be accessible with the keyboard alone.
  • Is the navigation order logical?
    • Focus should move in a sensible order, usually top to bottom and left to right.

Keyboard testing is a quick way to uncover accessibility barriers that automated tools miss. It helps ensure your content is a user-friendly digital experience for everyone.

Color Contrast

Text Contrast

Per WCAG 2.1 1.4.3 – Contrast Minimum (AA), text must have a contrast ratio of at least 4.5 : 1 for normal text and 3 : 1 for large text (18 pt regular or 14 pt bold and larger).

  • Test the contrast ratio between text and its background to ensure these minimums are met.

For more guidance, visit Color and Contrast – Digital Access.

Interactive Element States

When interactive elements change state (such as hover, focus, active, or disabled), users must be able to clearly perceive and understand those changes.

Under WCAG 2.1 1.4.11 – Non-Text Contrast (AA), these visual indicators must have sufficient contrast and remain distinguishable from the surrounding content.

Automated tools often miss color-only or subtle visual cues for interaction states. Manual testing ensures all states are perceivable and usable for keyboard and low-vision users.

What to Test

  • For each interactive UI element (buttons, links, form controls, toggles, etc.), test the following states:
    • Default (normal)
    • Hover (mouse over)
    • Focus (keyboard tab/selected)
    • Active/pressed
    • Disabled or inactive (note: inactive components are exempt from WCAG contrast requirements but should remain visually distinct from active controls)
  • Use a color-picker or contrast-checker tool to measure contrast between the element’s UI (fill, border, outline, focus ring) and its background. For more information, visit How to Check Digital Accessibility.
  • The non-text UI component or focus indicator must have a contrast ratio of at least 3 : 1 compared to its surrounding background.
  • If the only change between states is color, ensure the difference between those states also meets at least 3 : 1, or add a non-color cue (e.g., outline, shape change, underline) so the state change is perceivable to all users.
  • Low-contrast controls or graphics needed to understand page content or functionality may be difficult or impossible for people with low vision to perceive. Ensure all essential interactive and informational visuals meet minimum contrast requirements..

Quick summary checklist:

  • Each interactive element clearly shows all states (hover/focus/active/disabled).
  • All states maintain ≥ 3:1 contrast for non-text UI or focus indicators.
  • No state relies solely on color to indicate change; alternative cues present.
  • Keyboard navigation reveals focus state and state transitions visibly and reliably.

Desktop Screen Readers

Explore how screen reader users interact with content on both Windows and macOS. Use keyboard commands and gestures to navigate and understand the structure of a page.

Windows

  • JAWS (Job Access With Speech): A widely used commercial screen reader with extensive capabilities for navigating and interacting with digital content using speech and Braille. The JAWS 40-minute demo mode allows users to run the program for up to 40 minutes at a time without activating the paid version. After 40 minutes, the computer must be rebooted to use the software again. (JAWS is noted here for awareness but is not required for developer testing.)
  • NVDA (NonVisual Desktop Access): A powerful, open-source screen reader for Windows, NVDA is widely used for both everyday access and accessibility testing. It supports speech and Braille output and offers many of the same features as commercial tools like JAWS—at no cost. Maintained by an active global community, NVDA is an excellent option for developers and testers ensuring screen reader compatibility and accessible user experiences.

macOS

  • VoiceOver: Apple’s built-in screen reader, available on all Macs, iPhones, and iPads, supports speech, Braille, and gesture-based navigation. It’s an essential tool for both users and accessibility testing across Apple platforms. Since VoiceOver is included at no extra cost, it provides a readily available option for testing screen reader compatibility on macOS, iOS, and iPadOS.

Evaluation Resources

Need Help?

Manual accessibility testing provides a thorough and accurate understanding of how accessible your digital content is to all users. For additional support or guidance, contact the IT Accessibility Center at itaccessibility@missouri.edu.

Watch: Screen Reader Demo

A helpful video demonstrating how screen readers interpret web content. Great for those new to accessibility testing or stakeholder education.

Screen Reader Demo for Digital Accessibility