Manual Accessibility Testing — Complete Guide

In this tutorial, you will learn about Manual Accessibility Testing. We cover key concepts, practical examples, and best practices to help you master this topic.

Manual accessibility testing uses keyboard navigation, screen readers, zoom testing, color contrast inspection, and expert review to find the 50 to 70 percent of accessibility issues that automated tools cannot detect.

What You'll Learn

• Manual keyboard testing techniques
• Screen reader testing with NVDA, VoiceOver, JAWS
• Zoom and text spacing testing
• Visual inspection for contrast and focus
• Creating a manual testing workflow
• Documenting and tracking manual findings

Why It Matters

• Automated tools miss 50-70 percent of accessibility issues
• Only human testing can evaluate context, clarity, and user experience
• Screen reader testing reveals real user experience issues
• Legal Compliance requires manual testing

Real-World Use

• An accessibility specialist tests a checkout flow with NVDA
• A QA team runs keyboard-only tests before every release
• A designer inspects color contrast in real-world lighting
• A developer tests zoom behavior at 200 percent

flowchart LR
  A[Manual Testing] --> B[Keyboard Audit]
  A --> C[Screen Reader Audit]
  A --> D[Visual Audit]
  A --> E[Content Audit]
  B --> F[Tab Order, Focus, Traps]
  C --> G[Navigation, Announcements]
  D --> H[Contrast, Zoom, Motion]
  E --> I[Alt Text, Links, Headings]

Manual Testing Approaches

Manual testing is structured human evaluation of accessibility. Each test type covers different WCAG criteria.

Keyboard Testing

Keyboard testing verifies that all functionality is available without a mouse. This is the most important manual test and the easiest to perform.

Step-by-step keyboard test:

1. Unplug your mouse or use a laptop without a touchpad
2. Press Tab to navigate forward through the page
3. Use Shift+Tab to navigate backward
4. Use Enter and Space to activate elements
5. Use Arrow keys for widgets (tabs, menus, sliders)
6. Use Escape to close modals and dropdowns
7. Check that focus never disappears or gets trapped

What to check:

• All interactive elements are reachable by Tab
• Focus order follows visual order
• Focus indicators are visible at all times
• No keyboard traps exist
• Skip link is available and works
• Custom widgets respond to arrow keys

Code Example: Keyboard Test Script

// Automated keyboard test helper
const keyboardTest = {
    async run(page) {
        const issues = [];

        // Check all focusable elements
        const focusableElements = await page.$$(
            'a[href], button, input, select, textarea, [tabindex]:not([tabindex="-1"])'
        );

        // Test tab order
        for (let i = 0; i < focusableElements.length; i++) {
            await page.keyboard.press('Tab');
            const focused = await page.evaluate(() => {
                const el = document.activeElement;
                return {
                    tag: el.tagName,
                    text: el.textContent?.trim().slice(0, 50),
                    ariaLabel: el.getAttribute('aria-label'),
                    hasFocusStyle: window.getComputedStyle(el).outline !== 'none'
                };
            });

            if (!focused.hasFocusStyle) {
                issues.push({
                    type: 'missing-focus',
                    element: focused,
                    recommendation: 'Add visible focus indicator'
                });
            }
        }

        return issues;
    }
};

// Usage
const issues = await keyboardTest.run(page);
console.log(`Found ${issues.length} keyboard issues`);

Expected output: The test navigates through every focusable element and reports any that lack visible focus indicators or cause focus loss.

Screen Reader Testing

Screen reader testing reveals how assistive technology users experience your site. This is the most valuable manual test.

NVDA test script:

1. Start NVDA and open your page
2. Press Insert+F7 to open the elements list
3. Check links, headings, and landmarks lists make sense
4. Press H to navigate by headings — does the heading hierarchy make sense?
5. Press D to navigate by landmarks — are landmarks labeled?
6. Press K to navigate by links — does each link make sense out of context?
7. Tab through form controls — does each announce its label?
8. Interact with custom widgets — do they announce states correctly?

Code Example: Screen Reader Test Checklist

<h1>Screen Reader Test Results</h1>

<h2>Test Environment</h2>
<ul>
    <li>Screen Reader: <strong>NVDA 2024.1</strong></li>
    <li>Browser: <strong>Firefox 128</strong></li>
    <li>Page: <strong>Product Detail Page</strong></li>
    <li>Tester: <strong>Jane Smith</strong></li>
    <li>Date: <strong>2026-06-28</strong></li>
