When you hear the word “Accessibility”, what does it bring to mind? Generally speaking, when we talk about Accessibility, we are talking about ways to allow everyone to have access to information and services. The goal is to allow those with disabilities the same opportunities as their normative counterparts. The problem is, often, this is handled late in the process of development. A customer with deep pockets and a potential for a big sale says that any product they purchase needs to meet accessibility requirements. Occasionally, Accesibility is addressed because someone has decided to sue a company because their product is not accessible to those with disabilities.
I remember seeing a Tweet in early 2015 that put this whole situation in perspective. The message was “I’m worried that people are more concerned with getting their websites working on rich people’s watches rather than for the blind.” I share the frustration with that original tweet, but at the same time, I understand the reality that company’s face. Accessibility is often a very expensive process, especially if it is done after the primary development of a system has already been completed. Yet I will argue that Accessibility is worth the investment. First, from a moral perspective, it’s just the right thing to do. It’s also the law in many places, especially government agencies and those that contract with them. It also makes good business sense to make a product that is accessible, because in the process, it improves the usability for everyone.
Disabilities come in a variety of shapes and sizes. There are four primary disabilities; cognitive, visual, auditory, and mobility. People can have any or all of these in different combinations. We call these “primary disabilities”, and they are usually what we think of. Total blindness, total deafness, complete loss of movement, or greatly limited ability to physically or cognitively interact are hallmarks of these issues. These are, of course, realities for a significant part of the population. Making information and technology available, usable and enjoyable for people with these challenges is very important. Having said that, there is an even larger reality. Every one of us, if we are lucky enough to reach an advanced age, will deal with some form of disability, even if not as completely manifested as the examples listed. There are also “situational disabilities”, and these can affect anyone. Think of trying to hear in a loud environment, or trying to think when stressed or distracted. Language in a foreign place, especially where the alphabet is different from your primary language, can be significant enough to be a situational disability. In short, there comes a time where all of us would benefit from accessible products.
In “Design Accessible Web Sites” (Pragmatic Publishing, 2007), Jeremy Sydic spells out ten principles of Web Accessibility. For those looking to design sites to be more accessible, these principles will go a long way in helping guide development and create systems:
- Avoid making assumptions about the the physical, mental, and sensory abilities of your users whenever possible.
- Your users’ technologies are capable of sending and receiving text. That’s about all you’ll ever be able to assume.
- Users’ time and technology belong to them, not to us. You should never take control of either without a really good reason.
- Provide good text alternatives for any non-text content.
- Use widely available technologies to reach your audience.
- Use clear language to communicate your message.
- Make your sites usable, searchable, and navigable.
- Design your content for semantic meaning and maintain separation between content and presentation.
- Progressively enhance your basic content by adding extra features. Allow it to degrade gracefully for users who can’t or don’t wish to use them.
- As you encounter new web technologies, apply these same principles when making them accessible.
In addition to using these principles to help guide us in designing more accessible experiences, we can also use some different skills to help test sites for accessibility. Albert Gareev developed a mnemonic to help guide testing efforts. That mnemonic is “HUMBLE”.
H - humanize: Be empathetic, understand the emotional components.
U - unlearn: Step away from your default [device-specific] habits. Be able to switch into different habit modes.
M - model: Use personas that help you see, hear and feel the issues. Consider behaviors, pace, mental state and system state.
B - build: Develop knowledge, testing heuristics, core testing skills, testing infrastructure, credibility.
L - learn: What are the barriers? How do users Perceive, Understand and Operate?
E - experiment: Put yourself into literal situations. Collaborate with designers and programmers, provide feedback
If you have never had the experience of using a screen reader before, I encourage you to do the following:
1. Download a screen reader onto your system (NVDA is a free, open source screen reader for PC’s. VoiceOver is built into MacOS).
2. Turn on your screen reader software, then navigate to a site you enjoy.
3. Use your tab key to navigate a typical page. Listen to what the screen reader says to you.
4. If you would like to really help intensify this experience, put on a blindfold or go into a completely darkened room and turn of your display. Interact using only your keyboard.
Example of VoiceOver session with Wikipedia. Wikipedia has made great efforts towards making their site accessible.
I am willing to be that, with many sites, you will quickly find yourself lost or confused at what you are hearing. This is a common and very normal reaction. For those of us who do not have visual impairment, we can always go back to interacting with our systems the way we are used to. For those who are blind or have significant visual impairment, this is not an option.
It’s important to emphasize that we do not need to have a primary disability to experience these feelings of frustration. I wear “readers” specifically to interact with computers, books, or personal electronic devices. If you are standing more than three feet away from me, I can see every detail about you very clearly. According to the Department of Motor Vehicles in the United States, I have 20/20 vision. Yet if you put any text within three feet of me, it gets fuzzy. Small text? Forget it. Without my readers, I can't make out what it says. My situational disability is also much more common. I do not bring this up to compare myself to people who are blind or dealing with significant visual impairment, but I use this as an example of how making sites and applications more accessible benefits all of us.
Implementing accessibility options after a product has been designed can be intense, as well as expensive. Perhaps a better question might be “What if we considered these aspects at the very beginning of the process?" More to the point, what if we were to focus on making an experience that could be used and enjoyed by the largest possible group of people? This "design first” approach is called "Inclusive Design”. It is sometimes used as a synonym for Accessibility, but it is really a complementary discipline. Accessibility is “The design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both "direct access" (i.e. unassisted) and "indirect access”, meaning compatibility with a person's assistive technology.” (from Wikipedia). Inclusive Design is “the design of mainstream products and/or services that are accessible to, and usable by, as many people as reasonably possible ... without the need for special adaptation or specialized design." (British Standards Institute (2005), see).
Inclusive Design is becoming an important topic specifically because people are living longer. These people wish to keep doing the things that matter to them, for as long as possible. Additionally, people are not “able bodied” or “disabled”. Instead, there is a continuum, and all of us move along that continuum as we age. By minimizing capability demands, companies allow more people to use their product. This larger population being able to use a product directly improves the overall user experience for everyone.
A colleague of mine reached into their pocket, held up their smart phone, and said "the biggest push for Accessibility is right here. This device, and all like it, have changed the game". With many people using their mobile devices as primary interfaces, Responsive Design has become critical to displaying data on numerous devices. Having the output be sized and formatted for the screen of the receiving device means much of the legwork for making sites and apps more accessible, too. It's an additive effect, a benefit that carries over even if not the primary intention.
Inclusive Design is, at its core, a method and approach to create products that will work effectively for the broadest group of people possible. It does not mean that it can design for each and every person to use it. That simply may not be possible, but by widening the scope of who will be likely to use the product, and getting a diversity of experiences represented, it is possible to make designs that work well for most. By designating a family or suite of products, we can include more people, encourage them to use our products and have them come back happy to use them again.
A personal example that I currently carry around with me is an app called LoseIt. It's a calorie counting and graphical display program that can give a person a lot of feedback about what they eat and their activity levels. These details are data heavy, and there are lots of ways this can be displayed. What I find very nice about what LoseIt has done is that they have emphasized a design that can be viewed and interacted with in just a few strokes, if any are needed at all. Opening the app to the main screen, I see a number of elements I can select, but most important is how it's displayed. I have a calorie budget, and the way it is represented is a green dial that rises until it meets the limit, and then a red shading that appears after that line is crossed. The number in the center of the dial displays in large digits the number of calories I have left to still be under budget. Below the dial is a bar graph showing me the week's consumption and expenditure, showing how close to the line I am, or if I've gone over the line in the past.
Example screens from the LoseIt Mobile App: calorie count and the nutritional breakdown
What makes these screen beautiful? I can tell exactly what they mean without digging for my readers. It has a lot more detail I can look at, but the big picture is shown as a big picture. I can easily determine what I am looking at. More important, I can make decisions based on the information and feedback I can see. This is a simple example, but it illustrates design choices that don't just please the eye, but actually facilitate use by a broad group of people. Where this presented as a monochrome list of numbers in a table, it would be virtually unusable to me without my glasses. To be frank, when I'm on a bike, walking on a trail, shopping, or in some way moving about, I don't want to have to fumble for my glasses and hurriedly put them on every time I want to interact with the app. I greatly appreciate that LoseIt has taken the time to make sure I don't have to.
Accessibility does not have to be a painful, after the fact initiative, especially if products are designed with Accessibility at the start. Inclusive Design helps with that up front process. As you consider the products you are working on, you too can help advocate for more accessible and more usable sites and applications. Encourage your development team to make your site or app highly structured - easier to learn, remember, navigate, and operate. Make it consistent in terms of design, implementation, and communication. A nice side benefit is that product maintenance will ultimately be easier. Additionally, be HUMBLE and test your implementation. By making these principles priorities, you can help bring about a web that truly is for all.
About the Author
Michael Larsen is a Senior Quality Assurance Engineer with Socialtext in Palo Alto, California, USA. He is a Black Belt in the Miagi-Do School of Software Testing, former President of the Association for Software Testing (AST), and a founder and facilitator of the Americas chapter of Weekend Testing. Michael writes the TESTHEAD blog and can be found on Twitter at @mkltesthead.