What this page helps you do

Executive summary

Ship inclusive code by focusing on four pillars:

  1. Design-to-code parity: implement Quickstart patterns with semantic HTML and ARIA only when necessary.
  2. Predictable focus: ensure keyboard order, skip links, and roving tabindex follow focus guidance.
  3. Robust testing: combine CI automation with manual keyboard + JAWS/NVDA/VoiceOver/TalkBack passes before releasing.
  4. 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.

Focus, input, and navigation

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.
Structure, status, and semantics

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.
Media, documents, and alternative text

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.
Developer WCAG 2.2 checklist
  • ✅ 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.

Download machine-readable checklists from checklist-index.json for sprint automation.

Address WebAIM Million top findings

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 `
  • 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.

Before you merge (manual review)
  1. Keyboard sweep every interactive element (Tab/Shift+Tab + Escape for dialogs) to confirm focus order and visibility.
  2. Run Accessibility Insights FastPass plus the Tab Stops overlay; save the report in your PR artifacts.
  3. Spot-check page templates with WebAIM WAVE and note any errors/warnings not covered by automated scans.
  4. Trigger your team’s DubBot crawl or add the URL to the next scheduled scan for regression tracking.
  5. 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.

Navigation, menus, and tabs

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.

Forms & validation

Every form field needs a visible label, programmatic name, inline help, and error messaging.

  • Use native `
  • 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.

Media, embeds, and charts

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.

Dynamic content & announcements

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

Engineering checklist
Testing workflow
  1. Automated: axe/Accessibility Insights in CI + Storybook linting.
  2. Manual: keyboard-only navigation, focus traps, modals.
  3. Screen reader: JAWS or NVDA (Windows) and VoiceOver (macOS/iOS); include TalkBack for Android webviews.

Deep dive: Testing Toolkit, Keyboard patterns, Assistive technology coverage.

Exception process

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.

1. Run FastPass (2 minutes)
  1. Open the Edge/Chrome extension on the page under test.
  2. Select FastPass to capture automated checks + tab stops; export the report and attach it to your PR.
  3. Resolve failures immediately or log defects referencing the exact WCAG criteria surfaced in the report.

Docs: FastPass overview

2. Complete Guided Assessment (20–30 minutes)
  1. Switch to the Assessment view; walk through each requirement (structure, landmarks, focus order, gestures).
  2. Use built-in snippets (Tab stops, Landmarks, Headings) to capture evidence for reviewers.
  3. Mark steps as pass/fail/not applicable and sync results to Azure Boards/Jira.

Docs: Assessment overview

3. Use Ad hoc tools & Simulator
  • 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

4. Tie back to UA workflow
  • 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

Accessibility Testing Toolkit

Recommended automated/manual tools and scripts.

View toolkit

Accessibility office hours

Pair on code reviews and complex widgets.

Book time

Quickstart accessibility docs

Component guidance, code samples, design tokens.

Open docs

Deque University & axe

On-demand WCAG courses plus axe DevTools for CI/CD integration.

Browse catalog

DubBot campus license

Schedule weekly crawls for Quickstart and vendor sites; export prioritized WCAG 2.2 findings.

Request access

CI/CD readiness

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:

Document results and link to Assistive Technology Coverage when filing issues.

Training & community

On-demand: Mobile roadmap, Title II brief.

Reference library

Developer deep-dives

In-depth guides for specific development scenarios:

ARIA patterns

Accessible patterns for modals, tabs, menus, comboboxes, and more.

ARIA pattern library

React accessibility

Build accessible React apps with hooks, component patterns, and testing.

React guide

CI/CD testing

Automate accessibility testing in GitHub Actions, Azure DevOps, and more.

CI/CD integration

Feedback

Post questions in the Arizona Digital Teams channel or email accessibility@arizona.edu. Last reviewed: 2026-01-05.

Next steps for developers

Need help integrating tests? Book Accessibility office hours for a pairing session.

Your work may overlap with these roles:

Building Mobile?

VoiceOver/TalkBack testing and Title II mobile deadlines.

Mobile guide

All Roles

Browse all role-based guides.

I am a...