Glossary

Recurring accessibility terms used across this knowledge base, explained for readers who don't work with digital accessibility every day. Terms with an official WCAG 2.2 glossary definition quote it first, with a link to the source, followed by a plain-language explanation. Terms are listed alphabetically.

A

Accessibility tree

The browser's internal representation of a page built for assistive technologies — a parallel to the DOM that contains each element's name, role, and value plus states and properties. Screen readers read the accessibility tree, not the visual page. Semantic HTML and ARIA determine what ends up in it; aria-hidden="true" removes an element from it entirely.

Accessible name

The name of an element as exposed to assistive technologies — what a screen reader speaks when it reaches a button, link, or form field. It comes from the element's content, a label, or ARIA attributes like aria-label, following the browser's name computation rules. Closely related to WCAG's definition of name: "text by which software can identify a component within web content to the user."

Note: the accessible name may differ from what's visible on screen — which is why WCAG requires the visible label to be part of the accessible name (Label in Name).

Alt text (text alternative)

Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content (WCAG 2.2 definition).

In plain terms: a text description of an image or other non-text content that screen readers announce in its place. "Alt text" refers specifically to the alt attribute on images — the most common way to provide a text alternative. Good alt text conveys the image's purpose in context, not just its appearance.

Learn more: Writing effective text alternatives for images

ARIA (WAI-ARIA)

Accessible Rich Internet Applications — a W3C standard that adds attributes to HTML for describing what an element is and what it's doing, so assistive technologies can understand custom interface components. ARIA attributes can set an element's role (e.g., role="tab"), its accessible name (e.g., aria-label), and its state (e.g., aria-expanded).

The first rule of ARIA: don't use ARIA when native semantic HTML can do the job — native elements come with these behaviors built in.

Assistive technology

Hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents (WCAG 2.2 definition).

In plain terms: any tool people with disabilities use to interact with digital content in a way that works for them. Examples include screen readers, screen magnifiers, speech recognition software, alternative keyboards, and switch devices.

B

Braille display

A hardware device that renders text as refreshable braille — a row of pins that raise and lower to form braille characters. Used together with a screen reader, it gives people who are deafblind, or who prefer reading to listening, tactile access to digital content. One reason alt text and accessible names should be concise: they're read one braille line at a time.

C

Captions

Synchronized visual and/or text alternative for both speech and non-speech audio information needed to understand the media content (WCAG 2.2 definition).

In plain terms: on-screen text for video that conveys not just dialogue but also meaningful sounds — music, sound effects, who's speaking. Unlike subtitles (which assume you can hear but not understand the language), captions serve people who are deaf or hard of hearing. Closed captions can be toggled; open captions are burned into the video.

Contrast ratio

(L1 + 0.05) / (L2 + 0.05), where L1 and L2 are the relative luminances of the lighter and darker colors (WCAG 2.2 definition).

In plain terms: a measure of how different two colors are in brightness, from 1:1 (identical) to 21:1 (black on white). WCAG AA requires at least 4.5:1 for normal text, 3:1 for large text and for interface components like button borders and focus indicators. Low contrast affects readability for people with low vision and everyone in poor lighting.

D

Decorative image

Serving only an aesthetic purpose, providing no information, and having no functionality (WCAG 2.2 definition of pure decoration).

In plain terms: an image that adds visual polish but no meaning — a divider flourish, a background texture. Decorative images should be hidden from assistive technologies with an empty alt="", so screen readers skip them instead of announcing noise.

F

Focus indicator

Pixels that are changed to visually indicate when a user interface component is in a focused state (WCAG 2.2 definition).

In plain terms: the visible outline or highlight that shows which element currently has keyboard focus — typically a ring around a button or link. Without it, sighted keyboard users have no way of knowing where they are on the page. Browsers draw a default indicator; a common accessibility failure is removing it with CSS (outline: none) without providing a replacement.

Focus order (tab order)

The sequence in which keyboard focus moves through a page's focusable elements as the user presses Tab. WCAG calls this being navigated sequentially: "navigated in the order defined for advancing focus (from one element to the next) using a keyboard interface."

The focus order should follow the reading order and preserve meaning — if Tab jumps unpredictably around the page, keyboard and screen reader users lose track of where they are. By default the order follows the position of elements in the code (the DOM).

K

Keyboard focus (focusable)

The single element on a page that currently receives keyboard input — press Enter and it's the focused element that responds. An element is focusable if keyboard focus can move to it, typically with the Tab key. All interactive elements (links, buttons, form fields) must be focusable so people who navigate by keyboard — including screen reader users and people who can't use a mouse — can reach and operate them. Where focus currently sits is shown visually by the focus indicator, and the sequence it moves in is the focus order.

Keyboard trap

A part of the page where keyboard focus can get in but can't get out — the user can Tab into a component (such as a modal dialog, embedded widget, or custom control) but no keyboard command moves focus away from it. A mouse user can simply click elsewhere; a keyboard user is stuck. WCAG Success Criterion 2.1.2 (No Keyboard Trap) requires that focus can always be moved away using the keyboard alone.

Note the deliberate exception: a modal dialog should contain focus while open (often called a "focus trap"), but must let the user close it — e.g. with Escape — and return focus to where it was.

L

Label

Text or other component with a text alternative that is presented to a user to identify a component within web content (WCAG 2.2 definition).

In plain terms: the visible text that tells all users what a control is — "Email address" next to an input, "Search" on a button. Distinct from the accessible name, which may be hidden and exposed only to assistive technology; ideally the two match. Not limited to the HTML <label> element.

Landmark

