STORIES

5 ways to integrate accessible design into fast-paced projects

PROCESS
CONTENT DESIGN
PRODUCT DESIGN
By Caterina F.
13 min read
July 23, 2020
Woman of color holds smartphone while leaning as though she has hearing trouble.

SUMMARY

Find out how to offer more people access to online tools and content, even when shorter project timelines make that challenging.

In celebration of the 30th anniversary of the Americans with Disabilities Act (ADA) and National Disability Independence Day, we’re sharing our lessons learned incorporating accessibility into all projects, especially those with fast timelines.



Product release cycles continue to get shorter — days and weeks-long instead of months — making the task of integrating accessibility early in the process look even more challenging. But it’s a myth that making a product accessible is too difficult, too time-consuming, and requires specialized resources. Our experience at Facebook over the last two years building products for over 3 billion people has proved otherwise. Preparing for accessibility early in the product development process can save time and resources, improve overall usability, and set you up to design within fast timelines.



Designing for accessibility means enabling people of all abilities to perceive, understand, interact with, and contribute equally to the web and digital world. We have been learning a lot about this by supporting fast-paced projects, especially in the last few months launching Rooms, the Covid Info Hub, and Covid hashtags.



1. Acknowledge that accessibility is not a one-person job

It’s a common idea that only a specialist can contribute to an accessibility project. We’d like to dispel this myth here and now. It takes a village to launch an accessible product. Accessibility is a team effort. No matter what your level of experience and passion, no single person can do the job well. In order to start on the right foot you’ll need to get the right team in the room. It’s tough enough in normal circumstances to get everyone in the same place at the same time to collaborate, and lately it’s been impossible for us given the coronavirus social distancing limitations.



We have learned the importance of involving people with situational, temporary or permanent disabilities directly into our design process, by either organizing co-design sessions or planning multiple testing rounds with them. These participants might include people with low vision, hearing, cognitive and motor impairments, and people with low technical literacy.



“Waiting to incorporate accessibility after-the-fact sets up your project for failure.”



Finding people with disabilities may seem difficult, but the benefit of their input and feedback in the beginning and throughout the product development process is critical to ensuring the overall usability and success of your products. Reach out to disability advocacy organizations and chapters in your area that represent and support individuals with disabilities, such as the LightHouse for the Blind, United Cerebral Palsy, the National Association of the Deaf, and the National Federation of the Blind.



For some projects, it won’t be feasible to get everything done on the first go. Don’t let that stop you from getting the project off on the right foot. Waiting to incorporate accessibility after-the-fact sets up your project for failure. You may end up building the project on an inaccessible architecture or accrue insurmountable accessibility tech debt before a proper team can be put in place, resulting in a product that excludes the people it was intended to serve.



2. Make a game plan to tackle accessibility in your process

We’ve all been there: everyone is moving fast in every direction and feeling great about how much energy they’re putting into the project — but it’s not working. Stress has a way of showing you what really works, and what’s just wishful thinking. When we started incorporating accessibility into our project process, we weren’t really good at it. But we didn’t let that stop us, and we weren’t afraid to fail because we knew we’d get better. So here’s what we’ve learned to do at each step of the development process to incorporate accessibility into fast-paced projects:

Image of typical project timeline shows its steps displayed from left to right: plan, design, develop, ship and maintain.

Plan


Integrate accessibility into your project brief and mission


We start by considering how to fill in this phrase: “Our mission is to enable [target audience] by shipping an accessible [product or feature] to give equitable access to people of all abilities to create community.“ Including a phrase like this into your project brief mission statement will help align you and your team and keep the high-level goal crystal clear during development.



  • Plan to review and identify accessibility issues before shipping your product.

  • Plan to test for screen readers and keyboard navigation.

  • Work with your accessibility QA team to create a burndown list of tasks and bugs to resolve before shipping your product.


Design


Create design specs


(See the design examples in the next section).



Review your design


