accessibility
Accessibility at enterprise scale
How we turned a compliance obligation into a component-level engineering standard — impossible for authors to accidentally break.
- Role
- Lead UX Engineer
- Platform
- Fortune 200 Banking Platform
- Timeline
- 2022–2023
- Team
- 4 engineers · 2 accessibility specialists · QA integration
5/5
fully remediated
WCAG categories
0
at production launch
Axe violations
NVDA + VoiceOver
manual validation
Screen readers
Problem
An internal audit surfaced 47 distinct WCAG violations across the banking platform — clustering around five root causes: keyboard inaccessibility, broken document structure, absent focus management, invisible focus indicators, and contrast failures.
Approach
Reframed compliance as architecture — not fixing 47 items but eliminating the five structural root causes. Native HTML elements for all interactive controls, heading level computed from template structure, shared focus management utility, global focus visibility baseline.
Outcome
All five WCAG violation categories remediated. Axe-core violations at production: zero. NVDA and VoiceOver validated. Author configuration errors contributing to accessibility failures structurally eliminated.
The problem
Forty-seven distinct WCAG violations. Not random — five root causes, each pointing to a systemic failure rather than individual component errors. In a regulated financial services environment, this isn't a quality issue. It's legal exposure under ADA Title III.
The reframe that changed the approach: a remediation list fixes 47 items and watches the count drift back up. An architectural fix asks what structural change makes these violations impossible.
"Accessibility stops being something QA catches — and becomes something the system enforces structurally."
Remediation approach
Fix 47 violations. Ship. Monitor for regression. Repeat as new content is authored incorrectly. Compliance depends on ongoing vigilance.
Architecture approach
Identify five root causes. Move governance-critical properties out of author control. Compliance becomes a property of the component, not a QA gate.
System architecture
Five root categories. Five architectural fixes. Each one removes a class of violations rather than fixing individual instances.
Root cause → Architectural fix → Enforcement
Challenge
Decision
Outcome
Interactive controls using div/span with JavaScript handlers
Replace with native HTML elements — button for actions, a[href] for navigation
Browser-native keyboard handling
no event polyfills needed
Heading levels set by authors in dialogs
Compute heading level from structural template position via Sling Model
Authors can't create semantic mismatches
level is determined by position
Modals opening without focus management
Shared focus utility — trap, initial placement, Escape binding, trigger restoration
Consistent behavior across all overlay components
outline: none globally without replacement
focus-visible styles in shared ClientLib meeting 1.4.11 contrast requirements
Keyboard users have visible focus
mouse users unaffected
Missing or incorrect landmark regions
Landmark roles moved from author-configurable to component-defined policies
Landmark structure guaranteed by component, not authoring convention
Accessibility validation pipeline — per-component protocol
Validation protocol
Automated tooling catches approximately 35% of real WCAG failures. The rest require human validation — which means a defined protocol, not ad hoc QA.
Each remediated component ran through a fixed sequence: axe-core CI, keyboard traversal across all interactive states, NVDA on Windows/Chrome, VoiceOver on macOS/Safari, and VoiceOver on iOS/Safari — where swipe gesture behavior differs meaningfully from desktop.
The iOS/Safari step caught failures the other four passes missed. It's the most expensive step and the most important one to skip.
Outcomes
In the 18 months following remediation, no accessibility regressions were introduced through the governed component pathway.
5
5
0
Axe violations at launch
0
Post-launch regressions in governed components
2
Screen readers validated
Issues that were reported in the 18 months following came from ungoverned areas — third-party embeds, manually-authored pages. Not from governed components.
Reflection
Build the testing protocol before remediation begins. We built the keyboard/screen reader validation process as we went. Starting with a defined protocol would have produced more consistent results and made the QA handoff cleaner — testing is not something you refine into correctness, it's something you specify upfront.
Instrument the governance model. We had no telemetry on author behavior before or after the changes. Before/after misconfiguration data would have made a stronger case for the architectural approach — and would have quantified the actual risk reduction, not just the violation count reduction.