WCAG 2.2 and BITV 2.0 in Practice: Implementing Web Accessi­bility

You implement a website to WCAG 2.2 by setting level AA as the target, checking the key user journeys, fixing findings in reusable components and building tests into every release. BITV 2.0 mainly binds public bodies and points technically to the same criteria; for companies, the BFSG comes on top.

This article covers implementation: what WCAG 2.2 newly requires, who is responsible for what in a project, how to test and how to keep the result. Whether and since when the law applies to your offering is explained in our article on accessibility under the BFSG. The two complement each other: that one tells you whether you must – this one how to achieve it technically and organizationally.

WCAG, EN 301 549 and BITV: Who Sets Which Benchmark

The standards build on one another. The W3C’s Web Content Accessibility Guidelines (WCAG) define as success criteria what accessible web content must achieve – organized by the principles perceivable, operable, understandable and robust, and by levels A, AA and AAA. Laws and regulations draw on these criteria instead of creating technical rules of their own.

Standard	Role	What you derive from it
WCAG 2.2	International W3C standard, a recommendation since October 2023	Technical criteria; the implementation target is level AA
EN 301 549	European standard for accessible ICT; refers to WCAG level A and AA criteria for web content	Benchmark for audits; the widespread version V3.2.1 refers to WCAG 2.1
BITV 2.0	Ordinance under the German Disability Equality Act for federal public bodies; the federal states have rules of their own	Design websites, mobile applications and intranets to EN 301 549, publish an accessibility statement
BFSG	Act for certain private-sector products and services	Check whether you are affected (see article); technically the same benchmark

BITV 2.0 has applied to public bodies for some time: under the EU Web Accessibility Directive, new websites had to comply from 2019, existing ones from 2020 and mobile applications from 2021. For companies it becomes relevant when they work for public contracting authorities, where accessibility is often required by contract. Public bodies must also publish an accessibility statement and offer a way to send feedback.

If you build consistently to WCAG 2.2 AA, you meet the web criteria of the current standard and are prepared for future versions: WCAG 2.2 is backward compatible, so a conforming page also meets the criteria of 2.1 and 2.0. Clean, valid markup remains good practice even without the removed criterion 4.1.1 Parsing and is still checked in some audit methods.

What WCAG 2.2 Newly Requires

WCAG 2.2 adds nine success criteria to version 2.1. Six of them are at levels A and AA and therefore part of the usual implementation target; three are at level AAA. In addition, 4.1.1 Parsing was removed.

Criterion	Level	Practical consequence
2.4.11 Focus Not Obscured (Minimum)	AA	The focused element must not be completely hidden by sticky headers, cookie banners or chat widgets.
2.5.7 Dragging Movements	AA	Anything that can be dragged – sliders, sortable lists, maps – needs an alternative using a simple click or tap.
2.5.8 Target Size (Minimum)	AA	Click and touch targets are at least 24 × 24 CSS pixels or have enough spacing; there are exceptions, for example for links within running text.
3.2.6 Consistent Help	A	Contact, help or chat appear in the same relative place on all pages.
3.3.7 Redundant Entry	A	Data already entered is reused in the same process or offered for selection, for example the delivery address as billing address.
3.3.8 Accessible Authentication (Minimum)	AA	Login must not require a cognitive test such as remembering a password or solving a puzzle unless there is an alternative. Pasting and password managers must work.

Typical stumbling blocks are 2.4.11 and 2.5.8: fixed headers and cookie banners cover the focus, small icon buttons fall below the target size, and login fields block pasting passwords. All three can be solved centrally – with scroll padding for fixed headers, minimum sizes for controls and a login without a paste block.

Who Is Responsible for What in a Project

Accessibility rarely fails because of one person; it fails because of unclear responsibilities: design defines colors, development builds components, editors maintain content – and everyone assumes the others are taking care of it.

Role	Responsible for	Examples
Design	Contrast, states, layout, target sizes, understandable interaction patterns	Color palette with verified contrast pairs, visible focus style, error messages with text instead of color alone
Development	Semantics, keyboard operation, focus management, form logic, components	Native HTML elements before ARIA, dialogs with focus management, labels via label
Editorial	Content, alternative text, headings, link text, media	Meaningful alternative text, captions, link text such as “Download price list” instead of “here”
Project management	Requirements, acceptance, owners, feedback channel	Criteria in tickets and acceptance, a named contact for feedback

Accessibility is most economical when it lives in the design system: a button or dialog that is built correctly once is correct on every page. That is why we define colors, focus states, form elements and navigation patterns already in the design system – together with the design team of our partner agency LOMA DESIGN.

Typical Barriers and How to Fix Them

Structure and semantics

Use native HTML elements: button for actions, a for navigation, label for form fields, nav and main as landmarks and real headings in an unbroken hierarchy. ARIA adds semantics only where HTML offers nothing suitable – incorrectly applied ARIA is worse than none. A div with a click handler is neither reachable by keyboard nor recognizable as a button for screen readers.

