Tired of the same trivial accessibility discourse?
» Time for some authentic conversations! «

Use the arrow keys to navigate between menu items.

Glossary

Have you read the WCAG and still are just as clueless and frustrated because you don't understand what they're talking about?

Accessibility can be tricky if you don't know what some of the words mean. I hope the following glossary will help beginner and experienced accessibility practitioners better understand some of the confusing terms you may have come across, either in the Web Content Accessibility Guidelines(Opens external link) or elsewhere online.

This is a living document and I'm trying to add more definitions as I come across obscure abstract explanations for them.


A11y

A11y is numeronym for accessibility. The word "accessibility" begins with the letter a, followed by 11 letters and ends with the letter y. We pronounce it as ally, meaning, in the context of accessibility, "a person who is not a member of a marginalized or mistreated group but who expresses or gives support to that group." A11y becomes a shorthand for "accessibility" and for us who care about building a web for all.

ARIA

Accessible Rich Internet Applications, ARIA for short, is a specification that defines a set of attributes you can add to HTML elements. ARIA attributes will help assistive technologies understand these elements and relay that information to users. Developers should use ARIA attributes only when the browser does not already support a HTML tag that already does the same thing.

Ableism

Ableism refers to bias, prejudice, and discrimination against people with disabilities. It looks at people with a disability as not normal, and their disability as something that needs to be "cured." We can see this negative view of disability through every day language, inaccessible design and direct or indirect discrimination.

Direct discrimination happens when we treat a person with a disability less favourably than one without a disability would be treated under the same circumstances. Indirect discrimination occurs when we impose the same requirements for everyone, but this unfairly excludes persons with disabilities.

Accessibility

Accessibility is the ability of a product, website or service to be usable by everyone, regardless of their abilities. Although we mostly think of people with disabilities when we talk about accessibility, building an accessible product means giving all your customers, regardless of their ability, equal access to it.

Accessibility Conformance Report (ACR)

The Accessibility Conformance Report, or ACR, is a document that formally describes how an information and communications technology (ICT) product or service conforms to an agreed set of accessibility guidelines and standards. Typically, an ACR will summarise a product's conformance to Section 508 of the US Rehabilitation Act of 1973, the Web Content Accessibility Guidelines (WCAG), or ETSI EN 301 549. ACRs are not mandatory, but are commonly used as part of the procurement or tendering process. An ACR clearly says which accessibility standards a product or service meets.

Accessibility Conformance Testing (ACT)

Commonly referred to as an audit, an ACT is a series of tests to determine the accessibility compliance of a digital product. The tests should be integrated into the software development lifecycle as a way to continuously check against a set of accessibility guidelines. One of the deliverables of an ACT is the Accessibility Conformance Report (ACR). ACT typically consists of both automated and manual tests.

Accessibility audit

An accessibility audit is the process of evaluating a digital product or service to determine the extent to which it conforms to an accessibility standard. The audit will identify any violations and summarise the level of compliance. Since major legislation world wide is usually based on the Web Content Accessibility Guidelines (WCAG), we usually perform accessibility audits and test against the latest version of those guidelines.

The audit can be performed at any point during the project, as early as planning, but should be repeated throughout the software development lifecycle, i.e. during design, development, and testing.

Accessibility statement

An Accessibility statement is a page summarising the accessibility of the product or service, together with information on what to do if you encounter difficulties in using it. It's not meant to be as formal or as complete as an Accessibility Conformance Report (ACR), but rather its purpose is to show your users, in plain language, that you care about them and demonstrate commitment to social responsibility.

The Accessibility statement should contain information like which accessibility standard you applied, contact information in case users encounter difficulties or any known limitations and how users can work around them. Most statements will also include any technical prerequisites (such as supported browsers and devices) and details for the environments used to test the content.

Accessibility tree

The accessibility tree is what most assistive technologies interact with when interpreting a web page. Assistive technologies rely on it to relay the correct information about the page content to the user. The accessibility tree is not something we can see, but it is something we implicitly affect whenever we write HTML markup.

Accessible design vs Usable design

Usable design creates products that are easy to use. We usually rely on usability tests to accomplish this. The problem is that usability tests don't always include people with disabilities. So the design might be usable, but still create barriers for people with certain disabilities. This is where accessible design comes in, by putting the design through a process in which we specifically consider the needs of the people with disabilities.

It's only by using both design processes, in the right balance, that we can create a design usable by all people, regardless of their abilities.

Accessible name

