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.
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.