A glossary of web accessibility terms
Web accessibility has lots of specific terms, abbreviations and other jargon. This glossary clarifies some of them, and more. Further resources are added where available.
This page is very much a "living document"; it's intended to be updated and improved constantly. Your questions and contributions are much appreciated!
As it's due to change, bookmarking is probably more valuable than printing. You could also save some trees that way.
Table of Contents
- Accessible name
- Accessibility tree
- Assistive technology
- Keyboard testing
- Programmatically determined
- Screen reader
- Skip link
- Tab Stop
- Visually hidden
The accessible name of an element is the label by which it can be referred. It An accessible name is the name of a user interface element; it is the text associated with an HTML element that provides users of assistive technology with a label for the element.
Web browsers transform markup into an internal structure known as the DOM tree. This tree contains objects that represent all the elements, attributes, and text nodes present in the markup. To make the content accessible to assistive technologies like screen readers, browsers generate an accessibility tree based on the DOM tree. This second tree is based on the DOM tree and is specifically designed to be understood by assistive technologies.
The accessibility tree helps assistive technologies work smoothly with the webpage, making it easier for people with disabilities to access and interact with the content.
ARIA (Accessible Rich Internet Applications) is a specification by W3C. Its purpose is to enhance HTML by incorporating semantics and additional metadata, making web content more accessible.
An umbrella term for technologies that support people (with disabilities). The term is broad and hard to scope. Examples include glasses, wheelchairs, walkers, crutches, prosthetic limbs, screen readers, braille displays, magnification software, custom keyboards and many more.
Not everybody uses a mouse, so you shouldn’t test with just a mouse. The most universal device to test with is a keyboard. A lot of people either use a keyboard, or use something that interacts with your creation like a keyboard.
Something is programmatically determinable when it is communicated in code. For example, a state is not just communicated visually with an icon or color, but also as an HTML5- or ARIA-attribute.
Software that reads the screen (hence the name) and communicates it to the user (usually in speech but can be braille as well). It also enables the user to use a device without seeing its screen. Screen readers depend on non-visual information.
When using the tab-key on the keyboard to navigate, every spot you reach (usually every interactive element) is a tab stop.
Got feedback? I bet you'd appreciate a group of accessibility experts. Share insights and grow together.Join Discord!