Manual Accessibility Testing Guide

This guide provides practical procedures for manual accessibility testing. While automated testing catches many issues, manual testing with real assistive technologies and keyboard-only interaction is essential for validating user experience.

1. Core Principle

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

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

2. When Manual Testing Is Required

Manual testing should be performed:

• Before each release - Test critical user flows
• After UI changes - Test affected components and interactions
• For new features - Test complete user workflows
• When automated tests pass - Validate actual user experience
• When accessibility bugs are reported - Reproduce and verify fixes

3. Getting Started with Manual Testing

3.1 Required Setup

Screen Readers (choose based on your platform):

• Windows: NVDA (free, open source)
• Windows: JAWS (commercial, free demo)
• macOS: VoiceOver (built-in, Cmd+F5 to toggle)
• iOS: VoiceOver (built-in, Settings → Accessibility)
• Android: TalkBack (built-in, Settings → Accessibility)

Recommended Browser Combinations:

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

3.2 Learning Resources

Screen Reader Tutorials:

• WebAIM: Testing with NVDA
• WebAIM: Using VoiceOver
• Deque: Screen Reader Keyboard Shortcuts

Start Simple:

1. Test with keyboard-only first (easier entry point)
2. Learn basic screen reader commands for your platform
3. Practice on familiar websites before testing your own
4. Focus on one component or flow at a time

4. Keyboard-Only Testing Procedures

4.1 Basic Keyboard Navigation Test

Goal: Verify all interactive elements are keyboard accessible.

Steps:

1. Start at top of page - Click in address bar, then press Tab
2. Tab through entire page - Press Tab repeatedly
3. 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)
4. Navigate backwards - Press Shift+Tab to reverse through elements
5. Check for keyboard traps - Can you Tab away from every element?

What to Document:

• Elements that don’t receive visible focus
• Illogical focus order (jumps around page)
• Elements that can’t be activated with keyboard
• Keyboard traps (can’t Tab away)

4.2 Interactive Component Testing

Forms:

• Tab reaches all form fields
• Labels are announced clearly
• Required fields are indicated
• Error messages appear and are announced
• Can submit form with Enter key
• Can cancel/reset if applicable

Buttons:

• Enter and Space both activate
• Visual feedback on activation
• Focus moves appropriately after activation

Links:

• Enter activates link
• Destination is clear from link text
• Skip links work (if present)

Dropdowns/Select Menus:

• Arrow keys navigate options
• Enter or Space opens menu (implementation dependent)
• Escape closes menu
• Selected value is announced

Modal Dialogs:

• Focus moves into modal when opened
• Focus is trapped within modal
• Escape key closes modal (unless critical)
• Focus returns to trigger element on close

Custom Widgets (tabs, accordions, carousels):

• Follow WAI-ARIA keyboard patterns
• Arrow keys work as documented
• Home/End keys work (if applicable)
• State changes are clear

4.3 Common Keyboard Shortcuts to Test

5. Screen Reader Testing Procedures

5.1 Basic Screen Reader Test

Goal: Verify content and interactions are announced clearly.

Steps:

1. Start screen reader:
   • NVDA: Ctrl+Alt+N
   • JAWS: (runs at Windows startup if installed)
   • VoiceOver (macOS): Cmd+F5
   • VoiceOver (iOS): Triple-click home button or side button
2. Navigate by headings:
   • NVDA/JAWS: Press H (next heading) or Shift+H (previous)
   • VoiceOver (macOS): Ctrl+Option+Cmd+H
   • Check: Do headings create logical outline?
3. Navigate by landmarks:
   • NVDA/JAWS: Press D (next landmark) or Shift+D (previous)
   • VoiceOver (macOS): Use rotor (Ctrl+Option+U, then arrows)
   • Check: Are regions (<nav>, <main>, <header>, etc.) identified?
4. Navigate by form controls:
   • NVDA/JAWS: Press F (next field) or Shift+F (previous)
   • Check: Are labels announced? Is purpose clear?
5. Read all content:
   • NVDA: Numpad+ or Ctrl (to stop)
   • JAWS: NumPad+ or Ctrl (to stop)
   • VoiceOver (macOS): Ctrl+Option+A
   • Check: Is content in logical order? Any missing or confusing announcements?

5.2 Component-Specific Screen Reader Tests

Images:

• Decorative images are ignored (empty alt or aria-hidden)
• Informative images have descriptive alt text
• Complex images have longer descriptions (aria-describedby, longdesc, or adjacent text)

