Digital accessiblity glossary
Key terms explained clearly

An accessibility overlay is a widget that is integrated at a later stage and uses JavaScript to adjust the display of a website – for example, font size, contrast or a text-to-speech function. It is important to understand that an overlay does not fix barriers in the coding, it simply places a user interface over it. Providers who market an overlay as a “one-click solution for full compliance” are rightfully controversial within the professional community and cannot prevent formal warnings. We utilize an overlay exclusively in a transparent manner: as a declared interim solution whilst the actual coding is being adjusted – never as a substitute.

The Accessibility Tree is the structure that assistive technologies, such as screen readers, actually evaluate. It is derived from the DOM and contains only the information relevant to user interaction: roles, names and states. If this tree is incorrect, content remains invisible to blind users, even though it is visible on the screen. This is one of the most common and hardest-to-detect errors, because automatic tests often fail to identify them.

Alt text is a textual description of an image that screen readers read aloud and that appears if the image fails to load. It describes the information contained in the image within its context, not every single detail. Avoid using phrases such as ‘Image of’ and do not repeat the caption. Purely decorative images should have an empty alt text so that the screen reader skips them – this, too, is a conscious decision, not an oversight.

ARIA (Accessible Rich Internet Applications, or WAI-ARIA in full) is a set of HTML attributes that makes complex components such as drop-downs, tabs, sliders and modals accessible to screen readers. ARIA complements HTML, but does not replace it. The most important rule in practice is: no ARIA is better than incorrect ARIA. I regularly come across instances where well-intentioned attributes cause a component to become inaccessible because a native HTML element would have performed the task better by design.

The ATAG define how editorial and authoring tools must themselves be accessible and how they should support their users in creating accessible content. This is particularly relevant for CMSs, e-commerce systems and e-learning platforms. My practical tip: A content management system that prevents your team from entering alt text will consistently create barriers – no matter how good the template is.

An accessibility audit is the systematic assessment of a website, app or document against standards such as the WCAG, BITV or PDF/UA. It can be conducted automatically, manually or using a combination of both, and provides specific, prioritised recommendations. The key point is that, depending on the study, a purely automated scan covers only around a third of the relevant criteria. Anyone commissioning an audit should ask specifically how much of it was checked by a machine and how much by a human.

Automated testing tools such as axe-core or Lighthouse scan a page’s code and flag clear technical errors, such as missing alt text or poor contrast. They are quick, cost-effective and serve as a good initial filter. Their limitation is that no scanner can assess whether alt text is contextually appropriate or whether a keyboard navigation sequence is logical. Use these tools as an early warning system, not as proof of compliance.

Accessible authentication means that users can sign in without having to pass a cognitive ability test – such as typing out distorted characters or solving puzzles. WCAG 2.2, in Criterion 3.3.8, requires that there must always be an accessible alternative, for example, pasting from a password manager or confirming through a device. Many login and payment processes fail precisely on this point because their CAPTCHA does not provide an accessible alternative.

Digital accessibility means that websites, apps and documents can be perceived, operated and understood by everyone – regardless of physical or cognitive limitations. It provides the foundation for digital inclusion and has been a legal requirement for large parts of the economy since 2025. We deliberately use the term ‘barrier reduction’ rather than ‘100 per cent accessible’: Nobody can guarantee that a website is completely accessible, as circumstances vary infinitely.

An accessibility statement is a publicly available statement setting out the current state of accessibility of a digital service, including any known limitations and a feedback option. It has been mandatory for public institutions for years; for many companies, this transparency requirement is imposed by the BFSG. It is not just a tedious form, but a legally relevant document: whoever honestly lists outstanding issues and a timetable here is demonstrating that they have fulfilled their due diligence obligations.

The BFSG is the german law that implements the European Accessibility Act into national law and has been in force since 28 June 2025. It requires numerous organisations – including e-commerce businesses, banks, passenger transport operators and many service providers – to make their digital products and services accessible. Micro-enterprises in the service sector are exempt under certain thresholds; however, in practice, this exemption applies less frequently than many might believe. Anyone interested in checking whether they are affected should not rely on gut feeling, but should obtain a reliable assessment.

The BITV 2.0 sets out the accessibility requirements for digital services provided by federal public authorities in Germany. It refers, from a technical perspective, to the European standard EN 301 549 and thus to the WCAG. Whilst the BFSG applies to the private sector, the BITV is the authoritative framework for public authorities, government departments and public institutions.

A Braille display outputs digital content in a tactile form by raising pins to form dot patterns. It is the primary output device for many blind people, particularly those who are deafblind. For it to function, it requires exactly the same semantically clean code that is used by screen readers – accessibility improvements in one technology almost always benefit the other.

