Frequently asked questions
Frequently asked questions about digital accessibility
From the legal foundations of the BFSG through technical WCAG details to costs and project workflow: here you find well-founded answers to the questions we are asked most frequently.
Legal Questions About the BFSG
- What is the Accessibility Strengthening Act (BFSG)? The BFSG transposes EU Directive 2019/882 (European Accessibility Act) into German law and, since June 28, 2025, requires businesses to make their digital products and services accessible. Unlike the earlier BITV 2.0, which only applied to public bodies, the BFSG addresses private sector actors for the first time. Affected areas include online shops, banking, telecommunications, e-books, ticketing and passenger transport services. The technical requirements derive from the harmonized standard EN 301 549, which references the WCAG for web content. In practice this means content must be perceivable, operable, understandable and robust, including usable via keyboard and screen reader. Which obligations follow for your specific offering, we detail on the BFSG requirements page. Across 50+ projects (project experience) we have seen that most companies initially underestimate the scope.
- Is my company affected by the BFSG? If you offer products or services online to consumers (B2C), you are usually affected. The most important relief concerns micro-enterprises providing services: those with fewer than ten employees and annual turnover or balance sheet total of no more than two million euros may be exempt. Note: for products this exemption does not apply. Pure B2B offerings fall outside the BFSG. It gets tricky with hybrid cases, for example a shop selling to both businesses and consumers, or platforms with consumer-relevant functions. A careful case-by-case assessment pays off here. We clarify whether you are affected together with you in a free initial consultation and assess it against the criteria on the BFSG requirements page. This avoids both unnecessary effort and a costly misjudgment.
- What penalties apply for BFSG violations? The competent market surveillance authorities can impose fines of up to 100,000 euros (BFSG, Section 37). Before it comes to that, however, authorities usually first request that defects be remedied within a deadline. If a company fails to respond, distribution of the non-conformant service or product can in severe cases be prohibited altogether. At least as relevant is the litigation risk: consumer protection and disability associations have standing and can assert injunctive claims. On top of that comes reputational damage when an online offering is publicly criticized as inaccessible. The best protection is a documented conformance record. With a structured WCAG audit and a sound accessibility statement, you demonstrate that you are taking your obligations seriously, which authorities consider in their assessment.
- Are there transition periods for existing websites? Yes, the BFSG provides a limited transition rule. Services already provided before June 28, 2025 may, under certain conditions, continue in their existing form until June 28, 2030. This deadline is often misread: it is not a general reprieve for every existing website. New service contracts concluded after the deadline must be conformant immediately. Likewise, any substantial change or relaunch after June 28, 2025 must meet the requirements. So anyone reworking their website anyway cannot rely on the transition period. In practice we recommend not waiting until 2030. Early accessibility optimization spreads the effort, avoids time pressure and gives you better legal protection.
- Does my newsletter need to be accessible? A purely promotional marketing newsletter does not directly fall under the BFSG. Transactional emails are different: order confirmations, shipping notifications, invoices or contract documents are part of the digital service and should therefore be accessible, so that screen reader users can follow their orders too. Independent of any legal obligation, accessible email design is a quality marker: sufficient contrast, meaningful alt texts, a logical reading order and not-too-small font sizes improve readability for all recipients and reduce spam classification. We are glad to include your transactional emails in an audit and provide practical recommendations for your email template. Just mention it in the initial consultation.
- Do I need formal certification? No, the BFSG prescribes no state certification or official approval. There is no government seal you must present to authorities. What matters is that you can document conformance yourself and provide evidence on request. Concretely, the law requires an accessibility statement on your website that names the conformance status, the underlying standards and a feedback mechanism. This statement should be honest and verifiable, since inaccurate claims tend to increase rather than reduce your litigation risk. The most robust basis for it is a documented WCAG audit with a traceable report. On request we also draft the wording for your accessibility statement from it.
Technical Questions About WCAG and Accessibility
- What are the WCAG and which version applies? The Web Content Accessibility Guidelines (WCAG) are the internationally authoritative standard for accessible web content, published by the World Wide Web Consortium (W3C). They are organized around four principles: perceivable, operable, understandable and robust. The current version is WCAG 2.2, published in October 2023. EN 301 549, which the BFSG references, names WCAG 2.1 AA as the minimum. We consistently recommend WCAG 2.2 AA, however, because that version adds new criteria, on focus visibility, target sizes for touch interaction and simplified authentication, and thus reflects the current state of the art. Those who adopt 2.2 today are well protected against the foreseeable update of the EN standard. How we implement these criteria in practice, we show on the accessible web development page.
- What does WCAG 2.2 AA conformance mean? WCAG defines success criteria at three conformance levels: A (basic), AA (the recommended standard) and AAA (the highest level, often not achievable for all content). Conformance at level AA means all A and all AA criteria are met, for example 4.5:1 text contrast, full keyboard operability, meaningful alternative texts and consistent navigation. AA is the decisive target in practice: it is referenced by EN 301 549 as the minimum requirement and is internationally recognized. AAA is rarely required in full, because individual criteria are not feasible for certain content types. Importantly, conformance applies per page: a single unreachable element can break a page's conformance. It is exactly this completeness that we check systematically in our WCAG audit.
- Are automated accessibility tools sufficient? No. Automated testing is an important building block, but not a complete proof. Tools like axe-core or Lighthouse detect, depending on the source, only around 30 to 50 percent of all accessibility issues (Source: WebAIM). They reliably find technical defects like missing alt attributes or insufficient contrast, but cannot judge meaning and context. Whether an alt text is meaningful, whether a screen reader's reading order stays logical, whether error messages are understandable, or whether a complex widget is keyboard operable, can only be checked manually, ideally with real assistive technologies. That is why our WCAG audit combines automated scans with manual expert evaluation and screen reader testing. Only this mix delivers a robust conformance record.
- What is the difference between ARIA and semantic HTML? Semantic HTML conveys meaning directly through native elements: a ` is a button to the screen reader, a is navigation, an is a second-level heading. These elements bring role, state and keyboard behavior with them out of the box, with no extra code. ARIA (Accessible Rich Internet Applications) is a supplement for cases where native HTML is not enough, such as complex widgets like tabs, accordions, dropdowns or live regions. ARIA only adds semantics, it changes no behavior: a marked with role="button"` must still implement keyboard operation and focus itself. The first rule of ARIA is therefore: do not use ARIA if a native element does the job (Source: W3C WAI). How we apply this in practice, we show in our accessible web development.
- Does accessibility work with JavaScript frameworks? Yes, React, Vue, Angular and Svelte are fully compatible with accessible development. A framework is neither an obstacle nor an automatic solution, what matters is the implementation. Static content usually works fine; the typical stumbling blocks arise from the dynamics of modern single-page applications. Three areas need particular attention: focus management during client-side routing (focus must be set sensibly after a page change), the announcement of dynamic content via ARIA live regions, and the correct semantics of self-built components. If these points are ignored, keyboard and screen reader users experience markedly worse operation. With proven patterns, tested component libraries and automated tests in the build process, these challenges can be reliably addressed. Details on our accessible web development page.
- What are accessibility overlays and why don't they work? Accessibility overlays are JavaScript widgets embedded via a code snippet that promise to make a website accessible automatically and retroactively, often combined with a control panel for font size or contrast. The idea of compliance at the push of a button is tempting, but does not hold up in practice. Leading accessibility experts and disability associations explicitly warn against these tools (Source: W3C WAI, Overlay Fact Sheet). They do not fix the structural causes in the source code, frequently collide with users' own assistive technologies, and can thereby make operation even worse. Lawsuits already exist against websites that remained unusable despite an overlay. The BFSG demands real, structural accessibility in the source code. Instead of masking symptoms, we fix the causes, sustainably and verifiably. How we proceed, you can read under services.
Questions About Costs and Project Workflow
- What does an accessibility audit cost? Cost depends on scope, more precisely on the number of distinct page types and the complexity of interactions, not on the total number of URLs. We test one representative example per template (home page, category, product, form, checkout and so on), since similar pages usually share the same barriers. An audit for a mid-sized corporate website with around 15 to 30 page types starts in the low four-figure range. Complex online shops with checkout, filters and a customer portal are correspondingly higher, because dynamic functions are more demanding to test manually. A serious estimate is only possible after reviewing your site. In a free initial consultation we define the scope and name a binding fixed price, so you have full cost transparency.
- How long does accessible optimization take? A project runs through three phases: audit, remediation and re-audit. For a typical corporate website we estimate two to three weeks audit, two to four weeks remediation and about one week re-audit, totaling roughly five to eight weeks. For an accessible shop with checkout, filters and a customer account the effort is higher: three to five weeks audit, four to eight weeks remediation and one to two weeks re-audit, in sum around eight to fifteen weeks. The remediation duration depends heavily on whether you implement it internally or delegate it to us. These ranges are experience values (project experience); the real course depends on code quality and the pace of coordination. In the initial consultation we create a concrete timeline for your project.
- Is retroactive optimization cheaper than a relaunch? In most cases yes. Targeted retroactive optimization is usually significantly cheaper than a complete relaunch, because layout, design and content are preserved and only the barriers identified in the audit are fixed. You also save the cost of redesign, migration and re-testing all functions. There is, however, a tipping point: if the codebase is fundamentally problematic, with outdated markup, little semantic structure or a theme that cannot be extended, point repairs can become more expensive than accessible redevelopment. In that case a relaunch pays off in the long run. Which path is more economical for you can only be judged seriously after looking at the code. That assessment is exactly what our audit delivers, before budget is committed.
- Do you offer ongoing maintenance contracts? Yes. Accessibility is not a one-time state: every new piece of content, every plugin update and every design change can introduce new barriers. That is precisely why we offer compliance monitoring as an ongoing service that secures the level you have reached instead of gradually losing it. Monthly or quarterly packages include automated scans, manual spot checks of critical functions, updates to your accessibility statement and a fixed contingent for fixing newly occurring barriers. This keeps your conformance record permanently robust. We match the scope to your update frequency, a rarely changed website needs less care than an active shop. Reach out via services or directly through contact.
- Can we do the remediation internally? Yes, this is a frequently chosen and often more economical route. Many clients implement the fixes with their own development team because they know their codebase best. Our audit report is designed exactly for this: it lists each barrier with a reference to the violated WCAG criterion, a severity rating and a concrete, actionable solution proposal. For this to succeed, we recommend two flanking measures. An accompanying training course enables your team to implement fixes correctly and to avoid future barriers from the start. And a final re-audit by us ensures the corrections actually take effect and no new problems have arisen. This way you keep knowledge and control in house, while benefiting from external review quality, which is decisive for the conformance record.
- How are costs calculated: fixed price or time-based? Audits are billed as a fixed price, based on the scope defined together beforehand. Since the test scope is clearly delimitable in advance, there are no surprises here, you know exactly what the analysis will cost. For remediation the model depends on the audit result. If the report clearly bounds the effort, we offer a fixed price too. If complexity is hard to predict, for example with nested third-party integrations, time-based billing is more transparent and usually cheaper for you. Monitoring runs on fixed monthly or quarterly flat rates. Which variant fits your project we set out in writing before we start. You get an initial assessment in the free initial consultation.
Questions About Specific Website Types
- Which shop platforms can you optimize for accessibility? We work across platforms, including Shopware Community Edition, CMS-based shops, custom solutions built on modern JavaScript frameworks and headless commerce architectures. WCAG principles apply regardless of the technology; what differs is the way to implement them. With standard platforms the focus is often on theme adjustments, configuring extensions and connecting an accessible checkout. With custom or headless solutions we can work directly in the source code, which usually allows the cleanest results. The critical areas of a shop are always the same: product filters, cart, checkout and forms. These are exactly what we prioritize when testing and optimizing, more on the accessible shop page.
- Do product images also need accessible descriptions? Yes. Informative product images need meaningful alt texts that describe the product and purchase-relevant features, such as color, material or variant. A good alt text conveys what sighted users take from the image, no more and no less. Purely decorative images, by contrast, receive an empty alt attribute (alt="") so screen readers skip them and the reading flow is not disrupted. With extensive catalogs of thousands of items, manual maintenance is barely feasible. Here we develop a systematic alt text strategy that, for example, turns product data from your PIM or shop backend into sensible image descriptions in a structured way. The distinction matters: the product name alone as alt text is rarely enough, and redundant or empty descriptions are just as unhelpful. We check these nuances concretely on your assortment in the WCAG audit.
- How accessible are CMS default themes? This varies widely, and you should not rely on the claim that a theme is accessible across the board. Even well-meaning themes frequently show basic defects in practice: missing landmark structures, insufficient color contrast, mega menus that cannot be operated by keyboard, poorly marked-up sliders or missing focus indicators. On top of that, conformance always depends on the overall picture: even a solid base theme can acquire barriers through your own customizations, page-builder elements or embedded modules. The delivered state of your live site is decisive, not the theme's demo state. An audit shows precisely which adjustments your specific theme needs, and whether these can be implemented in a targeted way or a switch is more sensible. More on this under accessible web development.
- Can third-party plugins and widgets cause barriers? Yes, and they rank among the most frequent and most awkward sources of problems, because they partly escape your direct control. Cookie banners, chat widgets, social media embeds, review widgets and external payment forms regularly show significant defects: focus traps, missing keyboard operation or inaccessible dialogs. Cookie banners and checkout steps are especially critical here: if the consent overlay alone cannot be closed with the keyboard, it effectively blocks the entire page for affected users. That is why we include all embedded third-party components in our WCAG audit. Where a provider offers no accessible solution, we recommend configuration adjustments or an accessible alternative.
- What about PDFs and downloadable documents? PDFs that are part of your service, such as invoices, contract documents, manuals or downloadable forms, should be accessible too. The decisive format here is tagged PDF with structured headings, alt texts for images, a correct reading order, marked-up tables and a searchable text layer (not a pure scan). Many PDFs are produced by exporting from word processing or layout programs and are not automatically accessible in the process. Scanned documents without text recognition are even completely unusable for screen readers. We check existing documents for conformance and advise on how to generate accessible PDFs directly in the creation process going forward, often the more sustainable solution than retroactive repair. An accompanying training course for your editorial team complements this well.
- Does my intranet need to be accessible? From the BFSG's perspective not directly: the law addresses products and services for consumers, so purely internal systems like an employee intranet do not fall within its scope. That does not settle the matter, though. Employers may be obligated under the General Equal Treatment Act (AGG) and labor law to provide employees with disabilities accessible work tools, and an inaccessible intranet can become a problem here. On top of that: enabling accessible work widens the applicant pool and strengthens inclusion within the company. On request we also test internal applications by the same WCAG standards. Whether and to what extent that makes sense for you, we are glad to clarify in the initial consultation.
Questions About Training and Team Building
- What prior knowledge do training participants need? It depends on the format. Developer training requires solid basic knowledge of HTML, CSS and JavaScript. Designer training benefits from experience with common design tools, content training from routine work with your CMS. Specific accessibility prior knowledge is not a prerequisite for any format, that is exactly what we teach. More important than prior knowledge is role orientation: a training session only hits the mark when it builds on participants' real tasks. That is why we agree the content and depth with you in advance. We flexibly adapt the level to your team's knowledge, from a first overview to advanced practice. An overview of the formats is available on our training page.
- Do training sessions take place on-site or remotely? Both are possible, and both formats work very well in practice. Remote training via video conference uses screen sharing, collaborative code editors and live exercises and is in no way inferior in content to in-person formats. They save travel time and are easier to organize across distributed teams. For remote formats we recommend shorter blocks of three to four hours spread over several days rather than one long full day. This keeps concentration high and gives participants time to try out what they have learned in their own project in between. On-site workshops make sense when intensive joint work on code or design is desired. What suits your team we clarify when planning your training.
- How lasting are the training effects? Sustainability does not arise in the seminar room but through application in daily work. Pure knowledge transfer fizzles out if it does not carry over into concrete workflows. That is why our training is deliberately practice-oriented and works with your real projects and components rather than abstract examples. To make the effect last, we recommend three things: integrating automated accessibility tests into the development pipeline (so rules apply, not just good intentions), clear responsibilities, and refreshers after six to twelve months, also because standards keep evolving. On request we combine the training with a later audit that objectively shows how the accessibility of your projects has developed after the upskilling.
- Can different roles be trained together? Yes, in parts it is even explicitly sensible. For the fundamentals, the WCAG overview, the four principles and the understanding of why accessibility matters, all roles benefit from a joint session. A shared basic understanding considerably improves later collaboration between design, development and editorial work. For the in-depth modules, by contrast, we recommend role-specific groups. Developers work on semantic code and ARIA, designers on contrasts, focus states and components, editors on understandable texts, alt texts and correct structure in the CMS. Tools and exercises differ too much here for a joint format. This combination of a shared foundation and role-specific deepening has proven itself. We plan the right setup with you via training.
- Do you offer individual coaching for developers? Yes. Besides group training we offer individual coaching, which is particularly suited to small teams or to the focused deepening of individual developers. The big advantage: we work directly on your real code and your concrete problems, not on example projects. This format is especially effective when someone is currently implementing a difficult component, such as a complex form, a modal dialog system or a custom widget, and needs immediate, practical support. This way knowledge arises exactly where it is needed. Many clients combine coaching with a preceding WCAG audit, so the sessions can focus specifically on the identified weak points.
- Do participants receive training materials? Yes. Every participant receives accompanying documentation, practical checklists and compact reference cards that serve as a reference work in daily work. It is precisely these materials that ensure what was learned remains retrievable when the training was weeks ago. Remote training can be recorded on request, so the content can be reviewed later or passed on to colleagues who could not attend. This noticeably increases the reach of a single training session within the team. In addition, we answer follow-up questions free of charge in the 30 days after the training, because most practical questions only arise during application. Details on content and process are available under training.
Questions About Long-term Accessibility Strategy
- How will the accessibility landscape change in coming years? The standards keep evolving, but not abruptly. The W3C is working on WCAG 3.0, which pursues a fundamentally new evaluation approach: instead of a binary pass/fail check per criterion, a graduated, outcome-oriented scoring model is to take over, weighting actual usability more heavily. Important for planning: WCAG 3.0 is in the draft stage, adoption is not expected before 2027, and even after that a long transition period follows. The EN 301 549, relevant for the BFSG, is likely to first catch up to WCAG 2.2. This means: those who adopt WCAG 2.2 AA today are not investing in a dead end but building a solid foundation. Cleanly implemented accessibility largely carries over to future standards. How we anchor this in practice, you can read under services.
- How do we permanently integrate accessibility into our development processes? The key is to anchor accessibility as a fixed part of the process, not as an afterthought. In practice, three measures contribute the largest share. First, training for all relevant roles, so accessibility is considered already at the design stage rather than only at testing. Second, automated accessibility tests in the CI/CD pipeline that catch coarse regressions at every commit before they reach production. Third, regular manual audits, at least annually, for all those aspects no automated tool can reliably judge. It also helps to add acceptance criteria for accessibility to the definition of done. That way it becomes routine. We support you concretely in introducing these processes, more on this under services.
- Is accessibility worthwhile for websites with little traffic? Yes, for several reasons. The most important is legal: the obligation under the BFSG is not measured by visitor numbers but by the type and provider of the service. A rarely visited site is therefore not automatically exempt, the litigation and fine risk exists regardless of traffic. On top of that come tangible secondary effects: accessible structures, clean semantic markup and good operability also improve the general user experience and have a positive effect on SEO performance, which can even win traffic in the medium term. At the same time, the effort for small sites with few page types is usually manageable, because few templates need to be tested and fixed. We provide a realistic assessment for your site in the initial consultation.
- What happens if we are only partially conformant? Partial conformance is the normal case in reality, especially with large, grown websites, and it is considerably better than inaction. What is decisive is how you handle it: transparency and a recognizable plan are your best protection here. In the accessibility statement you can openly declare the status as partially conformant, concretely name the areas not yet accessible, and present a realistic timeframe for fixing them. It is important that this plan is then actually adhered to. Market surveillance authorities will likely consider whether a company is making serious, demonstrable efforts. We help prioritize the remediation sensibly, first the barriers that block core functions. We derive this roadmap directly from the WCAG audit.
- How do we measure progress of our accessibility efforts? Progress should be measured with several complementary metrics, since a single number can be misleading. We recommend three: the WCAG conformance degree (proportion of success criteria met), the number of critical barriers over time, and the automated accessibility score as a quick early indicator. The right weighting matters: automated scores are suitable for catching regressions early but say little about actual usability, for that the trend of critical, manually verified barriers counts. A high tool score alongside an unusable checkout would be deceptive. Our compliance monitoring delivers these values regularly and makes progress traceably documentable, which at the same time supports your conformance record. More on this under services.
- Can we use accessibility as a marketing advantage? Yes, though with measure and the necessary honesty. Accessibility reaches a relevant and often underestimated audience: people with permanent or situational impairments as well as older users. The clarity and operability this requires improves the experience for all visitors and thereby strengthens conversion and brand perception. Very concretely, accessibility can also be an award criterion: in public sector tenders BITV 2.0 conformance is frequently a prerequisite, and those who can prove it have an advantage. What is decisive is moderation: avoid exaggerated or absolute promises, because accessibility is an ongoing process, not a state reached once and for all. More credible than advertising slogans is an honest accessibility statement, backed by a genuine WCAG audit.