To many people, web accessibility sounds like a vast, technical rulebook only specialists can understand. In truth it rests on a simple idea: a website should be usable by as many people as possible, regardless of whether someone works with a mouse, the keyboard or a screen reader, whether they see well or rely on high contrast. Worldwide, around 1.3 billion (WHO) people live with a significant disability; in Germany, some 7.8 million (Federal Statistical Office) people were recently recorded as severely disabled. At the same time, the annual analysis of one million home pages shows that 95.9 percent (WebAIM Million) contain automatically detectable failures against the Web Content Accessibility Guidelines. WCAG 2.2 is the international standard for this, and level AA is the benchmark that matters in practice. This article explains the four areas that make the biggest difference in everyday use: contrast, keyboard operation, screen reader support and forms, each in plain language and with concrete implementation tips.
What WCAG 2.2 AA Actually Means
WCAG stands for Web Content Accessibility Guidelines, a set of success criteria published by the World Wide Web Consortium. Version 2.2 has been the official recommendation since October 2023 (W3C) and adds nine further criteria to the earlier edition without removing the old ones. The guidelines are organised into three conformance levels: A as the minimum, AA as the practice-relevant standard and AAA as the highest tier, which cannot be fully achieved for every kind of content. When people speak of accessible design on the web, they almost always mean level AA, because the European Accessibility Act and the German Accessibility Strengthening Act refer to it as well.
All criteria trace back to four underlying principles, summed up by the memory aid POUR. Content must be perceivable, so it can be taken in through different senses. It must be operable, meaning it works without a mouse too. It must be understandable, in language and structure. And it must be robust, so it reliably works with different devices and assistive technologies. Anyone who keeps these four ideas in mind understands most of the individual rules almost on their own. Why accessibility is now a legal question for many providers as well is set out in detail in our article on the legal duty for accessible websites.
The Four Principles of WCAG
Contrast: Visible for Everyone
The most common failure on the web is insufficient contrast. In the large sample, 81 percent (WebAIM Million) of all home pages examined had text with inadequate contrast. This affects not only people with a visual impairment but anyone reading a page in sunlight on a phone or working at an older screen. WCAG sets clear minimum values for this that can be measured with simple tools. Contrast is expressed as the ratio between foreground and background luminance, from 1:1 for the same colour to 21:1 for pure black on white.
| Element | Minimum contrast (AA) |
|---|---|
| Body text | 4.5:1 |
| Large text (from 24px or 18.66px bold) | 3:1 |
| Controls and active UI parts | 3:1 |
| Essential graphics and icons | 3:1 |
| Visible focus ring | 3:1 to surroundings |
It is also important that colour is never the only carrier of information. Marking a required field in red alone is not enough, because people with a colour vision deficiency cannot tell the difference. Better is a combination of colour, an icon and text such as an asterisk or the note required. Links within body text should not stand out from the surrounding text by colour alone either, but additionally through an underline. Anyone offering a dark mode should check contrast there just as carefully, because light text on a dark background follows the same rules.
Practical tip for contrast
Keyboard Operation: Reaching the Goal Without a Mouse
Many people operate a website solely with the keyboard, for example because a motor impairment makes the mouse difficult, or because a screen reader is in use. The central criterion is therefore: everything that works with the mouse must work with the keyboard too. In practice this means that every control can be reached with the Tab key and triggered with Enter or the space bar, that the order follows the visible layout logically, and that with the keyboard you never get stuck in a component you cannot navigate out of.
Just as important is a visible focus. Anyone moving through a page with the Tab key must be able to tell at all times where they currently are. A clearly visible ring or highlight around the active element is therefore mandatory, and WCAG 2.2 has tightened the requirements for this focus display. The widespread mistake of removing the focus ring for aesthetic reasons via CSS makes a page practically unusable for keyboard users. A skip link that, as the first focusable element, jumps straight to the main content additionally saves the route through the entire navigation.
- Every control can be reached with the Tab key
- The focus order follows the visible arrangement
- The focus is always clearly highlighted
- Menus, dialogs and sliders can be operated by keyboard
- No component becomes a keyboard trap
- A skip link leads straight to the main content
New in WCAG 2.2: larger target sizes
Screen Readers: Semantic HTML as the Foundation
A screen reader reads a website aloud, making it usable for blind and severely visually impaired people. For this to work, the structure of a page must be correct not only visually but in the source code too. The most important tool for this is semantic HTML, meaning the use of the right elements for their actual meaning. A heading belongs in a heading element, a button in a button element, a navigation in a navigation region. A non-button element styled with CSS to look like a button may be visually convincing, but to the screen reader it remains invisible or unintelligible.
A clean heading hierarchy is especially important. There should be exactly one main heading, with subheadings nested logically below it, without skipping levels. Many screen reader users jump deliberately from heading to heading to get an overview, much as sighted people skim a page. Equally central are meaningful alternative texts for images that describe the content or function of an image, as well as region markers for header, navigation, main content and footer, so that the structure of the page can be targeted directly.
Semantic elements
Headings, buttons, lists and links in the right element. That way the screen reader knows the role and meaning of each building block without having to guess.
Alt text
Every image that carries content gets a short, descriptive alternative text. Purely decorative images are marked empty and skipped.
Landmarks
Header, navigation, main content and footer as distinct regions. Users jump straight to the relevant section instead of hearing everything in sequence.
Where native HTML is not enough, for example with elaborate interactive components, ARIA attributes come into play. They add missing roles, states and labels for assistive technologies. The most important principle here is: as little ARIA as possible. A wrongly set attribute often does more harm than none at all, because it feeds the screen reader a false meaning. Semantic HTML first, ARIA only where it is really needed, carefully tested with a real screen reader. How technical cleanliness and usability work together is also shown in our article on mobile-first design.
Forms: Guide Clearly, Name Errors
Forms are where barriers become particularly costly, because this is where the actual action takes place: an enquiry, a sign-up, an order. If an input field lacks an associated label, a screen reader user does not know what to enter, and confusion arises with automatically filled fields too. Every field therefore needs a visibly and technically linked label. A placeholder text in the field is no substitute, because it disappears while typing and often has too little contrast.
The second critical point is error messages. When an entry is not accepted, it must be clear which field is affected and what to do, in understandable language and not by colour alone. The message should be clearly associated with the affected field and made audible to the screen reader so that it does not go unnoticed. Required fields are marked unambiguously, and matching autocomplete values let the browser offer known data such as name or email address, which saves all users time. Because well-usable forms also raise the number of completed enquiries, the effort pays off twice, as our article on conversion optimisation shows.
- Every input field has a visible, linked label
- Required fields are not marked by colour alone
- Error messages name the field and the fix in clear language
- Errors are tied to the field and announced to the screen reader
- Matching autocomplete attributes ease filling in
- On an error, the focus moves comprehensibly to the right place
From Review to Implementation
Accessibility is not a checkbox you tick once but an ongoing process, best considered from the very start. It begins with an honest inventory. Automated tools quickly find a portion of the problems, such as missing alt text or weak contrast. But they only capture a fraction of the criteria; the share is often estimated at around a third. The rest can only be found through manual review: operating the whole page with the keyboard alone, going through it once with a screen reader, checking the structure of the headings. Only the combination of automated test and human review gives a reliable picture.
From this inventory comes a list of priorities. It makes sense to first fix the barriers that affect many users and are easy to change, such as contrast and form labels, and then tackle the more involved points like complex interactive components. A realistic expectation matters: full conformance with every single criterion is a demanding goal, and individual details always remain a matter of interpretation. What counts is the consistent orientation towards WCAG 2.2 at level AA and the willingness to fix reported problems promptly. How we build accessibility into our work is described on our page on accessible websites, and the technical foundations of clean design can be found on our web design page.
Accessibility Benefits Everyone