Links:

• Link purpose is clear from announcement alone
• Link text is meaningful (not “click here”)
• External links or new windows are indicated

Buttons:

• Button label describes action
• State is announced (pressed/not pressed for toggles)
• Disabled state is announced (if applicable)

Form Fields:

• Label is announced before field type
• Required state is announced
• Instructions/hints are announced
• Error messages are announced
• Success messages are announced

Dynamic Content:

• New content is announced (via aria-live regions)
• Deleted content is communicated
• Loading states are announced
• Progress is communicated

Tables:

• Navigate by rows/cells (NVDA/JAWS: Ctrl+Alt+Arrow keys)
• Column headers are announced with each cell
• Row headers are announced (if applicable)
• Table purpose is clear (caption or aria-label)

Custom Widgets:

• Role is announced (e.g., “tab”, “menu”, “dialog”)
• State is announced (e.g., “selected”, “expanded”)
• Instructions are provided for complex widgets
• Keyboard shortcuts are documented

5.3 Screen Reader Announcement Checklist

For each interactive element, verify:

• Element type is announced (button, link, heading, etc.)
• Label/name is clear and descriptive
• Current value is announced (for form fields)
• State is announced (checked, selected, expanded, etc.)
• Instructions are provided for complex interactions
• Changes are announced (for dynamic updates)

6. Visual Accessibility Testing

6.1 Color Contrast Testing

Tools:

• WebAIM Contrast Checker
• Contrast Ratio by Lea Verou
• Browser DevTools (Chrome/Firefox/Edge have built-in checkers)

Requirements:

• Normal text (under 18pt or 14pt bold): 4.5:1 minimum
• Large text (18pt+ or 14pt+ bold): 3:1 minimum
• UI components and graphics: 3:1 minimum

Test:

1. Identify text color and background color
2. Check contrast ratio using tool
3. Test with different color modes (light/dark theme)
4. Test focus indicators (must be 3:1 against adjacent colors)

6.2 Zoom, Text Resize, and Reflow Testing

This section covers three related but distinct requirements. Conflating them produces incomplete testing.

These are two distinct success criteria with different tests. Do not conflate them: a page can pass one and fail the other, and horizontal scrolling at 200% zoom is not automatically a failure of either.

SC 1.4.4 Resize Text (Level AA)

Content must be resizable up to 200% without loss of content or functionality. This checks text enlargement specifically — it does not itself require eliminating horizontal scrolling.

Steps:

1. Set browser zoom to 200% (Ctrl/Cmd + +)
2. Verify all content is readable
3. Verify no content is cut off or overlapping
4. Verify functionality (menus, forms, controls) still works at 200%
5. Test responsive behavior at different zoom levels

SC 1.4.10 Reflow (Level AA)

Content must be presented without loss of information or functionality, and without requiring scrolling in two dimensions, at a viewport width equivalent to 320 CSS pixels for content that scrolls vertically (or a height equivalent to 256 CSS pixels for content that scrolls horizontally). A common way to test the 320-pixel-wide requirement on a desktop browser is a 1280 CSS-pixel-wide viewport at 400% zoom — the two are equivalent because zooming in by 4× on a 1280px viewport leaves 320 effective CSS pixels of width. This is a different test from the 200% zoom check above, and horizontal scrolling that appears only at 200% zoom is not by itself a Reflow failure.

Steps:

1. Set the viewport to 320 CSS pixels wide (or set browser zoom to 400% on a 1280px viewport)
2. Verify content does not require horizontal scrolling to read (for non-excepted content — see below)
3. Verify no content is cut off, overlapped, or hidden
4. Verify interactive elements remain operable (can be reached and activated)
5. Verify reading order, relationships, and operation are preserved without relying on the original visual layout

The exception, precisely: SC 1.4.10 exempts only the parts of content that require two-dimensional layout for their usage or meaning — not the page as a whole, and not “any page that happens to use a single column.” Normative examples include data tables, maps, diagrams, video players, games, presentations, and interfaces requiring a persistently visible toolbar.

This has consequences a reviewer must check:

• An excepted component does not exempt the rest of the page. The heading above a data table, the introductory paragraph, filters, search controls, and pagination around it must still reflow normally — only the component that genuinely needs two dimensions is excepted.
• Within an excepted component, individual sections may still need to reflow. A table’s overall grid may need two dimensions to convey row/column relationships, but that does not automatically exempt a single cell’s own text content.
• “Requires” is a meaning test, not a convenience test. A component that merely looks better in a wide fixed layout, without losing information or functionality if it reflowed, is not exempt.