Keyboard and focus

• All functions can be reached without a mouse, and the tab order follows the visual order.
• Focus is always visible – never remove the focus outline without an equivalent replacement.
• A “Skip to content” link at the top of the page bypasses the navigation.
• Dialogs, menus and overlays take focus, keep it inside and return it when closed.

Forms and error messages

Every field needs a visible, programmatically associated label. State required fields and formats before input and describe errors in text at the field – a red border alone is not enough. The autocomplete attribute helps browsers and password managers fill in known data. A good error message reads: “Please enter a valid email address, e.g. name@company.com” rather than just “Invalid input”.

Contrast, zoom and presentation

Normal text needs a contrast ratio of at least 4.5:1; large text, controls and icons need 3:1. The page must scale to 200% without losing content and work at a width of 320 CSS pixels without horizontal scrolling. Moving content can be paused; respecting the system setting “reduce motion” is good practice.

Media and content

Informative images get alternative text, decorative ones an empty alt attribute. Recorded videos need captions and – if important information appears only visually – audio description at level AA; audio-only content needs a transcript. Linked PDFs are documents in their own right with their own requirements: where possible, also provide the information as HTML.

Testing: Automated, Manual and with Users

Tools such as axe, Lighthouse or WAVE quickly find missing alternative text, unlabeled fields and insufficient contrast and can be integrated into the build pipeline. But they cover only some of the criteria. Whether alternative text is meaningful, the focus order feels logical or an error message is understandable can only be judged by a person. A reliable test therefore follows five steps:

1. Automated scan of the key pages and the component library
2. Keyboard test of the most important flows – navigation, form, login, inquiry or checkout – using only Tab, Enter, Space, arrow keys and Escape
3. Screen reader spot check, for example with NVDA on Windows, VoiceOver on macOS and iOS or TalkBack on Android
4. Zoom to 200%, rendering at 320 pixels width, increased contrast and reduced motion
5. Tests with people who use assistive technologies every day – they find problems that no checklist run reveals

Document every finding as a ticket with criterion, location, severity and effort estimate. For public-sector websites, the BITV-Test audit method is also widely used; a report organized by criterion is helpful in any case.

Practical Example: Machinery Manufacturer with Website and Dealer Portal

Suppose a mid-sized machinery manufacturer runs a website with a product catalog and a dealer portal with login and order form. A tender from a public contracting authority asks about accessibility. Here is how to proceed:

• Define key journeys: home page, product search, product page with data sheet download, inquiry form, dealer login and order form – then scan automatically.
• Group findings: they repeat in a few components – the fixed header covers the focus, icon buttons are too small, fields have no label, the password field blocks pasting.
• Fix in components: correct header, button, form field and login once – the effect spans every page.
• Verify manually: keyboard, screen reader and zoom on the key journeys; offer data sheets additionally as HTML or revise the PDFs.
• Involve editors and document: guidelines for alternative text and link text, accessibility statement with a contact route, audit report with a plan for remaining items.

Embedding It in Operations, Avoiding Mistakes, Checklist

Embedding it in operations

• Criteria belong in the definition of done: a component is finished when its keyboard, contrast and screen reader checks have passed.
• An automated check in the build pipeline flags new violations.
• Editorial guidelines with examples for alternative text, link text, headings and tables help everyone who maintains content.
• Third-party components such as cookie banners, booking widgets or chat are checked for accessibility before purchase.
• A named contact takes feedback; reports go into the backlog.

Typical mistakes

• Checking accessibility only shortly before launch, when changes are most expensive
• Relying on an overlay or plugin instead of correcting code and components
• Testing only the home page and skipping forms, login or checkout
• Checking contrast in the design file but not focus, hover and error states
• Adding ARIA attributes without testing keyboard and screen reader

Checklist before the relaunch

• All interactive elements are keyboard accessible, and focus is visible and not obscured.
• Headings, landmarks, lists and tables are marked up semantically correctly.
• Informative images have suitable alternative text, videos have captions.
• Form fields have labels, errors appear in text, and entries are not requested twice.
• Contrast meets level AA, and controls are at least 24 × 24 pixels or have spacing.
• Login works with password managers and pasting, without puzzle tasks.
• Zoom to 200% and 320 pixels width work without loss of content.
• An accessibility statement and feedback channel are in place where they are required of you.

How Nano Concepts Supports You

We review your status along the real user journeys, prioritize the findings and fix them in components, templates and content – together with our partner agency LOMA DESIGN in UI/UX design. For new projects we anchor accessibility from the start, for example in an accessible website. In the free initial consultation we clarify your status, goal and realistic effort. The legal assessment remains with your legal counsel; we provide the technical foundation and documentation.

This article does not replace legal advice.