Fintech

UX Research

Accessibility in UX Operations

I conducted accessibility research with team members to build strategies to incorporate accessibility practices into the design process for inclusive user experiences

Role

IT Accessibility Analyst

Domain

Fintech

Duration

16 weeks

Team

3 designers
2 developers
1 product owner

Mobile screen mockup annotated with accessibility review callouts, including labels for ARIA, landmarks/regions, tab order, and developer notes.

Details of this project and visual designs in this case study have been generalized or omitted due to confidentiality purposes

Overview

I collaborated with a team of designers and developers to align the company's product strategy with regulatory accessibility requirements

My task

  • Understand UX operational risks and deficiencies for accessibility compliance

  • Align the team on process improvement strategies to move in the right direction

  • Drive success by piloting and scaling the solution across teams

Outcomes

6 of 20 teams adopted proposed solution

1 fully compliant feature shipped in 8 weeks

made a requirement for all new product launches

informed discussions with product owner, product strategy AVP, and UX team lead

PROBLEM

Accessibility issues were caught too late

Most issues were caught in software production when fixing them meant development rework. By then, the cost compounds and becomes more expensive to fix. For brokers, issues are live barriers. Automated tools detect only 30-40% of known accessibility issues (A11y Project, 2025) so the timing of catching these issues matter just as just as the tooling

Diagram comparing two timelines across the Software Development Lifecycle, showing accessibility currently surfacing during testing versus a future state where it's addressed during design.

Interviews — Main Insight

Accessibility expectations weren't clear enough to designers

4 interviews with junior to senior designers, revealed that without internal accessibility standards, designers relied on their own judgment to fill the gap. And with competing priorities, there often wasn't time to validate those decisions at all

Expectations

Lack of a shared benchmark of requirements

Collaboration

Unclear when to loop in the accessibility team

Time

Designers didn't feel they had enough time

Workshop — Main Insight

Developers need documented design intent

One workshop with 7 designers and developers revealed that accessible design intent must be clear and documented for developers, or product accessibility risks getting lost during developer handoff

Digital sticky-note board capturing workshop feedback on accessibility validation, designer collaboration, and developer handoff steps.

Strategy

Making accessibility built-in

Research revealed that we needed (1) to create a shared benchmark so that designers know what to achieve and (2) a way to evaluate how well they meet these standards before proper implementation

Constraints

Manual over automated solution

The product owner and compliance stakeholders wanted a manual solution for catching accessibility issues before exploring technical ones

Limited to design and development phase

Solution is limited to design and development in the software development lifecycle before scaling to testing, deployment, and maintenance

Goals

  1. Decrease technical debt for developers

  2. Scale adoption for design reviews across all product teams

  3. Reduce variance in accessibility quality

  1. Decrease technical debt for developers

  2. Scale adoption for design reviews across all product teams

  3. Reduce variance in accessibility quality

Table contrasting a "Reactive" approach, where accessibility issues are caught after launch, with a "Built-in" approach, where they're identified and resolved starting at the design stage.

SOLUTION

A Design Review Solution

A design review process with 2 checkpoints at the midpoint and handoff phase of design in which designs are marked-up with design and developer annotation focused on accessibility requirements

Vertical timeline showing two review checkpoints with their trigger, completion percentage, and focus area tags: 60% complete at IA approval covering color contrast and content hierarchy, and 90% complete at handoff covering landmarks, focus order, and ARIA labels.

Why these checkpoints

Why these checkpoints

1. Midpoint

2. Handoff

Impact

User experiences with greater accessibility for 40k brokers

The design review process impacted both internal process improvements and the level of accessibility of our client-facing products

6

6

product teams adopted proposed solution

1

1

fully WCAG AA compliant feature launch within 8 weeks of deployed solution

1

1

deployed accessibility checklist to 20 designers

Key Decision #1

Aligning stakeholders with 3 process flowcharts

I found that flowcharts were the best tool for team alignment so I mapped to-be design review checkpoints from design ideation to developer handoff

Impact: these flowcharts initiated design reviews for 6 products and helped the Accessibility team reach agreement with 3 UX team leads on the right times for a design review

3 flowcharts mapping the design workflow across design Ideation, wireframing, and developer handoff, with color-coded steps distinguishing UX design tasks from accessibility review tasks.
40%
3 flowcharts mapping the design workflow across design Ideation, wireframing, and developer handoff, with color-coded steps distinguishing UX design tasks from accessibility review tasks.
30%

Key Decision #2

Establishing requirements with 6 pages of guidelines

In interviews, all 4 designers wished that there was a way for them to know how well they were meeting accessibility standards. Based on WCAG 2.2 AA standards, I created design documentation for accessibility requirements that defines what is required vs negotiable for designers to achieve

Impact: these guidelines were used to deploy a team-wide design checklist for accessibility by the Accessibility SME

Five digital pages covering accessibility topics like navigation, interaction methods, headings, and error prevention, each tagged with a WCAG conformance level.

Key Decision #3

Implementing a design review at developer handoff

Research highlighted that accessible design does not occur in isolation in the software development lifecycle (SDLC). My initial scope focused on design solely in the SDLC, but I realized developers must be able implement accessibility too. I built out a design review for technical implementation and developer tasks

Impact: 3 developers were assigned to conduct design reviews at developer handoff for upcoming products ready for development

Venn diagram of Design and Development circles overlapping at "Developer Handoff," marked as the point where accessible design decisions must be made explicit and shared.
Venn diagram of Design and Development circles overlapping at "Developer Handoff," marked as the point where accessible design decisions must be made explicit and shared.

Testimonials

"I'd like to recognize Ally Garcia for digging into the world of UX design reviews. This is an amazing step for our team as we work to achieve our goals. Ally brings her passion, creativity, and ability to ask the right questions every day as she discovers what this process will look like in the future."

Product Owner III, Accessibility Team

"Great job presenting your flowcharts! I am impressed (yet unsurprised) by your level of detail that went into making these."

Front-end Developer, Accessibility Team

Takeaways

Working on this project taught me how to navigate solving for a complex problem across disciplines. As I was building this solution, it was already being used and tested by team members at the same time. This challenged me to break down the problem, ask many questions, and gather lots of feedback through bi-weekly stakeholder demos and presentations.

My project initially focused on the design process, but the scope of my project expanded across design to front-end development. If I were to continue this project, I would like to interview developers about their perspectives working with designers to implement accessibility. I'd also like to capture these metrics to further refine the solution:

Accessibility: % of shipped features meeting WCAG AA compliance across product teams

Accessibility: % of shipped features meeting WCAG AA compliance across product teams

Accessibility: % of shipped features meeting WCAG AA compliance across product teams

Tickets: % change in amount of accessibility remediation tickets

Tickets: % change in amount of tickets to remediate accessibility issues after production

Tickets: % change in amount of tickets to remediate accessibility issues after production

Cost: average developer hours to remediate an issue caught at midpoint/developer handoff vs. one caught post-launch

Cost: average time or dev hours to remediate an issue caught at midpoint/developer handoff vs. one caught post-launch

Cost: average time or dev hours to remediate an issue caught at midpoint/developer handoff vs. one caught post-launch