Creating an Accessible Culture

Making commerce better for everyone is our mission at Shopify, and over the past months, we’ve talked about the importance of accessibility in that work. We’ve shared a lot about what we’ve built and shipped, and in this seventh and last post of the series, I want to focus on the teams and processes that helped us get here.

You may have noticed there hasn’t been mention of an “Accessibility Team” at Shopify, and that’s because there isn’t one. Our accessibility initiatives didn’t begin with a formal process or mandate. Instead they began with the work of a few individuals working on separate product teams. That early group focused both on making accessibility improvements as well as introducing accessibility to more people at Shopify. We recognized that most developers and designers aren’t familiar with accessibility or may even have existing misconceptions that it leads to reduced functionality or design creativity. An early goal for the group was to dispel those myths, show that small changes can make an impact, and convey that anyone can get started, even if they’re not an expert (yet!).

Within individual product teams, it didn’t take much to encourage others to write more semantic HTML or talk about where color contrast was working against us. It helped that these early accessibility-focused folks were vocal, and discussions and new allies started spilling across to new groups. Here’s how through a few new and existing initiatives we’ve been growing the group of accessibility allies and experts at Shopify:

1 — Bring the discussion to the day-to-day

We wanted to encourage discussion in the day-to-day, so we’ve created a few resources that are easy for anyone to check. At Shopify we’re big fans of Slack, and an #a11y channel was inevitable. Here, people from all teams and disciplines share learning resources and can get advice on how to approach features. Next, all code goes through review via GitHub pull requests, so we’ve also created an #a11y GitHub group that can be pinged for advice at review time. The group can help with anything from testing features to providing guidance before a feature ships. Finally, we’ve curated a list of common accessibility requirements anyone can start implementing. It’s not exhaustive, but it’s enough to get started with and make an impact. The goal in all of these resources is to bring down the barrier to entry for developers new to accessibility. Nearly anyone who has ever googled “How to make <X> accessible” will recount a story of misinformation, confusion, and the temptation to throw in the towel, but we’ve found that by making the information digestible and easy to access, more of the team can build their skills.

2 — Make it embeddable and shareable

Easily initiating people into accessibility was crucial to making it widespread across Shopify. One way to do that was through the re-usable pattern library our UX team had built, that includes component code used across our applications. Making sure these components were accessible was an obvious place to start. In the UI library, elements like form fields for example have standard markup across all parts of our Admin that developers apply using an API.

Screenshot of Shopify form fields and the code helper developers use to build their HTML

In this example, a developer can pass in the form field and suggested help text, and the component will spit out the appropriate input, label, and help text using the correct HTML and ARIA attributes. The helpers generate accessible markup but also provide an easy way to update and fix any bugs because that raw markup exists in a single file that gets reused. As we found more complex use cases for error states for example, we were able to update the helper’s markup and the improvements were made available to the entire application. The build-it-once, use-it-everywhere model has meant that the accessibility knowledge of the developer who built this module is now available to our entire team, and our Merchants get a consistent, accessible form interface, each and every time.

3 — Make it Real

Beyond making information available, our other major goal has been to make the issue more visible for more of our team. Accessibility isn’t for some hypothetical audience, it’s about people trying to use our product. Arthur described the user testing session he helped organize, and a crucial element to that testing session was that it was live streamed it across all our offices. Having the team watch a user struggle with the software they’ve designed and built wasn’t easy, but it drove the team to action. We’ve ran a few live streamed tests since that initial one, and that initial frustration is made up for each time we witness a small improvement over the last round of testing. Real user testing is something we will continue to do and make available to the wider team, both so they can feel our users’ frustration, but also see first-hand the impact of their work.

4 — Share your Lessons

Baking in accessibility means not everyone needs to be an expert, but we still want to grow more expertise within the team. To do this, the group leverages the several cross-company learning opportunities already established at Shopify. The Front End Development (FED for short) team for example has weekly cross-company “FED Talk” meetings where the whole team gets together to share their work. Here, people might share various strategies for making components more accessible, or ask advice on a specific bug. Because these are cross-company, it means that wins from one product area of Shopify can more easily be applied to another area, and we’re reducing the odds of duplicating our efforts. It’s also a great space for anyone new to accessibility to ask whatever questions are on their mind.

Outside of FED, we also do cross-company “R&D” talks that reach all of UX and Engineering. These are conference-style presentations that the team has used to introduce various a11y topics to that wider audience. Authors Ryan and Dave did a joint talk introducing the team to color contrast and HTML validation tools as one example, and our entire RnD team had a chance to learn about the topic.

5 — Keep pushing

Finally, we want to keep pushing ourselves as a company, and as more people learn the basics, we need to hold ourselves accountable to a high bar. This summer, leads and contributors from across the company began meeting regularly to start setting more aggressive goals and keep each other accountable. Sharing roadmaps and setting aside specific time means efforts will now be more deliberate across the team. The group still isn’t a dedicated Accessibility Team. They continue to work in their specific disciplines and product areas as described above, but that’s also because we feel that accessibility is part of everyone’s responsibility. This group aims to set goals and create resources, but we want to keep encouraging product teams to own their work. We expect more challenges and successes coming up, but having a group to keep us accountable will help keep our momentum.

A Culture of Fostering Growth

At Shopify, we encourage the team to follow their passions, and this probably had the biggest impact on spreading accessibility to the wider group. Everyone at Shopify is treated like an owner: we hold each other accountable and, more valuable, we encourage everyone to keep going when they find something interesting. We love seeing growing expertise, especially in new areas, and because of that, it isn’t surprising for teams to start introducing new topics to focus on. The growing attention on accessibility was interpreted as a new competency and area to learn about rather than a new set of rules to follow.

There’s a lot still to be done — more than what a handful of people can reasonably accomplish — but a remarkable thing has happened because of their work so far. Where we started with very little accessibility understanding, over the past year it’s slowly become part of the regular conversation at Shopify. More teams are picking up screen readers for the first time, are asking about keyboard implications of a user flow, and wondering how we can extend some of our best practices to our Partner community, all because of the efforts of a few passionate people across the company.

Slowly we’re seeing more and more people discover the direct impact they can have on our merchants by focusing more on accessibility. We’ve heard in this series from Front End Developers, Designers, and Content Strategists, but the actual work couldn’t have been done without the support of our Engineering, Product Management, Growth, and still other teams. It’s been a true collaboration across the company.

My favorite part has been watching people completely new to accessibility become super passionate about the topic, and it’s been a privilege to have seen this happen a few times over. I’m incredibly proud of the work done already, but am even more excited by what’s to come.

Make commerce better for everyone, consider joining our team.

Sending a huge thank you to Jaime Woo for helping with this series.