Our duty is to everyone: designing for accessibility and inclusion
October 23, 2019
October is National Disability Employment Awareness Month, an opportunity to raise awareness about our colleagues who experience disability, celebrate their contributions to our workplaces, and learn about how we can all help build more accessible and inclusive work practices.
As federal government employees, this month reminds us that we have a duty to serve everyone, regardless of temporary, situational, or permanent disability, and to remove barriers to access and participation in all government resources and services.
Our team is serious about accessibility. Legal compliance is just a starting point for us. As a user-centered design team, accessible and inclusive design is baked into our process and is among our core success metrics. It isn’t about legal compliance; it’s about fulfilling our mission to serve the people of the United States. You can’t do the latter if you’re not thinking about accessibility.
But evaluating and measuring accessibility can be difficult. Automated tools like Lighthouse and Pa11y can help, but there’s no replacement for talking to and working with people who experience disability. This, too, can be difficult – especially in government – where there are legal statutes that both require accessibility and place heavy restrictions on how agencies can recruit participants for usability testing of any kind, including testing for accessibility.
Even so, we’re finding ways to make accessibility a core part of our team’s daily work, and we’re leading a workshop this month for our colleagues to learn how they can support accessibility in their daily work.
We sometimes fall into the trap of thinking about disability and accessibility as binary; that is, someone is either disabled or not, or a product or service is either accessible or not.
The truth is, most of us will experience disability at some point in our lives, even while 1 in 4 U.S. adults lives with a disability that impacts major life activities as I write this.
For example, if you work with a computer every day and have ever broken your wrist, you know that a disability can be both temporary and catastrophically disruptive to your work life, not to mention your home life.
Accessibility, too, isn’t binary. A digital product can be Section 508 compliant and pass accessibility audits, yet still be poorly designed, frustrating, and time-consuming to use.
For these reasons, we try to avoid thinking about accessibility as just a checklist. To us, the responsibilities of accessible and inclusive design go beyond a clean audit report; rather, accessibility is part of our user-centered design process, an integral part of our design and development process.
We routinely audit our site for accessibility best practices, using automated browser or command-line tools. Whenever we release a new feature on the site, we run the tools to audit the accessibility of our changes.
A few months ago, after fixing issues flagged in our audits, we had the opportunity to observe a colleague navigate some of our new features. Our colleague, from a different working group, experiences vision impairment. He relies on various assistive technologies to access digital products.
In the course of observation, we discovered some of our data visualizations were not accessible via keyboard navigation. It was a problem we should have caught earlier, but not one flagged in our accessibility audits.
We were fortunate our colleague was willing to work with us, and we learned a valuable lesson: automated accessibility tools can only take you so far. They cannot serve as a replacement for usability testing with people experiencing disability.
Digital teams committed to accessibility understand it’s a team effort. From ARIA to structured content to color contrast, it takes everyone on the team to build a truly accessible digital product.
But accessibility has a more mundane, yet equally important, aspect. Recently, I received an email from one of our working groups. The body of the email was an image, with the text integrated into the image itself, and a decorative header at the top. There was no
alt text (used to provide an alternative text version of the image), and consequently no content for screen readers to access.
Of course, the author of this email did not intentionally create a barrier to accessibility, but the format of the email did just that.
Because of the role of accessibility in web design and development, web practitioners are well-positioned within their organizations to promote accessibility in other aspects of workplace products and practices.
To this end, we’re conducting a workshop for colleagues later this month focused on writing and formatting documents for accessibility, along with an “empathy lab,” similar to that created by the Government Digital Service in the UK. Our goal is to raise awareness about accessibility in general, and promote accessible design practices in our day-to-day work practices.
While we’re committed to accessibility and working hard to improve and promote accessibility in our products and practices, we recognize that we’re not perfect. We can’t observe every situation in which our products are used, and technology continues to transform the way we interact with digital products, requiring us to reassess our approach.
But we do care about it, and not because we’re legally required to do so. Accessibility is part of our process, part of how we interpret our duty to the public. It’s part of how we measure our success, and a key component of how we interact with our colleagues and share our work priorities.
In honor of National Disability Employment Awareness Month, consider how you might work with your colleagues to promote accessibility in your workplace.
Note : Reference in this blog to any specific commercial product, process, or service, is for the information and convenience of the public, and does not constitute endorsement, recommendation, or favoring by the Department of the Interior.