Skip to content

Our References for Digital Accessibility: Competence Areas and Project Approach

This page shows our technical competence areas, our project approach and typical starting points companies face with accessibility. We present concrete project results confidentially in a personal conversation.

WCAG audit from €2,480 fixed price Fixes in the source code, not an overlay Own accessibility statement published

In short and in plain language

This page shows what we do and how we work. It is about accessibility on the web.

Accessible means everyone can use a website. That includes people with disabilities.

We check websites against the WCAG. These are rules for accessible websites. We fix problems in the source code. We train teams and keep an eye on sites.

The page shows typical cases. These are examples, not real clients.

We do not publish client names. We are glad to tell you more in a private talk. Write to us or give us a call.

Key figures

EN 301 549

European standard as testing basis

6

competence areas

2013

agency founded

From WCAG 2.2 audits from €2,480 through technical remediation in your existing code to training and ongoing monitoring from €49 per month, we cover the entire lifecycle of digital accessibility. Since the German Accessibility Strengthening Act (BFSG) took effect on 28 June 2025, accessibility has become mandatory for many companies. We assess our own website against WCAG 2.2 AA ourselves; status and known limitations are set out in our accessibility statement. We gladly present concrete project results and details confidentially in a personal conversation. Ongoing services can be cancelled monthly; there is no minimum term.

Example audit report
WCAG 2.2 AA audit of a website
Benchmark WCAG 2.2 AA · methodology per WCAG-EM
AA
target level of the audit — findings per principle, mapped to the success criterion and prioritised by severity
PerceivableOperableUnderstandableRobust
Findings by page typeexample values
Home pageFormsSearch
Testing basisEN 301 549European standard
Reportprioritisedwith proposed fix
WCAG audit fixed pricefrom €2,480
After remediationRe-audit
Example WCAG 2.2 AA audit report: principles, findings by page type and testing basis at a glance. Example view — values are illustrative.

Our Technical Competence Areas

Every accessibility project is different, but the technical challenges fall into recurring competence areas. The following areas show what our service covers in each case.

WCAG 2.2 AA Auditing

Systematic testing of all Level A and AA success criteria with automated measurement (axe-core and our own in-browser measurements) and per-criterion assessment. Audit reports with prioritized recommendations and concrete solution proposals.

Technical Remediation

Fixing barriers in common CMS and shop systems: Shopware Community Edition, common CMS platforms and custom frameworks. Semantic HTML, ARIA, focus management and form optimization.

Keyboard and Screen Reader Output

Operation without a mouse and checks of screen reader output, in the desktop and smartphone layout. Real user scenarios from navigation through forms to the complete purchase process in online shops.

Team Training

Practice-oriented workshops for developers (HTML, ARIA, testing), designers (contrasts, layouts, focus) and content editors (alt texts, structure, language). Tailored to your technology.

Compliance Monitoring

Automated continuous monitoring with axe-core. Notifications for newly detected critical findings, regular manual spot checks; we offer updating the accessibility statement per BFSG Section 14 individually (€149 net).

Strategic Consulting

Analysis of BFSG obligations, creation of prioritized roadmaps, support with conformance documentation and long-term accessibility strategy for companies and organizations.

From Finding to Conformant Solution

Remediation in the source code, not an overlay

We fix barriers where they arise: in HTML, in ARIA attributes, in CSS and in the interaction. Using a checkout form as an example, you can see the difference between a typical starting state and the conformant solution — sustainable and without additional scripts.

  • Missing labels, insufficient contrast and invisible focus are solved structurally
  • Error messages as text and ARIA role, not by color alone
  • The fix lives in the code itself and does not depend on an active JavaScript overlay
Overlaybolted on
Barrier only covered by JavaScript
Inaccessible again without the active script
Errors still marked by colour only
VS
Source codestructural
Label, contrast and focus solved in the HTML
Error message as text and ARIA role
Works in the code, without an overlay script

Checks of keyboard and screen reader output

Automated tools find only part of the barriers. That is why in critical paths we additionally check whether headings, form fields and dynamic status messages are passed on to the accessibility interface so that screen readers can announce them understandably.

  • Keyboard and screen reader output on desktop and smartphone
  • Focus and reading order across the entire purchase path
  • ARIA live regions for dynamic cart and status messages
Keyboard and screen reader outputdesktop and mobile
Keyboard without a mouse
Screen reader output
Focus and reading order across the whole purchase funnel
ARIA live regions for cart and status messages
Measurement plus assessmentfull funnel depth

Typical Project Scenarios

The following scenarios describe typical starting situations in accessibility projects and how we approach them. They serve as illustrations and do not refer to specific client projects.

Typical Starting Points and Our Approach

Corporate website
Starting point
Numerous WCAG findings in the initial audit, conformance clearly below level AA, navigation not consistently keyboard operable.
Measure
Prioritized remediation in the existing code, focusing on keyboard operation, contrasts and form labels.
Result
Goal: meet WCAG 2.2 AA and create the accessibility statement per BFSG Section 14.
Online shop
Starting point
Multi-step checkout cannot be completed by keyboard, payment form in iframe, cart updates without announcement.
Measure
Semantic forms, consistent focus management and ARIA live regions for cart and status messages.
Result
Goal: complete purchase path usable by keyboard and with a screen reader.
Web application / portal
Starting point
Dashboard with dynamic tables and real-time updates without status announcement for assistive technologies.
Measure
ARIA live regions, correct focus management for client-side routing and clean table semantics.
Result
Goal: real-time updates are announced, complex interactions are operable and comprehensible.

Examples, not client projects.

Our Project Approach

Every accessibility project follows a structured process. The process is modular: depending on the starting situation, individual phases can be skipped or expanded.

In a free initial consultation we capture your starting situation: what digital products and services do you offer? What technologies do you use? What accessibility measures have already been implemented? From this we derive an initial assessment of action needed.

Industries and Project Types

Our services address various industries and project types. The technical benchmark under WCAG is the same across industries; for certain services such as electronic commerce or consumer banking services, the German BFSGV ordinance sets additional requirements (Sections 17 and 19 BFSGV). The practical challenges vary as well: an online shop poses different requirements than a customer portal or an informational corporate website.

E-Commerce and Online Shops

Accessible product search, filtering, shopping cart, checkout and customer account. Platforms: Shopware CE, SaaS shop systems, CMS-based and custom solutions. Focus on the critical purchase path and conformance with the BFSG.

Corporate Websites

Accessible presentation of services, references, career pages and contact forms. Platforms: common CMS systems and custom solutions. Focus on semantics, navigation and form accessibility.

Web Applications and Portals

Accessible dashboards, forms, tables, configuration pages and self-service areas. Frameworks: React, Vue, Angular, Svelte. Focus on dynamic content, ARIA and keyboard navigation.

Public Procurement

Accessibility in public tenders: in procurement under the German Act against Restraints of Competition (GWB), the technical specification must in principle take into account accessibility criteria for people with disabilities or design for all users where the service is intended for use by natural persons (Section 121(2) GWB). For bidders and contracting authorities we assess against Table A.1 of EN 301 549 in the BITV assessment.

Healthcare

Accessible patient portals, appointment booking systems and information sites for clinics, medical practices and health service providers. Special sensitivity for the needs of elderly and chronically ill users.

Multilingual Websites

Accessibility optimization for multilingual websites with correct language markup (lang attribute), hreflang configuration and language-specific screen reader compatibility. DE/EN, DE/FR and further combinations.

Let's talk about your accessibility project

Quality Assurance and Methodology

The quality of our audit results and remediation work is non-negotiable for us. Every audit report records the state under test with date, addresses and screenshots, so every finding stays traceable. This procedure reduces the risk of barriers being overlooked and serves to check that solution proposals are technically correct and practically feasible. Our audit methodology follows the W3C's WCAG-EM (Website Accessibility Conformance Evaluation Methodology) and EN 301 549 Annex C, making our results traceable and comparable.

For remediation we work on staging environments: every change is tested and validated before being deployed to production. Automated regression tests help detect whether accessibility improvements impair existing functionality or whether fixed barriers are reintroduced by later changes. We document every change with before-after comparison, affected WCAG criterion and explanation of the measure taken. This documentation serves not only traceability but also as learning material for your development team.

Our position in three articles

How we calculate effort and benefit in a project is set out in the article on audit cost and ROI. Why we prefer to plan accessibility early rather than repair it later is argued in the article on accessibility by design. And why we do not offer widget solutions is explained in the article on accessibility overlays.

Key Takeaways

  • Services from audit and remediation to training and monitoring — for corporate websites, web applications and online shops with multi-step checkout
  • Testing per WCAG 2.2 AA, WCAG-EM and EN 301 549, every report with a recorded state
  • Barriers are fixed in the source code, not via JavaScript overlay — sustainable and without extra scripts
  • Transparent entry prices: WCAG audit from €2,480, quick check for €490, ongoing monitoring from €49 per month (each net)
  • We assess our own website against WCAG 2.2 AA ourselves; status and known limitations are set out in our accessibility statement

Technological Breadth and Depth

Our competence covers a broad spectrum of modern web development. Server-side we work with common CMS platforms, Shopware Community Edition and custom frameworks. Client-side we master React, Vue, Angular and Svelte as well as classic server-side rendering. For testing we use axe-core and our own measurements, which load every page in a Chromium browser via Playwright. This technological breadth helps us choose and implement solutions that fit the existing architecture.

Particularly important to us is the connection of accessibility expertise with general web development competence. We understand not only which ARIA attributes a tab widget needs but also how the framework-specific implementation must look: how to connect state management in React with ARIA live regions, how Svelte stores can be used for focus management or how Vue transition hooks are synchronized with ARIA announcements. This is how we combine knowledge of the standards with the technical means to implement them in practice.

How We Measure the Success of Our Work

The success of an accessibility project can be measured by several objective criteria. The WCAG conformance degree, the proportion of met success criteria, provides a clear indicator: the initial audit and the re-audit show for each success criterion what is met and what remains open. Open points can concern aspects not fully within the website operator's control, such as third-party widgets or CMS limitations.

Benchmarks of Our Audits

AA
target level under WCAG 2.2
WCAG-EM
W3C evaluation methodology
Annex C
determination of conformance per EN 301 549

Beyond normative conformance, accessibility optimization can also improve general website metrics: semantic HTML and clean code can positively affect rendering performance and thus Core Web Vitals. Improved forms, clearer navigation and a logical page structure can enhance the user experience for all visitors. The Lighthouse Accessibility Score is a helpful indicator here, not proof of conformance.

Your Project in a Confidential Conversation

We do not publish client names or project details. In a personal conversation we explain the approach, the structure of the audit report and the price range for your project. Contact us for a confidential conversation.

At a glance

WCAG 2.2 AA
EN 301 549
BFSG Section 14
BITV 2.0
PDF/UA · ISO 14289-1
axe-core · Playwright
Desktop · smartphone
PAC 2024

Frequently Asked Questions About Our Approach

What your accessible website could look like

Three layout drafts from sectors with particular accessibility requirements. They show structure and handling — the organisations in them are fictitious.

Draft
Municipal utility

Customer portal with self-service and plain language

A draft for a municipal utility portal: submitting a meter reading, adjusting the instalment and registering a move sit side by side as six short paths, and the form checks entries and places the error as text right next to the field. Reporting a fault is laid out in four steps, and the tariff comparison is a table with labelled rows and columns. Text size and plain language can be switched in the page header.

Plain languageText sizeForm validationFault reporting
Draft
University department

Department with degree filter and disability provisions

A draft for a university department: eight degree programmes can be filtered by qualification and study mode, each listing award, standard duration and entry requirements in the same order. The application is described in four steps, and a separate section covers disability provisions and the advisory service hours. On campus accessibility the draft names ramp gradient, hearing loop and tactile guidance — and what is missing.

Degree filterDisability provisionsCampus detailsSubtitles
Draft
Rehabilitation clinic

Rehab clinic with application path and verifiable details

A draft for a rehabilitation clinic: three departments can be switched through, and the path from the medical report through the application to the funding body up to the arrival day is set out in four steps. A week in the house is shown as a daily plan, alongside rooms, visiting hours and support for relatives. The accessibility section states door widths, lift dimensions and call systems instead of a blanket assurance.

DepartmentsApplication pathWeekly planVerifiable measurements

Illustrative layout drafts. The businesses shown are fictitious; these are not client projects.

What can we help you with?

One click is enough — everything after that is optional.

Tell us briefly about the project

Everything on this step is optional.

As shown in your browser, with or without https://.

When would you like to start? (optional)
Rough budget range (optional)

Optional — you are not committing to anything.

A few keywords are enough. If you write something, please use at least 5 characters.

How can we reach you?

We usually get back to you within one business day.

Your name or surname, at least 2 characters.

Only needed if you would like a call back.

The address our reply should go to, with @ and domain.

By submitting you consent to the processing of your details to handle this request. Details in our privacy policy.