Manual Accessibility Testing Skill

Canonical source: examples/MANUAL_ACCESSIBILITY_TESTING_GUIDE.md in mgifford/ACCESSIBILITY.md This skill is derived from that file. When in doubt, the example is authoritative.

Apply these rules when planning or reviewing manual accessibility testing.

Severity Scale (this skill)

Core Principle

Manual testing reveals issues that automated tools cannot detect, including:

• Screen reader announcement quality and user experience
• Keyboard navigation flow and logical sequence
• Focus management in dynamic interfaces
• Forced colors mode (Windows High Contrast) — automated tools cannot simulate OS-level color overrides
• Real-world usability barriers

Critical: When Manual Testing Is Required

Perform manual testing:

• Before each release — test critical user flows end to end
• After UI changes — test all affected components
• For new features — test complete user workflows
• When automated tests pass — validate actual user experience
• When accessibility bugs are reported — reproduce and verify fixes

Critical: Keyboard-Only Testing

Every interactive element must be reachable and operable by keyboard alone.

Steps:

1. Click in the browser address bar, then press Tab to start from page top
2. Tab through entire page; check each focusable element:

• Is focus visible (clear outline or highlight)?
• Is focus order logical (follows visual/reading order)?
• Can you activate it? (Enter for links/buttons, Space for buttons/checkboxes)

1. Press Shift+Tab to reverse through elements
2. Confirm there are no keyboard traps

Key shortcuts to verify:

Component-specific checks:

• Forms: all fields reachable; labels announced; errors appear and are announced; Enter submits
• Modal dialogs: focus moves in on open; focus trapped inside; Escape closes; focus returns to trigger on close
• Custom widgets (tabs, accordions): follow WAI-ARIA keyboard patterns; arrow keys work as documented

Critical: Screen Reader Testing

Recommended platform pairings:

• NVDA + Firefox or Chrome (Windows)
• JAWS + Chrome or Firefox (Windows)
• VoiceOver + Safari (macOS / iOS)
• TalkBack + Chrome (Android)

Basic test procedure:

1. Start screen reader (NVDA: Ctrl+Alt+N; VoiceOver macOS: Cmd+F5)
2. Navigate by headings (NVDA/JAWS: H / Shift+H) — do they form a logical outline?
3. Navigate by landmarks (NVDA/JAWS: D / Shift+D) — are <nav>, <main>, <header> identified?
4. Navigate by form controls (NVDA/JAWS: F / Shift+F) — are labels announced?
5. Read all content — is order logical? Any missing or confusing announcements?

For each interactive element, verify:

• Element type is announced (button, link, heading…)
• Label/name is clear and descriptive
• Current value is announced (form fields)
• State is announced (checked, selected, expanded…)
• Changes are announced (dynamic updates, live regions)

Serious: Forced Colors Mode Testing

Why automated tools miss this: forced colors is triggered by an OS-level setting; browsers cannot simulate the full color override in a headless context.

How to enable:

• Windows 11: Settings → Accessibility → Contrast themes → choose a theme → Apply
• Windows 10: Settings → Ease of Access → High Contrast → turn on
• Chrome/Edge DevTools: F12 → More Tools → Rendering → "Emulate CSS media feature forced-colors" → active
• Firefox: about:config → ui.forcedColors → set to 1

What to look for:

• [ ] All text is readable against its background
• [ ] Buttons have a visible boundary
• [ ] Keyboard focus outlines are visible (outline is preserved; box-shadow may not be)
• [ ] SVG icons are visible (use currentColor for fill/stroke)
• [ ] Custom checkboxes / radio buttons remain visible and distinguishable
• [ ] Error states are identifiable without relying on color alone
• [ ] Background images that convey meaning have a text/ARIA alternative

Common fixes:

CSS system color keywords for patching:

@media (forced-colors: active) {
  :focus-visible {
    outline: 3px solid Highlight;
    outline-offset: 2px;
  }
}

Relevant keywords: Canvas, CanvasText, ButtonFace, ButtonText, ButtonBorder, Highlight, HighlightText, LinkText, GrayText.

Moderate: Visual Accessibility Checks

Color contrast

• Normal text (< 18 pt or < 14 pt bold): 4.5:1 minimum
• Large text (≥ 18 pt or ≥ 14 pt bold): 3:1 minimum
• UI components and graphics: 3:1 minimum
• Focus indicators: 3:1 against adjacent colors

Test with: WebAIM Contrast Checker, browser DevTools.

Zoom at 200 %

1. Set browser zoom to 200 % (Ctrl/Cmd + +)
2. Verify all content is readable and not cut off
3. Verify no horizontal scrolling on a standard 1280 px viewport

Focus indicator

• [ ] Focus indicator is visible for every focusable element
• [ ] Contrast meets 3:1 requirement against adjacent colors
• [ ] Focus indicator is not removed or replaced with something less visible

Definition of Done Checklist

• [ ] Keyboard-only test completed; all interactions reachable and operable
• [ ] No keyboard traps found
• [ ] Focus order is logical
• [ ] Screen reader test completed with at least one platform combination
• [ ] All images, icons, and charts have correct text alternatives
• [ ] Dynamic content changes are announced by screen reader
• [ ] Color contrast verified for text and UI components
• [ ] Forced colors mode tested for all custom UI components
• [ ] Zoom at 200 % tested; no content cut off or horizontally scrolling
• [ ] Findings documented with URL, element, WCAG SC, severity, and steps to reproduce

Key WCAG Criteria

• 1.1.1 Non-text Content (A)
• 1.3.1 Info and Relationships (A)
• 1.4.1 Use of Color (A)
• 1.4.3 Contrast Minimum (AA)
• 1.4.11 Non-text Contrast (AA)
• 2.1.1 Keyboard (A)
• 2.1.2 No Keyboard Trap (A)
• 2.4.3 Focus Order (A)
• 2.4.7 Focus Visible (AA)
• 2.4.11 Focus Appearance (AA — WCAG 2.2)
• 4.1.2 Name, Role, Value (A)
• 4.1.3 Status Messages (AA)

References

• Full guide
• WebAIM: Testing with NVDA
• WebAIM: Using VoiceOver
• Deque: Screen Reader Keyboard Shortcuts
• WAI-ARIA Authoring Practices Guide

Standards horizon: These rules target WCAG 2.2 AA. Monitor: <https://www.w3.org/TR/wcag-3.0/>