Accessibility Testing: How Companies Test Their Websites for Accessibility and Determine When an Audit Is Necessary

Before we dive into the practical aspects of testing, let’s briefly discuss the legal framework, since not every website is automatically affected. The BFSG transposes the European Accessibility Act (EAA) into German law and applies to products and services that are placed on the market or provided to consumers on or after June 28, 2025.

For websites, this means specifically: Generally, the pages through which services are offered to consumers are covered. These primarily include online stores, online marketplaces, online banking, online appointment scheduling, and booking platforms. According to the Federal Agency for Accessibility, websites that are purely informational or promotional, as well as purely B2B offerings, are generally not affected.

Also important: There is a micro-enterprise exemption for services. Businesses with fewer than ten employees and an annual revenue or total assets of no more than two million euros may be exempt from this requirement. However, this exemption does not apply to products.

Our tip: Even though websites are not formally covered by the BFSG, making them accessible is worth the effort. It’s not just a “nice-to-have”—it improves reach, SEO, and conversion rates alike. In the coming years, the scope of application is likely to expand, not shrink.

The BFSG states: Digital services must be “accessible.” But what does that mean from a technical standpoint? The Federal Agency for Accessibility refers here to the harmonized European standard EN 301 549, which in turn is based on the internationally recognized Web Content Accessibility Guidelines (WCAG).

Here’s a brief technical note, but an important one: The currently harmonized version of EN 301 549 is still V3.2.1. It references WCAG 2.1 for Conformity Levels A and AA. WCAG 2.2 was published as a W3C Recommendation on October 5, 2023, and adds nine additional success criteria to WCAG 2.1. The next version of EN 301 549 is expected to incorporate these requirements, thereby aligning the European accessibility standard with WCAG 2.2.

However, WCAG 2.2 will not become legally binding until the corresponding version of EN 301 549 is referenced in the Official Journal of the European Union. Until then, WCAG 2.1 AA remains the official benchmark for the harmonized standard.

In practical terms, this means that anyone who currently tests digital offerings against WCAG 2.1 AA is following the current standard and, in many cases, is well-positioned. Those who want to ensure their compliance is future-proof should also take into account the nine new success criteria from WCAG 2.2 starting today. This allows for potential adjustments to be planned early on and reduces the need for later corrections.

Whether you test it yourself or commission an audit, the WCAG organizes accessibility around four basic principles. If you’re familiar with them, you’ll have a good idea of where a website is falling short.

• Perceptible: Content must be presented in a way that allows all the senses to perceive it. Common questions: Do images have alternative text? Is the color contrast sufficient? Are there captions for videos?
• Accessible: Every function must be accessible, not just via the mouse. Can the page be navigated entirely using the keyboard? Are the clickable areas large enough? Is the focus clearly indicated?
• Comprehensibility: Language , structures, and interactions must be easy to understand. Are texts written in simple language? Are forms labeled clearly? Are errors explained?
• Robust: The code must be clean enough that assistive technologies (screen readers, voice input) can handle it. This is where semantic HTML, ARIA attributes, and valid structures come into play.

These four principles are the lens through which all WCAG success criteria are written.

Companies don’t have to wait for an audit to identify initial vulnerabilities. With just a few simple steps, they can get an initial sense of where their website stands in 30 minutes. The Federal Agency for Accessibility recommends quick tests and free tools, among other things, to get started. Important to know: These tests provide only an initial impression, not a comprehensive assessment.

A simple practical test quickly reveals whether keyboard navigation and focus management work: To do this, first click in the address bar and then navigate using only the Tab, Shift+Tab, Enter, and arrow keys. Are all relevant elements accessible? Is it always clear which element currently has focus? Can you open menus, fill out forms, and navigate through the entire shopping cart? This test often reveals within just a few minutes whether key usability requirements are met.

On Windows, the free, open-source screen reader NVDA can be installed in just a few minutes. At the very latest when you listen to the content for the first time, it becomes clear whether headings are logically nested, whether images have meaningful alternative text, and whether form fields are announced in a way that’s easy to understand. PAC (PDF Accessibility Checker) is also a good tool for PDFs.

Three tools that are quick to install and can be used right in your browser:

• Lighthouse is built into Chrome (DevTools → Lighthouse → Accessibility) and provides a score and specific recommendations in less than a minute.
• axe DevTools by Deque is a browser extension that generates much more detailed reports and is well-suited for developers.
• WAVE graphically highlights where problems lie right on the page. This is ideal for getting a quick overview.

In addition, the “BIK für Alle” initiative offers a BITV quick test that allows users to check ten selected requirements even without in-depth technical knowledge.

• Zoom the page to 200 percent: Will it remain readable and usable?
• Check the color contrasts using a contrast checker.
• Read the texts aloud: Are they clear and well-written?
• Check the link texts: Are they descriptive, or do many of them just say “Click here”?

This quickly results in a list of quick wins—issues that can often be resolved directly in the CMS or with minor adjustments to the front end.

If, after the self-test, there is still uncertainty as to whether a website is fundamentally compliant with the BFSG, a quick check is the next logical step. During this process, an expert reviews a limited selection of representative pages, such as the homepage, a product page, the checkout page, or a form. This is followed by an initial technical assessment.

The advantage: The time and budget required remain manageable, while at the same time providing concrete insights into whether a full audit is worthwhile and where the greatest opportunities for improvement lie. For many small and medium-sized websites, this serves as a solid basis for decision-making. Market rates for such checks often start in the low four-digit range, though the exact cost depends heavily on the scope of the work.

