The Web Accessibility Glossary
Accessibility gets sold with acronyms. WCAG, AA, VPAT, ARIA, axe, overlay. This defines 29 of them in plain English, says what each one does and does not prove, and gives you the question to ask the person putting it in a quote.
Hassan Jamal·Aug 13, 2026·21 min read
Hassan builds custom Next.js sites and writes the engineering guides on this site.
Three things are worth knowing before any of the definitions. WCAG is a technical standard, not a law, and level AA is what nearly every law actually points at. Automated testing detects a subset of failures, so a clean scan is not conformance. And the failures that dominate real sites are not exotic: contrast, alternative text and form labels account for most of what any tool will find on yours.
Standards and conformance
7 termsWCAG
WCAG is the Web Content Accessibility Guidelines, published by the World Wide Web Consortium through its Web Accessibility Initiative. It is the reference that nearly every accessibility law, procurement rule and audit points at, which is why it feels like a law. It is not one. It is a technical standard that laws choose to adopt, and the adopting law decides which version, which level and who it applies to. Read it at w3.org/TR/WCAG22. Why it matters: the distinction is the difference between a scoped engineering target and an unbounded promise. Vendors who blur it tend to sell the unbounded version.
A procurement form asks whether your site is “WCAG compliant.” The question is incomplete as written: WCAG has versions and three conformance levels, so the answerable version is “does it meet WCAG 2.2 level AA, and on which pages.”
“Which WCAG version and level are we being held to, and which pages does that cover?” A quote that says only WCAG has not been scoped yet.
POUR (the four principles)
WCAG is organised under four principles: content must be Perceivable, Operable, Understandable and Robust. Every success criterion sits under one of them. That structure is more useful than it sounds, because it gives you somewhere to start when you hit a problem with no obvious rule attached: ask which of the four it breaks and the relevant criteria narrow fast. Why it matters: it is also how you tell a real audit from a tool export. An audit reasons about principles. A tool export lists rule identifiers.
A carousel that advances on its own fails on Operable, because the user cannot control the pace. A form that rejects a phone number without saying what format it wants fails on Understandable. Same page, two different principles.
Success criterion
A success criterion is a single testable requirement, written as a pass or fail statement rather than as a technique. WCAG deliberately avoids prescribing how to satisfy them, because the right approach differs by platform and a standard full of implementation advice would date faster than the requirements themselves. Techniques are published separately and are explicitly informative rather than required. Why it matters: it means nobody can tell you there is only one compliant way to build something. If they do, they are describing their preference, not the standard.
Criterion 1.4.3 Contrast (Minimum) says text needs a contrast ratio of at least 4.5:1. It does not tell you to change a hex value, use a different palette, or add a background. Any of those can satisfy it.
“Which success criteria are we failing, and what is the evidence for each?” A finding without a criterion attached is an opinion, which may still be a good one, but should be labelled as such.
Levels A, AA and AAA
Success criteria are graded A, AA or AAA, and the levels are cumulative. Level A is the floor. Level AA is the practical target and is what almost every law and procurement rule actually points at. Level AAA is an enhancement that the W3C states is not required as a general policy for entire sites, because it is not possible to satisfy for all content. Why it matters: AAA in a sales document is usually either a misunderstanding or a way to justify a larger number. AA on named templates, with evidence, is what a real engagement looks like.
Level AA asks for a 4.5:1 contrast ratio on normal text. Level AAA asks for 7:1. The AAA version rules out a large part of ordinary brand palettes, which is one reason full AAA conformance is rare and not expected.
If a proposal promises AAA across the whole site, ask which AAA criteria they intend to meet and how. The W3C itself does not recommend AAA as a general sitewide policy, because some content cannot satisfy it.
WCAG 2.2
WCAG 2.2 has been a W3C Recommendation since October 2023, and it is the current WCAG 2 version. It added nine success criteria, largely covering focus visibility, alternatives to dragging, minimum target size and reducing the cognitive load of authentication. It also obsoleted the old 4.1.1 Parsing criterion, which had become a source of noisy findings that did not correspond to real barriers. Why it matters: if an audit you have been given is written against 2.1 and still reports Parsing failures, it is at least a version behind and possibly a tool export from an old ruleset.
One of the additions covers dragging: if an interaction requires a drag, there has to be a single-pointer alternative. That is aimed at people using a switch, a head pointer or a tremor-affected hand, and it quietly rules out a lot of fashionable interface patterns.
VPAT and the Accessibility Conformance Report
A Voluntary Product Accessibility Template is the form a vendor fills in to describe how their product meets accessibility standards; the completed document is an Accessibility Conformance Report. It is a genuinely useful artifact, particularly in procurement, because it forces a vendor to make specific claims criterion by criterion rather than a general one. The thing to hold on to is that it is self-reported. Why it matters: it evidences a claim, and a claim on the record is worth something. It does not evidence a test.
A supplier sends a completed VPAT saying every criterion is Supports. That is the supplier's own assessment of their own product. It may be careful and honest. It is still not an independent audit, and the document does not claim to be one.
“Who completed this, when, against which version, and was any of it tested by a third party?” A VPAT with no date and no author is a marketing asset.
EN 301 549 and Section 508
EN 301 549 is the European standard for accessibility requirements in ICT procurement, and it incorporates WCAG success criteria directly. Section 508 plays a comparable role for United States federal procurement. Both exist so that a buyer can put a testable requirement into a contract instead of the word accessible. Which one applies to you, from what date, and with what consequences, is a legal question with a jurisdiction-specific answer, and we do not publish dates for it here because a wrong date on this page would be worse than no date. Why it matters: the engineering work is the same either way. The paperwork, the deadline and the liability are not, and that part is not ours to answer.
“Which standard is in our contract, and who signed off that we meet it?” Then take the answer to a lawyer rather than to a web studio. We build to the technical standard; we do not advise on which one binds you.
How people actually use the web
7 termsAssistive technology
Assistive technology is any software or hardware someone uses to interact with a computer differently: screen readers, magnifiers, switch devices, voice control, braille displays. Accessible markup is what lets these tools do their job. That is the whole mechanism: the tool can only convey what the page exposes. Why it matters: it reframes the work from a minority accommodation to an interface contract. You are not writing markup for a device, you are writing it so that any device can present your content faithfully.
Someone with a temporary wrist injury using voice control, someone on a train with the sound off relying on captions, and someone who has used a screen reader for thirty years are all served by the same markup being correct.
Screen reader
A screen reader converts a page into speech or braille and lets someone navigate it by heading, landmark, link or form control. The critical detail is what it reads. It does not read your visual layout; it reads the accessibility tree. A page can look immaculately organised and be completely incoherent through one. Why it matters: this is why visual design review never catches accessibility problems, and why a designer signing off on a page proves nothing about whether it can be used.
A screen reader user often opens a page by listing its headings, the way a sighted reader skims. If your headings are chosen for size rather than meaning, that list reads as nonsense and they have lost the fastest route into your content.
“Has anyone actually navigated our checkout with a screen reader, and can I see the recording?” This is the single highest-value question in the list, and it is very rarely answered yes.
Accessibility tree
The accessibility tree is a structure the browser computes from the DOM, describing each element's role, name, state and value, and exposes to assistive technology through platform APIs. It is the actual interface between your markup and every assistive tool, which makes it the thing worth debugging when something is announced wrongly. Why it matters, and this part is new:the accessibility tree is increasingly how automated agents read a page too. Chrome's experimental Lighthouse agentic browsing checks include accessibility-tree quality directly. Work that was framed for years as serving a minority of users is now also the work that decides whether an AI agent can complete a task on your site.
Chrome DevTools shows it: open the Elements panel, select a node, then look at the Accessibility pane. You get the computed role, name and state, which is exactly what a screen reader will announce.
Visible focus indicator
The focus indicator is the visible marker showing which element currently has keyboard focus. Removing the browser default without providing a replacement makes a page unusable by keyboard, because the user can still move focus but can no longer see where it is. WCAG 2.2 tightened this area further, adding criteria about focus not being obscured by sticky headers and overlays. Why it matters:you can style the indicator however you like. The requirement is that one exists and is visible, not that it looks like Chrome's.
The CSS declaration outline: none applied to interactive elements, with nothing put in its place, is probably the most damaging single line in front-end development. It is usually added because a designer disliked the default ring.
Skip link
A skip link is a link, usually the first focusable element on the page, that jumps past repeated navigation straight to the main content. It exists so a keyboard or screen reader user does not tab through the same forty navigation links on every page of your site. Bypassing repeated blocks is a level A requirement, and a skip link is the simplest way to satisfy it. Why it matters: it costs one element and it is the clearest signal in the markup that somebody thought about this at all.
Press Tab once on a well-built site and a “Skip to content” link appears in the top corner. It is usually invisible until focused, which is why most people have never seen one.
prefers-reduced-motion
prefers-reduced-motion is a CSS media feature that reports whether someone has asked their operating system to minimise animation. Respecting it matters because motion causes nausea, dizziness and migraine for people with vestibular conditions, and because the preference is already set on their device. You are not asking them to configure anything; you are choosing whether to read what they already told the browser. Why it matters: it is one media query, and ignoring it is a decision rather than an oversight once you know it exists.
A full-screen parallax scroll effect is a design flourish for most visitors and a genuine trigger for nausea or migraine for someone with a vestibular condition. The media query lets you serve the flourish to one and a still page to the other, from the same code.
“Does the site respect reduced-motion, and can you show me the page with the setting on?” It takes one operating-system toggle to check.
The failures that dominate the data
7 termsThese seven are grouped together because they are not exotic. Six failure types accounted for 96% of all detected errors. Low contrast text appeared on 83.9% of home pages, missing alternative text on 53.1%, and missing form input labels on 52.8%. Every term in this section is one of those, or sits directly alongside them. See the full 2026 accessibility data for the method behind that figure and what it cannot show.
Contrast ratio
Contrast ratio is the measured difference in relative luminance between text and its background. WCAG at level AA asks for at least 4.5:1 for normal-size text and 3:1 for large text, with 3:1 also applying to interface components and meaningful graphics. It appeared on 83.9% of home pages in the 2026 WebAIM Million, making it the single most common detected failure. Why it matters: it is a hex value. The most widespread accessibility failure on the web is fixable by changing a colour, which tells you something about how much of this problem is really a design-review problem.
Light grey text on white reads as tasteful restraint in a design tool on a calibrated monitor, and as nothing at all on a phone held outdoors. That is why it is the most common failure on the web by a wide margin.
“What is the measured ratio for our body text and our button labels?” This is checkable in seconds in browser developer tools, so there is no reason for a vague answer.
Alternative text
Alternative text is text describing what an image conveys, read in place of the image. An image carrying meaning needs a description of that meaning rather than of the picture. A decorative image needs an empty alt attribute so assistive technology skips it silently. Missing alternative text appeared on 53.1% of home pages in the 2026 data. Why it matters: this is the clearest example of the limit of tooling. A machine can tell you the attribute is absent. It cannot tell you the sentence someone wrote is wrong, and a confidently wrong description is worse than silence.
A photo of a team at a laptop, used as decoration beside a paragraph, should carry an empty alt attribute so it is skipped. The same photo used as the only illustration of a process needs text explaining the process. Same image, opposite correct answers.
“Who writes our alt text, and against what rule?” If the answer is that a plugin generates it, you have an attribute-present problem rather than an alternative-text solution.
Form label
A form label is text identifying what an input is for, programmatically associated with that input. A placeholder is not a label. It disappears the moment somebody types, it is frequently rendered in grey too light to read, and it is not reliably announced. Missing form input labels appeared on 52.8% of home pages in the 2026 data, which is remarkable given how many of those home pages carry only a search box or a newsletter signup. Why it matters: visible labels help everyone. This is one of the places where the accessible version and the higher-converting version are the same version.
A checkout with placeholder-only fields: the moment someone starts typing their address, the word Address disappears. If they are interrupted, there is nothing on screen telling them what they were filling in.
Ambiguous link text
Link text should make sense read on its own, without the sentence around it. This is not a style preference; it follows directly from how people navigate. Pulling up a list of links is a standard screen reader behaviour, and it strips every link of its surrounding context by design. Why it matters: descriptive link text also happens to be what search engines and answer engines use to understand what you are linking to, so this one pays twice.
A screen reader user can pull up a list of every link on the page. On a typical marketing site that list reads: Read more, Read more, Learn more, Click here, Read more. It is a table of contents with the contents removed.
Empty button and empty link
An empty control is a button or link with no text an assistive technology can announce, usually because it contains only an icon. The fix is an accessible name, through visible text, an aria-label, or alternative text on the icon image. This is a common casualty of icon-only interface design, and it gets worse as interfaces get more minimal. Why it matters: icon-only controls are usually the most important ones on the page: search, menu, close, submit, cart.
A magnifying-glass icon button with no accessible name is announced simply as “button.” The user has been told something is there and can be pressed, and nothing about what pressing it does.
Heading structure
Heading structure is the h1 to h6 outline of a page, used by screen reader users to navigate the way a sighted reader skims. Headings should describe the content beneath them and should be chosen for structure rather than for visual size, which is what CSS is for. One correction worth making: skipping a heading level is not itself a WCAG AA failure, despite how often it is reported as one. The genuine problems are headings that are missing, inaccurate, or used purely as styling. Why it matters: when an audit leads with skipped heading levels, it is usually a tool export being presented as an assessment.
A page with eight h3 elements and no h1, because the h1 style was too large for the design. The visual hierarchy is fine and the navigable hierarchy does not exist.
“Do our headings describe the content under them, or were they picked for size?” The honest answer on most sites is the second one.
Page language
Page language is the lang attribute on the html element, declaring the natural language of the document. Without it a screen reader may apply the wrong pronunciation rules to otherwise perfect content. It is a level A requirement and it is a single attribute. Why it matters: it is the cheapest item on this entire page, and it is genuinely missing on a great many sites, including multilingual ones where it matters most.
An English page with no lang attribute, read by a screen reader configured for French, is pronounced using French phonetics. The words are correct and the output is unintelligible.
Markup, testing and evidence
8 termsSemantic HTML
Semantic HTML means using the element that already means what you want, rather than reconstructing it from generic containers. Native elements arrive with keyboard behaviour, focus handling and an accessibility role already implemented. Rebuilding them means reimplementing all of that, correctly, on every platform, forever. Why it matters: most accessibility work is not adding things. It is stopping the reconstruction of things the browser already gave you.
A div styled to look like a button needs a role, a tabindex, an Enter handler and a Space handler to behave like one. A button element needs none of them, because the browser already did that work and tested it on every platform.
ARIA
ARIA is a set of attributes that add role, state and property information where native HTML cannot express it. Its own first rule is not to use it when a native element would do. That rule exists because ARIA changes what is announced without changing how anything behaves. Badly applied, it makes a page worse than no ARIA at all, because the user is now given confident, wrong information. Why it matters: this is the one term on this page where more is reliably worse.
Putting role="button" on a div makes a screen reader announce it as a button. It does not make Enter or Space activate it. The announcement is now a promise the element does not keep.
“Where are we using ARIA, and could a native element have done it?” Heavy ARIA use in a codebase is usually a symptom rather than a sophistication.
Landmark regions
Landmarks are regions that let assistive technology jump between the major areas of a page. Native elements map to them automatically: header becomes banner, nav becomes navigation, main becomes main, footer becomes contentinfo, aside becomes complementary. No extra attributes are needed if the right elements are used. Why it matters: this is the second time on this page that the correct answer is simply to use the element that already exists, and it will not be the last.
A screen reader user can jump straight to main and skip everything above it. That only works if a main element exists. On a page built entirely from divs, the shortcut has nowhere to go.
Automated accessibility testing
Automated testing runs a tool against rendered markup and reports detectable failures. It is fast, repeatable and the only practical way to measure many pages, which is exactly why the WebAIM Million exists. Its boundary is stated by the people who run it: Automated testing detects a subset of WCAG failures. A page with no detected errors is not necessarily conformant. Why it matters: a clean automated report is a floor, not a certificate. Anyone presenting one as proof of conformance is either mistaken or counting on you not knowing the difference.
“Which pages were scanned, with which tool, on what date?” A scan of the home page is not a scan of the site, and the pages that matter are the ones with forms on them.
Manual testing
Manual testing covers what a machine cannot judge: whether alternative text is accurate, whether reading order makes sense, whether an error message explains how to recover, whether the task can actually be completed. It is slower and it does not scale, and it is where the real barriers are found. Testing with people who use assistive technology daily is better still, and different in kind from a developer trying a screen reader for an afternoon. Why it matters: the gap between a passing scan and a usable site is entirely made of things only this finds.
Turn on a screen reader and try to complete your own checkout. Most teams stop within two minutes, because they have found the problem and it is large.
“What was tested by a person, on which flows, and what did they find?” If the deliverable is entirely a tool export, no manual testing happened.
WAVE and axe
WAVE and axe are the two most widely used automated engines. WAVE is published by WebAIM and is the tool behind the annual WebAIM Million study. axe-core is published by Deque and is embedded in many other products, including the accessibility category in Chrome's Lighthouse. Both are free to use on a page. Why it matters: if you are comparing an error count over time, keep the tool constant. Switching engines and reporting the change as progress or regression is a measurement error, not a result.
Run both on the same page and you will get two different error counts. Neither is wrong. They implement different rulesets, and a count is only meaningful alongside the name of the tool that produced it.
The Lighthouse accessibility score
The Lighthouse accessibility score is a weighted result derived from a set of automated axe-core checks. Google's own documentation states plainly that a perfect score does not mean the page is accessible, because the checks only cover what can be automated. Why it matters: it is a useful smoke test and a bad acceptance criterion, which is the same thing this site says about the performance score sitting next to it.
A page scoring 100 in Lighthouse can still be impossible to complete with a keyboard, because none of the checks that would catch that are automatable.
If a proposal promises a Lighthouse accessibility score, ask what happens to the checks the score does not cover. The number is easy to move. The rest is the work.
Accessibility overlay
An overlay is a third-party script that attempts to correct accessibility problems in the browser after the page has loaded, usually sold as a fast route to compliance. Whatever view you take of the category, the mechanical limit is worth being clear about: it sits on top of markup it did not author and cannot see your intent. It does not change the contrast ratio your designer chose, and it does not write the alternative text nobody wrote. Those remain decisions about your content. Why it matters: the sales pitch is that it removes the need for the work on this page. It does not, and the failures it leaves behind are the ones in the data.
“Which of our failures does this actually remove from the page, and which does it leave in the markup?” Ask for the answer failure by failure rather than as a compliance claim.
Where does your own site sit?
Definitions are the easy half. Our free technical audit scans a URL you give it and reports what it finds, with no signup and no diagnosis invented to sell you something. If you would rather a person walked through it with you, that offer stands too.
Frequently asked questions
Frequently Asked Questions
What does WCAG AA mean?
WCAG success criteria are graded A, AA and AAA, and the levels are cumulative. Level A is the minimum, level AA is the practical target that almost every accessibility law and procurement rule points at, and level AAA is an enhancement the W3C states is not required as a general policy for whole sites because some content cannot satisfy it.
Is WCAG a law?
No. WCAG is a technical standard published by the World Wide Web Consortium. It feels like a law because nearly every accessibility law, procurement rule and audit points at it, but the adopting law decides which version, which conformance level and who it applies to.
Does a perfect Lighthouse accessibility score mean my site is accessible?
No. The Lighthouse accessibility score is a weighted result from a set of automated axe-core checks, and Google's own documentation states that a perfect score does not mean the page is accessible. Automated checks cover only what can be automated, so the score is a useful smoke test and a poor acceptance criterion.
Is a placeholder the same as a form label?
No. A placeholder disappears the moment someone types, is often rendered in grey too light to read, and is not reliably announced by assistive technology. A visible label programmatically associated with the input is the accessible version, and it also helps every other user of the form.
Do accessibility overlays make a website compliant?
An overlay is a third-party script that tries to correct problems in the browser after the page loads. It sits on top of markup it did not author, so it does not change the contrast ratio a designer chose or write the alternative text nobody wrote. Those remain decisions about your own content.
Is skipping a heading level a WCAG failure?
Not in itself at level AA, despite how often it is reported as one. The genuine problems are headings that are missing, inaccurate, or applied for visual size rather than structure. An audit that leads with skipped heading levels is usually a tool export being presented as an assessment.
What is a VPAT?
A Voluntary Product Accessibility Template is the form a vendor completes to describe how their product meets accessibility standards, and the completed document is an Accessibility Conformance Report. It is useful because it forces specific claims criterion by criterion, but it is self-reported, so it evidences a claim rather than an independent test.
For the measured picture behind the figures quoted here, read what the 2026 accessibility data actually shows. For the equivalent glossary covering AI search, rendering and performance, read the AEO and web performance glossary.
Related Articles
AEO & Web Performance Glossary: 26 Terms Defined (2026)
A source-linked map of 23 AI-search, rendering, structured-data, and web-performance terms, including what each term does and does not prove.
Why Is My Website Loading So Slow? 12 Causes + Fixes
Find the slow layer before paying for the wrong fix. This measurement-first guide covers field data, lab traces, templates, media, scripts, hosting, and platform constraints.
How to Speed Up Your Website in 2026: 12 Diagnostics
Twelve route-level performance diagnostics, how to measure field and lab evidence, and when optimization or migration is the more defensible investment.