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.
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)
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.
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.
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)
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.