This is part of a conversation that we hope continues throughout your time in government.
Accessibility is one of the most important values underlying all of the work that we do. Now, you might already have some experience with accessibility, but other people that you work with might be new to the topic, or need methods or tools to see how to improve the accessibility of a product or service.
We do have an introduction to accessibility, so consider this page a deeper look into why accessibility matters, and we hope that you share it with your team.
Accessibility is the Law
Section 508 Standards are established and maintained by the U. S. Access Board. Under Section 508 of the Rehabilitation Act of 1973, agencies must give disabled employees and members of the public access to information that is comparable to the access available to others.
How do we get there? The shortest version is to make sure that everyone ensures that their products meet the minimum Level-A and Level-AA Success Criteria (SC) of the Web Content Accessibility Guidelines (WCAG) — the globally recognized guidelines for creating accessible digital experiences from the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI).
WCAG 2.2, released in October 2023, outlines the principles, guidelines, testable success criteria, and techniques needed to optimize content. There are four principles known as “POUR,” where all online content should be:
Perceivable - Information and user interface components must be presentable to users in ways they can perceive (it can’t be invisible to all of their senses).
Operable - User interface components and navigation must be operable (the interface cannot require interaction that a user cannot perform).
Understandable - Information and the operation of user interface must be understandable (the content or operation cannot be beyond their understanding).
Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technology (as technologies and user agents evolve, the content should remain accessible).
Sometimes the technical descriptions of the WCAG requirements can make it harder to understand, but luckily we have the resources to help navigate the basics.
Becoming Literate in Accessibility
We’re not just here to talk about compliance and the rules. We’re here to talk about the right thing to do. We need to help everyone have equal access—from our coworkers, to the public we serve.
This principle is known as Inclusive Design; we create products, services, and environments without the need for special adaptation or specialized design.
In order to be an advocate for the creation of products and services that are accessible, we need to reframe our ideas around disability.
Being inclusive begins with perception. Think about permanent, temporary, or situational disabilities that might prevent you from interacting with products, services or society. Also, take a moment to observe how people in different circumstances can be excluded from participating in something that you can do without barriers.
For example, blind or low-vision colleagues and members of the public won’t be able to access the information in a PDF file if the document hasn’t been made accessible. Those who are deaf or hard of hearing won’t be able to participate in conference calls or video training without an interpreter or captioning services.
Reframing Our Idea of Disability
Disability is a mismatch between a person and their environment. For the person who isn’t able to do something, it’s this mismatch that impairs an individual.
What might first come to mind are people who have mobility restrictions, tremors, or low- or no vision, or are deaf or hard of hearing.
It’s important to understand that everyone experiences some form of disability. As an example, imagine that three people are trying to watch the same video, but each person has a different type of disability:
- Mark lost most of his hearing after a severe illness. He has a permanent disability.
- Jesse’s ears are ringing after a concert, and they are having trouble hearing a video. They have a temporary disability.
- Sam is struggling to listen to a video in a loud office. She has a situational disability.
The fix that benefits everyone in this circumstance might be to apply a captioning service to the video. That would directly help Mark who has a permanent disability, but also benefit Jesse and Sam who have temporary and situational disabilities. This is known as the “Curb-cut effect.” When we design for people with permanent disabilities, folks with temporary and situational limitations can also benefit.
According to Microsoft’s Inclusive Design Toolkit, each year in the U.S., approximately 26,000 new people suffer the loss of an upper limb. When we include people with temporary (13 million) and situational impairments (an additional 8 million people), that’s more than 21 million people each year who experience disabilities.
The idea that things that help people with disabilities can benefit everyone inspired the field of universal design, where buildings and objects are designed to be as usable as possible for everyone, regardless of age or ability. When assistive technology (AT) becomes sufficiently ubiquitous and widely used, it is no longer considered assistive technology. It becomes “normal.”
Let’s review temporary and situational disabilities in a bit more detail.
© Microsoft 2016 Licensed under Creative Commons Attribution-NonCommercial-NoDerivatives (CC BY-NC-ND)
Temporary disabilities — There are occasions where folks might have a temporary disability due to an illness or medical circumstances.
Someone with an arm in a cast will have difficulty typing on their keyboard, or, after an eye doctor appointment, one’s pupils are dilated and the usual brightness of a phone’s screen is painful.
© Microsoft 2016 Licensed under Creative Commons Attribution-NonCommercial-NoDerivatives (CC BY-NC-ND)
Situational disabilities — There are also situational disabilities that occur during specific circumstances.
Examples include a new parent holding a baby, someone trying to open a door while holding one or multiple items, or if calling into meeting where they have a visual presentation.
Cognitive, Learning, and Neurological Disabilities
It’s also good to remember that there are disabilities that are not physical that have an affect on our work, like anxiety, dyslexia, and autism. These posters from the U.K. government illustrate the do’s and don’ts around about designing for these types of disabilities.
It’s important to keep in mind the context for which folks are using your product or service, and how they’ll be interacting with you.
We work on projects where people might be in uncomfortable situations and they need to ask for government services. Consider how can we provide a clear, calm, and helpful experience to them.
User research is one of the best methods for building empathy for the people who use our products and services. This research should seek to incorporate diverse perspectives, and include people with disabilities.
Developing a strong understanding of the people who use your products is one of the more effective ways of ensuring that the decisions you make about your product directly impact the people on the other end.
There are lots of accessibility problems we can catch before we even put our products in front of people with disabilities. These automated tools are not a replacement for building empathy, they are just checks to ensure you’re building your product with the right code.
- Code Linting — Linting is the process of running a program that will analyse code for potential errors and prevent basic bugs from ever going live.
- Automated Testing — Catch anything that would break the app.
- Manual Testing — Verify that the experience is right by running additional scanning tools, walking through the common scenarios that your users go through, then add assistive tech to that flow.
With good testing practices, we’ll fix obvious bugs before they ever reach an end user. This is just as true with accessibility as it is for everything else.
What Can You Do to Help?
1. Set up a good process from the start
Establish accessibility requirements early in your project lifecycle, ensuring each team member knows their responsibility, and keeping the team accountable for building accessible products. This will ensure that you’re not only following legal requirements, but making your product or service more usable for everyone.
Here are some tasks for each member of your team:
- Product managers: Prioritize accessibility during project phases
- Designers or researchers: Create user-friendly solutions that have proper labels, visual contrast, and is constantly tested
- Engineering: Set up basic tests using standard components, and implement labels and keyboard navigation behavior
- Acquisitions: Make sure vendor tools are accessible
2. Be mindful of how to be more inclusive when working with others
Create an environment where folks feel comfortable letting you know what their preferences are so that every team member can contribute in their full capacity. Even if no one on your team needs accommodations now, consider how your resources will be used later (and if there are any barriers for folks to contribute).
Here are some practices for being more inclusive with those you work with, many of which are an extension of the courtesy that most people automatically practice.
- Create presentations or other documents that are accessible: Making internal documents accessible helps your co-workers and partners (and is required, too!)
- Be open to other ways of working if the tools aren’t working for some of your coworkers: If one tool isn’t working for some of your coworkers, switch to another.
- Make sure everyone can participate: Make use of the Federal Relay captioning services to help make your meetings and work accessible to those you work with. (We use Relay Conference Captioning for most hosted meetings)
Federal Relay services are free for federal agencies to use through a contract agreement. The one that we use most often for hosting meetings is “Relay Conference Captioning (RCC)”
Try Using a Screen Reader
A screen reader is a form of assistive technology used by folks who are blind or have low vision to help them navigate through digital experiences. It’s one of the most common scenarios we think about when we talk about accessibility (e.g., providing alternative text for images on a website so that screen readers can announce them).
However, many people are not familiar with screen readers, nor have they experienced their own products through a screen reader. Learning how to use this tool can be intimidating for people who have never used one before, but luckily free versions are included as part of most operating systems with tutorials available for you to try.
- How to use VoiceOver screen reader on a Mac (macOS) »
- How to use VoiceOver screen reader on a Mac (iOS) »
- How to use Narrator screen reader on a PC (Windows 10) »
- How to use Narrator screen reader on a PC (Windows 7 and 8.1) »
- How to use open source NVDA screen reader on a PC »
- How to use TalkBack screen reader on a Android »
Note that the most popular screen readers are NVDA and JAWS (with VoiceOver coming in third) according to a 2019 WebAIM survey, but you’ll get a basic overview of interaction patterns using the programs that come with your computer or mobile phone.
If you are able to test screen readers with multiple browsers, the following is a list of what AT works best with which browser:
- NVDA and Mozilla Firefox
- JAWS and Microsoft Internet Explorer
- VoiceOver (iOS) and Safari (iOS)
- Android TalkBack and Google Chrome
- ChromeVox and Google Chrome (desktop)
- Windows 10 Narrator and Edge
- VoiceOver (Mac) and Safari (Mac)
- Section508.gov — Provides guidance to federal agency staff who play a role in IT accessibility. Key topics include program management, procurement, tools & training, and policy compliance.
- 21st Century Integrated Digital Experience Act — 21st Century IDEA, signed into law in December 2018, directs agencies to maximize the number of federal services available to the public in a digital format, and establishes or reiterates requirements for accessibility, design, usability, security, and overall customer experience of federal websites and digital services.
- Required Web Content and Links - An Accessibility Statement is required on all internal and external federal websites.
- Accessibility for Teams — A guide to incorporating accessibility into product development teams.
- 18F Accessibility Guide — A resource for developing accessible products.
- U.S. Web Design System — Our design system for the federal government was built with accessibility first.
- Eight Principles of Mobile-Friendliness: Accessibility — Created by the MobileGov Community of Practice to highlight ways we can ensure that our mobile products also meet accessibility standards.
- Accessibility videos — A Digital.gov playlist of accessibility literacy and how-to videos on YouTube.
- WCAG 2.2 — This outlines the principles, guidelines, testable success criteria, and techniques needed to optimize content.
- W3C WAI: How to Meet WCAG 2.2 (quick-reference guide) — A compliance checklist; it will help you satisfy your Section 508 obligations. Be sure to review the white “Understanding” button given in each criteria section for more in-depth information. Remember: the success criteria for Level A and Level AA are just the baseline. We are encouraged to surpass the values specified; not see them as a ceiling to build to.
- W3C’s Web Accessibility Initiative (WAI) perspective videos — A variety of short videos that give examples of different kinds of disabilities.
- How People with Disabilities Use the Web — An introduction to how people with disabilities, including people with age-related impairments, use the Web. It describes assistive technology tools and approaches that people with different kinds of disabilities use to browse the Web (and the barriers they encounter due to poor design).
- Microsoft’s Inclusive Design Toolkit (PDF, 22 MB, 32 pages) — An approachable introduction to the history and principles of inclusive design (they also have a full site about Inclusive Design).
- Web Almanac, Part II, Chapter 8: Accessibility - Covers additional topics, including readability, navigation, and form controls.
This introduction to accessibility was based on content created by the Technology Transformation Services (TTS) Accessibility Guild. Many thanks to former guild co-leads, Toni Bonitto (TTS Solutions), Jacklynn Pham (18F), Nikki Lee (18F), and David Stenger (USAgov) for creating and iterating on this!
Subscribe to our weekly newsletter—a round-up of innovative work, news, and ideas from people and teams across government. It includes a list of the upcoming community events and training aimed at elevating your digital expertise.
Join our Communities of Practice—share resources and collaborate with others focused on building better digital experiences in government.
Some of the communities in the list that have discussions around accessible digital content and services include:
All references to specific brands, products, and/or companies are used only for illustrative purposes and do not imply endorsement by the U.S. federal government or any federal government agency.