Designing for accessibility is daunting – until you start doing

For Learnosity Product Designer (former) Jasha Aitchison, a momentary oversight led to a moment of clarity about the importance of accessibility.

As someone who grew up with a family member with a significant physical disability, I thought I might be more tuned-in to the broad spectrum of others’ needs than most people. Sadly, I discovered I was wrong.

My brother was just two when he was diagnosed with Duchenne Muscular Dystrophy. A genetic disorder, it eventually left him physically disabled, with very limited movement from the neck down.

Despite that he’s always been an ambitious person and has rarely let his disability get in his way — either when completing his degree in computer science or when learning how to speak Japanese (he somehow managed to both do simultaneously). 

Like billions more, technology has infiltrated his life over the years. After I relocated from California to Sydney, it was technology that allowed our family to stay connected, communicating as much as possible through a popular messaging app. 

In keeping with my family’s admittedly goofy sense of humor, I decided one day to change the group name in the app to “Boomshakalaka” (TIL the word originates from a 60’s pop song!).

Over the next few weeks, the group chatter continued as normal with one notable absence — my brother. 

He’s always been something of a social butterfly, so his inactivity in the group was odd. One day on a video call I seized the chance to ask why he’d been so quiet. He told me that to open the group chat he needed to use voice activation on his device and say the group name out loud.

I imagined what it must have been like: my brother having to repeat “boomshakalaka” over and over — sometimes when out in busy public spaces — only to be misunderstood by the voice recognition software and locked out of the family conversations as a result. This had gone on for weeks. I was horrified: how could I not have considered the possibility of this happening?

Thinking before you act

Looking back, I realized that I missed a simple step when updating the group name: I didn’t stop to think about how my brother (or my family for that matter) was accessing the group chat. I never considered how he actually left messages in the group, or whether he used a mobile device or a laptop when doing so. If I’d thought about these things from the start, I could have totally avoided the frustration that the name change caused him.

But hindsight is 20/20, as they say. The lesson I took from the situation was to make time for foresight and compassion. As product designer Lucia Liu puts it: “There are many obstacles in designing for accessibility, and the only real tool for finding solutions is empathy.”

Naturally, this applies to my role at Learnosity. As a UX designer who works closely with developers and product managers every day, I’ve gained a deeper appreciation of the impact our day-to-day activities have on millions of learners with all kinds of different needs. 

Living up to that responsibility means meeting as many of those needs as possible. This starts by giving teams the time and space they need to integrate accessibility into product development from the get-go instead of as an afterthought.

Where do we start?

Getting to that place can be a challenge for fast-growing teams who are often tasked with balancing several competing priorities. It takes a shift in mindset to make accessibility an expectation rather than an obligation; something that’s automatically built-in rather than added-on.

“People recognize the importance of accessibility but are often overwhelmed by the idea of executing on it,” writes Timothy Whalin, Senior UX Designer at Amazon. “They don’t know where to start.”

The best way of affecting a mental shift in your company is actually pretty straightforward: take charge by starting somewhere. Accessibility is a front-rank issue so it’s important to become more proactive and less reactive. To get started, here are some simple things you could do:

• Strike up conversations about accessibility with colleagues from different teams
• Exchange ideas and resources 
• Continuously re-examine your processes and look for ways of improving them

Putting accessibility at the center of product development

We kicked things off in the design team by doing a ton of R&D. We wanted to better understand how we worked as a team, what our key values were, and how we approached various design projects.

One of the core design values we developed was “Be inclusive and considerate of users with different abilities”, so we discussed ways we were making that happen and how we might do better. 

To add clarity at the start of each project around accessibility we created a template for an Accessibility Spec.

This is a document in which we dissect a project and look at familiar accessibility considerations such as color, focus states, layout, navigation, interactions, and forms. Because it’s a living document, the specs are flexible by design, which makes it easy for us to tailor them to each individual project.

My brother shouldn’t be considered a “fringe” or an “edge” case; we should recognize that inclusive design is good design.

Bringing them into being for each project is a collaborative effort as design and development come together to outline what considerations the specs should aim to address. They also give us a way to aggregate knowledge from different teams, stir discussion, and identify areas in our products that need attention.

An outline of an Accessibility Spec might look something like this:

Overview
A high-level explanation of what is covered in the document, its purpose, and a templated reminder of a few different ways people might access the product (e.g. people with limited mobility and power users that use the keyboard heavily).

Requirements
A templated reminder of standard accessibility requirements (e.g. “The interface must be navigable by keyboard” and “All elements must have a clearly visible focus indicator that is differentiated by color AND accompanied by visual cues”).

Section for each of the views
In the case that a product can be accessed from different “views” (e.g. in our case, a student view or grader view; we want to make sure we consider the accessibility for all users).

Breakdown of the page and/or components
Within each of the views you can list the page structure, components, focus states, tab order, colors, responsiveness, zoom, forms, and any other considerations specific to the project (e.g. a dynamic page might need some aria-live messaging so a screen reader can inform the user of any changes happening on the page).

Recommended implementations or enhancements
This section is a collection of any recommendations for new products or enhancements to existing products to make them accessible. This is a great way to bring to light any accessibility gaps in legacy products. If you have a design system in place you might find that some of this content comes from it or will be added to it once it’s complete. As these have been considered in collaboration with the product manager and developers, these should end up in a ticket for development.

More than a box-ticking exercise

Even though the accessibility specs act as guidelines when beginning a project, they represent more than a simple “to do” list. Their impact is as much the result of the actual process of putting them together as it is the end product. 

That’s because in working on the specs side by side, design and development teams are free to explore accessibility from a number of different perspectives. Devs shared their thoughts on design ideas while the design team learned more about implementation details from subject matter experts. 

The net success of all this is that it has helped place accessibility top of mind and firmly embed it in the product development process. 

Practice what you preach

But that doesn’t mean we can just sit back and admire our work. Inclusive design doesn’t have a fixed endpoint, it’s an ongoing process. User needs and technology are constantly evolving, which means so too is product design. Setting up some guidelines is a valuable step but there are two things to always keep in mind.

1. Guidelines are not immutable
   Accessibility is a dynamic area that requires constant reflection, discussion, and learning. You’ll always need to add to the guidelines you have, refine them, and scrap any that aren’t effective in making your products universally usable.

2. Users don’t experience guidelines, they experience products
   You can have a list of rules as long as your arm, but they won’t amount to anything unless you work hard to put them into practice and get feedback on them from people with a range of abilities.

Making products accessible to as many users as possible can seem overwhelming but it’s easier when your teams are supporting one another by staying connected and communicating. The more effort you put into running things like accessibility workshops, brown bag sessions, and developing guidelines, the more accessibility considerations simply become a normal part of the process.

My brother shouldn’t be considered a “fringe” or an “edge” case; we should recognize that inclusive design is good design. At Learnosity, and in your own organizations, each of us has the power to make a positive impact by trying to build products that work for everyone. The key is to get started.

Here are some accessibility resources I’d recommend:

• The a11y Project: A community driving easier web accessibility; quick tips, how-to’s, and resources
• Intopia: Accessibility audit and training services
• UX Stack Exchange: Forum to ask questions and read through other designers’ posts on UX and accessibility topics