The Path to Building Beautiful Inclusive Experiences

Stop the assembly line

If you walked into a General Motors auto plant in the 1980s, you would have seen a moving assembly line that never stopped. Money wasn’t being made if cars weren’t being built quickly, and the company had the attitude that if a mistake happened, they’d worry about it later. In other words, rather than stopping the assembly line, they fixed the problem at the end. This resulted in cars full of defects that, at the end of the day, took more time, manpower, and money to fix.

In an effort to build more reliable cars, GM turned to their new competitor, Toyota, and started an experimental joint auto plant partnership called NUMMI. Toyota’s solution to GM’s issue was to put quality before quantity by stopping the assembly line and addressing (and fixing!) problems as they occurred.

Today, like with GM, accessibility is sometimes approached backwards, which results in two big problems:

1. Accessibility deficiencies are treated as bugs

2. Bugs are fixed at “the end of the assembly line,” or as it’s known in tech, the “software development life cycle” (SDLC).

At WW, we practice an agile product and software development lifecycle. The idea is to have continuous improvement that prevents and fixes bugs before they get into production rather than a waterfall system where bugs are dealt with at the end. However there used to be one exception — accessibility!

When I started at WW, my first mission was to convince everyone that accessibility is a design feature, not a bug. My second goal: Find a place to include it so accessibility wouldn’t be retrofit at the end of our SDLC.

How I adjusted the life cycle to include screen reader requirements

If you have never heard of a screen reader, in a nutshell it’s software used by those with vision impairment or low vision that audibly announces the content that the person is interacting with. (If you are still curious about how a screen reader works, I recommend going into your accessibility settings on your phone and taking it for a test drive; both Apple and Android have it.)

I set out to better understand the process used by our designers and engineers, looking for a spot in the assembly line that would be the most appropriate to add in the screen reader specs.

I discovered that our design team uses Zeplin in the SDLC to hand off their designs to engineers. In Zeplin, the engineers get all of the design specs (such as pixel location and color) required to build. I identified this part of the development process as the perfect place to include the requirements for a screen reader.

I then traveled to San Francisco from New York to work with one of our user reachers, Anna-Lisa Bowans. We visited Lighthouse for the Blind and Visually Impaired and conducted our first user research seasons with participants who have vision impairment or low vision. The observational research that we gathered helped to inform our screen reader design.

Cultural Shift

None of my efforts to add accessibility into the process would have worked without first changing the minds of my fellow assembly workers.

It’s easy to forget that accessibility isn’t only a list of ADA requirements, but that there are also real people benefiting from the development of technology that has an inclusive design. So I brought in Ruth, one of our loyal members who is blind, to demo how she uses our app in front of our product and tech teams. With her phone projected onto a large screen, her phone audio piped into speakers, and her black Labrador, Velvet, at her feet, Ruth demoed one of our common flows: searching for and tracking a food item. Everyone in the audience sat in silence at the edge of their seats, frozen with anticipation. What would the experience be like for Ruth?

For a sighted person tracking a food, a Big Mac cheeseburger would take all of 10 seconds. For Ruth, the action took several minutes. The exercise was a reminder to everyone that we had a lot of work to do to achieve an exceptional experience for our screen reader members.

For inspiration, I took our designers on a field trip to the Cooper Hewitt, Smithsonian Design Museum to see two special exhibits about accessibility, The Senses: Design Beyond Vision and Access + Ability. Both exhibits offered examples and inspiration, such as tableware that is color-coded and ergonomically designed to help elderly people with dementia eat and a book that helps people visualize some of the reading challenges that people with dyslexia experience. It showed us what could be possible in our own accessible work here at WW, and everyone walked away from the experience ready to make our design more inclusive.

Eight months after our session with Ruth (and after updating our design based off that session), we brought in Dan Mancina, a visually-impaired skateboarder. Dan agreed to sit down with us and give his honest feedback about his experience using our app. We were happy to learn he found it a usable, clear experience without any traps or barriers. We’d made progress! That meant a lot to us.

Document Creation

