Accessibility Glossary
A plain-language Accessibility Field Guide glossary for common terms teams encounter during requirements, design, development, QA, and review.
Accessibility language can get technical fast.
That can make normal project conversations harder than they need to be.
This glossary gives plain-language definitions for terms that show up across the Accessibility Field Guide.
The goal is not to replace WCAG, ARIA documentation, formal training, or specialist review.
The goal is to help people understand the words well enough to ask better questions during real work.
Use this as a field reference when a guide, checklist, issue, vendor response, or review finding uses a term that is easy to nod along with but harder to explain.
How to use this glossary
Start with the term that is blocking the conversation.
Then ask three practical questions:
- What does this term mean in plain language?
- Where would someone notice it in the screen, workflow, document, or component?
- Which Field Guide page can help the team check the issue more concretely?
You do not need to memorize the list.
A glossary is useful when it makes the next conversation clearer.
Accessible name
An accessible name is the name assistive technology uses for a control, image, landmark, or other interface object.
For a button, link, input, or tab, the accessible name often comes from visible text, a label, alternative text, aria-label, or aria-labelledby.
Why it matters: if the accessible name is missing, vague, or different from the visible label, people may not know what the control does or how to activate it.
Where to go next: Accessible Names.
Alternative text
Alternative text gives the useful meaning or purpose of an image when someone cannot see the image or when the image does not load.
Good alt text depends on context.
The same image may need different text depending on whether it is decoration, evidence, instruction, chart content, or a link.
Why it matters: people need the information the image provides, not a pixel-by-pixel description.
Where to go next: Alt Text Basics.
ARIA
ARIA is a set of attributes that can add accessibility information when native HTML does not provide enough on its own.
ARIA can describe roles, states, relationships, and live updates.
It cannot make a broken interaction work by itself.
Why it matters: ARIA should describe behavior that already exists. It should not cover for missing keyboard support, unclear labels, poor focus movement, or incorrect HTML.
Where to go next: ARIA Is Not Duct Tape.
Assistive technology
Assistive technology is software or hardware people use to access digital content.
Examples include screen readers, screen magnifiers, voice control, switch devices, braille displays, alternative keyboards, and other input or output tools.
Why it matters: accessibility decisions affect real tools people use to read, navigate, understand, and complete tasks.
Where to go next: How to Use This Guide.
Button
A button performs an action on the current page or in the current interface.
Examples include submit, save, cancel, open, close, clear, expand, collapse, and show more.
Why it matters: if something performs an action but is coded or described like a link, people may get the wrong expectation or lose keyboard behavior.
Where to go next: Button vs Link.
Color contrast
Color contrast is the difference in lightness between foreground and background colors.
For text and meaningful interface parts, enough contrast makes content easier to read and recognize.
Why it matters: low contrast can make content hard or impossible to read, especially for people with low vision, color vision differences, glare, fatigue, or small screens.
Where to go next: Color Contrast.
Color-only meaning
Color-only meaning happens when color is the only cue that communicates status, category, error, success, selection, or instruction.
Why it matters: people may miss the meaning if they cannot perceive the color difference, if the display changes the colors, or if the context is unclear.
Where to go next: Color-Only Meaning.
Component
A component is a reusable piece of interface, such as a button, form field, accordion, modal, tab set, combobox, alert, card, or table pattern.
Why it matters: when a component has an accessibility problem, the problem can spread anywhere the component is reused.
Where to go next: Developer Component Checklist.
Error identification
Error identification is the practice of clearly showing what went wrong and where the user needs to fix it.
Why it matters: a form should help someone recover from a problem instead of making them hunt for the field, guess the rule, or start over.
Where to go next: Error Messages and Recovery.
Focus
Focus is the current place on the page that receives keyboard input.
If a person presses Tab, Enter, Space, or an arrow key, the focused item is usually the thing that responds.
Why it matters: keyboard users need to know where they are before they can decide what to do next.
Where to go next: Focus Visible and Focus Order.
Focus order
Focus order is the path keyboard focus follows through a page, form, workflow, or component.
Why it matters: if focus moves in a confusing order, skips important content, enters hidden content, or jumps unexpectedly, the interface may be technically reachable but hard to use.
Where to go next: Focus Visible and Focus Order.
Heading
A heading names a section of content.
Good headings help people understand what the page contains and jump to the part they need.
Why it matters: headings are not just visual styling. They also create structure that many readers and assistive technologies use for navigation.
Where to go next: Headings and Page Structure.
Keyboard access
Keyboard access means someone can reach, understand, and operate the interface without a mouse.
Why it matters: keyboard access supports people who use keyboards, switch devices, voice tools, screen readers, or other non-mouse input methods.
Where to go next: Keyboard-Only Navigation.
Keyboard trap
A keyboard trap is a place where focus gets stuck and the user cannot move away using normal keyboard controls.
Why it matters: a trap can block someone from closing a dialog, leaving a component, continuing a form, or using the rest of the page.
Where to go next: Keyboard-Only Navigation.
Label
A label tells someone what a form field, control, option, or section is for.
A visible label helps sighted users. A programmatic label helps assistive technology communicate the same purpose.
Why it matters: placeholder text, nearby visual text, or layout alone may not create a reliable label.
Where to go next: Forms and Labels.
Landmark
A landmark is a named page region, such as navigation, main content, search, or footer.
Why it matters: landmarks help assistive technology users understand the major parts of a page and jump around faster.
Where to go next: Headings and Page Structure.
Link
A link takes the user somewhere else.
That may be another page, another place on the same page, a file, an email address, or another destination.
Why it matters: links and buttons create different expectations. If the user is navigating, use a link. If the user is performing an action, use a button.
Where to go next: Button vs Link.
Name, role, and value
Name, role, and value are three pieces of information assistive technology needs about many interface objects.
The name tells what it is called. The role tells what kind of thing it is. The value or state tells what is currently true about it.
Why it matters: custom components often fail when the visual design, keyboard behavior, and exposed accessibility information do not match.
Where to go next: Name, Role, and Value.
Programmatic relationship
A programmatic relationship is a relationship available in code, not just visible on screen.
Examples include a label connected to an input, an error message connected to a field, a tab connected to its panel, or a table header connected to its data cells.
Why it matters: if the relationship only exists visually, assistive technology may not communicate it.
Where to go next: Forms and Labels or Tabs.
Semantic HTML
Semantic HTML means using HTML elements for their meaning, not just their appearance.
Examples include headings for headings, buttons for actions, links for navigation, lists for lists, and tables for data relationships.
Why it matters: native elements give browsers and assistive technology useful information and behavior without extra workarounds.
Where to go next: Native HTML First.
Screen reader
A screen reader is software that reads digital content and interface information aloud or sends it to a braille display.
Why it matters: screen readers depend on good structure, labels, names, roles, relationships, state changes, and meaningful text alternatives.
Where to go next: How to Review a Web App for Accessibility for the First Time.
Status message
A status message tells the user something changed without necessarily moving focus.
Examples include saved, loading, no results, three errors found, filter applied, or item added.
Why it matters: if a status update only appears visually, some users may not know anything changed.
Where to go next: Status Messages and Alerts.
Table header
A table header identifies what a row or column means.
Why it matters: data tables need relationships between headers and cells so people can understand the data without relying only on visual position.
Where to go next: Tables and Data Displays.
WCAG
WCAG stands for Web Content Accessibility Guidelines.
It is a set of accessibility standards used to evaluate web content and digital experiences.
Why it matters: WCAG gives teams a shared standard, but people still need practical examples to know what to notice during real project work.
Where to go next: WCAG 2.1 A/AA Map.
What to do next
When a term shows up in a request, review comment, issue, or vendor response, do not stop at the word.
Ask what the term changes about the work:
- Does a requirement need to be clearer?
- Does a design need another state or relationship?
- Does a component need a keyboard or focus check?
- Does QA need to test a path, not just a screenshot?
- Does the team need a more specific Field Guide page before moving forward?
A shared vocabulary is useful when it helps people make better decisions earlier.