Breadcrumb navigation shows the path a user is following within the website structure, such as Home, Products, Software. For it to work for screen readers, it must be marked up with as a navigation area and the currently selected item must be correctly highlighted. When implemented correctly, it improves both user navigation and SEO, as search engines also read the structure.

A CAPTCHA is designed to prevent automated access, but often becomes an insurmountable barrier in its own. Distorted letters are impossible for people with visual impairments to decipher, whilst purely visual image-based tasks are impossible for blind users in any case. More accessible alternatives include invisible, behaviour-based checks or logic-based questions with an accessible alternative option. Since WCAG 2.2, this is no longer simply a recommendation, but relates to the criteria for accessible authentication.

CI/CD stands for Continuous Integration and Continuous Deployment – in other words, the automated pipeline through which modern teams test and deploy code. For accessibility, this is a leveraging factor, not a minor detail: If you build accessibility tests directly into the pipeline, a pull request containing new accessibility issues will be flagged before it goes live. A quick note, as this term is often confused: in a technical context, CI/CD has nothing to do with corporate identity or corporate design. If you want to ensure accessibility is maintained in the long term, you need to embed it here – in the deployment process.

Closed captions are optional subtitles that, in addition to the spoken words, also describe relevant sounds, music and changes in speakers. They are designed for deaf and hard-of-hearing people and go beyond simple subtitles. A practical bonus: in noisy environments or when playing content on social media with the sound turned off, captions significantly increase the time viewers spend watching.

The contrast ratio describes the difference in brightness between text and background and is crucial for readability, particularly for people with visual impairments. The WCAG require a minimum of 4.5:1 for normal text and 3:1 for large text; graphical control elements also require a minimum of 3:1. Light grey text on a white background may appear subtle, but it regularly fails audits. Contrast is not a design detail, but a strict requirement.

Corporate design encompasses a brand’s visual identity – colours, typefaces and logos. It is relevant to accessibility because brand colours often fail to meet contrast requirements. My advice: define accessible colour combinations in the style guide from the beginning, rather than having to correct every page afterwards. This ensures the brand remains both consistent and compliant.

The DOM is the structured representation of a web page that the browser constructs from the HTML. It forms the basis for the accessibility tree – and is therefore the foundation on which all assistive technology relies. A semantically sound DOM structure – that is, proper headings, lists and buttons rather than generic containers – is the cheapest and most effective accessibility measure of all.

The European Accessibility Act is EU Directive 2019/882, which sets out standard accessibility requirements for products and services within the single market. It forms the basis for the German BFSG – and ensures that the rules are comparable across Europe. For companies operating internationally, this means there are not 27 isolated solutions, but a common standard against which they can gauge their compliance.

EN 301 549 is the European standard that sets out specific accessibility requirements for ICT – websites, software, documents and hardware. It translates the abstract provisions of the legislation into verifiable technical criteria, drawing on the success criteria of the WCAG. In practical terms, it acts as a bridge: if you are working to WCAG 2.2 Level AA, you are meeting the core requirements of EN 301 549 for the web.

Plain language is a simplified, clearly structured style of expression that is easier to understand than standard language, but less strictly regulated than easy-to-read language. It avoids complex sentences, technical terminology and foreign words, without adhering to a fixed set of rules. For most corporate websites, it is the more practical starting point, as it can be implemented without the need for certification.

Accessible error messages clearly state what has gone wrong, where the mistake lies and how to correct them – and are automatically announced by screen readers. A red outline alone is not enough, as colour does not convey information to everyone. In audits, the faulty form is a classic example: the user knows that something is wrong, but never finds out what.

The focus indicator is the visible marker that shows which element is currently active through the keyboard – typically a distinct border. Without it, keyboard operation is practically impossible, as users are navigating blind. A common design mistake is removing the focus border via CSS for aesthetic reasons instead of replacing it. The WCAG 2.2 guidelines have even tightened the requirements for focus visibility with two new criteria.

Form accessibility means that every field is clearly labelled, fully accessible by keyboard, and its purpose is clear. Labels must be programmed to be linked to the field, not just displayed visually alongside it. As forms are used for purchases, applications and logins, their accessibility often has a direct impact on turnover – a checkout form that cannot be used means a lost conversion.

A heading structure is the hierarchical organisation of a page using headings from H1 to H6, arranged logically and without gaps. Screen reader users navigate through the page using headings, much as sighted people glance over a text. Exactly one H1 per page, followed by clear nesting – this discipline helps to ensure both accessibility and visibility in search engines and AI responses.

‘Human-in-the-loop’ refers to a testing method that combines software and AI with real human testers – ideally people who use assistive technologies on a daily basis. It is only this step that covers the 60 to 70 per cent of WCAG criteria that an automated scanner is structurally unable to detect. In my experience, this is the only way to achieve a reliable result: a blind tester who exposes your checkout process as inaccessible in thirty seconds cannot be replaced by any software.

