Accessibility Testing Questions

Approach overview
I add automated accessibility checks to component-level and E2E pipelines so issues are caught early: run axe-core/pa11y in unit/component tests and Lighthouse/pa11y/axe CLI in CI-driven integration tests.

Tools & where to run

• axe-core: integrate with Jest + @axe-core/react or @axe-core/dom for component/unit tests.
• pa11y: lightweight CLI for single pages or storybook snapshots.
• Lighthouse (CI): full-page audits for performance + accessibility on staging.
• axe-playwright / axe-webdriverjs: for E2E checks in Playwright/WebDriver.

Example (npm script + CI)

# package.json scripts
"test:a11y:jest": "jest --config=jest.a11y.config.js",
"test:a11y:pa11y": "pa11y http://localhost:6006 --reporter json > pa11y-report.json"

CI integration & surfacing failures

• Run a11y jobs after build and before deploy; publish reports (HTML/JSON) as artifacts.
• Fail job when rules exceed thresholds (see below) and post summary to PR via GitHub Actions annotations or checks API.
• Attach detailed report and story/component URL for faster debugging.

Thresholds / when to break the build

• Fail build on any "critical" or "serious" WCAG violations (color contrast, missing role/aria-label on actionable controls, keyboard/focus issues).
• Allow a small, tracked number of "minor" issues (e.g., <=2) with a TODO ticket; escalate if growing trend.
• Maintain an exceptions JSON (with justification, owner, expiry) to avoid noisy blockers.

Triage: automated findings vs manual review

• Automated-first: treat axe/pa11y failures as reproducible signals. Triage steps:
  1. Reproduce locally with failing component/story.
  2. Classify by severity and WCAG guideline.
  3. Quick fixable (missing alt/aria/labels/semantic tags) → dev PR.
  4. Design/UX decisions (semantic vs visual) → route to product/design with examples and suggested fixes.
  5. Flaky/false-positive (complex widgets) → add test refinement or write a focused manual test and mark automation exclusion with justification.
• Use checklist for manual verification: keyboard navigation, screen reader (NVDA/VoiceOver) smoke checks, and context-specific scenarios.

Best practices

• Run lightweight checks fast in pull requests; full audits in nightly/staging.
• Keep rulesets versioned and regularly review exemptions.
• Surface failing snippets and suggested fixes in PR comments to reduce iteration time.

Accessibility Test Case Template — Regulatory / WCAG/ADA

• Test Case ID:
• Feature / Component:
• Accessibility Requirement (WCAG/ADA reference):
• Objective: (what must be true)
• Test Steps:
  1. ...
• Expected Result (objective pass/fail criteria):
• Actual Result:
• Evidence Collected:
  • Screenshots (with filenames & timestamps)
  • Screen reader output (copied text / audio transcript)
  • DOM snapshot / HTML snippet
• Impact / Severity:
• Priority (Fix timeline):
• Remediation Notes (developer guidance):
• Retest Criteria:
• Reporter / Date:

Filled Example — "Search input label" failure

• Test Case ID: A11Y-INPUT-001
• Feature / Component: Site header — Search input
• Accessibility Requirement: WCAG 2.1 AA 1.3.1 Info and Relationships; 4.1.2 Name, Role, Value
• Objective: Search input must have an accessible name/label programmatically associated so assistive tech announces it.
• Test Steps:
  1. Open homepage in Chrome.
  2. Enable NVDA/VoiceOver and tab to search input.
  3. Inspect DOM for <label for="..."> or aria-label / aria-labelledby.
• Expected Result: Screen reader announces "Search" (or equivalent); DOM contains label association.
• Actual Result: Screen reader announces "edit" with no label; input has placeholder="Search" but no label or aria attribute.
• Evidence Collected:
  • Screenshot: homepage_search_input_missing_label_2026-03-03.png
  • Screen reader transcript: "Edit" (NVDA 2021.1) — attached text file
  • DOM snippet:
    html

    <input type="search" id="site-search" placeholder="Search">
    

• Impact / Severity: High — prevents users relying on assistive tech from understanding purpose.
• Priority: P0 (Fix in next sprint / release blocker for public-facing search)
• Remediation Notes:
  • Preferred fix: Add a visible <label for="site-search">Search</label> or include aria-label="Search" if visual design prohibits visible label.
  • If using aria-label, ensure text matches visible copy and is localized.
  • After fix, run automated Axe check and manual screen reader verification.
• Retest Criteria: Screen reader reads "Search" when focusing input; automated scan returns no label/name violations for this element.
• Reporter / Date: QA Eng. Name / 2026-03-03

Overview / Approach
As a QA Engineer I’d implement a hybrid strategy: continuous automated checks for regressions + focused manual audits and assistive-technology testing to validate WCAG 2.1 AA semantics, keyboard/ARIA, and real-world usability.

Automated tooling

• Integrate axe-core, pa11y, or Google Lighthouse into CI for pull-request gating.
• Run nightly scans with Siteimprove or Tenon for broader site coverage.
• Output: actionable violation reports mapped to components and story IDs.

Manual audit checklist

• Per page/component: semantic headings, color contrast, form labels, error identification, focus order, ARIA usage, skip links, time limits, captions/transcripts.
• Use checkboxes and reference WCAG success criteria IDs.

Screen reader testing

• Test primary flows with NVDA+Firefox and VoiceOver+Safari for iOS; JAWS spot-check for Windows.
• Test: page load announcements, form entry, dynamic ARIA live regions, modal behavior, and link/button labels.
• Record scripts and sample recordings for reproducibility.

Keyboard navigation

• Verify full functionality using Tab/Shift+Tab, Enter/Space, Arrow keys; ensure visible focus, logical tab order, and no keyboard traps.
• Include tests for modal dialogs, composite widgets, menus, and custom controls.

Stakeholder roles

• QA (owner): test plans, audits, triage.
• Dev: fixes, unit/ARIA updates.
• Product/UX: acceptance criteria and prioritization.
• Accessibility SME: complex ARIA patterns and training.
• Release manager: gating releases until critical violations fixed.

Remediation workflow & acceptance

• Triage severity (Critical/High/Medium/Low) mapped to WCAG impact.
• Create defects with steps, failure criteria, axe dump, screenshots, screen-reader clip.
• Acceptance criteria for fix:
  • Automated scan shows zero regressions for that rule.
  • Manual checklist items marked PASS.
  • Screen reader recording demonstrates correct behavior.
  • PO/Accessibility SME sign-off.
• Re-test in CI and close ticket when all criteria met.

This strategy balances automation for scale with manual and AT validation for real-world compliance.