Accessibility is more than a technical problem

By Devon Persing | Shopify UX, April 21

Debunking these 3 myths will help you rethink your accessibility work

Accessibility is more than a technical problem to solve. (Sorry to break it to you.) But accessibility work isn’t actually hard to do. The tricky part is appreciating the complexity and breadth of disabilities that impact your users.

In this post, I’m going to help you rethink accessibility work and give you some practical tips for making your products and services more accessible, more easily. To do that, I need to debunk some myths.

I’ve been doing accessibility work full-time for about 10 years, so I’m pretty familiar with some of the myths surrounding accessibility work. I work as a technical program manager focused on accessibility and tooling within Shopify’s UX Operations team.

Myth #1: Disability is simple

There’s a myth around accessibility work that disability is simple. Or, maybe a better way of saying this is that disability is monolithic. “Disabled” is not a user type. Disability is often dynamic and situational.

To start, it’s important to know that 26% of adults in the United States, 22% of adults in Canada, and 15% of people worldwide have a disability that affects their daily lives. There are a few common types of disabilities, which can be organized into a few categories:

  • Dexterity and mobility
  • Cognitive and neurological
  • Vision
  • Hearing
  • Speech
  • Vestibular and motion

As Brianne Benness, who runs the ‘No End in Sight’ community on Twitter, says: “In mainstream culture and media, “disabled” usually refers to people with static and visible disabilities. … And so, if I tell somebody that I am disabled, I must explain that not all disabilities are visible and also not all disabilities are static.”

Using the social model of disability, disability is a mismatch between a person and the environment that has been designed. The negative impacts of disability are caused by systemic barriers, attitudes, and exclusion in society — not a failing of the person with a disability, nor something to be “fixed” or “overcome” in the person.

For example, I have a highly dynamic, “invisible” disability that impacts me differently day-to-day. I have fibromyalgia, which is a chronic pain disorder. On a good day, I can get away with having stiff joints that work loose as the day goes on. On a bad day, I might be in pain and have issues with visual and auditory processing, which often leads to brain fog, and makes balance and coordination difficult. Over 22% of Americans have arthritis, fibromyalgia, or similar chronic pain disorders, so it’s fairly common.

People like me, with dexterity and sensory issues, use a variety of different types of keyboards without a mouse or touchpad, including ones that are built for use with one hand, customizable, or completely lacking keys at all. You can also use VoiceControl on Apple products or similar tools on other platforms to completely control your device with your voice, without touch. I use VoiceControl or dictation on days when I’m experiencing a lot of arm and hand pain, for example, but not all the time.

Often when I talk to designers and developers about assistive technology, they get stuck on the idea of the screen-reader experience being the accessibility experience we need to work for. But, considering the broad diversity in disabled experiences, people with disabilities use a wide variety of assistive software and hardware tools to connect to technology, and some people with disabilities don’t use assistive tech at all.

For people with dexterity and mobility issues, there are also eye-tracking technologies that let you interact without touching a device at all. There are similar hardware and software combinations that let users interact through a switch device, by pressing simple buttons or doing small movements with their head or mouth to control the mouse.

One of the most common vision tools is the High Contrast theme in Windows, which allows users to change colors across the operating system and in the browser. This is used by people with vision issues, as well as visual sensory issues. It color codes different types of content, based on the user’s settings and based on how the page is marked up. There are other tools that invert colors to add permanent “dark modes” for content that many people use as well.

Picture of a computers settings.

Reader mode in the Safari and Firefox web browsers allows you to strip out all ads, navigation, sharing buttons — anything that’s not an article while you’re reading. It also gives you options for changing fonts and colors. It’s designed to make it easier to read without distractions or without complicated layouts.

For example, see how this Shopify Help Center article page (shown below) displays differently in Reader mode in Safari and Firefox:

Picture of an article page from the Shopify Help Center.
Picture of the same article viewed in Reader mode in Safari.
Picture of the same article in Reader mode in Firefox.

Ultimately, we all need a greater awareness of how people use (and don’t use) assistive tech. Pre-COVID, Shopify had device labs equipped to help UX folks do testing with assistive technologies. Since Shopify is now Digital by Default, we need to come up with other solutions.

To fill this gap, I’m collaborating on building a virtual assistive tech lab, working on improvements to our internal documentation, and providing clearer guidance about how and when to use assistive tech when testing new features and products. Testing with assistive tech should never replace testing with automated tools first, when they’re available, or working directly with users or research participants with disabilities who use assistive technology (and those who don’t!).

When I teach workshops about disability and accessibility, I often ask my students to do a matching exercise to compare different disability types to examples of good practices. My students quickly learn there are no one-to-one relationships between accessibility best practices and individual types of disabilities. The interconnections show us that none of these individual types of disabilities are experienced in a vacuum.

An example of mapping experiences to types of disabilities.

The upside to this level of complexity is that we can focus on how these different experiences are supported, rather than trying to over-engineer solutions for any one audience. When we’re considering disabled users, we can consider best practices, not silos of behavior.

Think about the types of experiences disabled users may have rather than trying to build solutions for individual types of users.

So, I’m going to recommend you think about the types of experiences disabled users may have rather than trying to build solutions for individual types of users. This makes it easier to think about disability as a collection of experiences that can be met with best practices, not a monolithic of people.