Single column is a technique, not the requirement. SC 1.4.10 does not itself require a single-column layout. Its actual requirements are: no loss of information or functionality; no two-dimensional scrolling for non-excepted content; content readable without repeated horizontal panning; and preserved operation, relationships, and reading order. A single column is simply a common way projects satisfy those requirements — a multi-column layout that still meets them is not automatically a failure.

Page-level overflow as an indicator: A page that triggers horizontal scroll at 400% zoom (or the 320 CSS-pixel equivalent) is a high-value indicator that Reflow has not been achieved. Investigate whether the overflowing content falls within the exception described above before concluding a failure. Automated tools that detect overflow at 320px can flag candidates, but human judgment is needed to confirm the finding and evaluate exceptions. See Behavioral Accessibility Automation for a reusable, tested Playwright implementation and its documented limitations.

Related low-vision checks (test alongside Reflow):

• SC 1.4.4 Text Resize: Does text enlarge to 200% without loss?
• SC 1.4.12 Text Spacing: Can text spacing be adjusted without content loss? (line height to 1.5×, paragraph spacing to 2×, letter spacing to 0.12×, word spacing to 0.16×)
• SC 1.4.13 Content on Hover or Focus: Can hover/focus content be dismissed, persistent, and hoverable without overlapping?

Automated Reflow Indicator Checks

A reusable, tested Playwright module for Reflow risk detection — examples/playwright/reflow-risk.mjs — is documented in full in Behavioral Accessibility Automation. It sets a 320 CSS-pixel viewport, waits for layout to stabilize (fonts, images, and JavaScript), attempts a horizontal scroll following the method used by the CWAC ReflowAudit, measures overflow, works for right-to-left documents, and returns a structured result distinguishing no-overflow-detected, potential-reflow-barrier, and cant-tell (page did not stabilize).

This is an indicator test, not a Reflow conformance check. Human judgment is needed to:

• confirm any detected overflow is not within the SC 1.4.10 exception (see above)
• verify content is not cut off or overlapped
• verify interactive elements remain operable
• test actual content at 400% zoom, not only at the 320-pixel-equivalent width

Screen Magnification

For users who employ screen magnification software:

• Windows: Magnifier (Windows + +)
• macOS: Zoom (System Preferences → Accessibility → Zoom)
• Check: Can users pan around page? Are labels close to fields? Is focus tracked when magnified?

6.3 Focus Indicator Testing

Focus indicator testing involves three distinct WCAG success criteria with different requirements and levels.

SC 2.4.7 Focus Visible (Level AA)

Any keyboard-focusable element must have a visible focus indicator. This is a binary check: either a visible indicator exists or it does not.

Verify for each focusable element:

• Focus indicator is visible (outline, border, or background change)
• Focus indicator is not removed unless replaced with a superior alternative
• Focus indicator is not obscured by other content

SC 1.4.11 Non-text Contrast (Level AA)

Focus indicators on UI components must have a contrast ratio of at least 3:1 against adjacent colors. This applies to the focus indicator itself, not to the component’s normal state.

Verify for each focusable element:

• Focus indicator contrast meets 3:1 against adjacent colors
• The 3:1 ratio is measured against the focus indicator color and the adjacent background or component color
• Custom focus styles meet the contrast requirement (not just the default outline)

SC 2.4.13 Focus Appearance (Level AAA)

This AAA criterion is stricter than SC 2.4.7. It requires:

• a minimum area equal to the perimeter of the focusable element multiplied by 2 CSS pixels
• a contrast ratio of at least 3:1 between focused and unfocused states
• the focus indicator must not be fully obscured by author-created content

Focus Appearance is a Level AAA criterion. Projects targeting AA conformance are not required to meet it, but meeting it provides stronger accessibility. Document whether your project targets this criterion.

Behavioral Screenshot-Difference Testing

The CWAC (Centralised Web Accessibility Checker) project, developed by the Web Standards team at Te Pūnaha Matihiko, New Zealand Government, uses a screenshot-difference approach in its FocusIndicatorAudit:

1. Sends actual Tab key presses.
2. Takes an initial reference screenshot of the whole page.
3. Takes a screenshot after each subsequent Tab press.
4. Compares pixel values between the reference and each screenshot.
5. Reports a finding when no captured pixels changed following a Tab press.

CWAC’s FocusIndicatorAudit does not:

