Smart phone in landscape view. Right edge is elongated, blends downward and continues underneath, forming a left-facing arrow, representing the shift left concept. — Illustrations by Alisha Giroux.

An inclusive design workflow for product teams

How and why the Flagship Themes team made accessibility a priority in the design process

Published in

Shopify UX

14 min readMar 16, 2022

When it comes to digital products, such as websites or mobile apps, accessibility has traditionally been considered near the end of the product creation lifecycle, if at all. In a typical project timeline it’s usually the Quality Assurance (QA) team’s responsibility to test and report issues.

The problem with this workflow is, by this point in the project when QA begins, core product decisions have been finalized, designs have been signed off, and development work is just about ready to ship. So much work has been completed and all the while without considering how people with disabilities using assistive technology (AT) may use the product, leading to unintentional barriers to access and costly sprints to retrofit.

As an industry we need to be mindful of inclusivity. Publishing user experiences with accessibility issues is like erecting a brick and mortar store without accessible parking, wheelchair ramps, or accessible facilities. This form of discrimination and ableism isn’t tolerated in the physical world around us, therefore, it shouldn’t be tolerated in the digital space either. The truth of the matter is people with disabilities who rely on AT often face difficulties when using web sites or mobile apps, especially during the Covid-19 pandemic when many businesses moved online. So how do we rectify this situation?

As an industry we need to be mindful of inclusivity.

Enter the concept of “shift left”. Specifically, shifting accessibility left in the product creation lifecycle. At a high level, this involves moving inclusive-design thinking earlier in the process. Before a developer writes their first line of code, even before a designer pushes their first pixel, consider how someone with a disability may perceive and use your product. Shift left as early as you can manage; during ideation, persona writing, or prototyping. As a result, barriers to access will be caught and addressed throughout each flow of the process, paving the way for highly-accessible user experiences by default.

How we approached this

As an accessibility specialist at Shopify, I’m in a unique position. I’m a front-end developer by trade, yet, I do not write or ship code. Why? There are already many talented front-end developers at Shopify. Instead of doing the work myself of writing “accessible code”, I work with teams and individual contributors (ICs) to embed accessibility best practices into their daily workflows. I share knowledge gained by years of experience through issue tickets, conducting internal training sessions, and hosting accessibility office hours. This is one part of our strategy to scale and build a culture of accessibility at Shopify.

More specifically, in terms of shifting accessibility left in a team setting:

I work with our designers by reviewing design files for visual design accessibility best practices and annotate designs to create accessibility specifications for developers
I work with leads to make sure accessibility is included on project roadmaps and deliverables, to prioritize time for training, and to set up sprints to address existing issues
I work with our developers by reviewing code, testing user interfaces (UI) with assistive technology, reporting issues, and sharing insight in to how to code for AT consumption
I also host usability test sessions with people with disabilities to gain further insight into what makes for a great user experience and to move our UI above and beyond accessibility laws and policy compliance

I’m currently positioned on the Flagship Themes team. Our team is responsible for creating Shopify’s free OS 2.0 themes. Not only do we have the opportunity to create beautiful themes for our merchant storefronts, we also have the responsibility of making sure our themes ship highly accessible by default. The storefront should be easily navigable no matter which AT is in use. When a merchant installs one of our themes and uploads their content, shoppers with disabilities should be able to perceive, operate, and understand the UI which they’re interacting with.

Let’s dive into the specifics regarding the “inclusive design workflow” I’ve created to achieve that. These are the steps which the Flagship Themes team has been following in order to ship accessible components by default.

When a merchant installs one of our themes and uploads their content, shoppers with disabilities should be able to perceive, operate, and understand the UI which they’re interacting with.

The general idea of this workflow is to identify potential barriers to access during product creation. Specifically, during the design phase and by extension, during development. By the time a developer wishes to release a new feature, there should be very few to no issues found by an Accessibility Specialist during code review. And as a result, there should be very few to no accessibility issues shipped to production.

A hand holds up a puzzle piece, representing accessibility as the missing piece of the product creation workflow.

The inclusive design workflow, part one: Design

Part one of the inclusive design workflow involves working with designers and our design files.

Our design team works exclusively within Figma to create new themes and produce component prototypes. In order to document designs for accessibility best practices and create specifications for our development team, I use the A11y Annotation Kit, a free Figma community asset.

1. Ready-for-review notification

Before the designer hands off their final design to the developer for implementation, the designer will notify the Accessibility Specialist for review. This is accomplished by pinging the Accessibility Specialist in a Figma comment or sharing a direct link to the Figma page via Slack.

2. Inclusive design review

The Accessibility Specialist will review the design with a strict inclusive design lens. The purpose of which is to check for visual accessibility best practices, such as color contrast, focus indicators, focus order, control hover/focus/active state, clear labeling, and not relying on color alone to convey information.

The Accessibility Specialist will include notes and annotations for developers on recommended markup, including: HTML elements and attributes to convey role, name and state, expected keyboard support, suggested aural user experience (such as including visually hidden strings which are visually represented as an icon or glyph character.) A new Figma frame will be created with the name “A11y Annotations”. This frame will contain all notes and A11y Annotation Kit asset layers.