In this way, we can focus on a few general types of experiences:

  • Dexterity and mobility barriers caused by pain or other factors can result in a variety of different ways of touching or interacting with hardware and software. These might even affect how people hold a device, and whether a user might touch a device at all, or rely fully on voice activation or other tools.
  • The wide variety of neurodiversity means we need to think broadly about how people think, process, and sense information. No two people think alike, and people with cognitive disabilities typically benefit from the simple language, clear organization, and consistent workflows that help all users.
  • Media that relies heavily on visuals, color, or sounds needs to have alternatives for people who can’t or prefer to not take in information in those ways. Many people are visual learners, but considering how people who don’t take in information visually strengthens how we design visual or color-based experiences, making our decision-making to use visuals or colors even stronger.
  • And people with vestibular or mobility issues need to have control over how they interact with motion, or how they move. Thinking about low-motion experiences makes us focus on the real goals we want users to achieve, and how we can use motion to guide those experiences. It forces us to make workflows and transitions that are clear even without motion.

A good way to start doing this is to focus on usability and inclusivity, and invite people with disabilities into the work. You’ll never be able to test for every use case, but engaging participants with disabilities is the best way to ensure the experiences of disabled experiences are included.

One way Shopify is doing this is scaling usability testing with people with disabilities. I’m working with the amazing team at Fable Tech Labs to help designers and developers get better insights into making usable, accessible experiences, primarily pushing interviews and reviews with participants who have disabilities as a way to get input early in the prototyping process.

Myth #2: Accessibility is a technical problem

To really deal with digital accessibility, we have to go beyond fixing things, and start preventing them. The lack of accessibility, and how to address it, is a cultural problem rooted in ableism. Most of our resources and standards around accessibility are technical and oriented towards testing. And, since so much accessibility work focuses on fixing things that have already been implemented, developers are often given the responsibility.

The primary tool we use to measure accessibility is the Web Content Accessibility Guidelines, a technical document created by a working group within the W3C. Not to knock all the extremely important work that these folks do, but this approach compounds a testing-oriented culture around accessibility that puts the onus on developers and testers.

This results in a lot of accessibility work being done at the end of a project, in a workflow that often starts with auditing sites and apps that are already in the wild, then fixing issues, but not digging into the processes and workflows that caused those problems in the first place.

This has also led to “solutions” like third-party overlays that promise to solve complex accessibility issues with the click of a button, but usually cause more harm than good. (Colleagues in the a11y field have put a useful resource together on overlays if you’d like more information.)

Resources and guidance for designers, writers, researchers, and others is minimal and repetitive. If you’re in one of these roles and you’ve tried to find resources on how to integrate accessibility into your practice, you’ve probably seen the same advice over and over again: “Use good color contrast!”. “Use simple language!”, “Test with users!”. There is a lot of ‘why’, and not a lot of ‘how’. And that’s because the ‘how’ is going to vary from project to project, and team to team.

Instead, try:

  • Holistic, continuing education about how disability and technology intersect
  • To include people with disabilities as part of your team and process
  • Continuous improvement of processes and workflows to move beyond technical guidelines to usability
  • To make accessibility part of the current work, not a future goal

As a place to start, teams can review usability feedback from users with disabilities together, acquaint themselves with the assistive tech available on the devices they support, and look at any reported issues for their product. These steps can help teams and team leads think about when they might insert specific steps to avoid accessibility issues in their workflow.

Picture of the letter a.

Ideally, a product workflow with accessibility included from the start looks something like this:

  1. Users with disabilities are included in the product audience from the start.
  2. Accessible experiences are included in design decisions.
  3. Prototypes for new work are tested for usability, including with users with disabilities.
  4. Built solutions leverage automated testing, and testing with common assistive tech.
  5. If issues are reported by users after the product is released, those issues are triaged and addressed by severity and priority along with any other issues.

A lot of accessibility education focuses on developers, designers, and content creators, but doesn’t support the people who manage those UX practitioners. This year at Shopify, I’m building out training materials for managers to help them better evaluate how literate their teams are in accessibility, and how to better support accessibility work in their processes, rituals, and hiring practices.

Myth #3: Accessibility is hard

Accessibility work doesn’t have to be hard. Everything is hard when you don’t know enough about it. Think back to when you first started learning your craft, gaining real experiences, learning new tools and standards, and sometimes failing. You have to celebrate small wins! Those wins just don’t represent the end of improvement.

And your goal doesn’t have to aim for expertise. Expertise is hard to teach because it takes a long time. I also don’t think it’s possible to really teach empathy. Instead, we should focus on ways to make accessibility just another part of every process to create products. Accessibility work at scale is an exercise in literacy and practice, not expertise or empathy.

Accessibility work at scale is an exercise in literacy and practice, not expertise or empathy.

To improve the accessibility of your work, here are some accessibility literacy aims, borrowed from information literacy in library science:

  • Learn how to discover resources about accessibility efficiently.
  • Evaluate the usefulness and accuracy of resources.
  • Understand the context in which those resources were created.
  • Create new work using what you have learned.
  • Participate in a community of practice to reinforce and scale learning.
Picture of an animated store.

Some of how we’re doing this at Shopify is by working on scaling tooling, education, and best practices for some of the stickiest parks of UX work. ReOps and Enablement is a small super-team inside UX Operations focused on just that.

By collaborating, we’re able to iterate on the best ways to support our UX folks, and collaborate with product teams to help them share what they’ve learned about doing accessibility work in their own area within the larger organization. We’re aiming to create a consistent, literacy-focused methodology for creating user-focused activities and resources across the organization.

This month, we’re starting an Accessibility Guild, which is open to everyone across Shopify. It will be a place for teams to share their accessibility wins, to ask questions from internal and external accessibility experts, and generally build a more sustainable community of practice around accessibility.

Accessibility should not be a future goal. Start now. Aim to become literate in accessibility, not an expert, and your users and products will benefit exponentially from the experiences you design and consistently improve.

About This Article:

A Life Worth Living has copied the content of this article under fair use in order to preserve as a post in our resource library for preservation in accessible format.  Explicit permission pending.

Link to Original Article: