WCAG 2.2 and the European Accessibility Act
Since 28 June 2025, many private companies in Germany must make consumer-facing digital services accessible under the BFSG, Germany's implementation of the European Accessibility Act. We use WCAG 2.2 Level AA as the current technical testing and development standard. Applicable legal requirements and standards such as EN 301 549 or public-sector BITV are assessed separately. Transition rules cover defined cases rather than every legacy platform through 2030.
Primary sources for this distinction are the W3C overview of WCAG and the official German provisions on BFSG scope and transition rules in section 1 BFSG and section 38 BFSG.
Accessibility means your software works for people with visual, motor, hearing or cognitive impairments and improves usability in many everyday situations. We support audits, implementation and CI integration. For technical assurance, we combine risk-based software testing with accessible UX design; privacy requirements are handled separately in GDPR-compliant software development.
Our accessibility services
Accessibility audit (WCAG / BITV)
Systematic review with axe-core and Lighthouse, manual screen reader testing (NVDA, VoiceOver), keyboard-only navigation and contrast checks. You receive a prioritised report with effort estimates per category.
Inclusive development
We build new applications accessible from the start—based on our custom software development—or remediate findings in existing React/Next.js code: semantic HTML, ARIA, focus management and CI checks via DevOps pipelines.
Accessibility statement & VPAT
We prepare the technical basis for your public accessibility statement—conformance status, known exceptions and timelines—aligned with BFSG and BITV expectations.
Assistive technology testing
Automated scans miss most focus-order and live-region issues in SPAs. We add manual passes—embedded in our QA and testing practice—before release.
Accessibility audit
WCAG 2.2 AA review with axe-core, screen readers and contrast analysis—prioritised remediation roadmap included.
Accessible development
Semantic HTML, ARIA and keyboard navigation for React, Next.js and other modern stacks.
CI/CD integration
axe-core in your pipeline—accessibility regressions fail the build early.
Compliance documentation
Technical findings for accessibility statements and VPAT-style documentation, matched to scope and context.
Frequently asked questions
FAQ: Accessible software development & WCAG
BFSG, WCAG and legal scope
What is the BFSG and who does it affect?
Germany’s Barrierefreiheitsstärkungsgesetz (BFSG) implements the European Accessibility Act (EAA).
Since 28 June 2025 it applies to specified products and consumer-facing services, which can include online shops, digital banking and telecom services. Transition rules do not apply to every legacy system through 2030; they cover defined situations.
We assess the technical scope, while binding legal classification remains case-specific.
What does WCAG 2.2 AA mean for developers?
WCAG 2.2 Level AA is our current development and testing standard for accessible web applications.
It builds on WCAG 2.1 and covers perceivable content, operable interfaces, understandable UI and robust markup. For React/Next.js that means semantic elements, purposeful ARIA, focus management, keyboard access and automated plus manual tests.
Applicable law and standards such as EN 301 549, BFSG/EAA or public-sector BITV are assessed separately.
Implementation, audits and cost
How do you implement accessibility in React applications?
We work in layers: semantic HTML instead of div-only UI, purposeful ARIA (labels, live regions, describedby), keyboard navigation and focus traps in modals, and sufficient colour contrast.
axe-core and Lighthouse run in CI so regressions surface in the build—not only before release. Manual NVDA and VoiceOver passes catch issues tools miss.
What does an accessibility audit and remediation cost?
The accessibility cost calculator gives EUR 2,856 – 82,334 excl.
VAT as its non-binding overall range. It accounts for automated scans, screen-reader review, keyboard testing and prioritised findings. Application size, existing technical debt and remediation depth determine the concrete result.
Building accessibility in from the start avoids expensive retrofitting and makes it part of the definition of done.
Can accessibility be added later?
Yes, but retrofitting usually costs several times more than baking it into design and development.
We audit existing systems, prioritise by compliance risk and effort, and plan incremental fixes without blocking releases.
Which tools do you use for automated checks?
axe DevTools, WAVE and Lighthouse catch a subset of issues.
We combine them with screen-reader, keyboard-only and expert review, then document scope, findings and limitations for remediation or an accessibility statement. This is not an automatic guarantee of full compliance or a government-issued certificate.
Accessibility as compliance and competitive edge
Accessible software reduces legal risk and opens markets. Good semantic structure also improves SEO and performance for all users—not only assistive technology users.
- ✓WCAG 2.2 AA: contrast, keyboard use, screen-reader structure, focus and scalable text
- ✓Automated plus manual testing before each release
- ✓Made in Germany—development and support from Ostfriesland
Request a free initial check of your key user journeys—we will outline scope, risk and next steps.
