Mapped across 386 screens; automated coverage complete, manual validation prioritized by risk.
How I structured and executed an accessibility audit across 7 enterprise platform capabilities—mapping all 386 screens to the complete 55-criterion WCAG 2.2 A/AA matrix, running automated detectable-rule scans across every screen, performing manual testing on core interactive flows, and maintaining a structured backlog for remaining manual validation.
Scaling accessibility assessment across a multi-capability platform.
The product ecosystem spans complex AI and automation capabilities. To establish baseline compliance, we built a central tracking matrix evaluating 386 live developed screens directly in rendered web builds.
Initial Baseline Assessment
Accessibility evaluation was historically fragmented. Centralizing data provided leadership with exact visibility into live technical compliance debt.
Strict Environment Focus
Audits were executed directly on live web builds—using automated rules (Lighthouse/axe-core) alongside manual DOM inspection, visual contrast verification, and keyboard testing.
Complete 55-Criterion Matrix
Evaluated against the full 55 WCAG 2.2 Level A & AA success criteria (reflecting the deprecation of 4.1.1 Parsing in WCAG 2.2).
7 Core Platform Capabilities
The scope spanned 386 screens across 7 workbooks: Home, Harness, Digital Worker, Value Discovery, Neural Connect, Document AI, and Fabric (the core platform engine).
Raw Audit Workbook Log (Representative Redacted Sample).
Below is a representative redacted sample from the master audit log tracking criteria evaluations across capability sheets during live DOM analysis:
Two-Pass Evaluation: Scans + Targeted Live Inspection.
We executed a structured two-pass approach: Pass 1 (Automated DOM Scans) was run across all 386 screens to flag HTML syntax issues. Pass 2 (Targeted Manual Inspection) was performed on high-priority core flows to test dynamic behaviors, keyboard focus, and screen reader output.
alt attribute, but manual testing ensures the text alternative conveys accurate context within the live UI workflow.
Capability Dashboard & Audit Execution Scope.
Scope resolution was strictly defined: Automated scans were completed across all 386 cataloged screens. Targeted manual testing was executed on high-priority user flows, while remaining manual testing is explicitly tracked in the backlog dashboard.
Audit Status Clarification: Automated scanning is 100% complete across all 386 screens. The gray indicator ("Manual Review Backlog") represents non-automated criteria (e.g., custom focus management, screen reader context) queued for manual browser inspection.
Targeted Manual Testing Protocol & Backlog.
Because automated tools evaluate roughly 20-30% of total WCAG criteria, manual browser inspection was prioritized for mission-critical paths, with the remaining screens logged in a prioritized backlog.
| Manual Test Protocol | Scope & Checks Covered | Execution Priority & Status |
|---|---|---|
| Keyboard Traversal | Logical tab order, focus traps, skip links, and visible focus indicator checks. | Completed: Priority 1 flows — highest-traffic screens across Fabric and Neural Connect. Backlog: Remaining screens, sequenced by usage volume. |
| Screen Reader Validation | NVDA / VoiceOver announcement accuracy for dynamic updates, alerts, and modal dialogs. | Completed: High-traffic flows (Neural Connect, Fabric Engine). |
| Color Contrast Spot-Check | Manual color picker verification of text over image overlays, hover/active states, and disabled controls. | Completed: Primary design system components & canvas screens. |
| Zoom & Reflow Testing | 200% text zoom and 1280×1024 viewport reflow without loss of content or horizontal scrolling. | Completed: Responsive dashboard container templates. |
| Motion & Reduced Motion | Verification of prefers-reduced-motion query support and manual animation toggles. |
Completed: Screens with live data visualisations. |
Common Architectural & Visual Defects.
Consolidating live build data across capability workbooks revealed key recurring accessibility defects across the application ecosystem:
Addressing audit findings in production components.
To prevent recurring compliance issues in future release cycles, audit findings were translated into standardized engineering guidelines and production UI components.
Verified Color Tokens
Established centralized production color tokens pre-evaluated for 4.5:1 text contrast and 3:1 graphical element boundaries across front-end themes.
Standardized Focus Indicators
Added explicit, visible CSS focus ring styles to core interactive components across browser environments.
Form Structure Patterns
Refactored front-end form components to enforce persistent programmatically linked labels and dedicated error text containers.
Developer Implementation Rules
Introduced code-level guidelines (Keyboard Traversal, ARIA Landmarking, Accessible Names) to standardize future component development.
Structured phase-by-phase execution.
High-Impact Remediation
- Address critical automated contrast failures, missing image labels, and basic form tagging across core platform templates.
Component Standardization
- Publish updated accessibility-verified UI components and technical implementation guidelines across engineering teams.
Continuous QA & Automated CI Gates
- Integrate automated accessibility scans into pull-request CI pipelines and establish manual keyboard reviews in sprint releases.
Strategic Compliance & Delivery Outcomes.
Remediation Direction:
- Screens with one or more contrast failures dropped noticeably after the shared, pre-verified color tokens replaced ad hoc hex values.
- Missing icon-button text alternatives were eliminated at the source once accessible-name requirements were built into the shared component library, rather than fixed screen by screen.
A small number of fixes covered most of the findings:
- The majority of flagged defects traced back to four recurring root causes — alt-text gaps, contrast, missing accessible names, and unlabeled form fields — so fixing those systemically resolved far more than a one-by-one remediation pass would have.
Fewer issues reaching QA:
- Accessibility-related rework requests to engineering became noticeably less frequent once standardized, pre-verified components were adopted — issues were caught at the component level before reaching a full screen build.
- Automated Release Gate: axe-core checks were added to the engineering pull-request pipeline as a release blocker, catching new regressions before merge rather than after.
Repeatable Governance:
- Unified audit tracking across 7 capability workbooks, establishing a permanent baseline for ongoing compliance reviews.
What I Would Do Differently.
Senior UX Retrospective & Trade-offs
1. Prioritize Representative-Flow Manual Testing Earlier: Auditing 386 screens via automated scanning produced a massive initial dataset, but manual testing on end-to-end user journeys uncovered functional accessibility issues (e.g., focus traps in complex drawers) that automated rules missed entirely. In future initiatives, I would pair manual testing with automated scans from day one on core journeys rather than sequencing manual reviews as a subsequent pass.
2. Embed Automated CI Release Gates Sooner: We initially relied on static spreadsheet logging before establishing automated continuous integration (CI) checks. Integrating automated axe-core scanning directly into engineer pull requests earlier would have prevented new syntax bugs from entering the build while audit remediation was actively underway.