If the design is particularly complex, the designer and Accessibility Specialist will meet to discuss the details of the UI. It’s of critical importance for the designer to share details and insight such as:

What is this element?
What does it do?
What is the end result of interacting with the element?

With this information, the Accessibility Specialist will be better equipped to annotate the design with accurate details.

3. Review complete

The Accessibility Specialist will inform the designer of the completed review. At this point the designer will ensure the Figma file is in a good state for developer handoff (organized to their preference, etc.)

4. Developer handoff

The designer will check the “accessibility review complete” checkbox. This is a checkbox which appears in the component issue on GitHub. This conveys the review has been finalized by the Accessibility Specialist.

A link to the annotated Figma file should be provided in the GitHub component issue for developer convenience.

In summary, the designer passes the design file to me for review, I review and create the accessibility specification via annotations, then the designer hands the design over to the developer to implement. This may sound like a siloed way to work, but there’s regular discussion and iterations of a component between team disciplines. When all parties are in agreement, we move on to implementation.

The inclusive design workflow, part two: Development

Part two of the inclusive design workflow involves working with developers and code. All of our product teams work in trifectas of disciplines: design, development, and product, so this workflow is tightly coupled with development, too.

Our development team manages theme code in GitHub. When a new component has been built based on the Figma design file, a pull request (PR) is created. This means a developer wishes to merge code into the theme. Before code is merged, I review to ensure the accessibility specification was followed and thoroughly test the component with assistive technology.

1. Review and implementation

When the design handoff is complete, the developer will review and implement the accessibility specification as noted via Figma design annotations. Annotations and notes will be found under the “A11y Annotations” Figma frame. Incorporate each annotation into your code, including recommended HTML elements, attributes, role/name/state properties, expected keyboard support, focus order, and focus management.

The developer is encouraged to reach out to the Accessibility Specialist for clarification on any notes or annotations as required.

2. Ready-for-review notification

When the developer has implemented the accessibility specification, they will notify the Accessibility Specialist for review. This is accomplished by pinging the Accessibility Specialist in a GitHub comment, or sharing a link to the PR via Slack.

3. Verification and testing

The Accessibility Specialist will verify the accessibility specification has been implemented. This is accomplished by reviewing the component code and testing the component using AT. Recommended code adjustments will be noted in the GitHub PR.

For particularly complex UI components, the Accessibility Specialist will host usability test sessions with people with disabilities. The purpose of which is to not only ensure a baseline user experience of meeting WCAG 2.1 Level AA, but to go above and beyond mere compliance by implementing usability feedback.

4. Review complete

When the Accessibility Specialist has completed the review, they will notify the developer via GitHub PR approval.

Timing is everything. As a team we do what we can to ensure all of the above is completed before code merge. If this is not possible due to critical/time sensitive changes, the developer will merge as needed. As a result, I’ll review changes in production, but this is to be an exception, not the rule.

Real-world example: Dawn slideshow component

I recall our first attempt at this workflow involved one of the more complex component patterns; a slideshow (a.k.a. a carousel.) I know some readers of this post likely have particular feelings about implementing a slideshow component (check shouldiuseacarousel.com). However, this was a highly-requested feature from our merchants, and we’re here to serve our merchants.

And like any other component that we create and make available for merchants to place on their storefronts, it must be made accessible by default.

The slideshow design in Figma showcasing accessibility annotations.

This image showcases the annotations for the slideshow component. Notice the details for the developer to implement, including:

HTML structure
Headings and landmarks
Control elements
Attributes to convey role, accessible names, and state
Focus order
Alt text
Suggested aural UX (screen reader user experience)

All annotations are carefully crafted and are intentional in order to provide a great user experience for many user groups. This includes sighted mouse/touch users and people who rely on assistive technology, such as a screen reader, screen magnification, or voice dictation software.

The slideshow component annotations were based on the WAI-ARIA Authoring Practices 1.1 — Carousel pattern. I felt this would be a good place to start in recommending keyboard support, document structure, control elements, attributes, and state for the carousel component. If you’re unfamiliar with this resource, the patterns outlined here are a good starting point when designing complex user experiences, though be sure to get feedback on the implementation via usability testing.

And like any other component that we create and make available for merchants to place on their storefronts, it must be made accessible by default.

During the slideshow component conversations between designers and developers, I hosted a few usability test sessions via Shopify partner Fable Tech Labs. For the most part, these sessions were successful. People using screen readers and screen magnification software were able to perceive and use the slideshow with their assistive technology.

In one session in particular, a screen reader user got stuck when navigating the slideshow content. This was due to the auto-rotating feature not being paused on keyboard focus (as it’s not possible to detect the screen reader virtual cursor position in the document.)

When a rotation occurred and the current slide was removed from view, the screen reader virtual cursor focus position would be “reset” to the top of the slideshow container. The tester eventually switched to heading navigation to move past the slideshow component.

When it came time to ship the slideshow component, it was done so with high confidence that we’d created a highly usable and accessible slideshow by default.

