A Web Accessibility Primer
One of the Web’s most central and lofty ideals is that of universal access. Advances in technology have created unprecedented access to information, entertainment, and community. However, that unprecedented access is still far from universal, and it can be easy for an able-bodied user or developer to neglect the experience of users with different constraints.
When I first got started writing my own code, I was thrilled just to get a form working. I hope I’m not the only person guilty of falling for the thought-trap that “if it works for me, it works.” However, now that I’m a little ways beyond “Hello, World,” I want to start thinking more carefully about my own practices and how they impact accessbility for all users.
It does take some conscious consideration to make code accessible. Luckily, there have been a lot of amazing advances that make that a much easier choice. Assistive technologies continue to improve and HTML5 continues to add more accessible, semantic tags for marking up the web. The more accessbility gets baked into web architecture, the closer we get to fulling the promise of an equitable platform for everyone. Hopefully, the following offers an entry point for contributing to that future.
The Selfish Appeal: Accessibility Benefits Everyone
If a better life for your fellow man isn’t reward enough, consider the elevator, or building ramps, or automatic doors. Public spaces are full of object lessons in how accessbility can and does benefit everyone, not just people with disabilities. It’s a kind of rising-tide-lifting-all-ships phenomenon. Easier is just easier.
On the web, simple, semantic forms, large buttons, the ability to navigate a page without a mouse, even autocomplete are all examples of accessibility. They’re also features I, an able-bodied user, use just about every day. ARIA text that makes the web more expressive for those using screen readers also happens to increase search engine visibility. It’s hard to see a downside to a more accessible web.
The Governing Bodies
There are a host of guidelines and policies that seek to formalize accessibility standards at the level of industries and governments. For instance, the United States has Section 508 (an amendment to the Rehabilitation Act of 1973) which requires accommodations for people who want to access government resources like websites and multimedia. However, it’s worth noting Section 508 only applies to the government. For private companies, advocacy groups have had varying levels of success applying the Americans with Disabilities Act (ADA) to the web, but the issue hasn’t been settled.
Many governments’ policies and guidelines are adapted from, or even directly reference a set of guidelines released by the World Wide Web Consortium’s (W3C) Web Accessibility Initiative (WAI).
Web Content Accessibility Guidelines (WCAG)
The WAI released the first iteration of the WCAG in 1999. WCAG 2.0 was released in 2008. As the name pretty clearly indicates, these guidelines define a set of criteria for what makes web content accessible. The guidelines can be summarized by saying content needs to be:
1. Perceivable. Users need to be able to see or hear or otherwise discover your content. Content should include audio or visual alternatives. That includes things like alt-text for images and captions for videos.
2. Operable. UI components should be easy to navigate and operate. That means making everything keyboard-accessible and giving users time to read the content of the page.
3. Understandable. Use simple language and clearly communicate how the site works.
4. Robust. Maximize the number of ways a maximal number of users can interact with your content. This primarily refers to making content compatibile with assistive technologies. Assistive Technologies might include:
- Screen Readers
- Braille Terminals
- Screen Magnification
- Speech Recognition
- Keyboard Overlays
- Mouth Sticks
- Access to Subtitles or Sign-Language in Videos
Aside from the WCAG, which focuses on content, the WIA has also released:
- Authoring Tool Accessibilty Guidelines (ATAG), which define requirements for building the tools that build content. This covers things like IDEs and code editors, as well as Content Management Systems.
- User Agent Accessibility Guidelines (UAAG), which define accessibility standards for things like web browsers and music players.