Evaluate color contrast ratios, tap targets, accessibility labels, focus areas/order, keyboard navigation and whether or not content is accessible to people with low technical literacy.



After struggling through a number of fast-turn projects, we realized that we needed to be better prepared. We began to offer accessibility training for product designers and content strategists and make accessibility “office hours” available on request to review design specs and product accessibility. This helped us identify issues that we would have otherwise missed. We strongly encourage you to listen to and learn from disabled users. There really is no substitute for this. But if you’re not able to engage people with disabilities early in the process, at least engage an accessibility expert in your company (if you have one) or find an external accessibility expert. The key point is that you get someone else who is knowledgeable to validate your work. We all know this is good practice, yet this is one of the first things we skip when under pressure.



Develop


Lint your code


As your engineers begin coding, make sure they are linting. We found this to be a powerful method for finding code issues and recommend implementing linting in your web stack.



Conduct accessibility quality assurance testing


Partner with an external accessibility vendor who employs QA engineers trained to perform accessibility evaluations in lockstep with your product lifecycle process. You should define the user flows to be tested and the optimal cadence for your team. They will test your flows, find bugs, and create tasks for you to address.



Ship


For fast development cycles (measured in weeks, not months or years), it’s not always possible to get in a last-minute check before shipping. But if at all possible, we’ve found that an expert accessibility review just prior to releasing a product almost always reveals issues we missed. At the least, it helps us identify and prioritize what we need to do next immediately after shipping.



Maintain


Continually improve


Chances are good (okay, it’s certain) that you won’t be perfect — especially the first time through the process. Now that you know you need to make improvements, what do you do? In addition to designing for accessibility up front, your process must include remediation when there’s regression. Your method for managing this should match your team’s current regression management process. At Facebook, we have developed our own QA process that has helped us improve how we design and implement accessibility features. This is how we monitor quality and make sure that we are continually improving over time. If you don’t have an established QA process, we encourage you to create one, and accessibility is a great place to start. It will be impossible to make progress on accessibility at scale without at least some monitoring, checks, and remediation to ensure you’re raising your quality bar over time.



Get user feedback


With your product released in the wild, you can and should collect and act on user feedback, and we strongly recommend that you create a mechanism in your product that makes it easy for users to provide it. We apply special rules and tagging on feedback related to accessibility so it’s easier to find and prioritize. Providing a channel for feedback will ensure that you catch major regressions that might be missed by engineering and QA, discover actionable insights from users of your products, and signal to the outside world your commitment to inclusion. You don’t necessarily need to respond to all inquiries, but you should track and taskify everything that is valid and reproducible.



3. Know your priorities

By definition, a fast-paced project doesn’t allow you to do everything you want to do in the first go. However, waiting until later to consider and incorporate accessibility into a design may lead to additional hurdles that may otherwise have been avoided. So consider accessibility from the outset for fast projects (remember, this means days or weeks, not months or years). This will set up your projects for future success, and help prioritize which of the many accessible design considerations you need to incorporate first (on the way to implementing them all). Of course, your priorities will change depending on the project, but we default to the following list unless the project or the schedule demands we shorten it or allows us to lengthen it.



Respect color contrast ratios


Designs should respect at least WCAG’s AA standard of at least 4.5:1 for standard text, 3:1 for large text (18pt and larger when rendered) and graphics.

“Do” on the left shows correct color contrast ratios. “Don’t” on the right shows incorrect color contrast ratios.

Test for color perception impairments


Make your design work without depending on color. Convert it into grayscale to see if it relies on color alone to convey important information. The design should convey information as well in grayscale as it does when using color. Use multiple visual cues beyond just color such as icons, textures, patterns or descriptive text to communicate important states.

“Do” on the left communicates with iconography and color, while “don’t” on the right relies only on one visual cue, color.

Create accessibility labels and image alt-text


All controls should have succinct and informative accessibility labels, whether they have a visible label or not. Decorative elements that do not communicate specific meaning do not require accessibility labels.

