I make web applications for humans. In theory, these applications are designed for all kinds of humans. Yet, for some time, I’ve had this uneasy feeling that I haven’t been doing enough to make the products that I work on accessible for more than one kind of person – a person like me.
With that in mind, I recently attended a few workshops and talks on accessibility. I am taking what I learned in those sessions, combining it with some additional research and ideas, and presenting it to you here.
At a high level, this is what we’ll cover:
- What is accessibility?
- Why do we care about it?
- How do we do it?
What is accessibility?
I once thought that accessibility meant putting
alt properties in your images and calling it a day.
<img src="contact-image.jpg" alt="This is a decorative image that shows some coffee on my desk - it doesn't really have anything to do with the content of the page but it adds to to ambiance of the site and I thought maybe if you had some kind of vision impairment, you might benefit from knowing that there was a functionally pointless image on this page."
It turns out that’s the wrong approach and there is a bit more to this whole accessibility thing.
Making an app accessible means ensuring that people with a variety of abilities and disabilities, languages, and ways of of using the web can perceive, understand, navigate, and interact with it.
Again, I used to only think about visual impairments. It turns out there are some other perspectives we need to think about. Some of these are:
- Physical disabilities – sometimes people have to navigate with only a keyboard or use an intermediary tool that gives them limited control of the keyboard.
- Poor vision or color blindness – these folks may not be using screen readers, but the color choices and design of the page matters a lot here.
- Blindness – screen readers don’t actually solve accessibility issues. Your app needs to be designed to work with the tools.
- Technical Ability – is the user familiar enough with technology to implicitly understand the flow of the application or do you need to be more explicit?
- Age – this one isn’t really it’s own category, but it may be more common for seniors to have any combination of other impairments, from vision and hearing, to shaking hands to memory issues. And while people of any age could have impaired technical abilities, it will be a more common issue for people who weren’t born texting.
- Cognitive Disabilities – Does your application accommodate those who need things presented in more simple terms?
- Language/Accents – is your content translated to a language that your users understand or easily translatable? If you use voice recognition technology, does it understand diverse accents?
Note that many of these perspectives and conditions may be permanent or temporary.
Why do we care about it?
About 19% of people in the United States have some kind of disability and about half of these are severe. Depending on how global your application is, that number may a bit higher or lower, but it’s still a lot of people. It’s a lot of people that may be left out if you don’t deliberately include them.
Beyond, that the Americans with Disabilities Act (ADA) requires that business make any and every public-facing digital product accessible . Think they’re kidding? In a recent example of enforcement, Winn-Dixie lost a lawsuit over their lack of accessibility, and the number of district court judges siding with plaintiffs in website accessibility cases is increasing.
Furthermore, if you look back at the short list of perspectives in the section above, you will notice that a lot of the issues I mention aren’t even about disabilities. Some of it is about diversity, and realistically, a more accessible application also makes interacting with a product easier for a person without disabilities.
How do we do it?
As a developer, you may have gotten some direction to “make the product accessible.” That isn’t exactly an actionable story and that makes it tough, but we’re going to have to figure how do this one way or another. The process has to start with empathy and evolve into a concrete set of measurable checks that ensure that we are at least moving in the right direction.
First, we need to think about how people use computers. Obviously, considering every possible perspective is nearly impossible when you’re knee deep in building a product, so I recommend making a checklist.
There is a lot to consider and some tradeoffs that have to be made, so I can’t write your checklist for you, but I will give you a starter list at the end of the article and share some ideas that incorporate into my design process.
Now, let’s think about how people use computers. While we cannot detect for assistive technologies, we can certainly make some assumptions about some of our users and accommodate for likely possibilities.
Keyboard (only) Navigation
It’s fairly common for users to be limited to their keyboards for navigation. Whether they use wands, breathing devices or simply don’t use a mouse with their keyboard, your app should accommodate the situation.
Examples of sites that handle this really well are MDN and Starbucks. They, not only allow the user to
tab through the menus in a logical order and select and deselect items with the
esc buttons, they have clear visual indicators of focus and they allow the user to skip navigation.
Tabbing through content isn’t special functionality that you have to enable, but it does mean that you have to structure your markup in a clear and semantic way. Your header tags should be in ordered from lowest (largest) to highest and you should avoid
tabindex reordering. For users who rely primarily on their keyboards, there are shortcuts that can be used to navigate to a specific
h tag. You also want to use landmark tags like
<aside>. To reiterate, users should be able to navigate through the site by understanding the HTML only.
You will also want to ensure that the visual feedback for what is selected is clear. This is also built into the browser stylesheet, but make sure you don’t override it. If an input is focused, it should be visually indicated.
There is a wide range of vision impairments. From no vision to poor vision to color blindness and everything in between, this means that you should take a variety of considerations into account when designing and developing your application.
With total blindness, the user is likely going to be using a screen reader. The nuances of this tool are out of your control. Most users of screen readers crank the speed up to get through the massive amounts of markup that are getting in the way of their content. They get used to the speed, but it’s still cumbersome to have to aurally navigate through unnecessary code when they want to get to the point, just like everyone else.
This brings us back to the topic above – keyboard only navigation (these concerns are all deeply connected). Blind users aren’t going to be using a mouse and as they tab through the options on the screen it would be a much more pleasant experience if they could skip over navigation, like a sighted person can scan a menu, skip it and use a mouse to click on the more relevant action.
Another consideration in this category is how you use visual cues to convey meaning on a page. Getting away from excessive text is wonderful for design. It declutters the page and it looks more modern, but when the color of a button conveys a meaning that is critical to the understanding of your product, where does that leave a person who cannot see it?
For that reason, you should create redundant ways to convey information if the primary delivery is through a visual cue. In some cases, it makes sense to put hidden text, an
alt tag or an
ARIA property in the component.
Let’s briefly go back to point that I started the article on –
alt tags. You may think that you’re doing blind people a favor by describing every single
img tag on your page, including decorative ones. You don’t want anyone to miss out, right? It turns out that doing this is totally unnecessary. If the image doesn’t add anything to the meaning of the page, include an
alt tag, but leave it empty, with the implication that you didn’t forget, but left it empty intentionally.
Now, there is a whole range of vision impairments that aren’t total blindness. Color blindness is one of them, and for the sake of brevity, I’m going to lump poor vision into this section too. In both cases, you must pick high contrast colors, meaning not only different hues, but different values. The user should be able to view the application in black and white and still differentiate the colors.
If you happen to be using Foundation, it tells you if your color choices aren’t contrasting enough when you build your project (which is so cool!) and if you are not, there are a plethora of tools out there that can help you pick good colors. Check out this color contrast tool.
It’s also a good practice to (prepare to be shocked!) use reasonable text sizes. These are, of course, adjustable in the browser, but in order for that to be a good experience, your app layout needs to be responsive (again, it’s all connected). In general, you don’t want to go much smaller than the browser default, which is usually around 16px. And by “much” I mean no less than `.9em` for the smallest small print on the page.
We won’t spend too much time on this, but it’s worth noting that video (with audio) is a pretty popular web element these days. If watching a video or listening to audio is an integral part of your product experience, please provide subtitles or a transcript.
“I’m just not tech saavy,” is a phrase we’ve all heard before and it becomes a real issue when the person saying that is trying to use your application. There are many reasons that an individual’s technical ability may be below your expectations in the design process. That knowledge gap will affect how actions that seem intuitive to you, seem to certain users. Ask yourself if all of your users are familiar enough with technology trends to implicitly understand the flow of the application or do you need to be more explicit? Make the next desired step obvious, even outside of the context of technology.
Many people with cognitive impairments have a tremendous amount of value to contribute to and get from the web. Does your application accommodate that perspective? Is the language simple? Is it easy to click on or select buttons? Is it possible to take an easy alternative path (perhaps with less customization)?
Not speaking the primary language of your application is not exactly a disability, but when English isn’t your language, navigating a site built only for English speakers it can be an obstacle for several reasons.
The most obvious one is reading, or consuming the content on the page. Google Translate is a great tool, but it’s not perfect. If you have any complexity or jargon in the information on your page, try to have translated versions for languages common to your users.
On a side note, limiting technical jargon helps in several accessibility categories too. If you must use jargon, include a key or a quick lookup mechanism that allows your users to fully understand the content.
If it’s not realistic to translate, at least include a language attribute in your
<html> tag so it’s easier for the browser to translate.
A second consideration that is often overlooked with our excitement over voice recognition technology is the issue of accents. If you’re writing software that takes voice commands, test how well it understands a diverse set of accents.
UX is Part of Accessibility
The overall experience of interacting with your application affects accessibility for all people. I won’t go into UX 101 (more than what I’ve touched on already), but the point is that when you think about accessibility, think about UX and vice-versa. The two domains are deeply connected.
More on the Language of Accessibility
Everything up to this point has been pretty general and I wholeheartedly believe that we need to start with why, what, and how. However, I want this to be the first step on a longer journey to becoming proficient at building accessibility into your work and with that in mind, I am going to introduce a few more concepts before we wrap up.
The Web Content Accessibility Guidelines are the standard for web content accessibility. They provide detailed and fundamental guidance for developing accessible applications. WCAG also has a kind of grading system. It makes it easier to understand where you stand and what you need to do to get better. The WCAG Levels are:
- A – Baseline
- AA – Good
- AAA – Amazing!
I highly recommend going straight to the source and browsing the guidelines from top to bottom.
This is a good mini mental checklist that you could review throughout the development process. Ask yourself, is the content…
- Perceivable – Can everyone consume the content? See it? Hear it?
- Operable – Can everyone use it? Navigate
- Understandable – Does it even make sense? Typos/ clarity. User Flow
- Robustness – Does it work in a broad variety of environments?
Accessible Rich Internet Applications (ARIA) is a set of accessibility attributes that can be added to HTML to improve accessibility of your application. These are extrememly useful, but not the end all solution to all accessibility issues. Use ARIA intelligently with other techniques.
There are three aspects of use:
- WAI-ARIA roles – give assistive technologies information about how to handle each element
- WAI-ARIA states and properties – let assistive technologies access the state of an application
- Managing focus
We should all be user testing our applications. The more, the better, but understandably, sometimes we have to work with limited resources, so we don’t get the opportunity to go big. In any case, when we do user testing, no matter how small, we need to make a concerted effort to test with diverse groups. Find people outside of the office or at least outside of the department. Older and younger people. People for whom English is a second language. Find color blind people. Ask people who you wouldn’t normally ask to test your app. It will be better for it.
As promised, I will leave you with a checklist that covers just the basics. Every item won’t apply to every product, but I hope that it gives you good template to create your own Accessibility Checklist.
- Can you tab through all of the elements on the screen?
- Can you skip the navigation with a keyboard?
- Is your HTML semantic and organized?
- Do all visual cues have a redundant text cue?
- Is the contrast high?
- How does it look in black and white?
- Is the text big enough?
- Is there any unnecessary jargon?
- Is the necessary jargon defined?
- If there is video, is it captioned?
- Is the UX intuitive for a low-tech person?
- Is there a simple route for a cognitively disabled person?
- Is the content translated if it needs to be?
- If there are voice recognition features, have you tested them with a variety of accents?
- Is the next desired expected action obvious?
- Is the UI simple and supportive of the functionality of the app?
This is truly just a start. Hopefully, it’s foundational enough that you can say ‘I already knew a lot of that’, but also informative enough that it has you thinking about how to apply accessibility principles to your own site. Most importantly, remember that accessibility is not all-or-nothing. If you don’t have the resources to make your product AAA, it doesn’t mean that adding a few helpers throughout the code isn’t helpful to someone. Do what you can and keep pushing to make it better.