What Is Accessibility?

Get a basic understanding of accessibility, its advantages, and the rules defined by WCAG.

So, what exactly are we talking about when we talk about accessibility?

Anyone and everyone should be able to access the web without barriers. Accessibility means that we are committed to creating robust websites and applications that are easily perceivable, operable, and understandable for all users.

Press + to interact
An illustration of a computer monitor surrounded by icons for many common applications (Messenger, YouTube, FireFox, Microsoft Office, Chrome, Facebook, Twitter, and Adobe Photoshop)
An illustration of a computer monitor surrounded by icons for many common applications (Messenger, YouTube, FireFox, Microsoft Office, Chrome, Facebook, Twitter, and Adobe Photoshop)

A huge percentage of our daily life happens digitally now: education, shopping, social connection, entertainment, and much more! We primarily use websites and applications to share this content. This means that when those websites or applications aren’t accessible, we restrict their use to only a subset of people.

Why is accessibility important?

Access to the internet shouldn’t be limited based on a person’s physical or mental ability. A fully sighted person has no more right to the web than a visually impaired person. And yet, so often, that’s exactly what happens because the creators of that website or application didn’t prioritize accessibility.

When we neglect to include accessibility, users are unable to get the full benefit—or possibly any benefit—from the software we build. For example, for blind or visually impaired users, a website built without any alternative text to describe images means they’re missing out on the crucial context supplied by those images. For deaf or hard-of-hearing users, a video of an interview offered without captions is nearly useless. For users who don’t or can’t use a mouse, a website that can’t be navigated by a keyboard is unusable.

Press + to interact
An illustration of one hand holding a clipboard with a paper titled “Review,” while the other hand writes checks or X’s in checkboxes
An illustration of one hand holding a clipboard with a paper titled “Review,” while the other hand writes checks or X’s in checkboxes

It’s currently estimated by the World Health Organization that one in every six people lives with a significant disability—roughly 1.3 billion people worldwide. The odds that some of those people are users of your application or website are incredibly high. Those users deserve just as enjoyable and effective an experience as everyone else. Often, accessibility is positioned as an extra or nice-to-have that only a small subset of our users will need. But when we look at the data, we can see quickly just how untrue that is. Ignoring 1.3 billion potential users is simply bad business, no matter how you slice it.

Everyone benefits from accessibility

Often, when we first think about accessibility requirements, we make an (incorrect) assumption that this only applies to people with permanent or apparent disabilities. While those individuals are an essential part of our user base that we do need to consider, it’s a misconception that they are the only ones who benefit from accessible software.

For example, imagine someone who ruptured their eardrum. Typically, this would leave them unable to hear in the injured ear for about a month, and then they would be hearing impaired in that ear for several months afterward. The injury is temporary—it eventually heals, and the person would no longer be impacted by it. However, during their recovery, accessibility features such as captions, the ability to adjust the output balance of headphones, and haptic feedback/vibrations for notifications (instead of audio alerts) would all be useful—if not essential.

Press + to interact
An illustration of a globe with many different location markers. Each location marker shows a user icon in a different color, symbolizing all types of users from around the world
An illustration of a globe with many different location markers. Each location marker shows a user icon in a different color, symbolizing all types of users from around the world

Accessibility features improve the user experience for everyone. Users who might not need those features to access your website or application could still be more comfortable or at ease having them available. Features built for visually impaired users will also benefit users who have migraines and can’t always look directly at a screen, as well as users who are outside in bright sunlight and can’t see their device screen well. Features built for motor-impaired users will also benefit users with a broken arm, as well as users holding a baby who don’t have both hands available.

You likely already make use of accessibility features without even thinking about them. If you’ve ever changed the theme colors of an app, zoomed in to adjust the size of the text in a browser, or dictated texts to Siri, then you’ve benefited from accessible design and development. At the end of the day, making our users’ experiences as frictionless and easy as possible is our primary responsibility. If people struggle to use our applications or websites, they will simply find an alternative. Accessibility is key to usability, and usability is key to user retention and growth.

Accessibility is a right

As developers, it’s our responsibility to ensure that we have been thoughtful and intentional about how we build our software so that it is as inclusive as humanly possible. But this isn’t only the kind and morally right thing to do. It’s also quickly becoming a legal requirement. In fact, according to the UsableNet research team, the number of web accessibility lawsuits has risen yearly since at least 2018. In 2020, web, app, and video accessibility cases went up almost 25% year over year in the United States, and there were more than 3500 digital accessibility-related lawsuits that year. New accessibility legislation, in the form of the Websites and Software Applications Accessibility Act, was introduced in the US Senate and House of Representatives in September of 2022.

Press + to interact
An illustration of a set of scales, symbolizing justice. The side holding the checkmark is weighted heavier than the side holding the X
An illustration of a set of scales, symbolizing justice. The side holding the checkmark is weighted heavier than the side holding the X

We can wait and see whether any of our users will choose to take legal action, or we can start focusing on accessibility now. Accessibility and meeting the Web Content Accessibility Guidelines criteria are just part of having a digital presence now. If you had a physical storefront, you would be required to meet the Americans with Disabilities Act criteria in the United States or the Disability Discrimination Act criteria in the UK. The requirement for equitable access doesn’t change just because we’re creating something digital and not physical.

It’s a mistake for us to think about accessibility features as an edge case or a nice-to-have that isn’t a true requirement. Accessibility needs to be a nonnegotiable part of everything we create. If you weren’t already completely committed to prioritizing accessibility or were unsure how to articulate it to get buy-in from a manager or boss, we hope that these past few lessons have given you the information you need to convince yourself and your organization of the importance of accessibility.

POUR: Accessibility principles

To make equal and accessible access a reality for our users, we (the developers) are obligated to create content that fits the following criteria:

Press + to interact
An illustration of a keyboard next to the word “POUR.” Underneath there is text that reads “Perceivable, Operable, Understandable, Robust”
An illustration of a keyboard next to the word “POUR.” Underneath there is text that reads “Perceivable, Operable, Understandable, Robust”
  • Perceivable: Our users need to be able to discern the information. The content on the page can’t be inaccessible to all their senses. For example, if a user can’t hear, the content must also be provided in a way that doesn’t require the ability to hear.

  • Operable: Our UIs can’t be based on specific interactions that not all users can do. For example, a drag-and-drop interface needs an alternative approach that doesn’t require the use of a mouse.

  • Understandable: Both the content and the UI that we present to the user need to be intuitive and easily digestible. For example, an article that includes technical terms should also include a glossary.

  • Robust: Anything that we include in our websites or applications needs to be able to stand up to the multiple ways our users might access it, including via assistive technologies. For example, our layouts should still be usable even when the user has zoomed in significantly.

These basic principles are often abbreviated to POUR. They are the baseline for assessing whether an application or website is accessible and the foundation for the set of guidelines compiled in the WCAG (Web Content Accessibility Guidelines). These guidelines are the standard upon which accessibility is most commonly assessed.