An HTML element's accessible name is information that assistive technologies use to properly identify that element for the user. The name is derived from several different attributes for that element, including the element’s content, an attribute, from an associated element, or through ARIA properties. It's our job to choose accessible names that don't confuse users who rely on assistive technologies.

Affordances

An affordance is what someone can do with an object based on their abilities. For example, a door affords opening if you can operate the handle. In the context of accessibility, affordances are what users can do to interact with a digital product or service. For example, a page affords navigation if the user can find and click on the links.

With the right affordances, a user knows exactly what to do with an element on the page without needing special instructions. For example, a button that looks like a button, has the label "Add to cart" and will add the product to the cart when clicked, is a good example of an affordance.

Specifically in the context of accessibility, it's our job to carefully design experiences that don't create barriers that users can't operate with their technology, for example users relying on assistive technology or people navigating with a keyboard.

Americans with Disabilities Act (ADA)

The Americans with Disabilities Act, commonly know as ADA, is a piece of legislation in the United States that protects people with disabilities in many areas of public life from discrimination. The law guarantees people with disabilities the same opportunities as everyone else when it comes to employment opportunities, buying goods and services, and participating in state and local government programs.

Although the law initially applied to physical accessibility (e.g. parking spaces and building access), courts have agreed that the law applies to websites as well.

Assistive technology (AT)

Assistive technology (or AT) is hardware and software that helps people with disabilities perform tasks that would otherwise be difficult or even impossible. Common examples include listening to a screen reader go through the contents of a web page, using a refreshable braille keyboard to view the content of a document, enlarging the size of text on a web page using a screen magnifier or using voice commands to navigate a web site.

Automated accessibility testing

Automated accessibility testing uses software to scan digital products for known accessibility issues. The software will use a predefined set of accessibility standards and go through a checklist looking for errors. Automated tests are easy to set up and repeat as many times as needed at any stage of the software development lifecycle. Because of the ease of getting started, there's no reason not to do it. But, it's important to note that automated tools don't catch all the accessibility errors. Both automated and manual testing are critical to achieving the most accessible product possible.

Braille

Braille is a code that conveys language to people who are blind or have low vision. It's a system of raised dots in specific configurations that translate visuals to tactile, giving meaning to letters and numbers.

To translate digital text on a website to braille, people who are blind use a refreshable braille display in combination with a screen reader. The screen reader will send the text to the braille display and the display will lower and raise round-tipped pins through holes in a flat surface in specific combinations as to create the correct text. A refreshable braille display is the only way a person who is deafblind can consume content on your website.

Color blindness

This disability impairs a person's ability to distinguish between certain colors. The most common form of color blindness is red-green color blindness, where people seem green more like red (deuteranomaly), red more like green (protanomaly) or red the same as green (protanopia). Another form of color blindness is blue-yellow, where people experience blue and green more like yellow and red (tritanomaly) and blue and green more like purple and red or yellow and pink (tritanopia). People who cannot see colors at all, meaning they see everything in gray, suffer from achromatopsia or monochromacy. They see everything in shades of black, white and gray.

This is why it's important to not rely on color as the only means to convey information.

Conformance Levels

The Web Content Accessibility Guidelines (WCAG) 2.1 contain 78 success criteria, split into three conformance levels: A, AA and AAA. To be compliant, you need to meet one of these three WCAG levels. To meet a level, you must pass all the success criteria of that level and the levels below it.

  • Level A contains 30 success criteria and is the minimum you need to meet to have an accessible website.
  • Level AA contains 20 success criteria, plus the 30 from Level A.
  • Level AAA contains 28 success criteria, plus the 20 from Level AA and the 30 from Level A.

Most legislation worldwide must meet WCAG Level AA.

Deaf or hard of hearing

6.1% or approximately 466 million people are deaf or hard of hearing (HoH). People who are deaf suffer total or near-total hearing loss and many know sign language and are more comfortable communicating like that. People who are hard of hearing use hearing aids.

Approxiamtely 5% of the population suffers from Central Auditory Procession Disorder (CAPD). They have difficulty hearing and understanding speech although no measurable hearing loss exists. The inability refers to not being able to interpret, organise and analyse what they hear. People that suffer from CAPD have problems locating the source of the sound, especially in loud environments.

You should confuse deaf with Deaf. While deaf refers to the disability, Deaf (capital letter) refers to an association with the community.

If your website has audio content, per-recorded video with audio or live media, consider adding captions and transcripts or sign language to help people who are deaf or hard of hearing understand the content.

Disabilities

