Designing for
Everyone.
Built for every user,
not just most.
Accessibility is a core design value, not a compliance checkbox. At BakerHill Solutions, siloed teams working across a complex public-facing financial application had created an uneven experience for users with varying abilities. I was brought in to establish a clear baseline, close the gaps, and put the team in a stronger position going forward.
The work touched every layer of the product: visual design, color theming, code quality, and developer tooling. The goal was to bring the application into conformance with WCAG 2.1 Supports standards and produce a sales artifact that gave the business team a confident, credible story to tell clients.
An uneven experience hiding in plain sight.
Organizations with distributed teams often develop accessibility debt without realizing it. At BakerHill, each team was building to their own standards, and the public-facing application reflected that fragmentation. Color contrast issues varied across themes, semantic markup was inconsistent, and there was no shared framework for catching accessibility gaps before they reached production.
Adding complexity to the challenge, the application supported multiple client-branded color themes. Any solution had to hold up across every combination, not just the default palette. A fix that worked in one theme could break legibility in another.
Accessibility is not a feature you bolt on at the end. It is a standard you build to from the start.
Fragmented Standards
- Inconsistent color contrast across branded themes
- Missing semantic markup and ARIA labels across key UI components
Unified WCAG 2.1 Baseline
- All themes verified to meet WCAG 2.1 contrast ratios
- Screen reader and keyboard navigation verified across the application
Auditing the design
and the code.
The audit began with a thorough review of the existing design system, including color palettes, typography, and the third-party UI framework the team relied on. I tested contrast ratios across every active color theme and used built-in browser accessibility tools to simulate custom foreground and background color settings, confirming that the interface remained legible even when users overrode the defaults.
The code audit went deeper. I performed manual testing and screen reader evaluation to surface issues that visual inspection alone would not catch. From there, I worked with the development team to define coding best practices and explore tooling that could surface accessibility errors during development, closing the loop between design intent and implementation quality.
Theme variance was the hidden risk
Contrast ratios that passed in the default theme failed in several client-branded palettes, making remediation a cross-theme effort from the start.
Screen readers exposed gaps visual review missed
Manual screen reader testing uncovered focus order issues and missing ARIA labels that automated tools had not flagged, reinforcing the value of manual evaluation alongside tooling.
Shifting from reactive
to proactive.
The audit revealed that accessibility was being treated as a final review step rather than a shared standard. Reframing the approach meant embedding accessibility thinking into the development workflow itself.
Catch issues after they ship.
Accessibility checks happened late in the process, often after code had already shipped to users. Siloed teams applied their own standards inconsistently.
Prevent issues before they reach production.
Defined WCAG 2.1 conformance targets, cross-theme testing protocols, and developer-facing tooling that surfaces issues in real time during development.
Closing the gaps required coordination across teams and buy-in from leadership.
Four decisions that
raised the standard.
The cleanup phase was guided by four core decisions that shaped how we approached remediation and positioned the work for long-term impact.
Audit color and contrast across every active theme, not just the default
Because BakerHill clients apply branded color themes, a single passing theme was not enough. Every active palette was tested for contrast compliance, ensuring that remediation held across the full product surface.
Build developer tooling to surface accessibility gaps before code ships
Defining best practices was not enough on its own. The decision to explore automated error messaging within the development environment meant that accessibility could be enforced as part of the natural workflow, reducing the cognitive load on individual developers.
Pair design remediation with semantic code fixes for lasting results
Updating color values without addressing underlying HTML structure would have created a false pass. Fixes in design and code were aligned so that improvements held up in real usage, not just visual inspection.
Translate the work into a client-facing artifact for the sales team
Accessibility work only creates lasting value if it is communicated clearly. Partnering with leadership to produce a client-facing document gave the sales team concrete evidence of our standards and a compelling narrative around our commitment to inclusive design.
Built to scale.
The remediation work was not treated as a one-time cleanup. As I worked through the code base I documented patterns, updated color values within the design system, and captured best practices that the broader team could carry forward. Developer tooling improvements were scoped to catch common accessibility oversights automatically during code changes.
Beyond the product itself, I partnered with leadership to translate the work into a client-facing artifact. The resulting document gave the sales team a clear, confident way to communicate the organization's accessibility standards, process, and outcomes to prospective clients.
WCAG 2.1 Conformance
Color contrast, semantic HTML, screen reader compatibility, and keyboard navigation verified across all active product themes.
Audit covered design system, production codebase, and screen reader compatibility. Results validated across all client-facing color themes.
What I'd do
differently.
Starting with a stakeholder education session earlier in the process would have helped. Accessibility debt accumulates because teams do not always understand the standard they are working toward. Having that shared understanding in place before the audit would have made the remediation conversations faster and more collaborative.
I would also advocate earlier for automated linting tools integrated directly into the development pipeline. Much of what was caught in the code audit could be surfaced automatically, freeing manual review time for the nuanced issues that tools cannot catch on their own.
Accessibility is not a project you finish. It is a practice you maintain. This audit gave the team a strong foundation and a shared language to build from.
— Michaela Hoffman, Principal UX/UI Designer