What is Accessibility for Web Apps and Why Do I Care?

As the web has grown in usage, old ways of doing things have fallen behind. But what technology makes difficult, it also can make easy. As long as we follow a few simple guidelines, we can make the web available to pretty much everyone. 

Every year more and more of our life is conducted on the web, from shopping and sharing to banking and business. What was done in person or on paper or on the telephone a few years ago all takes place on the web today. We all now have access to a dizzying amount of information and activities online. But as the web has grown in usage, the old ways of doing things have fallen behind.

Paper letters, telephone conversations, in-person shopping... these belong to a museum now, and in many cases there are things that now can only be done on the web, and no longer in person. Bank branches and even ATMs have been replaced with online banking. Blockbuster and Borders Books are a distant memory, and Sears filed for bankruptcy after shuttering many stores. Now we have Amazon.

This is great for most of us, and a time saver for many, but what if you are not able to use the web? What if the store you used to shop at went out of business from online competition, but the online store is not something that you can use easily? This is where accessibility comes in. And just like ramps on the sidewalk and braille on the elevator buttons have made physical movement easier for those with disabilities, so too has accessibility efforts made the web usable for those who are not able to surf the web in the same way that the rest of us are used to.

It might even surprise some of you that people with disabilities are even able to surf the web. But what technology makes difficult, it also can make easy, and there are a number of tools and processes that actually make the web available to pretty much everyone. At least, as long as we follow a few simple guidelines.

This is not an issue that only affects a small segment of the population, either. According to the US Census Bureau, nearly 1 in 5 Americans – 57 Million people - have a disability of some sort. These disabilities make life difficult in the world today. Many of these come with age which adds further burden to a group that already has to deal with reduced earning power, less technical familiarity, and other limitations. The likelihood of having a severe disability in the 65-69 year age group is one in four, where it is only one in 20 for the 15 to 24 year old group.

With widespread disability comes the need for accessibility for this group. Accessibility is often abbreviated “A11Y” because it starts with an “a”, then has 11 letters, then ends with a “y”. And that itself is really a matter of accessibility because if you struggle to enter characters, then a four-letter word is much better than a 13 letter word. Accessibility is not just one thing either, it’s a collection of things. It’s a little bit user experience, it’s a little bit design, it’s a little bit coding, and it’s a little bit testing. But put it all together and you have a pleasant web experience for everyone.

Let’s stop a minute and think about why we really care about all this. So what if a handful of people have trouble accessing the web. Do we really need to worry about one more thing when we are trying to get our app done? Well, yes, we do. For three main reasons.

3 Good Reasons to Care about Accessibility

First of all, let’s start with not being a jerk. It’s hard navigating life with a disability, and if you can make people’s life a bit easier with a few changes on your part, then you should do it. Let’s assume we all agree on that. Disabilities take a toll on people’s life in many ways, including reducing access to employment. Of the age group 21-64, people reporting a disability only experience 41% employment, compared to 79% employment in this same age group who had no disability. Among people 15 to 64 with severe disabilities, 11% experience persistent poverty.

Secondly, and selfishly, it’s usually in your best interest. There are over 56 million people in the US alone with some amount of disability. That’s a pretty big market. Do you really want to ignore that many potential customers when all you have to do is have a little more care when you build your apps?

Thirdly, even if you don’t care about the first two reasons (which is hopefully not the case) then you need to do it because it’s the law. Web site accessibility – whether internal or external – falls under the Americans with Disabilities Act (or ADA). And sooner or later, it will catch up to you. In 2017 over 800 federal lawsuits were filed in the US against websites for accessibility violations, 14 times as many as in 2015. Companies keep trying to argue that the ADA doesn’t apply to their website, and almost without exception the judges keep ruling that it does. Do it now, or wind up in court later.

And there is actually a fourth reason too (yes, I know I said three, this is a bonus). If you look at the things that you need to do to make a website or app accessible, most of it is just a bunch of good design practices for everyone. Sure, a deaf person might not be able to hear the soundtrack to your explainer video, but someone in a crowded open office might also just not be able to play it loudly enough to hear it. So put in captions – for the deaf user, sure, or just for the user who can’t play loud soundtracks. That’s just one example of a case where accessibility doesn’t just mean being accessible to people with disabilities.

Another factor to take into account (but not a fifth reason) is that while people often think that making an app accessible is a lot of extra work, it really isn’t. Most of it is simply following good design practices from the start. If you build your app right to begin with, you won’t have much extra work at all.

Types of Disabilities to Consider

What are the kind of things we need to worry about? Let’s start off with five types of disabilities to consider. These are:

• Physical – poor or no motor function
• Visual – low-vision, blind, color blind
• Hearing – deaf or hard of hearing
• Cognitive – dyslexia, autism, ADHD, etc.
• Speech – unable to speak or have speech impediment