Not everyone can see, hear, move or process information easily if at all. They may have sensory, physical, or cognitive impairments that limit their ability to perform one or more activities.

253 million people are visually impaired, due to disease, trauma or degenerative conditions, 1 in 7 people suffer from a mobility issue, over 1.5 billion people have some sort of hearing loss, while over 70 million people suffer from epilepsy, vestibular disorders or have a speech impediment.

We generally refer to them as people with disabilities. While some people are born with a disability, others may have acquired one due to an event like a sports injury, onset health condition or even old age. Some disabilities can be temporary (e.g. broken arm and cannot use a mouse) or even situational (e.g. in a crowded subway and cannot hear the conversation in a video).

According to the Social Model, a disability is something we experience, a disadvantage caused by society. Contrast that to an impairment, which is a description of the physical body.

EN 301 549

EN 301 549 is the European standard for digital accessibility. Its contents specify which requirements an information and communication technology (ICT) product or service needs to meet to be considered accessible for people with disabilities. Its goal is to set requirements for public procurement of products and services in the European Union.

EN 301 549 references the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. The standard includes web and mobile applications, and includes other technologies beside those covered by WCAG2.1.

Economic model

A disability is the person's inability to participate in work. This model looks at the economic consequences for the individual, the employer and the economy as a whole. The model recognises the need for economic support, but at the same time creates a legal threshold to be considered disabled.

Focus

Focus, in the context of the web, refers to which control on the screen currently receives input from the keyboard. For example, if you focus a text input field and start typing, what you type shows up in the text field on the page, as you type. We say the input field receives keyboard focus, or is focused. In the context of accessibility, focus (and focus management) is one of the Level A success criteria. Since many people use a keyboard or assistive technology that mimics the functionality of a keyboard to navigate and interact with a web page, proper keyboard and focus support is critical.

The elements on a page that a user can interact with using a keyboard are called focusable elements, or we say they "receive focus." The order in which they receive focus is called focus order, or tab order. Focus order must be logical and match the visual order of the page. Usually, the currently focused element is visually highlighted on the page.

Interactive HTML elements like form controls, buttons or select lists are implicitly focusable and have built-in keyboard event handling. Developers like to create custom elements and, in this case, it's important that they give proper consideration to keyboard navigation and focus.

Haptic feedback

Haptic technology uses vibration to simulate the sense of touch and deliver tactile experiences to digital products. People who are blind or have low vision cannot see or have difficulty interacting with digital products. Interactive systems, like touch screens or dashboards, use haptic feedback to simulate the experience of a mouse click or pressing buttons and this provides people with reassurance in their interactions.

Inclusive design

Inclusive design is a methodology where designers consider the needs of people with a wide range of perspectives when creating digital products and services. This includes designing to account for all levels of human ability, when it comes to eyesight, hearing, mobility and cognitive functions, as well as the environment where our products might be used.

Accessibility and inclusive design go hand in hand. The end goal of the process is to create digital experiences where people feel like they belong, regardless of their disabilities.

Information and Communication Technology (ICT)

We use ICT generally to mean all devices, networking components, applications and systems used by people to interact digitally. There's no formal universal definition of ICT and we sometimes used it interchangeably with IT. And rightly so; ICT includes computers, smartphones, robots, smart TVs, cloud computing, software as well as hardware, together with the data that moves between all these devices.

Landmarks

Assistive technologies (AT) rely on the structural elements of a web page to provide information about its structure. Landmarks divide the page into navigable regions that add structural context to a web page. For visual users, landmarks will not have any meaningful effect. But for AT users, developers can dramatically improve the navigation experience by using landmarks.

Examples of landmarks include header, footer and the nav element.

Low vision

3.5% of the population (approximately 246 million people) suffer from low vision. This means they don't have enough vision to do what they need to do and that depends from person to person. This disability cannot be corrected with medical procedures and equipment, so they need assistive technology like screen magnification to be able to use the web.

Manual accessibility testing

We call it manual testing because we manually go through a web page with a keyboard or other assistive technologies. Through a combination of visual, cognitive tests and techniques, we can find issues that automated tooling cannot. These tests are more complex and time consuming to run, making them more expensive to put in place.

Each product will differ in what type of manual accessibility tests we need to put it through. All digital products will need testing keyboard functionality and reviewing both the visuals and the content of a web page. Testing with assistive technologies (AT) is part of manual testing.

Only when we combine automated with manual accessibility tests can we create the most accessible product possible.

Medical and Social models of disability