Onboarding screen for Messenger Rooms shows screen reader design specs for labels, traits and hints for three interesting use.

Create focus areas and order


Cursor and screen reader focus should move in a predictable, logical way to aid in user comprehension and efficiency.

“Do” on the left exemplifies logical sequential order in a graphic; “don’t” on the right exemplifies nonlinear focus order.

Respect touch target size standards


Tappable elements should have at least a 44x44dp surface area that accurately respond to people’s taps and have at least 8dp space between tappable elements.

“Do” on the left shows correctly sized and spaced touch surface areas; “don’t” on the right shows them displayed incorrectly.

Design for low digital literacy


Content should be written and presented in a way that enables people who are less tech savvy to understand and interact with your products. Examples include simple workflows, reducing visual density, pairing text labels with iconography, using plain, simple language in short sentences, and using images or drawings in addition to text.

“Do” on the left shows iconography and descriptive text; “don’t” on the right shows iconography with no descriptive text.

Create inclusive visual representation


Visual assets such as illustrations, icons and emojis should represent the diversity of people’s abilities (or disability) including race, gender, and culture.

An illustration series related to the coronavirus shelter in place represents doctors, nurses and others of various abilities.

We’re not suggesting these are the only considerations for accessible design. We’ve simply found that these serve well as a feasible, solid place to begin, even on the fastest project startups. All of these recommendations have high value to people with various disabilities. Refer to the WC3’s WCAG 2.0 AA guidelines for a more complete list of accessibility considerations.



4. Transform an accessibility challenge into an opportunity

Invariably, you’re going to find a few accessibility barriers in your design, and you’ll find them in places you may never have expected. In one recent project, a team received input from people with disabilities that hashtags not displayed in CamelCase (#designforeveryone vs CamelCase #DesignForEveryone) were preventing screen readers from accurately speaking descriptions for people who are blind. We also found that hashtags in all uppercase and all lowercase are difficult for people with cognitive and learning disabilities to read and understand. While remedying the hashtag accessibility barrier wasn’t a ‘quick fix,’ having this information was important. In response, we were able to highlight this barrier for a future fix with another team, while also keeping our focus on other barriers we could surmount more quickly to deliver a strong accessibility result for the disability community.

“Do” on the left shows iconography and descriptive text; “don’t” on the right shows iconography with no descriptive text.

While this may sound like a miss, we consider it a victory. By incorporating accessibility into our design thinking from the outset, we caught this issue early and were able to get another team, unrelated to our project, to investigate it. That team proposed a fix in parallel while we quickly got our project up and running. That never would have happened if we had waited until after the project was “mature” to perform our first accessibility audit, and we may have been so far down the line that the effort to fix it would have cost us more in time and engineering, elongating our delivery time. The more we’ve incorporated accessibility from the outset, the better we’ve become and the more we’ve learned about which issues are common and which are unusual. This approach has enabled us to fine-tune our process, our tools, and our intuition so we can find problems and fix them even faster in the future.



5. Nurture an inclusive design culture

Influencing your whole company or team culture may not be easy, but it’s definitely one of the most impactful and long-term outcomes you can make happen through your work.



Designing for accessibility in the digital space has for decades been an engineering-driven practice, and unfortunately, an afterthought for many product teams. More recently, awareness of designing for accessibility has increased in the design community and more product designers have started advocating for it and writing about it. We’re all now much more aware of the importance of creating a corporate culture of inclusive and accessible design and hope you join us on this journey.



Facebook’s well-known bottom-up culture has allowed many individuals and teams to innovate and push boundaries in accessibility, and inspired a volunteerism culture. But in order to make a lasting, significant change in how we design products, we must also have a top-down culture of accessible and inclusive design.



To address this, we spun-up a series of activities and programs to help product teams to integrate accessibility in their process. These programs inspired leadership to adopt accessibility more formally into our company culture and policies. Here are a few of the initiatives we kicked-off to inspire you, and hopefully help you nurture a more inclusive design culture in your company:


  • Accessibility guides, resources and best practices

    We created corporate design accessibility guidelines, training resources, design cases, best practices, and an accessibility component library. These enable product teams to be more self-sufficient and improve our consistency across products and platforms.

  • Accessibility training sessions

    We kicked off an onboarding training program to provide an overview of what inclusive design and accessibility is and to orient our “n00bs” (“new-bees” or “noobs” are our new designers, researchers, content strategists and engineers) on what’s expected of them.

  • Accessibility office hours

    We make available “office hours” (originally in person but now virtual) hosted by our more experienced designers and accessibility program managers. During office hours, anyone can get answers to their questions about accessibility and inclusive design, and we can review product designs together.

  • Open (digital) space to discuss accessibility

    We created an internal online company forum using our own Workplace product to answer common questions from product teams and share updates on best practices, new tools and techniques from our team. This space often provides answers faster than scheduling office hours, and reaches more people who may share the same question.

  • Internal and public events

    We organized several events to amplify awareness and inspire and educate internal and external communities about accessibility and inclusive design. Recently, we hosted “Accessibility Week 2020” in celebration of Global Accessibility Awareness Day in May. We normally host this only for employees but decided to make it virtual this year and made two of the three sessions public. In the first we hosted design icon Don Norman, who set the stage for “why accessibility” by sharing his thoughts on the importance of designing for disability and the elderly. We then hosted three amazing and diverse speakers who shared what it’s like to live a typical day with a disability. This session helped our designers better understand who they’re designing for. The final session trained all of our designers on how to apply the lessons we’ve shared in this article, our priorities and process, and how to use our internal tools to create accessible designs.

  • Accessibility council

    We’ve also recently started an accessibility council to facilitate cross-pollination across the org about inclusive design, and to align guides, best practices and training across our company.

  • Accessibility task force

    We created an accessibility task force to support unexpected projects, like the Covid Info Hub and other projects, to ensure they integrate accessibility thinking from the start.



The Bottom Line

We hope these lessons will enable you, and give you the courage to incorporate accessibility and inclusion into even your fastest, most aggressive product development cycles. It’s okay if you’re not immediately successful. Your company culture may not change overnight, but we’ve learned that the tipping point for this shift lies with individuals. If you’re willing to integrate inclusive design and accessibility into your mindset, you can and will influence your entire design practice, product development process, and corporate culture.



We certainly don’t yet have all the answers, but we’ve learned a lot along the way and wanted to share what we’ve learned with the hope that it will encourage others who have yet to take this step. We continue to learn how to support designers and product teams by integrating accessibility into our design practice, and we’re taking a stand for inclusion through design. We hope you do, too, and that this article will help empower the broader design community to do the same.



_



Caterina Falleni is also the author of Accessible by Design, due out in 2021.



Thanks to:



Gui Schneider, Virginia Cagney, Jonathan Lee, Gregory Sarkis-Kelly, Gillian Terzis for being great teammates and for the great feedback and support along the journey of publishing this article.



Matt Brennan, Matt King, and the entire Facebook Accessibility team for their invaluable help, experience, and knowledge of accessibility and inclusion.



Tori McGoogan for her artistic direction of this article’s illustrations.



Mike Shebanek, Jesse Beach, Tali Krakowsky Apel, Shali Nguyen, Jeff Wieland and Espen Tuft for their continuous support in Caterina’s evolution as an accessibility design lead.



Shannon O’Malley for her gentle editing of this piece.

Design at Meta is for everyone who touches user experience and design.

Whether you’re a product designer, writer, creative strategist, researcher, project manager, team leader or all-around systems-thinker, there’s something here for you.


Design at Meta is a window into the unique expertise and perspectives of the multidisciplinary teams who are building the future of human connection and the technology that makes it possible.

FacebookInstagramThreadsDribbbleMedium