Accessibility Glossary: Key Terms Explained

Speak the language of accessibility

Understanding digital accessibility starts with learning its vocabulary. The field sits at the intersection of law, design, engineering, and lived experience, so the terminology can feel dense the first time you encounter it. Acronyms like WCAG, ARIA, and VPAT get used in the same breath as concepts like “perceivable content” and “accessible name,” and it is easy to lose the thread.

This glossary groups the most important terms into four practical buckets — standards and laws, disabilities and assistive technology, technical and ARIA concepts, and testing and process — so you can find what you need fast and see how the pieces relate. Each entry includes a plain-language definition and, where it helps, a short example.

A note before you begin: no single tool, plugin, or “accessibility overlay” makes a website compliant or genuinely usable. Real accessibility comes from accessible code, thoughtful design, and testing with the people who rely on assistive technology. Treat any product that promises instant compliance with deep skepticism.

Standards, laws, and frameworks

These terms describe the rules of the road — the guidelines you measure against and the laws that can make compliance mandatory.

WCAG: Web Content Accessibility Guidelines. Published by the W3C, WCAG is the global technical standard for accessible web content. The current version is WCAG 2.2. Success criteria are organized under four principles — Perceivable, Operable, Understandable, and Robust (POUR) — and graded at three conformance levels: A, AA, and AAA. Most laws and contracts reference WCAG 2.1 or 2.2 Level AA as the target. Learn how it maps to your obligations in our WCAG compliance guide.
Conformance Level (A, AA, AAA): The three tiers of WCAG success criteria. Level A is the minimum, AA is the practical legal standard most organizations aim for, and AAA is the highest bar (rarely required across an entire site because some criteria are not achievable for all content types).
POUR: The four foundational principles of WCAG: content must be Perceivable (users can sense it), Operable (users can interact with it), Understandable (users can comprehend it), and Robust (it works reliably across browsers and assistive technologies).
ADA: The Americans with Disabilities Act. US civil-rights legislation that prohibits discrimination against people with disabilities. Courts increasingly apply it to websites and apps, and the ADA is the basis for the majority of US digital accessibility lawsuits. See our ADA compliance overview.
Section 508: A section of the US Rehabilitation Act requiring federal agencies and federally funded organizations to make their electronic and information technology accessible. Section 508 incorporates WCAG 2.0 Level AA by reference. Details in our Section 508 guide.
EAA: European Accessibility Act (EU Directive 2019/882). Requires a wide range of products and services — including e-commerce, banking, transport, and e-books — to meet accessibility requirements. Enforcement began in June 2025. Read more in our EAA compliance guide.
EN 301 549: The European harmonized accessibility standard for ICT products and services. It is the technical backbone the EAA points to and adopts WCAG success criteria as its web requirements, so meeting WCAG 2.1 AA goes a long way toward EN 301 549 conformance.
AODA: Accessibility for Ontarians with Disabilities Act. Canadian provincial legislation setting accessibility standards for organizations operating in Ontario, including web content requirements. See our AODA compliance guide.
W3C: World Wide Web Consortium. The international standards body that develops and publishes WCAG, ARIA, and the broader set of open web standards.
WAI: Web Accessibility Initiative. The arm of the W3C dedicated to accessibility. WAI produces WCAG, the ARIA specification, supporting techniques, and educational resources.
VPAT®: Voluntary Product Accessibility Template. A standardized document used to produce an Accessibility Conformance Report (ACR) describing how a product meets standards such as WCAG, Section 508, and EN 301 549. Frequently required in enterprise and government procurement. Learn what one involves in our VPAT/ACR guide, or have us produce one through VPAT reporting services.
ACR: Accessibility Conformance Report. The completed, evidence-backed document that results from filling out a VPAT for a specific product version. Buyers use ACRs to compare vendors and assess procurement risk.

Disabilities and assistive technology

Accessibility exists to serve real people. These terms describe the technologies and interaction methods people with disabilities use to access digital content.