In addition, we need to consider combinations of disabilities where possible as well as single disabilities. This can present particular challenges for the user. For example, if your solution to impaired vision is to use a screen reader and the user is also hard of hearing, they have a problem.

For each of these, we need to think about how that affects the functionality of the app. We need to consider non-standard means of interaction: Does my site work without a mouse? Without visual cues? Without sound? It can be very interesting to try to disconnect the individual I/O devices from your computer and see how well your app works. Turn off the monitor, put away the mouse, turn off the speakers… what happens when you do?

To really test out an app, however, we need to test it in the situation that a disabled user will typically be in. Users with vision impairments will usually be using a screen reader so while they might not be able to see the screen, they will be having it read to them. So we also need to consider the use of common assistive tech that people with disabilities might be using: Does my site work with various assistive technologies (AT) like readers, magnification, special keyboards, etc. ? Understanding the environments that will be used helps create apps that will work well with these devices and also set the stage for effective testing.

Disabilities that are not Disabilities

We have been considering people with typical disabilities that we are largely familiar with, but there is another class of users that we should include in this grouping: people with transient or situational disabilities.

First of all, we need to include people who might not have a very good handle on technology. This is largely older users who grew up without computers or the internet. Many of them simply are not comfortable or particularly familiar with the use of technology. Add to this age-related issues like reduced eyesight, hearing, or mobility, and simply not understanding what a user interface is asking for can have the same effect as an actual cognitive impairment.

Next we should consider the environment that the user is working in. What if they are surfing the web in a noisy Starbucks, left their earbuds at home, and just can’t hear the nifty explainer video you posted? What if they are in a sunny park with their laptop and the bright sun is washing out their screen and making it hard to see? Or what if they are in a location with very slow wifi (horrors!) and each page is loading very slowly?

In addition to location, consider equipment. What if they are on a mobile phone, or an old computer, or on a computer with an old version of a browser?

And finally, what about temporary health issues? You would not expect someone to be buying rock climbing gear if they did not have the use of their hands, so maybe you don’t do much about physical disabilities on your rock climbing store site. But what if they simply broke their hands on their recent rock climbing excursion and, because they are slow learners, want to buy some more equipment so they are ready when the cast comes off?

These are situations where it is dangerous to assume that you know your users and are certain that they will not be operating with specific disabilities.

Hitting 100% Accessible

One short but important point to make is that the reality is that you will likely never be 100% accessible to everyone. Accessibility isn’t binary, and it isn’t measured in “yes” or “no.” There are limitations to any approach to providing alternate forms of access. Combinations of disabilities can be extremely challenging. And finally, some techniques to help one type of disability can actually make it harder for other types of disabilities.  Accessibility is all about providing the most good for the most people without making your app hard to use for people without disabilities. Fortunately you don’t have to figure this out and there are standards and guidelines to follow to reach this state.

So how do we prioritize? What are the disabilities we need to worry about the most? If we look at data from the US census, we see the following:

Of the 57 million people in the US with a disability:

• 8.1 million have some level of vision impairment
• 2 million are blind
• 7.6 million have hearing impairment
• 1.1 million have severe hearing loss
• 5.6 million use a hearing aid

Beauty vs. Accessibility

Another short but important point to make is that making your app accessible absolutely does not mean you have to make it ugly, or clunky, or violate your company’s brand standards. A large number of the accessibility guidelines will actually make your app more usable for everyone and will provide a better all-around user experience. You do not need to compromise to be accessible. 

The Next Step

Having taken a quick look at how disabilities impact a user’s access to content and services on the web, the next step is to take a look at the laws and guidelines that apply to web access. This will primarily be the WCAG 2.1 specification in the United States, and the governing law is the ADA. Most countries have their own laws in place to provide online accessibility, but this is a good place to start for most people and if you plan on operating in the US, then you need to be at least compliant with the WCAG 2.1 standards. In the rest of this blog series on accessibility we will go into more detail on the laws that apply to online accessibility and the standards that are used to guide implementation. We’ll take a deeper dive into exactly what that means for your app development, and then show actual examples of how to code popular design elements to guarantee accessibility. Stay tuned!

Update: Click here to learn more about Accessibility and the Law.

Learn More about Accessibility

We have created a comprehensive whitepaper on accessibility for developers that covers everything from laws to coding to testing.

Download the whitepaper: Accessibility for Developers

Adding Accessibility to Your Apps

One easy way to make sure that you are creating accessible web apps is to start with components from the Kendo UI libraries. Our components are all WCAG complaint and give you great functionality from grids and charts to schedulers and pickers. Get a head start on your app's UI and a head start on accessibility compliance at the same time.

Learn more about: Kendo UI