Why Accessibility Matters (To Me)
For a number of years, I’ve been following the topic of web accessibility. My interest began as a curiosity, a desire to better understand what it was and how to make it happen. Over the years, though, that curiosity has changed to a deep-seated need to understand and make better overall products.
Before going any further, I feel it is important to establish what web accessibility is. According to Wikipedia, “Web accessibility refers to the inclusive practice of removing barriers that prevent interaction with, or access to websites, by people with disabilities. When sites are correctly designed, developed and edited, all users have equal access to information and functionality.”
In some circles the word “accessibility” is abbreviated to “a11y”, as there are eleven characters between the first and last letter of the word (similar to how “i18n” is used to abbreviate “internationalization”).
A simpler way I’ve found to describe it is as follows: Making web content available to users, regardless of their abilities.
This is not to say that all users will experience a website or product identically. Rather, that they’ll all be able to interact with the full contents of the site.
The foundation of the Web Content Accessibility Guidelines, or WCAG for short, is based upon four simple principles that form the acronym POUR (Perceivable, Operable, Understandable, and Robust).
To be perceivable, the content of our sites must be presentable to users in ways they can perceive, not only how I best consume content.
To be operable, the user must be able to interact with components and navigate the site. This means that content can be navigated via keyboard, and won’t trap the user’s cursor. It also means that they’ll have sufficient time to read and use the content. Finally, they’ll be able to navigate, find content, and determine where they are within the product.
To be understandable, the content must be understandable. Obvious, right? To be a bit more precise, this means that the language of the content is defined. Also, the content appears and behaves in consistent, predictable ways. Finally, it is built to prevent mistakes and, when made, helps to correct them.
To be robust, the content of our sites must be able to be reliably interpreted by a wide variety of user agents, including assistive technology. This means that current and future products will be able to parse the content we’re creating and present it to the user.
Now that that is out of the way, let me explain why accessibility is important to me. First, it’s simply the right thing to do and, in reality, the remaining arguments aren’t really necessary, but I’ll provide them anyway. Second, without going into too much detail, I have several family members who have, in recent years, gone from extremely able-bodied to not. Arthritis, physical mobility, vision degradation, and a series of strokes have impacted members my family and I’ve seen the effects less than fully accessible physical spaces have had on these family members. Why should the web be any different? In fact, shouldn’t the web be more accessible?
Finally, the number of people who fall into at least one category of need is astounding. These needs are not always permanent, but are often profound. An Alphabet of Accessibility Issues shows a sample of conditions that, if you stop and think about it, will include someone you know who faces these issues.
For people without disabilities, technology makes things easier. For people with disabilities, technology makes things possible.
– IBM training manual 1991
If the above reasons aren’t sufficient, keep in mind the high cost of digital discrimination. While costs of defending litigation and retrofitting existing products to meet accessibility requirements are very tangible and measurable, the cost on your reputation isn’t. Do you want to be the creator of a product that doesn’t care about the needs of its users?
So, how can we build complex web applications that are accessible? To start, I’d like to ensure that we’re thinking about web accessibility in the appropriate manner. First and foremost, HTML is inherently accessible when written semantically. Accessibility tools are built to consume and relay HTML to their users in a manner that is understandable to them.
The place where we go wrong is in how we use the development tools made available to us. Every decision we make either retains that accessibility, or removes a portion of it. Providing good alt text for an image? Accessibility kept. Removing the outline from focused elements with a CSS rule because it’s not as “clean”? Accessibility lost. Make an element clickable via JavaScript that isn’t focusable with the keyboard? Accessibility lost.
Accessibility is not something we add to a website, but something we start with and risk losing with each enhancement. It is to be retained.
– @scottjehl
So how do we build accessible, complex web applications? It may sound like an arduous task, but the answer is relatively simple. For each decision we make that has a negative impact on accessibility, we take the step to restore that accessibility, often using ARIA attributes. The Mozilla Developer Network has a great collection of ARIA resources.
Here are a couple of straightforward example: I want to build a product that includes a form. By utilizing the for attribute on the label element, I associate the label with its input. This benefits both sighted and non-sighted users. It ties the label to the input for the non-sighted user, and allows sighted users a larger click area to place focus into the input. Further, if I have fields that are required, I can include visual indicators for those fields, but I can also include the attribute aria-required=”true” to allow accessibility tools to improve the interaction for non-sighted users.
For more complex interactions, such as modal windows, dropdown, tabbed interfaces, or embedded videos, there are many resources to ensure the accessibility of your products. The a11yproject pattern library is one of many such resources you can use to get started.
If I have any advice to give, it is this: Try. You won’t knock it out of the park on your first attempt. You’ll miss opportunities. You’ll make things that are totally inaccessible, but that’s okay. Keep trying and you’ll continue to make better product with each and every attempt. And your users, both fully able-bodied and not, will be better for it.
Photo credit: Ralph Aichinger via Flickr cc