Assistive Technology (AT): Any hardware or software that helps people with disabilities use computers and the web. Examples include screen readers, screen magnifiers, switch devices, voice-control software, refreshable Braille displays, and alternative input devices. Building for accessibility ultimately means building for AT.
Screen Reader: Software that converts on-screen content — text, images, form fields, and controls — into synthesized speech or Braille output. Common screen readers include JAWS and NVDA (Windows), VoiceOver (macOS and iOS), and TalkBack (Android). Our screen reader testing guide walks through how to evaluate with them, and you can commission screen reader evaluation from our team.
Text-to-Speech (TTS): Technology that reads written text aloud. TTS is a building block of screen readers but is also offered as a stand-alone feature for general audiences. It is not the same as a screen reader, which conveys structure, roles, and state — not just words. We explain the distinction in text-to-speech versus screen readers.
Refreshable Braille Display: A hardware device that renders on-screen text as tactile Braille characters using pins that rise and fall. It pairs with a screen reader and is essential for many deafblind users.
Screen Magnifier: Software that enlarges part of the screen for users with low vision, often with color and contrast adjustments. Layouts that reflow cleanly at high zoom levels work far better with magnification.
Switch Access: An input method that lets people with significant motor disabilities operate a device using one or more switches (buttons, sip-and-puff tubes, or other controls) instead of a mouse or keyboard. It depends on a logical, fully operable interface.
Voice Input / Speech Recognition: Software such as Dragon or built-in voice control that lets users navigate and dictate by speaking. It relies on accurate accessible names so commands like “click Submit” match the visible label.
Keyboard Navigation: Operating a website using only a keyboard — typically Tab, Shift+Tab, arrow keys, Enter, and Space. It is essential for people who cannot use a mouse and underpins switch and voice access too. If something works only on hover or click, it fails keyboard users.
Cognitive Disability: A broad category covering conditions that affect memory, attention, problem-solving, or comprehension. Clear language, consistent navigation, predictable behavior, and generous error tolerance all support cognitive accessibility.
Low Vision: Reduced visual ability that is not corrected by glasses. Users may rely on magnification, high contrast, or custom colors, which is why resizable text and strong color contrast matter so much.

Technical and ARIA concepts

These are the engineering-level building blocks — the parts of the page and the markup that determine whether assistive technology can make sense of your interface.

Semantic HTML: HTML written with elements that carry meaning — <nav>, <main>, <button>, <article>, and heading tags — rather than generic <div> and <span> wrappers. Native semantics give assistive technology role, state, and keyboard behavior for free, which is why the first rule of ARIA is “don’t use ARIA if native HTML can do the job.”
ARIA: Accessible Rich Internet Applications. A set of HTML attributes (prefixed aria-) plus roles that communicate the role, state, and properties of UI elements to assistive technology when native semantics fall short — for example, aria-expanded on a custom dropdown. Misused ARIA can make things worse, so it should be applied deliberately.
Role: An ARIA (or implicit HTML) attribute that tells assistive technology what an element is — a button, a tab, a dialog, a navigation landmark. Roles let users understand and predict how to interact with a control.
Accessible Name: The label a screen reader announces for an element, computed from sources like visible text, aria-label, aria-labelledby, or an associated <label>. An icon-only button with no accessible name is announced as “button,” leaving users guessing.
Accessibility Tree: A parallel structure the browser builds from the DOM, exposing the roles, names, states, and relationships of elements to assistive technology through platform accessibility APIs. It is what a screen reader actually “sees.”
DOM: Document Object Model. The browser’s live, structured representation of an HTML page. The accessibility tree is derived from it, so a well-structured DOM is the foundation of an accessible experience.
AOM: Accessibility Object Model. A browser API that exposes the accessibility tree to JavaScript, letting developers query and adjust accessibility properties programmatically.
Alt Text: A text description of an image supplied via the HTML alt attribute. Screen readers announce it so non-sighted users get the information the image conveys. Decorative images should use an empty alt="" so they are skipped rather than read out as noise.
Color Contrast: The luminance difference between text and its background. WCAG requires at least 4.5:1 for normal text and 3:1 for large text (and 3:1 for meaningful UI components and graphics). Adequate contrast helps users with low vision and anyone reading in bright sunlight.
Focus Indicator: A visible outline or highlight showing which element currently has keyboard focus. WCAG requires it to be clearly visible so keyboard users always know where they are. Removing focus outlines in CSS without a visible replacement is a common, serious failure.
Focus Order: The sequence in which keyboard focus moves through interactive elements. A logical order follows the visual layout and meaning of the content, so navigation feels predictable rather than scrambled.
Landmark: A region of the page identified by role — banner, navigation, main, contentinfo — that lets screen reader users jump directly between major sections instead of reading top to bottom.
Skip Link: A link, usually first in the tab order, that lets keyboard users bypass repeated navigation and jump straight to the main content. It is often visually hidden until focused.
Real Text: Text rendered as actual HTML characters rather than baked into an image. Real text can be resized, reflowed, translated, and read by assistive technology. Images of text fail WCAG except for logos and incidental cases.
API: Application Programming Interface. In accessibility, platform accessibility APIs are the channels through which assistive technology communicates with the operating system and applications to retrieve information about UI elements.
CAPTCHA: Completely Automated Public Turing test to tell Computers and Humans Apart. Traditional image CAPTCHAs are a major barrier for users with disabilities. Prefer accessible alternatives such as audio challenges, honeypot fields, or invisible risk-scoring methods.

