top of page
CASE STUDY
How Marketplace adopted and scaled web accessibility as a design practice
My role📝
I worked with my manager, as the team accessibility champion to drive a11y adoption within the design team and cross-functional crafts, and to come up with a scalable accessibility strategy.
Impact⏳
The Marketplace team had the highest a11y adoption points tracked among all design teams. All hand-offs were done with AA-compliant specs, followed by build reviews. Go to impact stats >
First off - why even be accessible? We learned it the hard way...
For long, accessibility was considered as a good-to-have for any roll-out.
It wasn’t until we received MUCH flak on community channels for poor accessibility that we realized the loss of user base and trust. The team recognized an issue and set a goal to be AA-compliant for all future releases.
FY 24 Design OKR - Build Enterprise-grade usability
Accessibility forms one of the pillars identified to reach Enterprise grade baselining against competitor products.
So, how do we begin?
Deque Systems, a provider of accessibility tools, found 67% of issues originate in the design phase. Thus, it's crucial to prioritize accessibility from the beginning. Tasked with driving adoption, I researched accessibility-forward companies and consulted with the internal team for insights into ideal a11y-incorporated design process -
Raw Studio and "Understood" were helpful in identifying the a11y intervention points
The flowchart made it clear that to create an accessible product, the entire triad had to be on board. Secondly, this process was more suited to projects being built from scratch - but we already had a running product in place.
Hence, the next step was to:
-
come up with the least-resistant path to include a11y in our existing roadmap projects, and
-
assign drivers among the stakeholders to lead their craft
Historical challenges with implementing a11y
While various attempts have been made at incorporating a11y, there has been no attempt at fully quantifying the entire scope of accessibility work, with a formal recommendation for standardized practices and implementation strategy. Issues included:
To work on the strategy, I started by going over our roadmap and identified 2 distinct project typologies in terms of a11y opportunities:
With an immediate opportunity at hand for project Type I, we decided to first focus on strategy for this. My manager and the design leads helped with evangelizing the strategy and getting the triad onboard.
Week 0 to 1: Choosing the right approach
Redesign of Marketplace’s discovery experience - how can we design and execute an accessible experience within the given timelines?
Challenge: A strict timeline had already been allotted. On adding a11y in scope, developers expressed concerns with some AA pillars like text-zoom which would require significant upskilling and time. To mediate this, I came up with proposals for progressive a11y incorporation:
After a stakeholder discussion, we decided to go ahead with option 3 of scaling up from A to AA compliance progressively while prioritizing low-vision, keyboard, and assistive technology user cohorts respectively.
Weeks 1 to 2: Creating a gameplan with shared responsibilities
After understanding the process, I identified stakeholder responsibilities for moving the project forward. I researched processes, discussed with the accessibility team, and shared the breakdown with the team. The final breakdown was as follows:
*Illustrations used from StorySet
Since the design team had already created the designs at this point, we had to revisit them and spar it with various accessibility champions, while developers set ground to implement a dashboard.
Weeks 3 to end of project: Supporting the process
Key drivers were identified from each craft to start the project. I communicated with POCs regularly to update the framework. As we progressed, I made process changes and developed artefacts as needed to standardize and eventually scale the workflow.
Week 9: Retrospective and re-use
As the project went live, the team did a retrospective call to summarize our learnings:
-
Accessibility must be considered as early on as in the quarterly planning stage to ensure enough bandwidth is allocated.
-
Constant monitoring and upskilling is needed
CLOSING THE FEEDBACK LOOP -
Templates: We shared the bug blitz and prioritization templates with the Central a11y team for further iteration to reach a share-out stage.
Components: The re-designed components were sparred with the ADS (Atlassian Design System) team but were built independently by us. We shared the new component designs with the Central a11y team for consideration to update their system.
The question of incorporating a11y in projects of Type II remains...
Impact
-
Redesign launched was 100% AA-compliant
-
The team adopted a new, a11y-inclusive way of working in both design and code
-
We now had newer components and interactions with in-built accessibility
Post-roll-out, we noticed a ~66% drop in the violations caught by Axe Scanner and an overall positive reaction from the community. Here are some of the changes that helped us get there:
Accessible visual design
Modal (before)
Modal (before)
Modal (after)
Accessible interactions
Older loading pattern (Inifnite loading)
New loading pattern (Finite loading)
Optimising for keyboard users
Before - invisible focus state (search field)
8 repetitive tab stops to go through each app tile
After - visible focus state
Redesign to only 2 tab stops per tile
Thank you for your time!
bottom of page