Accessibility is a crucial part of government product design. First, it’s the law. Federal agencies face legal consequences when they don’t meet accessibility requirements. Second, it affects us all. Whether you have a motor disability, you sprained your wrist playing dodgeball, you need a building to have a ramp for your wheelchair or stroller, or you literally just have your hands full, we all find ourselves unable to do certain things at different points in our lives. Accessible products are better products for everyone.
But accessibility is hard: It comes across as a set of complex rules that are hard to follow. Not everyone feels confident that they’re doing it right. It’s difficult to prioritize alongside other work and project needs. How do you make sure you’re building products that are accessible and inclusive?
The Accessibility Guild in the Technology Transformation Services (TTS) at the U.S. General Services Administration (GSA) set out to understand how people in different roles practice accessibility. We asked designers, developers, and product managers across our organization to share their accessibility practices, from self-testing to asking for help. We heard about the barriers that can stand in the way of making products more accessible, from lack of knowledge to lack of buy-in.
We distilled what we learned into a quick-start guide for embedding accessibility and inclusive design into a team’s workflow.
Each person on a team, whether you’re a manager, designer, or developer, has a role to play. Your responsibilities are different depending on your role. So that’s how we structured the guide, with a separate section for each of five roles:
- Product management
- Content design
- UX design
- Visual design
- Front-end development
This guide provides:
- An overview of how each role can contribute to a product’s accessibility
- A framework for thinking about accessibility and inclusive design in your role
- An understanding of the human need behind accessibility practices, introduced with clear questions and personas that describe people who would experience particular accessibility issues
We’ve shared the guide with accessibility practitioners across government, and we’ve incorporated their feedback.
We all have a part to play in building accessible products. We hope this guide can help you understand your role.
Check out the guide at accessibility.digital.gov. Let us know if it’s helpful and how we can improve.
We’d like to thank everyone who contributed and provided feedback (apologies for leaving anyone off):
David Stenger, Carolyn Dew, Victor Zapanta, Kate Saul, Nikki Lee, Andrew Maier, Atul Varma, Corey Mahoney, Andre Francisco, James Hupp, Julia Sultan, Michael Torres, Jen Thibault, Leah Bannon, Michelle Hertzfeld, Rebecca Piazza, Nick Bristow, Jeremy Zilar, Dan Williams, Micah Taylor, John Yuda, Aviva Oskow, John Sullivan, Kathy Eng, the Accessible Design & Dev Technical Guidance Workgroup, the Section 508 listserv and Accessibility Coordinators.
This DigitalGov Guide is maintained by the Accessibility Guild in TTS at GSA. In the government, accessibility isn’t a nice-to-have, it’s the law. Find out more about Section 508 of the Rehabilitation Act of 1973, a law that requires all information and communications technology released by the government to be accessible to anybody with a disability. Learn about the Section 508 Refresh that went into effect in January 2018.