Digital inclusion refers to the aim of ensuring that no one is excluded from digital life – whether it be online banking, dealing with public authorities or shopping. Accessibility is the means; inclusion is the aim. Around 135 million people with disabilities are living in the EU; this is not a marginalised group, but a target group with considerable purchasing power, which many providers continue to exclude through technical barriers.

The WCAG recognises three levels of conformance: A as the baseline, AA as the legally relevant standard, and AAA as the highest requirement, which is often only achievable in specific areas. In Europe, Level AA is effectively the standard against which public authorities and businesses are assessed. You should aim for AAA where it makes sense, but nobody expects full AAA compliance across the entire website – some criteria simply cannot be implemented consistently across the board.

Easy language is a greatly simplified form of language based on a fixed set of rules, designed for people with learning difficulties, cognitive impairments or limited knowledge of German. It typically features short main clauses, large print, explanatory images and the avoidance of metaphors. Important to note: Easy language does not replace the standard version; it complements it. In audits, I often see that public authorities are, quite rightly, subject to strict scrutiny in this regard, whilst the private sector underestimates the need for it.

The Matterhorn Protocol is the PDF Association’s validation checklist, which translates the requirements of the PDF/UA standard into specific, verifiable criteria. It lists the types of errors that make a PDF inaccessible and distinguishes between what a machine must check and what a human must check. It is the authoritative standard for validating accessible documents – when someone checks PDFs properly, they do so according to Matterhorn.

PDF/UA (Universal Accessibility, ISO 14289) is the international standard for accessible PDF documents. It sets out requirements for tags, reading order, alternative text, correct table markup and navigation. A PDF often looks flawless to the naked eye, yet is completely unusable for a screen reader. It is precisely this gap that public authorities and large organisations with extensive document collections most frequently underestimate – very few have ever checked their annual reports and forms for compliance with PDF/UA.

A screen reader is a piece of software that reads out screen content or outputs it to a Braille display, thereby enabling blind and severely visually impaired people to use the computer. Common examples include JAWS and NVDA on Windows, VoiceOver on Apple devices and TalkBack on Android. Important: Different screen readers may interpret the same code differently. That is why we test against several rather than just one – what works perfectly on one may fail on another.

Keyboard navigation means that the entire webpage can be operated without a mouse – all interactive elements are accessible, the order is logical, and there are no keyboard traps from which you cannot escape. Many people with motor impairments, as well as power-users, navigate exclusively using the keyboard. My quick test for every page: go through the whole page using the Tab key, without touching the mouse. You’ll be surprised at what gets stuck.

Tooltips provide additional information when an element is focused on or hovered over. To ensure they are accessible, they must also be triggerable via the keyboard, readable by a screen reader, and visible for long enough to allow users to read them at their own pace. A tooltip that only appears when the mouse hovers over it and disappears immediately is of no help to anyone who relies on the keyboard.

A transcript is a complete written record of audio or video content. It makes podcasts, interviews and videos accessible to deaf people, whilst also being readable by search engines. A properly prepared transcript is therefore twice as valuable: it ensures accessibility and boosts SEO, as spoken content would otherwise remain invisible to Google.

Subtitles reproduce the spoken text of a video in written form, in sync with the images. They help people with hearing impairments, but also anyone who watches videos without sound. Automatically generated subtitles are a start, but they are not a free pass – speech recognition often gets technical terms and names wrong, and an incorrect subtitle is sometimes worse than none at all.

Usability describes how efficiently, effectively and satisfactorily people can use a system. Accessibility and usability are not opposites, but rather reinforce one another: a clearly structured, keyboard-navigable website is more user-friendly for everyone, not just for people with disabilities. This is precisely where the often-overlooked business case lies – better usability reduces bounce rates and boosts conversion rates.

Perceivability is the first of the four WCAG core principles: content must be presented in such a way that it can be perceived through at least one sensory channel. Together, the four principles form the acronym POUR – Perceivable, Operable, Understandable, Robust. No information should be conveyed exclusively through sight or exclusively through hearing. Anyone who internalises this has already grasped the core of the WCAG.

WCAG 2.2 are the W3C’s current international guidelines for digital accessibility and have been the authoritative version since October 2023. They organise requirements according to the four principles of perceivable, operable, understandable and robust. Version 2.2 introduced nine new success criteria that are often overlooked in practice: such as a minimum display size of 24 by 24 pixels for clickable targets (2.5.8), keyboard focus that is not concealed (2.4.11) and – particularly important – accessible authentication (3.3.8), which excludes pure puzzle-based and memorisation-based tests for logins. Anyone still working to WCAG 2.1 is carrying out outdated testing.