The Medical Model views disability as a defect within the individual. Disability is something abnormal and people with disabilities need to be "cured" or "fixed." It's the responsibilities of doctors to diagnose and fix people with disabilities by focusing on cures and treatments to get rid of any bodily impairments. People have disabilities and therefore cannot fully participate in society due to their impairments.

In the Social Model, disabilities are restrictions imposed by society. Disability is an aspect of a person’s identity, much like race or gender. The solution lies not in fixing the person, but in changing our society. And all of us, rather than just doctors, are responsible for removing the barriers to environmental change and inclusion. In this model, it's the environment that creates the barriers for participating in society, not the disability.

POUR

POUR is an acronym for Perceivable, Operable, Understandable, and Robust. These are the four foundational principles of WCAG.

  • Perceivable means the information and user interface must be presented in such a way that users perceive them - it can't be invisible to all of their senses.
  • Operable means that users must be able to operate the user interface components, regardless of how they choose to interact with the interface.
  • Understandable means that the information must be presented in such a way that users understand it and how to interact with it.
  • Robust means that your content must be presented in such a way that it is reliably interpreted by a wide variety of devices (called user agents), including assistive technologies.

Screen magnifiers

A screen magnifier is a software application that allows people to zoom in their screen or a part of it. It looks like you would put a magnifying glass on top of your screen and saw everything through that lens.

Screen readers

A screen reader is software that uses computer language to read and navigate web pages. People with visual impairments or other cognitive disabilities, such as dyslexia, rely on a screen reader to read text aloud and understand the structure of a web page.

Imagine you had a friend to read everything they see on the screen for you in a robot voice and you could customise the reading speed; that's a screen reader.

Section 508

Section 508 of the Rehabilitation Act is one of several disability laws in the United States. It requires that any Information and Communication Technology (ICT) the United States Federal government "develops, procures, maintains, or uses" meet its standards. It essentially means that ICT is accessible to people with disabilities - regardless of whether or not they work for the federal government.

The Revised 508 Standards incorporate by reference the Web Content Accessibility Guidelines (WCAG) 2.0.

Semantic HTML

Semantics refers to the meaning of an HTML element and can be deducted by asking yourself, "what purpose does this element serve?" For example, what does an h1 do on a page? It's a top level heading of that page, which functions as a page title carefully describing what the page is about, similar to a chapter title in a book. As you can see, there is nothing related to how the element looks, since you can make any element look like a top level heading, but without assigning any semantic value to it.

Most assistive technology will rely on an element's semantics in relation to all the other elements on the page in order to give meaning to the content in a way that's useful to the user. For example, screen readers will rely on semantics to help visually impaired users navigate the page. This means that function trumps looks and we must write our HTML to represent the content in a meaningful way, and not based on its presentation. How it looks, the presentation, is the responsibility of CSS.

Examples of HTML semantics include:

  • Headings form a succinct outline of the overall page content. You have six headings ranging from h1 to h6 and the sequence is important.
  • Lists semantically group items similar to one other giving them inherent meaning. You have three types to choose from: ul, ol and dl.
  • Tables are for layout (presentational) or to organise data.

Shift left

The principle of shifting left is an IT concept that means performing certain tasks earlier in the software development lifecycle (SDLC) in order to minimise the number of errors that will later cause rework and add extra costs that could have been avoided. In the context of accessibility, shifting left means considering accessibility from the very early stages of a product. By keeping people with disabilities in mind, including accessibility requirements in the planning stage and setting up accessibility testing as early as possible, we're shifting left.

Shifting left is a cost-effective way to ensure that we catch accessibility defects as early as possible. While shifting all the way to the left may be an impossibility in reality, every tiny bit of nudge to the left means a huge step forward.

Skip links

Skip links are anchor links that allow a keyboard user to jump to a different section of the same page. Skip links allow them to bypass sections of a website that repeat on many pages, such as the navigation, heading graphics or ad images. They are an affordance for users, who rely on assistive technologies to find their way around the page.

Having a mechanism to bypass blocks of content repeated on many web pages is also one of the Level A success criteria.

Software development lifecycle (SDLC)

The software development lifecycle (SDLC) explains the different stages of software development, from planning, building, deployment, and maintenance of software. Strategies can differ from organisation to organisation, depending on their individual requirements. Generally speaking, the SDLC will cover at least a planning stage where we gather requirements, a design stage, followed by implementation, testing, deployment and maintenance.

SDLC is mentioned in the context of accessibility when we discuss ways to shift left, meaning introducing accessibility as early as possible in the stages of SDLC.

Success criteria