• measure focus-indicator contrast (SC 1.4.11) — it has no contrast computation, only a pixel-equality check;
• prove that a detected visual change is local to the focused element — its comparison is whole-page, so any page-wide change can satisfy its “something changed” test;
• determine that a detected indicator is sufficiently perceptible — it only reports whether any pixels differed, not by how much or where;
• distinguish a genuinely missing indicator from one that is completely obscured by other content — both can register the same way;
• guarantee that unrelated animation elsewhere on the page did not cause the detected change (CWAC mitigates this with a separate animation-settling wait before testing, but the focus-comparison step itself remains whole-page);
• compare a distinct focused and unfocused reference image for every individual element — it uses one initial whole-page reference and compares each subsequent Tab-stop screenshot against that same reference.

This repository’s own reusable implementation, examples/playwright/focus-visible-risk.mjs, is an independent reimplementation of the documented method (see Behavioral Accessibility Automation for the full attribution and license statement), and deliberately departs from the whole-page-reference approach: it captures a fresh unfocused/focused screenshot pair for each Tab stop, scoped to a padded region around that element’s own bounding box. This closes some of the limitations above (a page-wide animation cannot masquerade as that element’s indicator) while introducing its own documented tradeoffs (an indicator rendered well outside the padded region can be missed). See Behavioral Accessibility Automation for the full detail, including which findings are conclusive versus indicators.

Neither implementation, nor any screenshot-diff approach alone, verifies that a focus indicator meets SC 1.4.11 (contrast) or SC 2.4.13 (minimum area, AAA). Use screenshot-difference testing as a supplementary check alongside manual verification, not as a sole focus indicator test.

6.4 Forced Colors Mode Testing

Why automated tools miss this:

Forced colors mode is triggered by an OS-level accessibility setting that replaces all author-defined colors with a constrained system palette. Automated tools cannot reliably test for it because:

• They don’t simulate the OS color override that happens outside the browser
• They can’t detect which elements become invisible when custom colors are stripped
• They cannot assess whether focus indicators, icons, or custom controls survive the color substitution

What forced colors mode is:

When a user enables a high contrast theme in Windows (or a similar OS contrast setting), the browser activates the forced-colors: active CSS media query. The browser overrides color, background-color, border-color, fill, stroke, and related properties with a small set of CSS system color keywords. This allows people who require very high contrast or specific color combinations to use the web comfortably.

The relevant WCAG success criteria are:

• 1.4.1 Use of Color (Level A) — information must not be conveyed by color alone
• 1.4.11 Non-text Contrast (Level AA) — UI components and focus indicators must retain sufficient contrast
• 1.4.3 Contrast (Minimum) (Level AA) — text contrast requirements still apply through system colors

How to enable or emulate forced colors mode:

Real OS settings (most accurate — always verify with these before release):

• Windows 11: Settings → Accessibility → Contrast themes → choose a theme (e.g., “Aquatic”, “Desert”, “Dusk”, or “Night sky”) → Apply
• Windows 10: Settings → Ease of Access → High Contrast → turn on “Turn on high contrast”
• Use Alt + Left Shift + Print Screen as a keyboard shortcut to toggle High Contrast on Windows

Browser DevTools emulation (convenient during development):

• Chrome / Edge DevTools: Open DevTools (F12) → More Tools (⋮) menu → Rendering → scroll to “Emulate CSS media feature forced-colors” → select active
• Firefox: Navigate to about:config → search ui.forcedColors → set the integer value to 1 (set back to -1 to reset)

Dedicated browser tool:

• Polypane includes a forced colors emulation panel in its accessibility toolset

What to look for during testing:

Test these elements while forced colors mode is active:

Text and backgrounds:

• All text is still readable against its background
• Body text (CanvasText) contrasts clearly against the page background (Canvas)

Interactive controls:

• Buttons have a visible boundary (system ButtonBorder color provides an outline)
• Links are distinguishable from surrounding body text
• Form fields (inputs, textareas, selects) have visible borders

Focus indicators:

• Keyboard focus outlines are still visible (outline is preserved; box-shadow may not be)
• No custom focus styles have silently disappeared

Icons and images:

• SVG icons remain visible (icons using fill: none or a hardcoded fill color may vanish — use currentColor)
• Background images that convey meaning are still perceivable, or a text/ARIA alternative is present

Custom controls:

• CSS-only custom checkboxes and radio buttons are still visible and distinguishable
• Toggle buttons show their current state through text, ARIA attributes, or an outline — not color alone

Information not relying on color:

