Accessibility - What is accessibility?

Accessibility - What is accessibility?



Information drawn from

Accessibility (often abbreviated to A11y — as in “a” then 11 characters then “y”) in Web development means enabling as many people as possible to use Web sites, even when those people’s abilities are limited in some way.

For many people, technology makes things easier. For people with disabilities, technology makes things possible. Accessibility means developing content to be as accessible as possible no matter an individual’s physical and cognitive abilities and no matter how they access the web.

“The Web is fundamentally designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability.” (W3C - Accessibility)

What is accessibility?

This article starts the module off with a good look at what accessibility is — this overview includes what groups of people we need to consider and why, what tools different people use to interact with the web, and how we can make accessibility part of our web development workflow.

So what is accessibility?

Accessibility is the practice of making your websites usable by as many people as possible. We traditionally think of this as being about people with disabilities, but the practice of making sites accessible also benefits other groups such as those using mobile devices, or those with slow network connections.

You might also think of accessibility as treating everyone the same, and giving them equal opportunities, no matter what their ability or circumstances. Just as it is wrong to exclude someone from a physical building because they are in a wheelchair (modern public buildings generally have wheelchair ramps or elevators), it is also not right to exclude someone from a website because they have a visual impairment. We are all different, but we are all human, and therefore have the same human rights.

Accessibility is the right thing to do. Providing accessible sites is part of the law in some countries, which can open up some significant markets that otherwise would not be able to use your services or buy your products.

Building accessible sites benefit everyone:

What kinds of disability are we looking at?

People with disabilities are just as diverse as people without disabilities, and so are their disabilities. The key lesson here is to think beyond your own computer and how you use the web, and start learning about how others use it — you are not your users. The main types of disability to consider are explained below, along with any special tools they use to access web content (known as assistive technologies, or ATs).

Note: The World Health Organization’s Disability and health fact sheet states that “Over a billion people, about 15% of the world’s population, have some form of disability”, and “Between 110 million and 190 million adults have significant difficulties in functioning.”

People with visual impairments

People with visual impairments include people with blindness, low-level vision, and color blindness. Many people with visual impairments use screen magnifiers that are either physical magnifiers or software zoom capabilities. Most browsers and operating systems these days have zoom capabilities. Some users will rely on screen readers, which is software that reads digital text aloud. Some screen reader examples include:

It is a good idea to familiarize yourself with screen readers; you should also set up a screen reader and have a play around with it, to get an idea of how it works. See our cross-browser testing screen readers guide for more details on using them. The below video also provides a brief example of what the experience is like. Video

In terms of statistics, the World Health Organization estimates that “285 million people are estimated to be visually impaired worldwide: 39 million are blind and 246 million have low vision.” (see Visual impairment and blindness). That’s a large and significant population of users to just miss out on because your site isn’t coded properly — almost the same size as the population of the United States of America.

People with hearing impairments

Deaf and hard-of-hearing (DHH) people have various levels of hearing loss ranging from mild to profound. Although some do use AT (see Assistive Devices for People with Hearing, Voice, Speech, or Language Disorders), they are not widespread.

To provide access, textual alternatives must be provided. Videos should be manually captioned, and transcripts should be provided for audio content. Furthermore, due to high levels of language deprivation in DHH populations, text simplification should be considered.

Deaf and hard-of-hearing people also represent a significant userbase — “466 million people worldwide have disabling hearing loss”, says the World Health Organization’s Deafness and hearing loss fact sheet.

People with mobility impairments

These people have disabilities concerning movement, which might involve purely physical issues (such as loss of limb or paralysis), or neurological/genetic disorders that lead to weakness or loss of control in limbs. Some people might have difficulty making the exact hand movements required to use a mouse, while others might be more severely affected, perhaps being significantly paralyzed to the point where they need to use a head pointer to interact with computers.

This kind of disability can also be a result of old age, rather than any specific trauma or condition, and it could also result from hardware limitations — some users might not have a mouse.

The way this usually affects web development work is the requirement that controls be accessible by the keyboard — we’ll discuss keyboard accessibility in later articles in the module, but it is a good idea to try out some websites using just the keyboard to see how you get on. Can you use the Tab key to move between the different controls of a web form, for example? You can find more details about keyboard controls in our Cross browser testing Using native keyboard accessibility section.

