When Matt May joined Adobe in 2007 as an accessibility engineer, the two most common questions he heard were, “Who are you?” and, “What is accessibility?”
At the time, accessibility in tech and at Adobe was more about checking off items on the Web Content Accessibility Guideline checklist than an area of innovation. Assistive features — like keyboard shortcuts to help blind users navigate a page without a mouse, or adding alt text to images — were add-ons rather than integrated product features, May said.
May’s role more often meant validating the minimal accessibility work engineering teams had done than it did building a more accessible experience.
“This isn’t me just talking about Adobe — this was everywhere I’ve worked,” May said. “Accessibility was a matter of, ‘We need to do this for compliance, let’s figure out what to do to meet compliance and then we’re done.’ It was a series of small engagements that never had any continuity.”
A lot has changed since then. Now, Adobe engineers, designers and product managers can regularly be found trading ideas in an “Accessibility” Slack channel around issues like keyboard interaction systems and API accessibility integrations. The design software firm recently wrapped a project in which they incorporated macOS voice command and speech playback features for the web app design tool Adobe XD. It’s the type of project that has become the norm for the company.
“This isn’t me just talking about Adobe, this was everywhere I’ve worked.”
That transformation is the culmination of May and the rest of Adobe’s inclusion and accessibility teams’ efforts to shift the culture around accessibility. It isn’t just one team’s responsibility anymore, it’s everyone’s, said May, who is now the company’s head of inclusive design.
“Everybody now understands that this is an ongoing process and that the more we integrate accessibility into every phase of the process, the better the outcome is going to be,” May said. “It’s a much more integral part of the experience.”
Getting there required a concerted effort to educate people on accessibility and change the way Adobe approached its products.
Tips For Prioritizing Accessibility
- Take the time to educate all teams on the elements of an accessible product. May ran a training to encourage all teams from design to product, engineering, and even sales, on how to think about and prioritize accessibility.
- Introduce a diversity of users to the team to show how different people engage with the tech. Adobe hosts a speaker series where the company brings in a variety of users to highlight how they interact with tech.
- Take a holistic approach to accessibility. Adobe’s teams integrate accessible design features in the planning phase to create a more fluid experience for all users.
- Leverage accessible APIs. Operating systems already have accessible capabilities built in. Finding ways to incorporate those elements into your product design creates a smoother experience for the user and is easier than starting from scratch.
- Focus on what each team can do to improve accessibility, rather than making it all about the business value.
Educate Team Members Around What Is Possible in Accessibility Tech
“How many people have used a screen reader?”
When May asks this question during a conference or accessibility training, fewer than a quarter of the people in the room raise their hands, he says. Those who have used it have typically only spent a few minutes tinkering with it. The response doesn’t surprise him.
Most of the time, it’s not that designers and engineers aren’t interested in building accessible tech — it’s that they aren’t aware of what’s possible.
“People don’t even know the scope of what they’re designing for, and they don’t even know that a blind user can interact with technology in that way,” May said.
Tech companies have historically done a poor job serving users with disabilities. A 2016 Pew Research study found that these users were three times less likely to own a smartphone or go online, compared to those without disabilities. While companies like Google, Amazon and Facebook have rolled out better maps for users with disabilities, automated descriptive alt text on images and enabled voice recognition tools to create a better experience, many websites and software still lack basic accessibility features, reports CNet.
“People don’t even know the scope of what they’re designing for, and they don’t even know that a blind user can interact with technology in that way.”
Meeting compliance doesn’t necessarily lead to a better experience for users with disability, either. When the Naval History Museum website went live, every image had an alt text labeled as “Image for placement only,” May said. It met regulatory compliance, but it didn’t account for how a blind user might engage with it.
To raise awareness at Adobe, May implemented mandatory accessibility training for everyone at Adobe Design to educate them on what’s possible in the assistive tech space. From April of 2019 to January of 2020, May hosted 11 sessions in nine cities with co-presenters from across the tech industry with expertise in inclusive design.
The sessions allowed May and his team to talk about common mistakes and how they limit the experience of a user with any specific disability. It also gave team members the tools to think creatively about accessibility and how to integrate it into the product from end-to-end.
During one training, the design team receives three laser-cut tiles titled label, role and group and an artboard of an existing app. Participants are then told to break down the underlying structure of the app and label each part based on the three tiles. The exercise never fails to stimulate lengthy discussions and arguments, May said.
“Once you can explain how applications are structured underneath it all and how people interact with them, then it opens up a whole new layer of human-computer interaction,” May said. “It’s like they start seeing the Matrix.”
Still, it’s one thing to understand accessibility best practices, it’s another to understand how a blind user consumes information on a screen through a 40-cell braille display. So, May and his team have brought in speakers to introduce those users to the team.
“If people building the products and designing the products are educated and have opinions that they’re excited about and vocalizing the importance of accessibility and inclusive design, they’re going to do things that no one is telling them to do.”
The last speaker they brought in was Leonie Watson, who is the director of the inclusive tech consulting firm TetraLogical. Watson, who is blind, showed off her 3-D-printing work and discussed her involvement in teaching soldering to blind users in makers labs and designing websites.
“A lot of this comes down to actually exposing to people the fact that people can do this stuff,” May said. “Not only is this something we can enable, but there is a user base for it and they want to be able to use these tools. The only way we can find that out is by working with them.”
The training and speakers series have helped inspire each team to think about what they can do to improve accessibility, said Cameron Cundiff, a computer scientist at Adobe. Now, when a product is being built, there’s a back-and-forth exchange on accessibility between design and engineering — something that never would have happened without the training.
“The education part of it is so vital because there has to be this leadership message,” said Cundiff, who co-founded New York accessibility meetup group, A11yNYC. “If people building the products and designing the products are educated and have opinions that they’re excited about and vocalizing the importance of accessibility and inclusive design, they’re going to do things that no one is telling them to do.”
Make Accessibility Relevant to Each Employee’s Role
One of the most frequent mistakes May made early in his career at Adobe was trying to make a business case for accessibility.
It’s not that there isn’t a lot of value in building products that all users can access, but approaching it that way turned accessibility into a trade-off.
“Everyone wants to hear ‘Yes, you can have the resources to do this work,’ but what ends up happening is that people try to horse trade,” May said. “If you say ‘Do this thing for me, and you get this bag of money,’ they’re focused on the bag of money. It always ends up leading toward an outcome where the money is more important than the accessibility.”
“It’s about making cases that are relevant to what this person is trying to get done so that you can both get what you want in a common spirit.”
Instead, May positioned accessibility as a fundamental part of Adobe’s products. When an engineering manager asked questions like how many people would use a particular feature, May made the conversation about their responsibility and how they can make the product more accessible. If they didn’t listen, he’d go to another leader in the business to champion the cause.
While that doesn’t happen anymore, learning how to speak to what each team can be doing to improve accessibility helped change the way the company approached it.
“It’s about making cases that are relevant to what this person is trying to get done so that you can both get what you want in a common spirit,” May said. “Accessibility has to be the desired outcome from the beginning.”
Accessibility is now just a part of the product’s development, like security. If a product doesn’t meet accessibility standards, it doesn’t ship.
Think Holistically About How Accessible Features Will Operate Within a Product’s Design
For engineers developing accessible tech, it can be easy to treat each feature like a to-do list of items to be crossed off. Semantic labels, check, keyboard interactivity, check, voice control integration, check, balanced color contrast, check.
But even if every feature is included, a product can still be inoperable for a user with a disability if the features aren’t intuitive or integrated together, Cundiff said. Instead, it’s critical for engineers to think like designers and figure out how different users will actually interact with each feature, what interfaces they’re using and what’s most natural for them.
“I think a lot about how someone actually interacts with the content of this application, and then based on that, can they actually do it?” Cundiff said. “If their intent is to open a modal and they give it a bunch of inputs, can they do it, given the architecture of the application?”
Fortunately, the outline for how to do that is readily available. Every major platform, from macOS to Windows desktop to the web come with an accessibility API, Cundiff said. They have the components in place that can be read by a screen reader, navigated via keyboard and accessed with voice commands.
It’s up to the engineer to add those native buttons and label them appropriately to properly tap into the accessibility API.
When Cundiff worked on the voice command integration of Adobe XD, he used standardized NS buttons in the toolbar and a lot of the standardized components the platforms provided. From there, he just had to focus on enhancing the labels to integrate with the accessibility API to be accessed via voice control.
The quality of the product came in thinking about all those components from the inception of the product and the design stage.
“That’s where the robustness comes from: it’s in the design process, thinking of all the different ways someone could input and actually receive information out of this design,” Cundiff said.
But labels can often fall short, May said. It’s not uncommon to run into a website where every button is labeled “Button,” meaning a blind user would have no way to differentiate between a “delete” button versus a “submit” one. May encourages the design team to turn on voice-over to hear to see how each app’s feature is labeled and differentiate between what’s on screen versus how accessibility interacts with it.
“That’s where the robustness comes from: it’s in the design process, thinking of all the different ways someone could input and actually receive information out of this design.”
Ultimately, building accessibility into a product is an interactive process, May said. While Adobe tests products with users with disabilities and those without, there is no one type of disability. There are different degrees and types of disabilities, along with previous experience levels with the product. Those all impact the user experience and are equally important to consider, May said, so accessibility needs to be a constant conversation among the teams.
“We have a lot of different user scenarios and disability is one aspect of it — and a really important one that tends to get swept under the rug if people aren’t comfortable talking about it,” May said.
Give Teams Creative License
Now, when May talks with teams about accessibility, it’s no longer about what needs to be done to meet compliance. Instead, it’s about improving the accessible experience.
Employees across all teams are asking him for places they can go for research, strategies for speaking with users with disabilities about their experiences, and ways they can develop professionally when it comes to accessibility design.
“There’s a collaboration and back-and-forth around how we’re going to make it happen.”
“Those are the conversations where we don’t feel like we’re the only ones coming up with the ideas,” May said. “There’s a collaboration and back-and-forth around how we’re going to make it happen.”
It’s a lot more to keep up with, May said, but it also means each team is growing. For him, that’s a success.
“It’s great for my job satisfaction because I’m not repeating myself all the time,” May said. “I don’t feel like I’m the only one pushing the rock up the hill all of the time.”