• Error states are identifiable without relying on red vs. green
• Required fields are marked with text or icons, not only color
• Charts or data visualizations use pattern/texture/label alternatives

Common issues and fixes:

Patching broken elements:

Use these CSS system color keywords inside @media (forced-colors: active) to restore visibility without overriding the user’s theme:

Example:

/* Restore a custom focus ring that uses box-shadow */
@media (forced-colors: active) {
  :focus-visible {
    outline: 3px solid Highlight;
    outline-offset: 2px;
  }
}

/* Restore a CSS-only checkbox that disappears */
@media (forced-colors: active) {
  .custom-checkbox::before {
    forced-color-adjust: none;
    border: 2px solid ButtonBorder;
    background-color: ButtonFace;
  }

  .custom-checkbox[aria-checked="true"]::before {
    background-color: Highlight;
  }
}

Use forced-color-adjust: none only as a last resort when a component is genuinely impossible to adapt with system colors — it opts the element out of forced colors entirely and can negate the user’s accessibility settings.

Further reading:

• MDN: forced-colors media feature
• MDN: forced-color-adjust property
• Chrome DevTools: Emulate CSS media features
• Smashing Magazine: Windows High Contrast Colors Mode & CSS Custom Properties
• Adrian Roselli: WHCM and System Colors

7. Testing Workflows by Component Type

7.1 Forms

Complete workflow test:

1. Navigate to form with keyboard only
2. Fill out all fields (test Tab order)
3. Trigger validation errors (leave required field empty, invalid format)
4. Verify error messages appear and are announced
5. Correct errors and revalidate
6. Submit form with Enter or Space on submit button
7. Verify success message appears and is announced

Screen reader additions:

1. Navigate form by fields (F key in NVDA/JAWS)
2. Verify labels and instructions are announced
3. Verify field types are clear (email, phone, etc.)
4. Verify error messages are in logical reading order

7.2 Modal Dialogs

Complete workflow test:

1. Activate trigger element (button/link that opens modal)
2. Verify focus moves into modal
3. Tab through all elements in modal
4. Verify Tab doesn’t leave modal (focus trap)
5. Press Escape to close (or close button)
6. Verify focus returns to trigger element

Screen reader additions:

1. Verify modal is announced (role=”dialog”, aria-labelledby for title)
2. Verify modal content is in logical reading order
3. Verify closing action is clear

7.3 Single Page Applications (SPAs)

Page navigation test:

1. Click navigation link
2. Verify page content changes
3. Verify focus management (moved to main heading or main content)
4. Verify page title changes
5. Verify route change is announced (or focus provides context)

Screen reader additions:

1. Verify new page structure is clear (landmarks, headings)
2. Verify back button works and announces changes
3. Test with aria-live announcements for route changes (if implemented)

8. Documenting Test Results

8.1 What to Report

For each issue found:

Required Information:

• Component/page tested: URL or component name
• Issue description: What doesn’t work?
• Expected behavior: What should happen?
• Steps to reproduce: Numbered steps
• Assistive technology: Name and version (e.g., NVDA 2024.1, VoiceOver macOS Sonoma)
• Browser: Name and version (e.g., Firefox 133, Safari 18)
• Operating system: Name and version
• Severity: Critical, High, Medium, Low

Optional but Helpful:

• Screenshot or screen recording
• Error message or console output
• WCAG success criterion violated (if known)

8.2 Severity Classification

• Critical: Users cannot complete essential tasks (e.g., can’t submit form, can’t access main content)
• High: Major barrier but workaround exists (e.g., poor focus visibility, missing labels)
• Medium: Usability issue that causes confusion (e.g., unclear link text, missing skip link)
• Low: Minor issue or enhancement (e.g., helpful hint missing, suboptimal announcement)

8.3 Issue Template

## Accessibility Issue: [Brief Description]

**Component:** [URL or component name]