In terms of statistics, a significant number of people have mobility impairments. The US Centers for Disease Control and Prevention Disability and Functioning (Non-institutionalized Adults 18 Years and Over) reports the USA “Percent of adults with any physical functioning difficulty: 16.1%”.

People with cognitive impairments

Cognitive impairment refers to a broad range of disabilities, from people with intellectual disabilities who have the most-limited capabilities, to all of us as we age and have difficulty thinking and remembering. The range includes people with mental illnesses, such as depression and schizophrenia. It also includes people with learning disabilities, such as dyslexia and attention deficit hyperactivity disorder. Importantly, though there is a lot of diversity within clinical definitions of cognitive impairments, people with them experience a common set of functional problems. These include difficulty with understanding content, remembering how to complete tasks, and confusion caused by inconsistent webpage layouts.

A good foundation of accessibility for people with cognitive impairments includes:

Notes

Implementing accessibility into your project

A common accessibility myth is that accessibility is an expensive “added extra” to implement on a project. This myth actually can be true if either:

If however, you consider accessibility from the start of a project, the cost of making most content accessible should be fairly minimal.

When planning your project, factor accessibility testing into your testing regime, just like testing for any other important target audience segment (e.g., target desktop or mobile browsers). Test early and often, ideally running automated tests to pick up on programmatically detectable missing features (such as missing image alternative text or bad link text — see Element relationships and context) and doing some testing with disabled user groups to see how well more complex site features work for them. For example:

You can and should keep a note of potential problem areas in your content that will need work to make it accessible, make sure it is tested thoroughly, and think about solutions/alternatives. Text content (as you’ll see in the next article) is easy, but what about your multimedia content, and your whizzy 3D graphics? You should look at your project budget and think about what solutions you have available to make such content accessible. Having all your multimedia content transcribed is one option which, while expensive, is possible.

Also, be realistic.“100% accessibility” is an unobtainable ideal — you will always come across some kind of edge case that results in a certain user finding certain content difficult to use — but you should do as much as you can. If you are planning to include a whizzy 3D pie chart graphic made using WebGL, you might want to include a data table as an accessible alternative representation of the data. Or, you might want to just include the table and get rid of the 3D pie chart — the table is accessible by everyone, quicker to code, less CPU-intensive, and easier to maintain.

On the other hand, if you are working on a gallery website showing interesting 3D art, it would be unreasonable to expect every piece of art to be perfectly accessible to visually impaired people, given that it is an entirely visual medium.

To show that you care and have thought about accessibility, publish an accessibility statement on your site that details what your policy is toward accessibility, and what steps you have taken toward making the site accessible. If someone does notify you that your site has an accessibility problem, start a dialog with them, be empathetic, and take reasonable steps to try to fix the problem.

Note: Our Handling common accessibility problems article covers accessibility specifics that should be tested in more detail.

To summarize:

Accessibility guidelines and the law

There are numerous checklists and sets of guidelines available for basing accessibility tests on, which might seem overwhelming at first glance. Our advice is to familiarize yourself with the basic areas in which you need to take care, as well as understanding the high-level structures of the guidelines that are most relevant to you.

So while the WCAG is a set of guidelines, your country will probably have laws governing web accessibility, or at least the accessibility of services available to the public (which could include websites, television, physical spaces, etc.) It is a good idea to find out what your laws are. If you make no effort to check that your content is accessible, you could be legally liable if people complain.

This sounds serious, but really you just need to consider accessibility as the main priority of your web development practices, as outlined above. If in doubt, get advice from a qualified lawyer. We’re not going to offer any more advice than this, because we’re not lawyers.

Accessibility APIs

Web browsers make use of special accessibility APIs (provided by the underlying operating system) that expose information useful for assistive technologies (ATs) — ATs mostly tend to make use of semantic information, so this information doesn’t include things like styling information, or JavaScript. This information is structured in a tree of information called the accessibility tree.

Different operating systems have different accessibility APIs available :

Where the native semantic information provided by the HTML elements in your web apps falls down, you can supplement it with features from the WAI-ARIA specification, which add semantic information to the accessibility tree to improve accessibility. You can learn a lot more about WAI-ARIA in our WAI-ARIA basics article.

Summary

This article should have given you a useful high-level overview of accessibility, shown you why it’s important, and looked at how you can fit it into your workflow. You should now also have a thirst to learn about the implementation details that can make sites accessible, and we’ll start on that in the next section, looking at why HTML is a good basis for accessibility.

------------------------------------------------------------------------

Last update on 26 Jan 2022

---