Accessibility Infrastructure
Enterprise Financial Services Platform
From 47 violations to zero — by changing the architecture, not the checklist.
How accessibility stopped being something QA caught and became something the system enforced structurally.
- Role
- Accessibility Engineering Lead
- Platform
- Enterprise Financial Services Platform
- Timeline
- 2022–2023
- Team
- 4 engineers · 2 accessibility specialists · QA integration
5/5
fully remediated
WCAG categories
0
at production launch
Axe violations
0
18 months governed
Post-launch regressions
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 WCAG violations across a enterprise financial services platform. Not random errors — five distinct root causes, each one a structural failure that would reproduce itself indefinitely regardless of how many individual violations were fixed.
In a regulated financial environment, this isn't a code quality issue. It's ADA Title III legal exposure.
Before vs After
The decision that changed the approach: treat this as an architecture problem, not a remediation list.
QA-driven accessibility
Find violation. Fix violation. Ship. Monitor for regression as new content is authored incorrectly. Compliance depends on ongoing vigilance from every engineer on every component.
Architecture-driven accessibility
Identify root cause. Move governance-critical properties out of author control. Compliance becomes a property of the component itself — not a QA gate, not a checklist, not anyone's ongoing responsibility.
"The goal wasn't to fix 47 violations. It was to build a system where those violations couldn't exist in the first place."
System architecture
Five root causes. Five architectural fixes. Each one removes an entire class of violations rather than patching individual instances.
Root cause → Architectural fix → Outcome
Challenge
Decision
Outcome
Challenge
Interactive controls using div/span with JavaScript handlers
Decision
Replace with native HTML elements — button for actions, a[href] for navigation
Outcome
Browser-native keyboard handling
Challenge
no event polyfills needed
Decision
Outcome
Challenge
Heading levels set by authors in dialogs
Decision
Compute heading level from structural template position via Sling Model
Outcome
Authors can't create semantic mismatches
Challenge
level is determined by position
Decision
Outcome
Challenge
Modals opening without focus management
Decision
Shared focus utility — trap, initial placement, Escape binding, trigger restoration
Outcome
Consistent behavior across all overlay components
Challenge
outline: none globally without replacement
Decision
focus-visible styles in shared ClientLib meeting 1.4.11 contrast requirements
Outcome
Keyboard users have visible focus
Challenge
mouse users unaffected
Decision
Outcome
Challenge
Missing or incorrect landmark regions
Decision
Landmark roles moved from author-configurable to component-defined policies
Outcome
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 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.
The iOS/Safari step consistently caught failures the other four passes missed — swipe gesture behavior differs meaningfully from desktop. It's the most expensive step and the one most likely to be cut. It shouldn't be.
Outcomes
Zero violations at launch. Zero regressions in 18 months of production. Every accessibility issue reported after launch came from ungoverned areas — not from a single governed component.
5 of 5
WCAG categories fixed
0
Axe violations
0
Post-launch regressions
2
Screen readers validated
The distinction matters: regressions after launch came exclusively from third-party embeds and manually-authored pages outside the governed component pathway. The governed system held perfectly.
Reflection
"The difference between a remediation and an architectural fix is whether you have to do it again. We did it once."
Specify the testing protocol before remediation begins. We built the validation process as we went. A defined protocol from day one would have produced more consistent results and made 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.