**Issue:** [Description of what doesn't work]

**Expected:** [What should happen]

**Severity:** [Critical/High/Medium/Low]

**Steps to Reproduce:**
1. [Step 1]
2. [Step 2]
3. [Step 3]

**Testing Environment:**
- **Screen Reader:** [Name and version]
- **Browser:** [Name and version]
- **OS:** [Operating system and version]

**WCAG Criterion:** [If applicable, e.g., 2.4.3 Focus Order]

**Suggested Fix:** [If you have one]

9. Encouraging Participation from People with Disabilities

9.1 Why This Matters

People with disabilities are the experts in identifying barriers and validating solutions. Their lived experience is essential for:

• Identifying issues automated tools miss
• Validating that fixes actually work
• Understanding real-world impact of design decisions
• Prioritizing issues by actual user impact

9.2 Creating Inclusive Testing Opportunities

Remove barriers to participation:

• Provide clear, jargon-free testing instructions
• Offer flexible timeframes for testing (not rush)
• Allow asynchronous feedback
• Provide compensation for testing time (if budget allows)
• Make issue reporting accessible (multiple formats, support)

Invite diverse testers:

• Screen reader users (blind and low vision)
• Keyboard-only users (motor disabilities)
• Voice control users (motor disabilities)
• Users with cognitive disabilities
• Users with multiple disabilities

Make testing guides accessible:

• Provide alternative formats (audio, large print, plain language)
• Test your testing documentation!
• Ensure issue templates are screen reader friendly

9.3 Acknowledging Contributions

• Credit testers in release notes (with permission)
• Highlight accessibility improvements driven by tester feedback
• Create opportunities for ongoing involvement
• Compensate testers fairly for their time and expertise

10. Quick Reference Checklists

10.1 30-Minute Keyboard-Only Test

• Tab from start to end of page
• Verify focus is visible on all elements
• Activate all buttons with Enter and Space
• Activate all links with Enter
• Fill and submit a form
• Open and close a modal/dialog (if present)
• Use any custom widgets (tabs, accordions, etc.)
• Navigate menu/navigation (if present)
• Check for keyboard traps

10.2 30-Minute Screen Reader Test

• Navigate by headings (H key)
• Navigate by landmarks (D key)
• Navigate by form fields (F key)
• Read full page content (continuous read)
• Activate buttons and links
• Fill and submit a form
• Test custom widget (menu, tabs, etc.)
• Verify images have alt text
• Verify dynamic content updates are announced

10.3 Visual Accessibility Quick Check

• Test at 200% browser zoom
• Check focus indicator visibility
• Check color contrast (sample text and UI components)
• Verify content is readable without color alone
• Test light and dark color modes (if applicable)
• Test in forced colors mode (see section 6.4)

11. Building a Manual Testing Culture

11.1 Make It a Habit

• Add manual testing to Definition of Done
• Include in code review checklist
• Schedule regular testing sessions (weekly/biweekly)
• Pair test with teammates
• Celebrate finding and fixing issues

11.2 Start Small

• Focus on one component or flow per session
• Learn one new screen reader command per week
• Build confidence with familiar patterns first
• Share learnings with team

11.3 Learn Together

• Host lunch-and-learn sessions
• Watch screen reader demos together
• Practice on popular websites first
• Invite guest speakers (users with disabilities)
• Share “aha moments” and discoveries

12. Resources and Further Learning

12.1 Testing Guides

• WebAIM: Screen Reader Testing
• W3C: Easy Checks - First Review
• A11Y Project: Checklist

12.2 Screen Reader Resources

• NVDA Training
• JAWS Training
• VoiceOver User Guide
• Deque: Screen Reader Keyboard Shortcuts

12.3 Community and Support

• WebAIM Discussion List
• A11y Slack Community
• Stack Overflow: Accessibility Tag

Machine-Readable Standards

For AI systems and automated tooling, see wai-yaml-ld for structured accessibility standards:

• WCAG 2.2 (YAML) - Machine-readable WCAG 2.2 normative content
• ARIA Informative (YAML) - ARIA patterns and testing procedures
• HTML Living Standard Accessibility (YAML) - HTML element testing requirements
• Accessibility Test Catalogs (YAML) - Structured testing rules and procedures

Related Documentation:

• Behavioral Accessibility Automation - Canonical guide to Reflow risk, Focus Visible, and other rendered-page behavioral checks, with reusable tested Playwright modules
• CONTRIBUTING.md - How to contribute, including testing expectations
• BROWSER_SUPPORT.md - Browser and AT support matrix
• KEYBOARD_ACCESSIBILITY_BEST_PRACTICES.md - Keyboard interaction patterns
• FORMS_ACCESSIBILITY_BEST_PRACTICES.md - Form accessibility requirements
• COLOR_CONTRAST_ACCESSIBILITY_BEST_PRACTICES.md - Contrast requirements and patterns
• LIGHT_DARK_MODE_ACCESSIBILITY_BEST_PRACTICES.md - Theme testing
• USER_PERSONALIZATION_ACCESSIBILITY_BEST_PRACTICES.md - User preferences and overrides

Last Updated: 2026-07-25