Next, I set out to create a document that could be included in the assembly-line handoff from designers to engineers. I wanted it to be a place where Content, Design, Accessibility (me), and Engineering could all collaborate about the screen reader design.

Typically, when you think of screen reader requirements, alt-text and button labels come to mind, but a screen reader should be thought of as an audio-only design feature. Location, orientation, and cues into the design purposes (for example, how we know solely by its design that an e-commerce website is not a social media website) all need to be planned for when building your audio-only screen reader experience, and they need to be integrated in the early stages of the process.

Previously, the accessibility requirements were delivered as an incoherent monster stack of ADA “bugs” listed in Excel sheets. My first improvement was to annotate with arrows on top of screenshots. This diagram was a way to explain what needed to be added for a screen reader — but it was still being done after the design was built.

Collaboration

I took the annotations further by collaborating cross-functionally with our designers, Jesse Kim and Maggie Armstrong, and iOS engineer, Steven Grosmark. We came up with a Screen Reader Accessibility Annotation Document (SRAAD). The document uses boxes and numbers rather than a mess of arrows to annotate the design. We also came up with a standard for writing the text that is announced by the screen reader.

Standard:

#. “label” , “control type”

Example:

4. “next” , “button”

Notes:

“#”: is the focus order

“,”: is a small but important detail:

• Comma used to give pause to engineers, if it’s costume or “out of the box” control
• Custom controls won’t automatically announce the control type by a screen reader, but “out of the box” controls will
• Costume control types (in addition to the labels) need to be translated for foreign markets

The document is also used to explain the nuances of how a screen reader will work with the more complex elements of the design, like an image carousel, and any place that needs additional context that might be implied in a visual layout but lost in the audio-only experience of the screen reader.

Wireframe and annotation example of our “My Day” screen.

Screenshot snippet with annotations for the “Learn More” in app guest experience.

Looking forward…

We still have work to do, such as:

1. We need accessibility to come up front in the product and development life cycle.

2. We need to have all designs include our SRAAD before they are handed off to engineers.

3. We need regular inclusive user research to drive our decisions on how to best design and build for accessibility.

4. We need to continue to communicate (and celebrate!) accessibility awareness to the company.

5. We need to use SRAAD to validate in QA.

6. We need to add accessibility requirements to our universal React components. I’m exploring now and that will complement the SRAAD well.

My biggest project to date is building an empathy lab here at our WW New York office. With help from my intern, Leah TenEyck, this last summer we met and visited a handful of other companies from Verizon Media, IBM, AT&T, Facebook, Oath, and Workday to learn about their labs.

We wrote a proposal based on what we learned and came up with a budget to build our own lab, which should be up and running sometime in 2020. The lab will be a space for our teams to test their designs with assistive tech (think refreshable braille devices) and hopefully a place to build empathy for our diverse members.

The ongoing awareness campaign itself has been a huge success in bringing accessibility awareness to WW.

In conclusion…

Adjusting any process first requires changing the culture. Even if you are passionate about accessibility and have clear ideas on how to design and build for it, that doesn’t mean everyone you work with will automatically share that vision. Instead of demanding that people care about accessibility, let them discover what first made you excited about it through education and then find ways to incorporate accessibility into your product and development life cycle.

When the NUMMI experiment ended, the lessons learned were never adopted by GM’s leadership, and not because it wasn’t effective (it was estimated that it took 50% less people to make a car the Toyota way). The reason they weren’t adopted was because the change in culture was too difficult to overcome. It would have required a fundamental reorganization of things like the pay structure and seniority rights, which were too much a part of the company fabric to unweave.

Not at WW! We’re taking the time to collaborate cross-functionally and use our SRAAD to give us a place to pool all our ideas and research, with the intent of giving engineers detailed specs for how to build for a screen reader. This has been a big first step in helping our teams think about accessibility and screen reader design not as a bug or retrofit, but instead as a value added feature that can help meet our mission of making WW for everyone.

— Michael D’Anvers, Accessibility Expert at WW (formerly Weight Watchers)

Interested in joining the WW team? Check out the careers page to view technology job listings as well as open positions on other teams.