Embedding Accessibility in UX Workflows

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

Role

IT Accessibility Analyst

IT Accessibility Analyst

Domain

Finance
UX Research

Finance
UX Research

Duration

16 weeks

16 weeks

Team

3 designers
2 developers
1 product owner

3 designers
2 developers
1 product owner

01 - The Brief

02 - Impact

03 - Problem

04 - Research

05 - Solution

06 - Testimonials

TL;DR

TL;DR

Problem

Problem

At a U.S. mortgage company, accessibility team members noticed that new designs contained accessibility issues, which led to products shipping with varied levels of accessibility quality

What I did

What I did

I conducted research with team members (interviews, workshops) to implement a new design review process for the design team to ensure that all products had accessible experiences for broker clients. Throughout this, I collaborated heavily with design and engineering to identify friction in the ux workflow

Outcomes

Outcomes

  • 6 product teams adopted this process

  • 25% of new products launched with full compliance

  • Optimized UX and Accessibility team workflow by 30%

Jump to solution

THE BRIEF

Uncovering accessibility gaps with a design review

Uncovering accessibility gaps with a design review

As an Accessibility Analyst, I collaborated closely with design and engineering to lead research into varied levels of product accessibility. I implement a new design review solution that involves the evaluating a design based on WCAG 2.2 AA standards so that designers can fix accessibility issues before production

IMPACT

User experiences with greater accessibility for 40k brokers

User experiences with greater accessibility for 40k brokers

My work impacted both internal process improvements and the level of accessibility of our client-facing products

My work impacted both internal process improvements and the level of accessibility of our client-facing products

6

6

product teams adopted proposed solution

25%

25%

of new products launched with 100% compliance

30%

30%

optimization of UX touchpoints

PROBLEM

Accessibility issues were caught too late

Accessibility issues were caught too late

Despite a UX Accessibility sub-team, designers relied on engineers for remediation, making it harder and more expensive to fix accessibility issues

Despite a UX Accessibility sub-team, designers relied on engineers for remediation, making it harder and more expensive to fix accessibility issues

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.

RESEARCH

Interviews with 4 designers

Interviews with 4 designers

Interviews revealed that unclear accessibility expectations drove lack of engagement with the Accessibility team, pushing designers to rely on intuition rather than guidance. This gap contributed to the varied levels of accessibility quality across products

Interviews revealed that unclear accessibility expectations drove lack of engagement with the Accessibility team, pushing designers to rely on intuition rather than guidance. This gap contributed to the varied levels of accessibility quality across products

Finding #1

Designers were unsure when to engage the Accessibility Team throughout their workflow

Finding #2

Designers wanted to engage the team, but they didn't have enough time

Finding #3

Designers were working without a shared benchmark

WORKSHOP

Leading a workshop with 7 designers & developers

Leading a workshop with 7 designers & developers

I conducted a workshop to reimagine the ux workflow with a design review process. I discovered that accessibility often gets lost during developer handoff because accessible design intent is not being documented for engineers

I conducted a workshop to reimagine the ux workflow with a design review process. I discovered that accessibility often gets lost during developer handoff because accessible design intent is not being documented for engineers

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

STRATEGY

Standardized accessibility checks in the designer workflow

Standardized accessibility checks in the designer workflow

  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.

ITERATING

Refining the design review process 2x times

Refining the design review process 2x times

When the team began conducting these design reviews, we had to continually update our strategy to solve theses 2 critical challenges:

01: Too early

01: Too early

After a review, the design would be completely changed, wasting time and effort to conduct the review at all

After a review, the design would be completely changed, wasting time and effort to conduct the review at all

02: Too late

02: Too late

Reviews would occur too late, making it very challenging for designers to make changes

Reviews would occur too late, making it very challenging for designers to make changes

We realized that instead of trying to fit 1 point in the project's timeline for a design review, we needed 2 separate points to address design vs engineering feedback when the design is stable yet open enough for feedback implementation

SOLUTION

Design review process with 2 checkpoints at the midpoint and handoff phase of design

Design review process with 2 checkpoints at the midpoint and handoff phase of design

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 midpoint?

  1. Simplify Navigation

With information architecture approval from the product owner, designers have enough time to fix accessibility issues in an already validated design direction, maximizing impact and likelihood for feedback implementation

With information architecture approval from the product owner, designers have enough time to fix accessibility issues in an already validated design direction, maximizing impact and likelihood for feedback implementation

Why handoff?

  1. Simplify Navigation

Designers must document accessible design intent including semantics so that developers have clear requirements to implement them

Designers must document accessible design intent including semantics so that developers have clear requirements to implement them

KEY DECISION #1

Creating 3 process flowcharts to increase timeline clarity

Creating 3 process flowcharts to increase timeline clarity

I found that flowcharts were the best tool for team alignment so I mapped design review checkpoints from ideation to handoff. 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.

I found that flowcharts were the best tool for team alignment so I mapped design review checkpoints from ideation to handoff. 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%
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

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

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. These guidelines were used to deploy a team-wide design checklist for accessibility

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. These guidelines were used to deploy a team-wide design checklist for accessibility

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

KEY DECISION #3

Defining a design review at developer handoff

Defining 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

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

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.
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.

Key achievements

Key achievements

Design review adopted by 6 product teams

Optimized workflows between the UX and Accessibility team by 30%

Led an Accessibility governance standard, approved by the Software Development Council

  1. Design review adopted by 6 product teams

  1. Optimized workflows between the UX and Accessibility team by 30%

  1. Led an Accessibility governance standard, approved by the Software Development Council

Testimonials

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."

"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."

"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

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.

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 research 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.

My research 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.