The Web Content Accessibility Guidelines (WCAG) lists a number of success criteria that your product needs to meet to be accessible. Success criteria are broad statements that should help you understand what users need to be able to do when interacting with your product. They don't contain technical requirements or strict rules by themselves. They are guidelines, after all!

For example, Success Criterion 1.3.4 Orientation, says "Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential." This means, no matter how the user is holding their phone, make sure your content is still readable. Notice how this says nothing about how you should implement this.

Tabindex

Tabindex is global attribute for HTML elements that allows developers to control focus on the page either by making elements focusable, prevent an otherwise focusable element from receiving focus and even determining the focus order on a page. Positive tabindex values will make HTML elements receive focus, while negative values will remove them from the focus order. But, simply adding a tabindex=0 to an element isn't enough to make it focusable; extra work is required to make them fully keyboard accessible. Generally, developers should refrain from using positive tabindexes, giving focus to non-interactive elements or disrupting the normal focus order on the page.

The Capability Maturity Model for Software

The model was initially an IT process improvement model for software development, but it has been recently adapted to ICT accessibility. The model consists of four maturity levels:

  1. Initial, when an organisation responds to specific accessibility complaints, without an established accessibility policy or dedicated resources.
  2. Repeatable, when an organisation has plans for accessibility, but it hasn't yet taken any action to implement them.
  3. Defined, when an organisation consistently integrates accessibility throughout the software development lifecycle with a dedicated accessibility team.
  4. Managed, when an organisation has had experience of implementing accessibility for a few years.
  5. Optimising, when an organisation has accessibility at the heart, is part of its culture and is continuously innovating and sharing their experience with the industry.

Universal design

The design of an environment or product so that it can be used to the greatest extent by all people is universal design. It's not a special requirement for the benefit of a minority, it's a fundamental condition of good design.

Universal design has seven principles:

  • Equitable use. Design should be useful and marketable to people with diverse abilities.
  • Flexibility in use. Design should accommodate a wide range of individual preferences and abilities.
  • Simple and intuitive use. Design should be easy to understand, regardless of a user's experience, knowledge and language skills.
  • Perceptible information. Design should communicate information effectively to the user regardless of ambient conditions or their sensory abilities.
  • Tolerance for error. Design should minimise hazards and adverse consequences of accidental actions.
  • Low physical effort. Design should be used effectively and comfortably with minimal fatigue.
  • Size and shape for approach and use. Design should be appropriate for use regardless of the user's body size, shape and posture.

Voluntary Product Accessibility Template (VPAT)

The Voluntary Product Accessibility Template, or VPAT for short, is a template of an accessibility conformance report (ACR), designed specifically to document how information and communication technology (ICT) products conform to the Revised 508 Standards for IT accessibility. Just like an ACR, it is a report of the state of a product from an accessibility conformance perspective, and, just like an ACR, it helps government buyers assess ICT for accessibility when doing market research and evaluating proposals.

Web Accessibility Initiative (WAI)

The Web Accessibility Initiative (WAI) is a sub-group of the W3C that focuses on digital accessibility. WAI pursues accessibility on the web by developing guidelines, creating evaluation tools and conducting education and outreach. Within WAI, there are several working groups and interest groups, working on guidelines, technical reports and educational materials in an effort to improve web accessibility.

Web Content Accessibility Guidelines (WCAG)

The Web Content Accessibility Guidelines, or WCAG for short, is an internationally recognised set of accessibility standards developed through the World Wide Web Consortium (W3C) in cooperation with individuals and organizations. Its goal is to provide a shared standard for digital accessibility that makes web content more accessible to people with disabilities. It includes the four design principles (POUR), guidance on what should be considered by designers and developers to make a website accessible, as well as specific technical requirements to ensure that a website is compliant with the standard.

It is considered the "gold standard" for accessibility conformance testing and it is this standard that major legislation worldwide is based upon, including Section 508 of the US Rehabilitation Act of 1973 and the European Telecommunications Standards Institute (ETSI) EN 301 549.

World Wide Web Consortium (W3C)

The World Wide Web Consortium, commonly W3C, is an international community that develops protocols, guidelines and open standards that ensure the long-term growth of the Web (think standards like HTML, CSS, and many more). It was founded by Tim Berners-Lee (you might have heard of him). Their vision is a web for all available on all devices, and one of their initiatives is making the web accessible. One of their specifications is Accessible Rich Internet Applications (ARIA) and the Web Content Accessibility Guidelines (WCAG).

If you have any questions, changes or additions, email me at bogdan@bogdanlazar.com.