A labeled region of a page — such as the header, navigation, main content, or footer — that assistive technologies use for orientation and quick navigation. Screen reader users can jump directly between landmarks instead of reading through the whole page. Landmarks come from semantic HTML elements (<main>, <nav>, <header>) or ARIA roles (role="main", role="navigation").

Learn more: HTML landmarks

Live region

A page area marked (e.g. with aria-live or role="status") so that screen readers announce changes to its content automatically, even while the user's focus is elsewhere. Used for dynamic updates like form errors, search result counts, or "item added to cart" messages that sighted users notice visually but screen reader users would otherwise miss.

Low vision

Vision impairment that isn't fully corrected by glasses or contacts — including reduced acuity, limited field of view, light sensitivity, and color vision deficiencies. People with low vision may use screen magnification, large text, high-contrast modes, or a screen reader. Far more common than blindness, and the reason behind requirements like contrast ratio, text resizing, and reflow at high zoom.

N

Name, Role, Value

The three pieces of information every interface component must expose to assistive technologies (from WCAG Success Criterion 4.1.2): its name — text by which software can identify the component to the user (WCAG definition); its role — text or a number by which software can identify the function of the component, e.g. button, checkbox, tab (WCAG definition); and its value or state — its current condition, such as checked, expanded, or a slider's setting.

Native HTML elements expose all three automatically; custom components built from <div>s and <span>s must supply them with ARIA. See also accessible name.

Non-text content

Any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language (WCAG 2.2 definition).

In plain terms: images, icons, charts, audio, video — and also character art like emoticons and ASCII art. Non-text content needs a text alternative so its meaning is available to everyone.

P

Programmatically determined

Determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities (WCAG 2.2 definition).

In plain terms: information that's available in the code, not just visible on screen. A heading that's styled big and bold but marked up as plain text looks like a heading, but isn't programmatically determined as one — so a screen reader can't announce it or navigate to it as a heading.

S

Screen reader

Software that reads digital content aloud or renders it as braille, letting people who are blind or have low vision use websites and apps. Screen readers announce text, images (via their alt text), and interactive elements like buttons and links, and provide keyboard or gesture commands for navigating a page. Common screen readers include JAWS, NVDA, and Narrator (Windows), VoiceOver (macOS/iOS), and TalkBack (Android).

Learn more: Practical guides for using screen readers

Semantic HTML

Using HTML elements according to their meaning, not their appearance — <button> for actions, <a> for links, <h1>–<h6> for headings, <nav> for navigation. Semantic elements carry built-in name, role, and value information and keyboard behavior, so assistive technologies understand them without extra work. Generic containers like <div> and <span> carry no meaning, which is why building interactive components from them requires ARIA and scripting to catch up to what native elements provide for free.

Learn more: HTML semantics and accessibility

Skip link

A link — usually the first focusable element on a page — that lets keyboard users jump straight to the main content, bypassing repeated blocks like the header and navigation. Without it, reaching the content means tabbing through every menu item on every page. Often visually hidden until it receives keyboard focus. Satisfies WCAG Success Criterion 2.4.1 (Bypass Blocks).

Success criterion

A single testable requirement in WCAG, numbered by guideline — e.g. Success Criterion 1.4.3 (Contrast Minimum). "Testable" means it can be objectively verified as passed or failed. Each criterion has a conformance level (A, AA, or AAA). WCAG 2.2 contains 86 success criteria; accessibility issues are typically reported against the specific criterion they fail.

Switch device

Assistive technology for people with significant motor disabilities: one or more physical switches — pressed by hand, head, foot, or breath (sip-and-puff) — that step through and activate on-screen options. Switch access depends on the same underpinnings as keyboard access, which is why everything must be operable without a mouse and why a logical focus order matters.

T

Target size

A target is the region of the display that will accept a pointer action, such as the interactive area of a user interface component (WCAG 2.2 definition).

In plain terms: the clickable/tappable area of a control. Small or crowded targets are hard to hit for people with motor disabilities, tremors, or simply large fingers on small screens. WCAG 2.2 AA requires targets to be at least 24×24 CSS pixels or sufficiently spaced (Success Criterion 2.5.8).

U

User agent

Any software that retrieves and presents web content for users (WCAG 2.2 definition).

In plain terms: browsers, media players, and plug-ins — and assistive technologies working alongside them. The term appears throughout WCAG because accessibility is a contract: authors provide correct information in the code, and user agents present it to users in whatever form they need.

V

Viewport

Object in which the user agent presents content (WCAG 2.2 definition).

In plain terms: the window through which the user sees the page — typically the browser window or a frame within it. Relevant to accessibility because content must remain usable when the viewport is small or zoomed: WCAG requires content to reflow without two-dimensional scrolling at 320 CSS pixels width, and pages must not disable pinch-to-zoom.

Voice control (speech recognition)

Assistive technology that lets people operate a device by speaking — e.g. Voice Control (Apple), Voice Access (Android/Windows), or Dragon. Users say what they see: "Click Submit." This is why WCAG requires the visible label to be part of the accessible name — if a button shows "Send" but its accessible name is "Submit form," the spoken command fails. Used by people with motor disabilities and for hands-free situations.

W

WCAG and conformance levels (A, AA, AAA)

The Web Content Accessibility Guidelines — the W3C's international standard for accessible web content, currently at version 2.2. Each requirement (success criterion) is assigned one of three levels: A (minimum), AA (the level most laws and policies require, including the ADA rule and the European Accessibility Act via EN 301 549), and AAA (enhanced). Conforming at a level means meeting all criteria of that level and the levels below it.