Skip to main content

Welcome to our new website! The content and organization have been heavily redone and we want to hear from you! 
Submit feedback

Web & App Accessibility

Deliver WCAG 2.2 AA experiences for Arizona Sites, applications, and digital services.

Title II compliance milestone: April 24, 2026

Owner: Arizona Digital · Last reviewed: 2026-01-05 · Next review: 2026-04-05

What this page helps you do

  • Plan and build Arizona sites and applications that meet WCAG 2.2 AA and Title II expectations.
  • Choose the right Quickstart components, patterns, and testing tools for your stack.
  • Know when to escalate issues, request exceptions, or coordinate with Procurement and Accessibility PMO.

Executive summary

All UA digital properties, including mobile apps, must meet WCAG 2.2 AA. Align your roadmap with the Title II deadlines, implement Quickstart components as designed, and document any fundamental alteration claims with alternative access plans.

  • Reference the Title II brief for scope, dates, and expectations.
  • Use Quickstart’s accessible components and shared snippets (`skip-link-snippet`, `focus-management`, `web-keyboard`).
  • Integrate automated and manual testing (axe, Accessibility Insights, JAWS/NVDA/VoiceOver/TalkBack).
  • Engage Procurement early when selecting third-party widgets or SaaS platforms.

If you only do one thing: run a keyboard-only walkthrough of your next feature before it ships.

Quick wins (5–10 minutes)

  • Navigation & focus: Add a visible skip link, ensure Tab/Shift+Tab follow a logical order, and verify focus is always visible.
  • Forms: Check that every input has a programmatic label, error messages are announced, and inline help is not color-only.
  • Links & buttons: Replace vague text like “click here” with descriptive labels, and make sure interactive elements have a clear role and name.
  • Color & motion: Use UA design tokens or Quickstart palettes for contrast, and respect prefers-reduced-motion for animations.

Minimum, better, best for web & apps

  • Minimum: Public-facing sites and applications avoid blocking barriers (keyboard traps, missing alt text on key images, inaccessible menus, uncaptioned required media).
  • Better: Teams adopt Quickstart components and patterns, run automated and basic manual tests before releases, and address findings within planned sprints.
  • Best: Accessibility requirements are part of definition of done, CI enforces checks, design and code reviews include disabled user feedback, and exception processes are documented and rare.

Quickstart & component patterns

Developer deep-dives

WCAG 2.2 AA checklist

PrincipleCriteria highlightsUA implementation
PerceivableText alternatives, captions, contrast, reflow, dragging movements (2.5.7/2.5.8).Use shared media guidance, color tokens, and responsive layouts with rem units.
OperableKeyboard, pointer gestures, focus visible, target size, bypass blocks.Adopt skip link snippet, roving tabindex, `min-height` hit areas ≥ 44px.
UnderstandableConsistent navigation, error identification, input assistance.Link to `shared/do-dont.md` patterns, add summary boxes, keep nav order static.
RobustNames/roles/states, status messages, accessible APIs.Use native HTML whenever possible; test with multiple screen readers.

Download the full checklist or import into your team’s issue tracker.

Download checklist

Testing toolkit

  • Automated: axe DevTools, Accessibility Insights CLI, Storybook a11y add-on.
  • Manual keyboard: Tab/Shift+Tab/Enter/Space/Escape flows per `web-keyboard` guidance.
  • Screen readers: JAWS, NVDA, VoiceOver, TalkBack; include Fusion/ZoomText for magnification.
  • Contrast & visuals: TPGi CCA, UA design tokens, prefers-reduced-motion QA.
  • Reference material: WebAIM checklists and Deque axe DevTools guides.

See Testing Toolkit for scripts, logging templates, and CI recipes.

Mobile apps

Title II now explicitly covers mobile apps. Follow the mobile roadmap to inventory apps, schedule audits, and remediate issues.

Exception & equivalency process

  1. Document why meeting a criterion would be a fundamental alteration or undue burden.
  2. Outline the alternative access plan (who to contact, what formats, response times).
  3. Route request through Accessibility PMO, Legal, and Executive Sponsor for approval.
  4. Review annually and retire once resolved.

Use the consultation form to start an exception review and store decisions in the governance log.

Training & community

  • Arizona Digital developer guild (bi-weekly).
  • WCAG 2.2 code labs (monthly).
  • Mobile accessibility deep dives (quarterly).

Need help? Request a consultation.

Request consultation