Many times as developers, our study of website accessibility focuses on the technical know-how of making websites ADA Compliant, and rightly so. It is our duty as builders of the internet to make sure that the content we create is accessible for as many users as possible.
In this article, however, we’re going to talk about accessibility from the viewpoint of the users. We will take a look at the basic principles of website accessibility as defined in the WCAG and some of the most prevalent conditions that impair people’s ability to use the internet.
To be clear, if you’re looking for highly technical documentation on how to make a website that you are building accessible, let me save you some time because that isn’t what this article is all about. That said, we have literally written the book on how to create accessible websites. Check out our free Ultimate Guide to the ADA.
By taking a non-technical approach to talking about web accessibility, and learning about the actual conditions that affect a person’s ability to use websites, we can paint a more full picture of what an accessible website looks like.
When we do this, we create a mental model of accessibility that can be acted upon intuitively while building websites – rather than a technical checklist to be gone through after completion.
Who’s the boss?
Unless you’ve been intensely studying website accessibility for the last several years, you may find yourself a bit puzzled by all the acronyms surrounding this topic. Let’s go ahead and take a minute to talk about those first.
- ADA (Americans with Disabilities Act) is the legislation that was first signed into law in 1990 ensuring that most businesses that served the public were to be made accessible to persons with disabilities. The original version did not include anything about websites, but a later revised ruling in 2010 changed that, extending the “public use” term to electronic media such as websites and applications.
- W3C (World Wide Web Consortium) is the international group that creates the standards that developers use every day to make websites, so naturally it is quite fitting for them to also create the guidelines for web accessibility.
- WAI (Web Accessibility Initiative) is the official initiative created by the W3C to author the specific guidelines that we follow to create accessible websites. This initiative is made up of several different groups and stakeholders in web accessibility and they help ensure that new W3C standards support accessibility.
- WCAG (Web Content Accessibility Guidelines) are the specific guidelines published by the WAI. These guidelines are constantly being updated and revised, and so the current version we are operating on as of this writing is the WCAG 2.1. The WAI also has 3 levels of conformance to accessibility standards: A, AA, and AAA with A being the lowest and AAA being the highest.
Most organizations should strive to have their website achieve the WAI-AA WCAG 2.1 conformance standards.
It is fairly interesting to note here that because the W3C WAI is an international group the WCAG standards are actually international standards, even though we commonly refer to accessible websites as being ADA (Americans with Disabilities Act) compliant. (the more you know!)
Time to POUR it on…!
The WCAG 2.1 defines that accessible websites should be: Perceivable, Operable, Understandable and Robust.
When creating an accessible website you want to make sure that the information you are presenting is going to be perceivable to your audience no matter how they ‘view’ it. In a nutshell, you want to look at your content and ask how someone might receive it, if not by the typical method. For example, if I were blind, how would I read the text on this page or know what is depicted in an image? If I were deaf or hard of hearing, how would I know what the people are saying in a video, or what the music they’re dancing to sounds like? If I magnified the font by 400% would I still be able to follow the layout of the text?
Most of us are very accustomed to operating a computer by using a keyboard and mouse, but for a substantial (and growing) number of people who use the internet, this is simply not a possibility. Making a website operable tells us to think about the structure of the website we are building, and ask ourselves how easy it would be to navigate through it if using a keyboard, or a mouse, or both were not available. It is also a reminder that some people have sensitivities to certain kinds of content, or may generally take more time to digest or use the content we present, and not factoring those things into our construction may make a website inoperable to those users.
It is important for us to remember that learning and comprehension can take place at a variety of levels varying from person to person. When building out web pages, this criteria is prompting us to ask ourselves how we could make the content we are presenting the most understandable for our audience as possible. This piece often goes well beyond the technical knowledge of the developer, and relies heavily on the designers and content writers to help create clearly written and well organized content. While it may be tempting to sacrifice organization for a fancy new-age design, the WCAG asks us to find a compromise that allows for a clear structure to make a site most accessible.
While this one may be the most difficult to define directly, it is in fact one of the most important criteria the WCAG provides. By maximizing the amount of tools (currently available and future) that can interpret our websites, we are in turn making the website more robust for the user. At first glance, it may be confusing to say we should make websites that are able to interface with tools that don’t exist yet, but it is actually quite simple. We already possess the tools needed to make the most semantic sense of the websites we are building. We just need to use those tools to their fullest potential.
I said that I wasn’t going to get into the technical details of web accessibility, and I’m going to hold to that, but hopefully the developers out there reading this had a bit of a lightbulb moment…
As we continue our discussion to take a more personal look at the WCAG, the point I’m trying to make in this article should become more and more clear: by making a more accessible website you are, by all considerations, making a better website.
“The one argument for accessibility that doesn’t get made nearly often enough is how extraordinarily better it makes some people’s lives. How many opportunities do we have to dramatically improve people’s lives just by doing our job a little better?”Steve Krug, User Experience Expert and Author
Let’s Get Personal
I would like to spend some time now on the actual conditions that people have impairing their ability to use the web. Keep in mind that this is not an exhaustive list – I’m just highlighting some of the most prevalent disorders that occur to better illuminate the previously detailed list of criteria in the WCAG 2.1.
It is also important to remember while we are going through these that people can have any number of differing disabilities often creating requirements that consist of combining two or more forms of enhancement.
The W3C WAI highlights five top-level categories of disabilities affecting the use of the web may fall under, with one additional category called “Diversity of Abilities.”
These five categories are:
- Cognitive, Learning, and Neurological
This category can be broadly classified into two separate groups: hard of hearing – which is mild to moderate hearing loss in one or both ears, and deafness – which is complete loss of hearing in both ears.
The main point to understand with auditory conditions is that any multimedia presented that has audio should be captioned and contain transcripts. Furthermore, if you have the ability to allow users to control the size, font, and color of those captions they will be even more accessible for those who may have auditory and visual impairments at the same time.
Keeping in mind that auditory impairments include people who are hard of hearing (not fully deaf), we want to try to choose audio content that is as clear and easy to hear as possible. For podcast creators, the end goal of making audio content accessible actually starts with the sound engineer that mixes the audio and/or treats the room used for recording.
Going even further into creating accessibility for auditory impairments, if you’re trying to enhance the experience you are creating for as many people as possible, then you will even want to offer the ability to access the audio in your multimedia via sign language.
Cognitive, Learning, and Neurological
Often, I believe, some of the most overlooked conditions affecting website accessibility are these. Because it is quite a bit more straightforward to understand how someone who can’t see or hear would have a difficult time interacting with the websites we create, it’s not always easy to not realize all the ways people with cognitive, learning, or neurological issues might be obstructed from properly using a website.
These conditions may involve behavioral or mental health disorders, learning disabilities, or could stem from other neurological issues. While users presented with these conditions do not necessarily have impacted intelligence, the conditions do impact their ability to hear, move, see, speak and understand information.
Because this is a relatively broad category, I’m going to give a brief (not extensive) list of conditions that fall under the terms cognitive, learning, and neurological impairments: Attention deficit hyperactivity disorder, autism spectrum disorder, intellectual disabilities (also referred to as learning or perceptual disabilities in different regions), mental health disabilities, memory impairments, multiple sclerosis, neurodiversity, and seizure disorders.
For people with these types of conditions the very best thing we can do is be very considerate in thinking about the design, underlying structure, navigation, and interaction of our websites.
We want to make sure that if someone is unable to use a mouse that our website can be logically tabbed through using the keyboard, and that the elements focused on are clearly indicated. It is also important to try to use clearly written language, breaking up large chunks of text into more readable bits, and supplementing with images, graphs or illustrations.
As developers we want to take advantage of as much semantics as we can in our programming, becoming increasingly granular in how we use HTML elements, and make sure to use labels for our elements wherever possible.
Because these conditions also include seizure disorders such as epilepsy we want to try to stray away from flickering or blinking elements (including flashing animations) as much as possible, or include obvious ways to turn those elements off if they can’t be avoided.
Reading this you might realize that everyone building websites most likely knows someone who will benefit from web accessibility…
That’s a big leap, and an important one.
Physical or motor disabilities are another broad category of conditions that can severely limit people’s ability to use a computer. Signatures of physical disabilities include weak or limited muscle control, tremors, lack of coordination or sensation, paralysis, arthritis, and/or missing limbs.
Physical limitations can occur from birth such as with muscular dystrophy, they can be onset with conditions like tremors or Repetitive Strain Injury, or happen suddenly in an accident resulting in amputation or quadriplegia.
One of the reasons it is important to understand this, is because when someone is dealing with a condition that is newly prohibitive to them, they can quickly become frustrated and confused by their inability to use a website. They also may not be aware of all the different assistive technologies available to help them use your website and/or have limited access to find them.
People with physical disabilities will often need to use assistive devices and technologies to help them navigate a website, and so a clear, easy to follow, and well indicated navigation is essential to them.
One basic way to test out whether or not your website is accessible on this level is to try to ‘walk’ through your website just using the TAB key. If you’ve never done this before, it’s definitely worth it to see if you can get to where you want to go on the site. This is obviously not a catch-all test, but can surely give you an indication that you have more work to do.
Some website users may have trouble with speech, particularly with their speech being interpreted by voice recognition software. If your website or application requires a user to operate any part of it by voice, you may want to think about offering another way for them to provide input.
In a potentially more common situation, if your website only lists a phone number as a way to communicate with that business, then you may want to consider adding a form or chat for them to send a message to you.
If your website does not require any speech interaction, then you may have less to worry about with making it speech accessible. Simply having the knowledge that there could be speech barriers to your website if such functionality arose, and knowing how to handle those issues, is what we’re trying to accomplish.
It is also worth noting that while a website you are building might not have any direct speech input requirements, someone could be using one or multiple devices that do rely on speech, and so clear and well organized content is always your best tool in creating the most accessible website possible.
Users with impaired vision may be completely blind with no vision in both eyes, have low vision – which is mild to moderate vision loss in one or both eyes, color blindness, or even have increased sensitivity to very bright colors.
As developers, we’ve been trained to make sure that images contain alt text and that ARIA attributes are used to describe certain elements of a website. We know by now that we have to make sure that the websites are readable by screen readers for blind people to access our content.
Blindness, however, is only one of the visual impairments that someone can have preventing them from fully experiencing your website. It is more often overlooked by designers and developers how something would appear to someone that is color blind, or even how your website would look if you were to magnify the text by 400%, but these are also very real scenarios that website users encounter every day.
There are many ways you easily check on the accessibility of your website for visual limitations. You can use the WebAIM Contrast Checker to see how the contrast of text color and background are perceived together, you can use the built-in screen reader in Chrome to hear how your page would be read aloud, and you can even very simply just start increasing the zoom on your browser and see how the content reacts.
A great explanation of how text-wrapping can affect someone’s experience who is trying to view a website with a lot of magnification can be viewed here. This video is yet another reminder that by simply using the tools already available to you as a developer to make a better website, you are in fact making a more accessible website.
Diversity of Abilities
The last section of disabilities that the W3C WAI provides guidance on is called “diversity of abilities’” and is really a more general statement that people can experience a variety of levels of diminished capabilities in all of the previously mentioned categories. Some of these ailments may start with the individual from birth, onset at an old age, and even throughout life brought on by accident, illness or disease.
It is important to note that many people who have debilitating conditions do not actually consider themselves to be disabled, and because of this may not have access to, or knowledge of, assistive technology.
This is why it is essential for us as developers, designers, project managers, content writers, and the like to take on the role of “being the boss” about website accessibility and making sure that we’re constantly trying to raise the bar when thinking about ensuring that everyone has equal access to the content we create.
By the way, if watching a case study video in the previous section helped you put some pieces together, these perspective videos produced by the W3C WAI may offer some additional insights as to how real people both with and without disabilities can benefit from accessibility.
As mentioned many times in this article, by making a website more accessible, you are indeed making a better website for all who use it. One of the best things we can do right away to make more accessible websites is to be as semantically precise as possible when we are building.
By creating a website that is easier for machines to understand, you are allowing the ability for more devices to help humans interpret the content. By building a clear and consistent layout into your website, it will be the most accessible for anyone (with or without disabilities) to use.
Are you passionate about accessibility and want to help? There’s loads of ways you can take part in the discussion! Later this year you can join, sponsor or volunteer at the WordPress Accessibility Day. If you’re not in a technical field regarding web accessibility, hopefully this article inspires you to become an a11y in any way you can! (By the way, that’s a11y as in ally, and also there are 11 letters between the a and the y in accessibility.)
If you would like to contribute to the discussion on website accessibility, we’d love to hear from you! You can post on Twitter with your feedback – we may include it in a future article on accessibility. If you’d like to write a paid guest article on accessibility (or any other topic), please let us know!
If you want to learn more about how to make websites accessible and desire a more hands on approach, stay tuned! We are actively working on putting together a full course on website accessibility that will be released in the coming months. To be the first to know about that course and others on their way out of the gate this year, use the form on this page to hop on our newsletter.
Thanks for joining me on this one, and until next time, cheers!