From alt text to target size: this glossary explains the terms you meet when you make a website accessible, work with WCAG, or prepare for the European Accessibility Act in Germany. Every entry opens with a one- or two-sentence definition, followed where useful by examples, the legal reference and the matching WCAG success criterion.
Some German legal terms have no exact English equivalent. Where that is the case, we keep the German word and explain it – Abmahnung is a good example.
Law & standards
The European Accessibility Act, Germany’s BFSG and BITV 2.0, EN 301 549, WCAG as a standard, market surveillance and the exemptions.
These entries are reviewed by a legal expert before they are published. They appear here once that review is done.
Code
What has to happen in HTML, CSS and JavaScript: alt text, ARIA, landmarks, focus, contrast, target size.
- Accessibility tree
- The structure a browser derives from the DOM, holding each element's role, name and state; screen readers and other assistive technology read from it.
- Accessible name
- The name an element exposes to assistive technology, computed by the browser from its text content, label, alt, aria-label or aria-labelledby.
- Alt text
- A text alternative that conveys an image's content or function; decorative images get an empty alt attribute (WCAG 1.1.1).
- ARIA (WAI-ARIA)
- A W3C specification of roles, states and properties that convey meaning to assistive technology where HTML alone cannot; misused, it makes pages harder to use.
- Contrast ratio
- Luminance difference between two colours, from 1:1 to 21:1; body text needs at least 4.5:1, large text 3:1 (WCAG 1.4.3).
- Focus indicator
- The visible marker on the element that has keyboard focus, usually an outline; it must be visible (WCAG 2.4.7, Level AA).
- Focus order
- The sequence in which elements receive focus with the Tab key; it must preserve meaning and operability (WCAG 2.4.3).
- Form label
- A visible, programmatically associated label for a form field; a placeholder is not a label (WCAG 1.3.1, 3.3.2, 4.1.2).
- Heading structure
- A page's logical outline built with h1 to h6; for many screen reader users, the main way to skim a page.
- Keyboard accessibility
- Every function of a website can be operated with a keyboard alone, without a mouse (WCAG 2.1.1, Level A).
- Keyboard trap
- A component keyboard users can move into but not out of (WCAG 2.1.2, Level A).
- Landmark
- A page region with a defined role (such as header, nav, main or footer) that screen reader users can jump to directly.
- Language attribute (lang)
- The
langattribute declares the language of a page or passage so screen readers pronounce it correctly (WCAG 3.1.1, 3.1.2). - Live region
- An area with
aria-liveor a suitable role whose changes screen readers announce without moving focus (WCAG 4.1.3). - Non-text contrast
- UI components, their states and graphics needed to understand content must stand out at 3:1 or more against adjacent colours (WCAG 1.4.11, Level AA).
- Reflow
- Content stays usable at 320 CSS pixels wide – 400% zoom at 1280 pixels – without scrolling in two directions (WCAG 1.4.10, Level AA).
- Semantic HTML
- Using HTML elements for their meaning (such as button, nav, h2) so browsers and assistive technology understand the structure and the controls.
- Skip link
- A link at the top of the page ("Skip to content") that lets keyboard users bypass repeated navigation (WCAG 2.4.1).
- Target size
- Pointer targets must be at least 24 × 24 CSS pixels or have enough spacing from other targets (WCAG 2.5.8, Level AA, new in 2.2).
- Text spacing
- No content may be lost when users increase line, paragraph, letter and word spacing (WCAG 1.4.12, Level AA).
Assistive technology
How disabled people use the web: screen readers, braille displays, magnifiers, voice control.
- Assistive technology
- Hardware or software disabled people use to operate computers and the web – screen readers, braille displays, magnifiers, voice control.
- Braille display
- A device that shows text as tactile braille using moving pins; usually driven by a screen reader.
- German Sign Language (DGS)
- The visual language of Deaf people in Germany, recognised in section 6 of the BGG; federal public bodies provide explanations in DGS on their websites (BITV 2.0 s. 4).
- Screen magnifier
- Software that enlarges part of the screen; users see only a portion of the page at a time, so layout and focus must allow for that.
- Screen reader
- Software that outputs screen content as speech or braille and is operated by keyboard or gestures – e.g. JAWS, NVDA, VoiceOver, TalkBack.
- Voice control
- Operating a computer by spoken commands ("Click Send"); it works only when the visible label is part of the accessible name (WCAG 2.5.3).
Language & media
Easy Language, plain language, captions, audio description, transcripts and accessible PDF.
- Audio description
- Narrated description of important visual content in a video for blind and partially sighted people (WCAG 1.2.3, 1.2.5).
- Captions
- Synchronised text for speech and meaningful sound in video; required for prerecorded (WCAG 1.2.2, A) and live content (1.2.4, AA).
- PDF/UA
- ISO 14289, the standard for accessible PDF (tags, reading order, alt text); PDF/UA-2 extends it to PDF 2.0.
- Plain language
- Clear standard language: short sentences, familiar words, clear structure – less strictly defined than Easy Language (see ISO 24495-1).
- Transcript
- A full text version of audio or video content; the usual alternative for audio-only content (WCAG 1.2.1).
Testing & tools
Automated and manual testing, axe-core, and what overlays can and cannot do.
- Automated accessibility testing
- Software checks pages against rules (e.g. axe-core); only a minority of WCAG criteria can be fully decided this way, the rest needs people.
- axe-core
- Deque Systems' open-source testing library (MPL 2.0) with rules for WCAG and best practice; the engine behind many tools, including Reviseberg.
- Manual accessibility testing
- Testing by people with a keyboard, screen reader, zoom and judgement – needed for the criteria software cannot decide.
All terms from A to Z
A
- Accessibility tree
- Accessible name
- Alt text
- ARIA (WAI-ARIA)
- Assistive technology
- Audio description
- Automated accessibility testing
- axe-core
B
C
F
G
H
K
L
M
N
P
R
S
T
V
Why precise words matter
Accessibility sits where law, code and the lived experience of disabled people meet, and loose wording has consequences. The accessibility statement a German public body publishes and the accessibility information a company must publish under the BFSG look alike, but the obligations behind them differ. Copy one as a template for the other and you easily publish something that is wrong.
Every entry therefore names its source – the statute, the standard or the W3C document – and says so where the legal position is still open.
This glossary explains terms. It is not legal advice for your specific case.
From term to test
Many of these terms describe things you can test: missing alt text, low contrast, a keyboard trap. Reviseberg runs every axe-core rule on every page and sends a keyboard agent through your most important journey. Anything automation cannot decide is shown as "untested" or "potential issue" – never as a pass.
How far an automated check gets on each criterion is stated on every page of our WCAG 2.2 overview.