Testing, roles, and process

Accessibility is something you verify and maintain, not a box you tick once. These terms cover how teams evaluate and sustain it.

Automated Testing: Using software to scan pages for detectable issues like missing alt text, low contrast, or empty labels. It is fast and great for catching regressions, but it finds only a portion of all issues. Our accessibility scanning software and free accessibility scan are good starting points.
Manual Testing: Evaluation performed by a human using assistive technology and expert judgment. It catches what automation cannot — logical reading order, meaningful link text, sensible focus management, and whether a flow is actually usable. See our manual accessibility audits guide and recurring audit services.
Usability Testing with People with Disabilities: Observing real users of assistive technology completing tasks on your product. This is the gold standard, surfacing friction that neither tools nor checklists reveal. Explore our audits by people with disabilities.
Accessibility Audit: A structured assessment of a product against a standard (usually WCAG 2.2 AA), combining automated and manual methods to produce a prioritized list of issues with remediation guidance. The principles are covered in true digital accessibility.
Remediation: The work of fixing the accessibility issues an audit uncovers — correcting code, redesigning components, or rebuilding documents. For non-web files this often means PDF remediation to make documents readable by assistive technology.
VPAT / ACR (in process): Beyond being documents, producing a VPAT-based ACR is a process: testing the product against each applicable criterion, recording the support level, and documenting evidence. Buyers treat a credible ACR as proof of due diligence.
Shift Left: Moving accessibility work earlier in the development lifecycle — into design and code review rather than post-launch fixes. Catching issues early is dramatically cheaper than retrofitting, the core idea behind accessibility consulting.
Accessibility Statement: A public page describing your conformance level, known limitations, the standards you follow, and how users can report barriers or request help. Many laws, including the EAA, expect one.
Accessibility Overlay: A third-party widget that claims to make a site compliant automatically via a script and a toolbar. Overlays do not deliver genuine conformance, can interfere with users’ own assistive technology, and have featured in lawsuits. QualiBooth does not endorse them. For a transparent, user-controlled approach instead, see our accessibility toolkit and Agora.
A11y: A numeronym for “accessibility” — the letter “a,” 11 letters, then “y.” Common community shorthand you will see in code, conference talks, and team channels.
Universal Design: A philosophy of creating products usable by as many people as possible without special adaptation. In digital work it means designing for accessibility from the start rather than retrofitting it — and it tends to improve usability for everyone, not only people with disabilities.

Where to go from here

A glossary tells you what the terms mean; it cannot tell you where your product stands. The fastest way to turn vocabulary into action is to combine an automated baseline with expert manual review and testing by people who use assistive technology every day.

Start with a free accessibility scan to see surface-level issues, browse common accessibility issues to avoid, and when you are ready for a real assessment, request a demo or talk to our team about accessibility consulting.