accessibility Shipped
What this lens looks for
Confirm every component integrates with platform accessibility APIs from initial implementation, not as a retrofit. Every interactive element carries a semantic role and an accessible label (set AutomationProperties.Name on Windows controls lacking visible text, AutomationProperties.LabeledBy for form fields, contentDescription and proper roles on Android, ARIA roles on web); full screen reader support across VoiceOver, TalkBack, Narrator, and ARIA; keyboard and switch-control navigation where every interactive element is focusable, reachable via Tab, and actionable via Enter/Space, with switch access reaching all controls; Dynamic Type / font scaling honored — layouts MUST NOT break or clip at larger text sizes (handle 2x font scale on Android, up to 225% text scale on Windows); WCAG AA minimum contrast of 4.5:1 for text and 3:1 for large text; meaningful focus order that follows the visual layout. Verify components respond to platform accessibility and display settings: reduced motion (replace animations with crossfades/instant transitions, disable custom animations when animator duration scale is 0 or animations are disabled), reduced transparency (opaque backgrounds instead of blurs/vibrancy), differentiate-without-color (add icons/shapes/patterns alongside color), increased/high contrast (higher-contrast color pairs, wider borders, WCAG AA ratios), invert/forced colors (mark images/video to ignore inversion, respect the system color palette, never hard-code colors — use ThemeResource/system tokens), bold text, grayscale, dark theme/dark mode, reduced-data (lazy-load images, shrink assets), caret browsing (non-interactive text navigable), color filters/vision-deficiency usability, and prefers-cross-fade transitions. On web target WCAG 2.2 AA — the current Recommendation superseding 2.1 — honoring its new criteria: focus not obscured, focus appearance, a single-pointer alternative to dragging, target size minimum 24×24 CSS px (44pt is the stricter Apple guidance), consistent help, redundant entry, and accessible authentication with no cognitive-function test; treat WCAG 3.0 as a not-yet-actionable horizon. Use platform tooling and patterns: SwiftUI environment values (accessibilityReduceMotion, accessibilityReduceTransparency, accessibilityDifferentiateWithoutColor, colorSchemeContrast, invert/cross-fade keys), Android AccessibilityManager and Configuration/displayMetrics signals, ARIA roles with aria-live for dynamic content and proper landmark regions plus CSS preference media queries, and Windows UI Automation with WinUI 3 patterns, AutomationProperties.LiveSetting for dynamic regions, and Accessibility Insights testing.
What its verifier checks
Every component integrates platform accessibility APIs from initial implementation rather than retrofitting; every interactive element has both a semantic role and an accessible label via the platform-appropriate API; screen reader support is complete (VoiceOver/TalkBack/Narrator/ARIA); all interactive elements are keyboard- and switch-reachable via Tab and actionable via Enter/Space; layouts survive Dynamic Type / font scaling without breakage (2x font scale, up to 225% Windows text scale); text contrast meets WCAG AA at 4.5:1 normal and 3:1 large; focus order follows the visual layout; reduced-motion is honored (prefers-reduced-motion, accessibilityReduceMotion, animator-duration-scale==0, Windows animations-disabled) with animations replaced or disabled; reduced/forced transparency uses opaque backgrounds; differentiate-without-color adds non-color indicators; high/increased contrast uses higher-contrast colors and wider borders; invert/forced colors are respected with media/images marked to ignore inversion and no hard-coded colors (ThemeResource/system tokens used); bold text, grayscale, dark theme/dark mode, reduced-data, caret browsing, color filters, and cross-fade preferences are each handled; web components conform to WCAG 2.2 AA including focus-not-obscured, focus appearance, dragging alternative, 24×24 CSS px target size, consistent help, redundant entry, and accessible authentication, with correct WAI-ARIA roles/states/properties; platform-specific mechanisms are used (SwiftUI environment keys, Android AccessibilityManager/Configuration, ARIA roles + aria-live + landmarks + CSS preference media queries, Windows AutomationProperties + UI Automation patterns); Windows controls expose Name/Role/patterns with AutomationProperties.Name on label-less elements and AutomationProperties.LabeledBy on form fields; accessibility is validated with platform tooling (e.g., Accessibility Insights, Narrator).