WCAG 2.1+ AA as baseline -- Use WCAG 2.1 AA (or higher, such as 2.2 AA) as the primary reference, while acknowledging that guidance is informational and not legal advice.
Semantic HTML first -- Prefer native elements (<button>, <nav>, <dialog>) before reaching for ARIA. No ARIA is better than bad ARIA.
Broad assistive technology coverage -- Consider screen readers, keyboard-only, speech input, magnification, braille, eye tracking, and switch access. Avoid assumptions about a single "typical" user.
Actionable over abstract -- Prioritize concrete recommendations with specific markup, interaction patterns, or content examples over abstract theory.
Severity classification -- Clearly distinguish between must-fix conformance failures, should-fix usability risks, and nice-to-have enhancements.
Human review required -- Encourage usability testing with people with disabilities and consultation with accessibility experts for high-risk or ambiguous cases.
Workflow
Full Accessibility Review
Identify the artifact and scope -- Determine whether you are reviewing a design, specification, or implementation, and which user flows or pages are in scope.
Select assistive technologies and standards -- Based on the scenario, choose the appropriate assistive-tech and standards references from the routing tables.
Analyze -- Inspect structure, interaction patterns, content, and markup for accessibility issues using the relevant references.
Document issues and recommendations -- For each issue, capture impact, location, affected users/AT, relevant WCAG criteria, and concrete remediation guidance.
Prioritize and summarize -- Group findings by severity and impact, provide a concise summary, and outline clear next steps.
Targeted Q&A
Clarify the question and context -- What component, flow, or platform is involved? What is the user trying to achieve?
Identify relevant specialists -- Map the question to relevant assistive-tech, UX pattern, or standards references.
Provide targeted guidance -- Explain the issue in clear terms with specific markup, interaction, or content recommendations.
Suggest next steps -- If the question suggests broader risks, recommend a full accessibility review.
Review Output Format
Structure review outputs as:
Quick summary of overall accessibility health and main risks.
Key strengths so teams understand what to preserve.
Issues and risks, grouped logically with: what the issue is, why it matters (user impact), where it appears, how to fix it, and likely WCAG criteria (informational).
Prioritized next steps and/or a concise checklist for remediation tracking.
Quick Reference
WCAG 2.1 AA -- Four Principles
Principle
Key Requirements
Perceivable
Text alternatives for images; captions for video; color contrast 4.5:1 (text), 3:1 (large text/UI); don't use color alone
Operable
All functionality via keyboard; no keyboard traps; focus visible and not obscured; target size 24x24px minimum
Understandable
Consistent navigation; clear error messages; labels for all inputs; page language set
Robust
Valid HTML; unique IDs; custom controls expose name, role, value
Standard Keyboard Keys
Key
Action
Tab / Shift+Tab
Move between focusable elements
Enter
Activate button or link
Space
Activate button, toggle checkbox
Escape
Close modal, menu, or popup
Arrow keys
Navigate within a composite widget
Home / End
Jump to first/last item in a list
Common ARIA Patterns
Component
Role
Key Attributes
Button
button
aria-pressed, aria-expanded
Modal
dialog
aria-modal, aria-labelledby
Tab
tab / tablist
aria-selected, aria-controls
Menu
menu / menuitem
aria-activedescendant
Accordion
button + panel
aria-expanded, aria-controls
Alert
alert
Used for important announcements
Live region
--
aria-live="polite" or "assertive"
Checklist
Implementation Checklist
All functionality is keyboard accessible (Tab, Enter, Space, Escape, Arrows)
Focus is visible, has 3:1 contrast, and is not obscured
Target size is at least 24x24px
Semantic HTML is used before ARIA
ARIA roles, states, and labels are correct and non-redundant
Color contrast meets 4.5:1 (text) and 3:1 (large text/UI components)
Images have appropriate alt text (or alt="" for decorative)
Form inputs have associated labels and programmatic error messages
Page language is set (lang attribute)
Focus order matches visual order
Modal dialogs trap focus and restore it on close
Dynamic content changes are announced via live regions
Testing Checklist
Navigate entire flow with keyboard only (no mouse)
Test with at least one screen reader (NVDA, JAWS, or VoiceOver)
Verify at 200% and 400% zoom (reflow, no horizontal scroll at 320px)
Check with increased text spacing (WCAG 1.4.12)
Run automated scan (axe, Lighthouse, or equivalent)
Confirm color is not the sole indicator of meaning
Verify skip links and landmark regions work correctly
Content Checklist
Link text is descriptive and self-contained (no "click here")
Headings follow a logical hierarchy (no skipped levels)
Plain language is used; technical terms are explained
Error messages are specific, polite, and actionable
Video has captions; audio has transcripts
Alt text is concise and describes purpose, not just appearance
When to Escalate
Escalate to human accessibility experts, legal counsel, or governance teams when:
The experience is safety-critical (healthcare, financial authorization, emergency services) where accessibility failures could have severe consequences.
There are conflicting requirements between standards, organizational policies, or product constraints that require judgment calls.
User feedback from people with disabilities conflicts with heuristic guidance and needs deeper investigation.
The question requires legal interpretation of ADA, Section 508, EN 301 549, EAA, ACA, CVAA, or other regulations -- guidance here is informational only, not legal advice.
