From 12% to 84%: Scaling Accessibility
Overview
This case study highlights how I led the integration of accessibility into our design process at J.P. Morgan.
I created a framework that helped designers build accessible solutions by incorporating targeted accessibility training and introducing standardized “Greenlines” accessibility annotations.
As a result, designers became more confident applying WCAG guidelines and consistently included accessibility annotations in their work — increasing adoption from 8% to 84%.
Why does accessibility matter?
Globally, over 1.3 billion people — roughly 1 in 6 — live with some form of disability. These may be permanent, temporary, visible, or invisible.
But designing for accessibility isn’t just about inclusive access; it also leads to better, more intuitive experiences for everyone.
Beyond usability and ethics, there’s also a legal imperative. Many major companies have faced lawsuits due to non-compliance.
And from a business perspective, accessibility expands your reach and builds trust.
In short: accessibility isn’t optional at J.P. Morgan — it’s a requirement.
The problem
Despite the importance of accessibility, many of our products still failed to meet accessibility standards. Our QA teams routinely logged hundreds of accessibility-related defects in JIRA, forcing engineers to fix issues retroactively just to achieve compliance.
The root cause was clear: accessibility wasn’t prioritized early enough in the process. Designers often overlooked it, which carried over into engineering and led to inaccessible code, poor user experiences, and significant risks — from legal exposure to reputational damage.
To make matters worse, both designers and engineers across the organization had inconsistent levels of accessibility knowledge. Without a shared baseline understanding, accessibility was treated as an afterthought rather than a core part of our workflow.
What does it mean for us to build accessible products?
Accessibility can take many forms, and the space is complex — but for us at J.P. Morgan, it comes down to one clear requirement: be compliant with WCAG 2.2 AA standards. That’s our baseline, and every product we ship must meet this requirement.
Key players and their responsibilities
So who’s responsible for making sure our products are accessible? Everyone. Designers, engineers, and QA teams all play a role in building accessible solutions. Designers define accessible interactions and annotations, engineers implement them, and QA helps validate compliance. But ultimately, the product team is accountable for making accessibility a priority and ensuring it’s part of the delivery process.
In short: execution is shared, but ownership is not.
The goal
While accessibility involves collaboration across product, engineering, and QA, my focus for this initiative was specifically on the designers’ contribution. I set out to define how designers could embed accessibility into their daily workflow and make it a consistent part of every design we deliver.
From this perspective, the initiative centered on two main goals:
- Educate designers on accessibility — building a baseline understanding of accessibility principles and WCAG guidelines across the design org.
- Adopt accessibility annotations (“Greenlines”) in Figma — making it standard practice to include clear, consistent annotations in every design file.
These goals aimed to ensure our designs were accessible from the start, reducing rework downstream and helping create more inclusive, WCAG-compliant products.
Measuring success
To measure impact, I defined two KPIs and built them into our existing tracking systems:
- Training completion: Designers were required to take two accessibility courses (foundational and advanced) through J.P. Morgan’s Udemy partnership. Completion rates were tracked automatically, with a goal of 100%. Within two months, 96% of designers were certified.
- Greenlines adoption: We added a column to our monthly global tracker where design leads marked each project as Yes, No, or Not Applicable for accessibility annotations. This provided clear visibility into adoption rates across the org and made accessibility measurable within our workflow.
Accessibility training
To support this initiative, I partnered with our global accessibility team to identify two key training courses: one foundational and one advanced. Through J.P. Morgan’s partnership with Udemy, all employees had free access to these courses.
We made both trainings mandatory for designers, distributed them across teams, and leveraged the existing tracking system to monitor completion rates. This made it simple to measure progress and ensure accountability.
Within just two months, 96% of designers completed both courses and earned certifications, establishing a strong baseline understanding of accessibility principles across the design org.
Greenlines (JPMorgan accessibility annotations)
Greenlines are standardized accessibility annotations in design. They serve as a tool for UX designers to clearly document accessibility considerations directly in their Figma files.
In practice, Greenlines help communicate intent to engineers by marking elements like tab order, labels, and contrast requirements, ensuring accessibility is implemented correctly in code. They also act as a reference for QA teams during testing, creating a shared source of truth across disciplines.
Not all WCAG checkpoints are designable
WCAG is a critical standard, but let’s be real: not everything in it lives in the design file.
Plenty of checkpoints are about code, structure, and user interaction — things like semantic HTML structure, proper heading hierarchy, dynamic content updates announced by screen readers, or error handling implemented in code - that’s dev territory.
Designers can’t cover every WCAG checkpoint directly in Figma — and that’s okay.
Making Greenlines reusable and scalable
To make Greenlines easy to adopt, I built reusable components for accessibility annotations and added them to our design system library. Under the Utilities section, I created a dedicated Accessibility category where designers could quickly access and apply these components directly in Figma. This ensured that every designer, regardless of their team, had immediate access to standardized, ready-to-use Greenlines.
Writing a guide
I also created a comprehensive step-by-step guide to show designers how to use Greenlines effectively and apply relevant WCAG checkpoints in Figma. The guide included real examples, clear instructions, and best practices, making it easy for any designer — regardless of experience level — to get started and integrate accessibility annotations into their workflow.
Adoption
Once the documentation was complete, I focused on driving adoption. I presented the Greenlines framework during our Payments All-Hands, attended by hundreds of designers, explaining why it mattered and how to use it in day-to-day work. I then met individually with each of the 12 design managers to align on integrating Greenlines into our delivery process. Together, we updated our definition of done to require every Figma file to include accessibility annotations alongside the final UI.
Outcomes
To track adoption, we integrated Greenlines into our existing monthly tracker, where design managers audited their teams’ Figma files for accessibility annotations. We set an ambitious target of 100% compliance and achieved an average of 84% across the year.
More importantly, we saw a clear culture shift. Designers began proactively raising accessibility questions, incorporating them into critiques, and collaborating more closely with engineers. QA and development teams also started referencing Greenlines themselves, which reduced defects and improved cross-functional collaboration.
Closing thoughts
This initiative fundamentally changed how I approach accessibility — and design in general. What began as a focused effort to introduce training and Greenlines annotations evolved into a cultural shift across our design org. Accessibility went from being an afterthought or a compliance checkbox to becoming a habit — something we now consider by default in every project.
Personally, it deepened my collaboration with engineering and QA teams, helping me better understand their challenges and how design decisions influence implementation. It also reinforced an important lesson: embedding accessibility early doesn’t just reduce defects or legal risks — it creates better, more inclusive products for everyone.
This project was more than just documentation and process—it was the first step in redefining how we, as a team, think about accessibility. And seeing designers proactively advocate for it, raise questions, and integrate it into critiques confirmed that this shift is here to stay.
Thank you for scrolling all the way!
From 12% to 84%: Scaling Accessibility
Overview
This case study highlights how I led the integration of accessibility into our design process at J.P. Morgan.
I created a framework that helped designers build accessible solutions by incorporating targeted accessibility training and introducing standardized “Greenlines” accessibility annotations.
As a result, designers became more confident applying WCAG guidelines and consistently included accessibility annotations in their work — increasing adoption from 8% to 84%.
Why does accessibility matter?
Globally, over 1.3 billion people — roughly 1 in 6 — live with some form of disability. These may be permanent, temporary, visible, or invisible.
But designing for accessibility isn’t just about inclusive access; it also leads to better, more intuitive experiences for everyone.
Beyond usability and ethics, there’s also a legal imperative. Many major companies have faced lawsuits due to non-compliance.
And from a business perspective, accessibility expands your reach and builds trust.
In short: accessibility isn’t optional at J.P. Morgan — it’s a requirement.
The problem
Despite the importance of accessibility, many of our products still failed to meet accessibility standards. Our QA teams routinely logged hundreds of accessibility-related defects in JIRA, forcing engineers to fix issues retroactively just to achieve compliance.
The root cause was clear: accessibility wasn’t prioritized early enough in the process. Designers often overlooked it, which carried over into engineering and led to inaccessible code, poor user experiences, and significant risks — from legal exposure to reputational damage.
To make matters worse, both designers and engineers across the organization had inconsistent levels of accessibility knowledge. Without a shared baseline understanding, accessibility was treated as an afterthought rather than a core part of our workflow.
What does it mean for us to build accessible products?
Accessibility can take many forms, and the space is complex — but for us at J.P. Morgan, it comes down to one clear requirement: be compliant with WCAG 2.2 AA standards. That’s our baseline, and every product we ship must meet this requirement.
Key players and their responsibilities
So who’s responsible for making sure our products are accessible? Everyone. Designers, engineers, and QA teams all play a role in building accessible solutions. Designers define accessible interactions and annotations, engineers implement them, and QA helps validate compliance. But ultimately, the product team is accountable for making accessibility a priority and ensuring it’s part of the delivery process.
In short: execution is shared, but ownership is not.
The goal
While accessibility involves collaboration across product, engineering, and QA, my focus for this initiative was specifically on the designers’ contribution. I set out to define how designers could embed accessibility into their daily workflow and make it a consistent part of every design we deliver.
From this perspective, the initiative centered on two main goals:
- Educate designers on accessibility — building a baseline understanding of accessibility principles and WCAG guidelines across the design org.
- Adopt accessibility annotations (“Greenlines”) in Figma — making it standard practice to include clear, consistent annotations in every design file.
These goals aimed to ensure our designs were accessible from the start, reducing rework downstream and helping create more inclusive, WCAG-compliant products.
Measuring success
To measure impact, I defined two KPIs and built them into our existing tracking systems:
- Training completion: Designers were required to take two accessibility courses (foundational and advanced) through J.P. Morgan’s Udemy partnership. Completion rates were tracked automatically, with a goal of 100%. Within two months, 96% of designers were certified.
- Greenlines adoption: We added a column to our monthly global tracker where design leads marked each project as Yes, No, or Not Applicable for accessibility annotations. This provided clear visibility into adoption rates across the org and made accessibility measurable within our workflow.
Accessibility training
To support this initiative, I partnered with our global accessibility team to identify two key training courses: one foundational and one advanced. Through J.P. Morgan’s partnership with Udemy, all employees had free access to these courses.
We made both trainings mandatory for designers, distributed them across teams, and leveraged the existing tracking system to monitor completion rates. This made it simple to measure progress and ensure accountability.
Within just two months, 96% of designers completed both courses and earned certifications, establishing a strong baseline understanding of accessibility principles across the design org.
Greenlines (JPMorgan accessibility annotations)
Greenlines are standardized accessibility annotations in design. They serve as a tool for UX designers to clearly document accessibility considerations directly in their Figma files.
In practice, Greenlines help communicate intent to engineers by marking elements like tab order, labels, and contrast requirements, ensuring accessibility is implemented correctly in code. They also act as a reference for QA teams during testing, creating a shared source of truth across disciplines.
Not all WCAG checkpoints are designable
WCAG is a critical standard, but let’s be real: not everything in it lives in the design file.
Plenty of checkpoints are about code, structure, and user interaction — things like semantic HTML structure, proper heading hierarchy, dynamic content updates announced by screen readers, or error handling implemented in code - that’s dev territory.
Designers can’t cover every WCAG checkpoint directly in Figma — and that’s okay.
Making Greenlines reusable and scalable
To make Greenlines easy to adopt, I built reusable components for accessibility annotations and added them to our design system library. Under the Utilities section, I created a dedicated Accessibility category where designers could quickly access and apply these components directly in Figma. This ensured that every designer, regardless of their team, had immediate access to standardized, ready-to-use Greenlines.
Writing a guide
I also created a comprehensive step-by-step guide to show designers how to use Greenlines effectively and apply relevant WCAG checkpoints in Figma. The guide included real examples, clear instructions, and best practices, making it easy for any designer — regardless of experience level — to get started and integrate accessibility annotations into their workflow.
Adoption
Once the documentation was complete, I focused on driving adoption. I presented the Greenlines framework during our Payments All-Hands, attended by hundreds of designers, explaining why it mattered and how to use it in day-to-day work. I then met individually with each of the 12 design managers to align on integrating Greenlines into our delivery process. Together, we updated our definition of done to require every Figma file to include accessibility annotations alongside the final UI.
Outcomes
To track adoption, we integrated Greenlines into our existing monthly tracker, where design managers audited their teams’ Figma files for accessibility annotations. We set an ambitious target of 100% compliance and achieved an average of 84% across the year.
More importantly, we saw a clear culture shift. Designers began proactively raising accessibility questions, incorporating them into critiques, and collaborating more closely with engineers. QA and development teams also started referencing Greenlines themselves, which reduced defects and improved cross-functional collaboration.
Closing thoughts
This initiative fundamentally changed how I approach accessibility — and design in general. What began as a focused effort to introduce training and Greenlines annotations evolved into a cultural shift across our design org. Accessibility went from being an afterthought or a compliance checkbox to becoming a habit — something we now consider by default in every project.
Personally, it deepened my collaboration with engineering and QA teams, helping me better understand their challenges and how design decisions influence implementation. It also reinforced an important lesson: embedding accessibility early doesn’t just reduce defects or legal risks — it creates better, more inclusive products for everyone.
This project was more than just documentation and process—it was the first step in redefining how we, as a team, think about accessibility. And seeing designers proactively advocate for it, raise questions, and integrate it into critiques confirmed that this shift is here to stay.
Thank you for scrolling all the way!