To help screen reader users avoid this issue in the future, I made the recommendation to move the slideshow controls to the top of the container only when auto-rotation is enabled. With this change the user would discover the controls, pause the auto-rotation, and then consume the slideshow content at their leisure.

Throughout these sessions the testers were happy to point out specific improvements which would make the experience even better (moving past WCAG compliance.) This improvement feedback was shared in the slideshow PR for developer implementation, and added back into the accessibility specification in Figma.

As a general note, changes or updates to a component which arise as a result of team discussions or usability testing should be reflected back in the Figma design file. Since this represents our accessibility specification, the “single source of truth”, it’s important to have accurate and up-to-date documentation of the accessibility of our components.

When it came time to ship the slideshow component, it was done so with high confidence that we’d created a highly usable and accessible slideshow by default. Suffice it to say, shipping the slideshow component was a big moment for the Flagship Themes team and for accessibility at Shopify; this was the first time I’ve been on a project where accessibility was baked in from the very beginning. I’m very proud of this team and the work we’re doing to provide free, highly-accessible themes for our merchants.

Room for improvement

Of course, there’s definitely room for improvement. Though this workflow is currently unique to Flagship Themes, it’s also flexible to include accessibility in other steps of product creation and portable to be adopted by other product teams.

For example, including people with disabilities during early product discussions or hosting usability sessions for prototypes. This would help to remove potential barriers and create more inclusive products even earlier in the creation flow. Also, providing more training for my team would help to scale accessibility and inclusive design thinking. While this would increase the accessibility knowledge within the team, it would have the effect of lowering the amount of testing required on my part. Thus, carving out more time to dig deeper with other assistive technology and usability testing.

If there was one takeaway from working this way, it’d be that communication is everything. When I first started on designing this workflow, I originally wrote two internal documents, each outlining the inclusive workflow model for our design and development teams. I then set up two meetings with both groups to go through the respective document to make sure everyone understood its purpose and to answer questions. These initial meetings were a success as folks on both teams agreed this work would be important for increased success and adoption of our themes. But as new folks join our team, I’ll need to make sure to re-communicate the expectations embedded within this workflow. It’s also important for others on the team to share when their work is ready for review as the timing of each phase of this workflow is critical for success. If a design is handed over for implementation or code is shipped without a review, there exists a chance for access barriers to leak through.

Why this workflow… works

I feel it’s worth mentioning why I believe this workflow works and works well for the Flagship Themes team specifically. To put it simply, everyone on this team is on board with shipping accessible themes. From team leads to designers, content strategists, and developers, there exists an understanding of why accessibility is important. There’s no need to convince anyone of why this matters by making a business case for accessibility or having to justify that accessibility is a human right. It’s clear and understood that accessibility is the right thing to do–full stop.

It’s clear and understood that accessibility is the right thing to do–full stop.

In addition, I think there’s one other piece to point out as to why this works: the team knows me and trusts my recommendations. And I believe that’s key; trust. As a member of a team you need to trust your teammates and their expertise to build the best products for your customers. This includes that one person on your team who constantly talks about how inclusive design makes for better UX!

As previously mentioned, this workflow is part of a larger initiative to scale and build a culture of accessibility at Shopify. This workflow is meant to be portable, meaning if I were to switch teams at some point, I could introduce this workflow as part of my new team’s strategy to build equitable products. We’re also planning to hire more accessibility specialists onto product teams over time. As they get started in the role, this workflow could be used as a blueprint for specialists to implement into their team rituals.

Keep the conversation going

Accessibility is to be considered and acted upon alongside other core product principles such as security, performance, and mobile-first design. People expect these to be implemented by default. This also includes the expectation that digital products will work with assistive technology. Shifting accessibility left in the product creation lifecycle is one way to remove unintentional barriers to access, avoid costly sprints to retrofit accessibility into your product, and, most importantly, make your product available for more people to use and enjoy.

Meaningful change happens when you humanize the process.

If we as a society had a better understanding of disability and accessibility, I believe people would react differently. They’d approach the problem with empathy and compassion rather than indifference or pushback. By talking about these topics more often, we normalize the conversation and remove stigmatization. After all, “[disability] is just something that’s part of what makes people who they are.”

If you’re on a product team, I encourage you to try and implement a similar workflow. Reach out to your local Accessibility Specialist with questions or blockers you may be facing. If you don’t have an Accessibility Specialist on your team, share this post with your team lead and get them to hire a specialist. A dedicated Accessibility Specialist will help your team succeed in digital inclusion by:

Staying abreast of new or upcoming accessibility trends and technology, thoroughly testing existing and new components, and helping to build a culture of accessibility by being proactive rather than reactive
Providing growth opportunities for all team members by way of inclusive design training tailored for your product, setting role based expectations, and incorporating accessibility tooling into everyday workflows
Working with leads to set clear objectives for including accessibility on project roadmaps and deliverables, setup quarterly accessibility sprints to retrofit existing products, and provide data on progress for senior leadership

Meaningful change happens when you humanize the process. By openly communicating across disciplines and being mindful of accessibility best practices while we work, we’ll achieve equity in our digital products. Let’s keep the conversation going.