A quick check is no substitute for a full audit, but it prevents companies from getting bogged down in details without clear priorities.

This brings us to the gold standard: the comprehensive accessibility audit. While automated tests reveal symptoms, an audit uncovers the root causes, prioritizes actions, and provides a clear roadmap.

An audit follows a structured process that typically consists of three major phases.

During the analysis phase, experts systematically review all relevant WCAG success criteria across code, design, and content—using a combination of automated tools, manual testing, keyboard and screen reader checks, and content evaluation. The audit does not cover “the website” as a whole, but rather representative page types, critical user journeys (login, checkout, search, forms), and cross-site components.

During the optional user testing phase, real users with various disabilities are brought in. This is where it becomes clear whether a form—while technically WCAG-compliant—still presents obstacles in practice.

During the reporting phase, a document is created that describes each barrier identified, prioritizes them by severity, and provides concrete solutions. Good audits don’t stop at “What’s wrong?”—they also answer the question “What should we do first?”

Three scenarios in which, based on our experience, we strongly recommend an audit:

• When websites are subject to the BFSG and a solid basis is needed for the necessary adjustments. It is best to document this so that you are not left without a case during an audit by the MLBF.
• When major decisions regarding a relaunch or migration are made, it is significantly more cost-effective to incorporate accessibility from the start than to retrofit it later.
• When companies operate in a highly regulated or reputation-sensitive environment—such as banking, healthcare, public administration, or large, high-visibility platforms—accessibility quickly becomes a risk management issue.

This is the most honest part of this article: Automated tools are important, but they’re only half the battle. A widely cited Deque study based on over 2,000 audits, more than 13,000 pages reviewed, and around 300,000 issues identified, concluded that automated axe tests can, on average, cover about 57 percent of the issues found. That’s significantly more than the 20 to 30 percent figures often cited in the past. However, it also means that 43 percent of the issues remain undetected when testing is performed exclusively through automation.

What tools are systematically unable to check reliably:

• Whether alternative text makes sense in terms of content. A tool can only detect whether it exists.
• Whether the order of the keyboard navigation is logical. Formally, it may be correct, but it still feels chaotic.
• Whether a form error is described in a way that is easy to understand.
• Whether it works in practice with screen readers.
• Whether complex interactions such as drag-and-drop, modal dialogs, or dynamically reloaded content are truly usable for users.

An audit that incorporates human review, genuine assistive technologies, and a user-centered approach is precisely what fills these gaps.

Even though the new EN 301 549 V4.1.1, which aligns with WCAG 2.2, will only gradually become mandatory, it’s worth taking a look at the new success criteria now. They address gaps that, in practice, particularly affect people with motor or cognitive impairments. Four of these are particularly common topics in audits:

Focus Not Obscured (April 2, 2011): When an element receives focus, it must not be completely obscured by a cookie banner, sticky header, or chat widget. It sounds trivial, but it’s a classic issue in everyday use.

Dragging Movements (2.5.7): Features that are operated by dragging (sliders, drag-and-drop) require an alternative method of operation using a single click or the keyboard.

Target Size (2.5.8): Clickable areas must be at least 24×24 CSS pixels in size (with exceptions). If you’re developing for mobile, you shouldn’t skimp on this anyway.

Accessible Authentication (3.3.8): Login processes must not require purely cognitive tests. Password managers, passkeys, and copy-and-paste must work; CAPTCHAs that rely solely on memory are prohibited.

Anyone testing or building a new website today should always consider these four criteria. They can often be implemented with little effort and will save you from costly rework later on.

As an IT service provider, we have been developing software for medium-sized companies and international corporations for over 20 years. For us, accessibility is not just an add-on at the end of a project, but an integral part of our approach, guided by the principle of “Security & Accessibility by Design.”

Specifically, this means that we incorporate accessibility from the very beginning—from the UX concept through component libraries to clean, semantic code. During architecture and code reviews, our experts also evaluate aspects of digital accessibility, rather than addressing them only at the very end.

We combine automated tests in our CI/CD pipelines with manual testing, including keyboard, screen reader, and contrast checks. With our UX partner UID, we also conduct real-world user research when the project requires it.

And let’s be honest: accessibility isn’t a one-time effort—it’s an ongoing process. Every new feature, every relaunch, and every update can introduce barriers. That’s why we recommend integrating accessibility testing into your regular development and release cycles, rather than getting stressed out once a year.

Accessibility testing is no longer just a bonus—it’s a must. As of June 28, 2025, it’s not just an ethical or strategic consideration, but a legal requirement. The good news: Companies can get started right away. With a keyboard, a screen reader, and a few free tools, you can get an initial idea of where a website stands in just half an hour.

The truth of the matter: Automated tests reveal some issues, but they don’t catch them all. An accessibility audit identifies root causes, prioritizes actions, and turns a complex issue into a clear roadmap. What’s right for a company depends on its size, industry, and legal obligations, but the process is always the same: first, get your bearings; then, conduct targeted testing; and finally, implement changes in a structured manner.

And the best part is: An accessible website is almost always a better website. This applies to search engines, conversion rates, and, above all, the people who use it.

Does this sound like something that interests you? If you want to know where your website stands today and what a suitable next step might look like, feel free to reach out. Together, we’ll determine whether a quick check, a full audit, or integrating accessibility into your development process makes sense for you.