</ul>

<h2>Test Results</h2>

<h3>1. Page Structure</h3>
<table>
    <tr>
        <th>Test</th>
        <th>Result</th>
        <th>Notes</th>
    </tr>
    <tr>
        <td>Page title announced correctly</td>
        <td>Pass</td>
        <td></td>
    </tr>
    <tr>
        <td>Language announced correctly</td>
        <td>Pass</td>
        <td></td>
    </tr>
    <tr>
        <td>Landmarks identified (H + D)</td>
        <td>Pass</td>
        <td>Main, Navigation, Contentinfo</td>
    </tr>
    <tr>
        <td>Heading hierarchy logical</td>
        <td>Fail</td>
        <td>h1 > h4 skip. Missing h2, h3</td>
    </tr>
</table>

<h3>2. Navigation</h3>
<table>
    <tr>
        <th>Test</th>
        <th>Result</th>
        <th>Notes</th>
    </tr>
    <tr>
        <td>All links have descriptive text</td>
        <td>Pass</td>
        <td></td>
    </tr>
    <tr>
        <td>Current page indicated in nav</td>
        <td>Fail</td>
        <td>No aria-current on Products link</td>
    </tr>
    <tr>
        <td>Dropdown menu works with Arrow keys</td>
        <td>Pass</td>
        <td></td>
    </tr>
</table>

Expected output: A structured test results document that tracks which tests pass or fail, with specific notes for remediation.

Visual Inspection

Visual inspection catches issues that affect users with low vision, color blindness, or cognitive disabilities.

What to check visually:

• Color contrast ratios (use a contrast checker)
• Information conveyed by color (add icons or text)
• Focus indicators visible in all states
• Text readability at 200 percent zoom
• No horizontal scrolling at zoom
• Touch targets adequately sized
• Motion sensitivity considerations

Common Mistakes

1. Testing only with automated tools — Automated tools miss 50-70 percent of issues. Manual testing is not optional.
2. Testing only one screen reader — Different screen readers behave differently. Test with NVDA (Windows) and VoiceOver (Mac) at minimum.
3. Not testing dynamic content — Content that appears after user interaction (modals, dropdowns, error messages) needs special attention.
4. Testing in ideal conditions — Test with different lighting, different font sizes, and different zoom levels.
5. Not documenting test results — Without documentation, you cannot track progress, prove compliance, or reproduce findings.
6. Relying on developers for all testing — Developers have blind spots. Involve QA, designers, and ideally users with disabilities.
7. Testing only once — Accessibility degrades over time. Test regularly and after every significant change.

Practice Questions

1. What percentage of accessibility issues do manual testing methods typically find that automated tools miss? 50-70 percent.
2. What is the first manual test every developer should perform? Keyboard navigation — unplug the mouse and navigate using only Tab, Enter, Space, and Arrow keys.
3. Why is it important to test with multiple screen readers? Different screen readers (NVDA, VoiceOver, JAWS) behave differently and may expose issues others miss.
4. What should you check during a visual inspection for accessibility? Color contrast, information conveyed by color only, focus indicators, text readability at zoom, touch target sizes, and motion sensitivity.
5. Challenge: Perform a complete manual accessibility audit on a website of your choice. Test with keyboard navigation (document the full tab order), a screen reader (test 3 user journeys), visual inspection (check contrast, zoom, focus), and zoom testing (200 percent). Produce a report with at least 10 findings, including severity ratings, WCAG criterion references, and recommended fixes.

FAQ

Mini Project

Create a complete manual accessibility testing toolkit. Design: a keyboard test script (automated helper that walks through all focusable elements), a screen reader test plan (with specific commands and expected announcements for 3 user journeys: browse products, add to cart, checkout), a visual inspection checklist (15+ items covering contrast, zoom, focus, motion), a test results template (with sections for each WCAG principle), and a severity rating guide (critical, serious, moderate, minor). Use the toolkit to audit a sample e-commerce site and produce a full report with at least 15 findings across all test categories.

What's Next

Continue with Lesson 28: Understanding the Accessibility Tree to understand how browsers expose content to assistive technologies.