Engineering teams ship WCAG 2.2 AA-compliant Arizona Sites, apps, and integrations.
Goal: 0 critical WCAG defects per release
What this page helps you do
- Ship accessible web components and apps that meet WCAG 2.2 AA expectations.
- Build repeatable testing into CI and manual review workflows to prevent regressions.
- Document exceptions and evidence so reviewers can approve releases quickly.
Executive summary
Ship inclusive code by focusing on four pillars:
- Design-to-code parity: implement Quickstart patterns with semantic HTML and ARIA only when necessary.
- Predictable focus: ensure keyboard order, skip links, and roving tabindex follow focus guidance.
- Robust testing: combine CI automation with manual keyboard + JAWS/NVDA/VoiceOver/TalkBack passes before releasing.
- Documented exceptions: log fundamental alteration requests with remediation plans.
Use this page for the executive overview, then drill down into shared specs, WebAIM checklists, and Deque University labs linked below.
Top tasks
| Task | Steps | Primary Tools |
|---|---|---|
| Implement accessible components | Reference Quickstart patterns → include skip link/focus styles → document semantics. | Quickstart, Design System |
| Test releases | Run automated scans → manual keyboard review → screen-reader pass with JAWS/NVDA + VoiceOver/TalkBack. | axe, Accessibility Insights, NVDA, VoiceOver |
| Document exceptions | Assess risk → draft alternative access plan → route for approval. | Accessibility PMO workflow |
| Build CI/CD gates | Add linting + axe scripts → fail builds on critical defects → store evidence in release notes. | GitHub Actions, Playwright, Accessibility Insights CLI |
| Support mobile & embedded flows | Apply responsive breakpoints → retest in embedded browsers → sync with native app owners. | Quickstart responsive grid, WebView test harness |
Impactful principles & checks
Accessibility should feel predictable—not a burden—when you follow the same playbook every sprint. Anchor your work to WCAG 2.2 AA highlights and verify code with Accessibility Insights, WebAIM’s WAVE, DubBot (campus license), and Microsoft Accessibility Checker for any docs you attach to releases.
Cover SC 2.1.1, 2.4.3, 2.4.11, and 2.5.7 by keeping keyboard orders logical, ensuring focus indicators meet the 4px/3:1 requirements, and offering single-pointer alternatives to drag/drop.
- Test with keyboard only plus Accessibility Insights’ focus order view.
- Run WAVE or DubBot on staging URLs to confirm headings/landmarks remain intact after CMS edits.
Meet SC 1.3.1, 4.1.2, and 4.1.3 by using semantic HTML, exposing accessible names, and announcing async updates with `role="status"` or live regions.
- Keep DOM order synced with visual order; rely on Quickstart components before adding custom ARIA.
- Log Accessibility Insights issues directly to Azure Boards or Jira for traceability
When you ship docs or media alongside features, run Microsoft Accessibility Checker, follow WebAIM alt text guidance, and ensure PDFs are tagged per Adobe remediation steps.
- Confirm reading order and form field labels in Acrobat before attaching PDFs to releases.
- Ask writers to provide source files plus tagged exports so DubBot can crawl links without false positives.
- ✅ Focus appearance (2.4.11) meets thickness/contrast guidance.
- ✅ Drag actions offer single-pointer alternatives (2.5.7) and targets meet 24×24 px (2.5.8).
- ✅ Authentication and MFA support copy/paste and password managers (3.3.8).
- ✅ Error messages identify fields, include text guidance, and set `aria-invalid` (3.3.1/3.3.3).
- ✅ Live updates announce status (4.1.3) without forcing focus changes.
WebAIM’s annual Million report consistently shows six failures that account for 96% of detected issues. Bake these into code reviews and linters:
- Low contrast (SC 1.4.3/1.4.11): enforce token usage, run axe/Accessibility Insights contrast checks.
- Missing alternative text (SC 1.1.1): require `alt` or ARIA labels for informative media; mark decorative imagery as `alt=""`.
- Empty links/buttons (SC 2.4.4/4.1.2): ensure every interactive element has visible text and an accessible name.
- Missing form labels (SC 1.3.1): pair `` or `aria-labelledby`; include instruction text via `aria-describedby`.
- Missing document language (SC 3.1.1): set `lang` on every HTML root and ensure embedded documents inherit it.
- Link purpose (SC 2.4.4/2.4.9): write descriptive link text (“Review the procurement checklist”) instead of “click here.”
When opening links in a new window, inform users via inline text (e.g., “opens in new window”) and only do so when necessary (external policies, workflows). Source: WebAIM Million report
- Keyboard sweep every interactive element (Tab/Shift+Tab + Escape for dialogs) to confirm focus order and visibility.
- Run Accessibility Insights FastPass plus the Tab Stops overlay; save the report in your PR artifacts.
- Spot-check page templates with WebAIM WAVE and note any errors/warnings not covered by automated scans.
- Trigger your team’s DubBot crawl or add the URL to the next scheduled scan for regression tracking.
- Attach Microsoft Accessibility Checker or Adobe Acrobat reports for any documents or PDFs in the release.
These five steps align with the role guide's optional manual review checklist so every code drop ships with consistent evidence.
Implementation playbooks
Use these scenario playbooks to translate the checklist into working code.
Adopt the Quickstart nav component with built-in skip links, `aria-expanded`, and roving tabindex.
- Expose a single tab stop per composite widget; move focus internally with arrow keys.
- Mirror visual labels in `aria-label` / `aria-labelledby` attributes for voice control.
- Keep the DOM order aligned with visual order so reading order stays predictable.
Reference: Keyboard guidance, Skip link snippet.
Every form field needs a visible label, programmatic name, inline help, and error messaging.
- Use native `` pairs when possible; add `aria-describedby` for help/error text.
- Mark required fields with text and `aria-required="true"`; never rely on color alone.
- Send focus to the first invalid control on submit; provide summary errors for longer forms.
Reference: Do/Don’t patterns, WCAG checklist, WebAIM form techniques.
Ensure iframes, third-party widgets, and chart components provide names, controls, and fallbacks.
- Wrap embeds with titles and descriptions; ensure keyboard focus can enter/exit.
- Provide text alternatives for charts (data tables or summary lists).
- Lazy-load media without removing it from the accessibility tree.
Reference: Media playbook, Document & media hub.
When updating DOM regions, announce changes with `aria-live`, focus management, or status messages.
- For toasts/status, use `role="status"`; for errors, use `role="alert"` and keep messages concise.
- Trap focus inside modals and restore it after close; avoid off-screen focus jumps.
- Include skeleton loaders or progress indicators that expose name/role states.
Reference: Focus playbook, Testing toolkit.
Guidance
- Include skip links, keyboard support, and focus management for all interactive regions.
- Meet contrast via color guidance.
- Structure content with semantic headings and landmarks.
- Automated: axe/Accessibility Insights in CI + Storybook linting.
- Manual: keyboard-only navigation, focus traps, modals.
- Screen reader: JAWS or NVDA (Windows) and VoiceOver (macOS/iOS); include TalkBack for Android webviews.
Deep dive: Testing Toolkit, Keyboard patterns, Assistive technology coverage.
Submit fundamental alteration requests with business justification, impacted WCAG criteria, alternative access plan, and remediation timeline.
Accessibility Insights assessment guide
Follow this lightweight workflow each time you prep a release. It mirrors Microsoft’s Accessibility Insights help topics so new teammates can jump in quickly.
- Open the Edge/Chrome extension on the page under test.
- Select FastPass to capture automated checks + tab stops; export the report and attach it to your PR.
- Resolve failures immediately or log defects referencing the exact WCAG criteria surfaced in the report.
Docs: FastPass overview
- Switch to the Assessment view; walk through each requirement (structure, landmarks, focus order, gestures).
- Use built-in snippets (Tab stops, Landmarks, Headings) to capture evidence for reviewers.
- Mark steps as pass/fail/not applicable and sync results to Azure Boards/Jira.
Docs: Assessment overview
- Color picker + Contrast tools validate UA tokens on the fly.
- Tab stops overlay illustrates focus order; screenshot it for documentation.
- Issue filing pipeline pushes results straight to GitHub, Azure Boards, or export JSON for DubBot.
Docs: Ad hoc tools reference
- Upload FastPass/Assessment artifacts to the release folder so auditors can trace WCAG coverage.
- Link Accessibility Insights findings with WAVE/DubBot results for prioritized remediation.
- Share the one-page WCAG highlight sheet with stakeholders so they understand the “why.”
Tools & contacts
Deque University & axe
On-demand WCAG courses plus axe DevTools for CI/CD integration.
DubBot campus license
Schedule weekly crawls for Quickstart and vendor sites; export prioritized WCAG 2.2 findings.
CI/CD readiness
- Gate builds: Run axe or Accessibility Insights CLI in pull requests; fail on critical violations and link reports to Jira or Azure Boards.
- Snapshot flows: Capture screen reader transcripts or screen recordings for modals, carousels, and complex widgets.
- Regression guardrails: Pair Playwright or Cypress tests with `aria-role` and focus assertions.
- Evidence: Store results in the release checklist so leadership sees coverage rates.
Need a starting point? Import the CI templates in Testing Toolkit or attend the developer guild session.
Assistive technologies to test with
Every release should be validated with these AT combinations:
- JAWS + Chrome or Edge on Windows (forms, tables, ARIA widgets).
- NVDA + Firefox for standards-aligned testing.
- VoiceOver + Safari (macOS/iOS) and TalkBack + Chrome (Android) for responsive/mobile patterns.
- Fusion and ZoomText for magnification, focus indicator visibility, and reflow.
Document results and link to Assistive Technology Coverage when filing issues.
Training & community
- Arizona Digital accessibility guild (bi-weekly).
- Screen reader testing labs (monthly).
- WCAG 2.2 deep dives (quarterly).
On-demand: Mobile roadmap, Title II brief.
Reference library
- Web & App accessibility hub — WCAG checklist, exception workflow, mobile guidance.
- Checklist index — import into issue trackers for automation.
- UA brand + color guidance — ensures tokens stay accessible.
- Resource registry — authoritative sources and review dates.
- WebAIM resource library — deep dives on forms, landmarks, ARIA, and testing.
- Deque pattern library — code samples for menus, dialogs, and widgets.
Developer deep-dives
In-depth guides for specific development scenarios:
ARIA patterns
Accessible patterns for modals, tabs, menus, comboboxes, and more.
React accessibility
Build accessible React apps with hooks, component patterns, and testing.
CI/CD testing
Automate accessibility testing in GitHub Actions, Azure DevOps, and more.
Feedback
Post questions in the Arizona Digital Teams channel or email accessibility@arizona.edu. Last reviewed: 2026-01-05.
Next steps for developers
- This sprint: Add Accessibility Insights FastPass to your PR checklist and attach FastPass artifacts to the PR.
- This month: Gate releases with axe/Accessibility Insights in CI for critical rules; document any exceptions with remediation plans.
- Ongoing: Maintain a shared evidence folder with screen-reader transcripts, FastPass reports, and DubBot scan links for leadership reviews.
Need help integrating tests? Book Accessibility office hours for a pairing session.
Related guides you may need
Your work may overlap with these roles: