SUMMARY
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
Cursor and screen reader focus should move in a predictable, logical way to aid in user comprehension and efficiency.
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.
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.
Visual assets such as illustrations, icons and emojis should represent the diversity of people’s abilities (or disability) including race, gender, and culture.
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.
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.
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.
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.
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.
RELATED STORIES
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.