Enter password to view case study
ION
2026
Solving for accessibility remediation by reducing time spent by 90%
An in-house AI tool that compresses weeks of specialist accessibility remediation into days, for any team member to use
TLDR
What
An on-premise AI dashboard that gives product teams implementation-ready WCAG 2.2 AA remediation guidance — no accessibility specialist required on the call.
Why
A client of an FX trading portal raised an issue regarding accessibility compliance under US law. and neither automated scanners nor generic AI could remediate a complex, time-bound trading flow without leaking sensitive data or forgetting our standards every session.
Who
PMs, designers, engineers, QA, and client support who need implementation-ready accessibility fixes without pulling in a specialist — especially on sensitive, on-prem client work.
Impact
A 26-issue remediation cycle drops from 5–6 weeks to 1–2 days (~92% faster), saving $9K–$16K per cycle at 30× throughput, with one part-time reviewer doing the work of three specialists.
Solution
Balancing personality with clarity
The Accessibility Agent takes a problem in the messy form a PM or client actually reports it, and hands back a structured fix illustrating the user goal, applicable WCAG guidelines, interaction model, requirement and verification steps.
Every response comes back mapped to WCAG 2.2 AA, with a severity rating and the specific behaviour to correct — keyboard, screen reader, semantics — not just "this fails"
Behind it all is a knowledge graph of our accessibility standards, design system, and curated external guidance — connected, searchable, and growing. It even reads PDFs and adds what it learns
Because it's on-premise with no external services, sensitive client code never leaves the building. Security isn't a feature bolted on; it's the foundation
Problem
How the need arose
How the need arose
It started with a clear client requirement from Spectrum — a foreign exchange (FX) trading platform used by bank clients for front-office workflows. Because Spectrum is ultimately a B2B2C client portal, it fell under US accessibility compliance expectations (e.g., ADA — Americans with Disabilities Act). The risk was straightforward: we needed to demonstrate accessibility compliance, or the bank would be exposed to regulatory risk and potential fines.
This wasn't a one-off. Banks increasingly write accessibility into their own policies, which means they push it onto every vendor they work with, ION included, asking for VPAT reports and formal compliance evidence.
Client and their accessibility requirements research
At the time, I was the UX lead in the Accessibility Center of Excellence, supporting delivery teams with standards, patterns, and remediation guidance — which positioned me to turn this pressure into something reusable, not a one-time scramble.
Why the existing tools weren't enough
We tried the obvious first: Deque tools + screen reader testing. It surfaced issues, but it didn’t translate into fixes — scanners aren’t context-aware, and this flow was complex: time‑bound trading steps, dense data grids/tables, heavy keyboard interaction, and patterns applied inconsistently across screens.
So the real gap wasn’t “finding problems” — it was turning findings into implementation-ready remediation.
Why generic AI agents didn't solve it either
I already had a workflow for smaller remediation efforts: pre-made “context chats” with our standards, checklists, and patterns.
But for Spectrum I was new to FX — I didn’t fully understand the platform, and I didn’t have the time (as a part‑timer) to absorb the existing documentation beyond a PM walkthrough.
Even when the fix was clear, scaling it was hard: I had to make the PM self‑sufficient, then spread the same expertise to the wider team.
And generic AI didn’t close that gap: I couldn’t share sensitive client data, it drifted/hallucinated under heavy context, and it struggled to stay consistent in structure and standards.
How might we…
…democratize accessibility expertise so non-specialists can deliver WCAG-mapped, implementation-ready fixes — fast, on‑prem, and consistent with our internal standards?
Build
Ideation and building loop
The product goal was to convert my manual accessibility workflow into a reusable internal system with memory.
Through vibecoding, I transitioned from using AI to orchestrating it into a standalone product. It runs on our own infrastructure (infosec approved), it remembers our standards (no rebuilding context), and it outputs in the exact format our fintech teams need.
I architected this in phases: define scope → automate knowledge mining → wire the intelligence layer → test & deploy. Rather than writing syntax line-by-line, my role was setting the systems logic and directing agents to execute it.
1. The Knowledge Foundation — Orchestrating the Data Pipeline
Before the app could be smart, it needed to be educated. Every accessibility standard, WCAG guideline, and internal component checklist had to be codified.
After researching for external processors and getting a fair idea of structural references to give to AI, I designed an AI-driven curation pipeline: raw → processing → output.
Raw: Unstructured captures (web, PDF, Excel) are dropped in.
Processing: I engineered specialized Claude prompts (acting as data processors) to automatically extract text, strip out HTML junk, chunk the content by heading, and attach structural metadata.
Output: Clean, categorized Markdown, ready for the search index.
By turning this into an automated loop, I didn't just clean data once; I built a repeatable machine. Whenever new standards are introduced, the AI processors clean and categorize them automatically.
2. The Brain of the agent
I soon realized standard flat search wasn't enough. We needed the system to understand relationships between accessibility concepts as for most cases multiple guidelines act together and hence cross referencing was needed.
Example of multiple accessibilty guidelines applying
This is where “RAG” starts to matter.
RAG (Retrieval-Augmented Generation) means the model does not answer from memory alone; it first retrieves relevant chunks from a trusted knowledge base, then composes the response using that evidence. That reduces generic answers and helps control hallucination.
The knowledge base hence becomes structured as a graph:
Nodes represent WCAG concepts, patterns, or remediation rules
Edges capture relationships between them (depends on, related to, example of)
Retrieval combines text relevance with graph proximity
This let the system connect what rule applies with how to fix it and who needs the output (designer, dev, or QA) — more contextual than plain keyword search.
3. Why the LLM layer was necessary
Early versions that relied mainly on retrieval gave technically correct but generic responses. The LLM wrapper was the turning point.
The architecture became:
Retrieve from graph + indexed chunks -> reason with LLM -> format role-specific output
That added:
Better conversational quality
Better explanation quality
Better formatting for real workflows (including structured outputs for tracking)
Integrating the LLM tested my systems-thinking the most. Strict data-privacy rules meant the app had to run on ION's private AI infrastructure — self-hosted models behind an internal LiteLLM gateway.
4. Multi-model orchestration and failure handling
As requirements grew (text + screenshots + larger responses), one-model logic was not enough.
Routing logic was the real orchestration challenge: strong reasoning models like qwen3-coder-next were text-only, but users needed to upload UI screenshots. So I architected a split-brain routing system:
A text model handles reasoning and Knowledge Base querying
A vision model (
qwen3-vl-8b) takes over strictly for analyzing screenshot uploadsConditional handling for long outputs (document-style response mode)
This introduced real engineering trade-offs:
Context-window constraints
Model-specific behavior differences
API key scope issues per model
Latency vs quality decisions
We also defined a hard guardrail: if confidence is low or evidence is weak, do not fabricate an answer. Return a constrained response instead of hallucinating.
Ultimately, I designed the system to solve problems exactly the way the PM handed them to me:
Multimodal input — drop in a screenshot, paste a scenario, or log a client request.
Grounded answers — it cites working links back to our internal knowledge base. No hallucinations.
Paste-ready output — formatted specifically for our Excel tracking flows.
5. Testing & Iteration
We tested the agent on real client queries from Spectrum. If the agent hallucinated or gave a generic answer, I tweaked the system prompts and adjusted the RAG chunking logic until the output matched a human expert's standard. We structured the agent's answers to be clear and give remediation first and other links second.
One of the major complaints from the agent was the lack of bulk upload which we plan to deliver in phase 2.
Stress testing and fixing bugs
6. Deployment and operational learning
Deployment meant navigating ION's pipeline:
Building static assets
Transferring them via SFTP
Assigning proper permissions to a service account
Containerizing with Docker and an Nginx reverse proxy routing
/llm/traffic securely to the gatewayVerifying on a live UAT URL
Getting it live wasn't something I could do alone.
I treated my AI tools as DevOps co-pilots — vibecoding the Dockerfile, docker-compose.yml, and nginx.conf. But actual deployment still needed developer support to execute safely within ION's infrastructure.
Rather than let that dependency repeat, we converted the process into a reusable internal skill/playbook.
The real outcome wasn't just one dashboard shipping — it was a transferable deployment capability. Future teams (and future me) can now deploy internal AI products with far less reliance on any one person.
Limitations
All the things that went wrong
The biggest limitations were not just “tool problems”; they were architecture constraints that forced deliberate trade-offs.
Strict on-prem boundary reduced tooling freedom. We intentionally avoided external runtime services, so we couldn’t use managed vector databases, hosted LLM APIs, or cloud orchestration shortcuts. That improved data control, but increased local complexity around indexing, retrieval quality, and model routing.
RAG quality depended heavily on source hygiene. In a RAG setup, bad chunks create bad answers. The system’s output quality was directly tied to extraction accuracy, chunk boundaries, metadata tagging, and de-duplication. We spent significant effort improving retrieval precision before generation quality could improve.
Knowledge graph coverage was strong but not complete. The graph compounds over time, but early on some domains were sparse, which caused uneven answer depth. In practice, this meant high confidence in common accessibility patterns and weaker confidence in edge cases.
Model orchestration introduced operational fragility. Running separate text and vision paths improved capability, but added failure points: model-specific context limits, key-scoping mismatches, and intermittent routing breaks under heavy prompts.
Large-response behavior needed explicit handling. Complex remediation outputs sometimes exceeded what a normal conversational response could handle cleanly. We addressed this with a document-style output mode, but it was a learned architectural addition, not something obvious on day one.
Outcome
The impact
Measured against one real 26-issue remediation cycle, same team and scope:
Metric | Without agent | With agent | Saving |
|---|---|---|---|
Calendar time | 5–6 weeks | 1–2 days | ~92% faster |
Effort | 3–5 person-weeks | 1–2 person-days | ~85% less |
Cost (@ $75–100/hr) | $10K–$18K | $1K–$2.4K | $9K–$16K per cycle |
Throughput | 4–5 issues/week | 26+ issues/day | 30× |
Reviewers | 3 specialists | 1 part-time | 67% fewer |
Scaled to ~4 cycles a year across 2 product areas, that's $72K–$128K in recovered design and engineering capacity annually — before counting legal-risk mitigation and client retention.
And it isn't theoretical. Phase 1 is built, tested on real accessibility issues (grounded in the ongoing Spectrum and Western Alliance Bank cycles), and deployed — the internal container came through and the dashboard is live on UAT. The strategic shift matters more than any single number: the agent moves accessibility from a specialist bottleneck to a team capability, spreads awareness to PMs and client support, and turns a source of legal exposure and client friction into something we resolve in days.
Roadmap
What next?
The agent solved the issue of data processing and guideline formation. Now we have a source of clean data on ION specific use case for accessibility.
Next we have the task to understand the embedding of the accessibility data into a wider pipeline, i.e. once an issue is identified as per an accessibility ticket by a client the agent should be able to identify and remediate solution and give suggestions.
The agent exists as a companion of sorts but embedding it into different flows still remains to be explored. That final state — accessibility running as an automated, always-on stage inside the agentic workflow — is the real destination.
Lessons
Few of the things I learned
The strongest learning was that this was not “prompt and pray.” It required product judgment, technical framing, and iterative architecture decisions.
Guardrails are part of product quality. “If unknown, don’t fabricate” became a core behavior rule. Reliability in enterprise settings comes from controlled failure behavior, not just impressive best-case answers.
Human review improved system decisions. Peer and mentor input materially shaped processing strategy, architecture trade-offs, and deployment choices. AI accelerated execution, but decision quality came from collaborative judgment.
My role evolved from UI execution to system orchestration. The key capability I developed was translating ambiguous product needs into architecture constraints, prompt strategy, validation loops, and production-ready behavior.
