Accessibility for websites, portals and applications
We make barriers reproducible, prioritise fixing them and re-test the corrections. Where a defined state needs a documented assessment, we agree the standard, the scope and the limits of the conclusion before we start.
For public bodies, universities and providers of services covered by the German Accessibility Strengthening Act. Digital projects since 2005.
Where you stand today and the outcome you need determine whether an audit, delivery work or a conformity assessment is the right next step.
Accessibility audit
We test an agreed scope, make the barriers reproducible and prioritise the findings as a basis for fixing them.
Delivery and re-test
We turn findings into tasks for editorial teams, design and development, support the corrections and re-test them in the agreed release.
Documented conformity assessment
We assess a clearly named state against the agreed standard and record the result, the scope it covers and the limits of what it says.
Accessibility audit
Before we begin we agree the requirements catalogue, its version and the target level, the legal or contractual basis, and the scope and method of testing. Representative page types, complete processes, components and states are tested manually with agreed browsers and assistive technologies. Suitable automated checks complement that work.
An audit makes sense when the extent of the problem is still unclear, when remediation or a relaunch is being prepared, or when one critical process needs targeted testing.
A sample-based audit describes the agreed scope. It is not a blanket conformity statement, not a user test and not legal advice.
Error message in the form
Status: Not met
Step 2 of the form, required field
The visible message is not announced reliably.
We help you place your particular case. This orientation does not replace legal advice.
For federal public bodies in Germany, the BGG and BITV 2.0 form the legal framework. For federal states, municipalities and public universities, the corresponding state regulations apply. We include complete administrative processes, reused components and decentralised editorial work when we set the scope.
The BFSG only covers products and services named in the law; not every company website falls under it. The organisation responsible establishes which legal or contractual requirements apply. Our view on the testing scope does not replace legal advice.
The process stays traceable so that business units, editorial teams, design and development can all work from the same findings.
Pages, processes, states, standard and test environment are agreed in writing.
Complete tasks and the relevant components are examined with assistive technologies and suitable tools.
Locations, impact and recommendations are prepared for the teams responsible.
An agreed re-test checks the documented changes in a named release.
The original report stays as it is. Every new tested state gets its own date, release and clearly named scope.
Checks named corrections and updates their status. It does not produce a new overall statement.
Checks the affected areas plus a documented regression sample when templates, components, processes or third-party services change.
Assesses the agreed scope again, for example after a relaunch, a change of CMS or design system, or a change to the standard applied.
New editorial content is not automatically covered by an earlier report. That needs ongoing quality assurance or a fresh sample.
We establish which corrections, releases and evidence matter for the next re-test.
Conformity assessment with a documented report
We assess a state defined in advance against the agreed standard. The outcome is open until the assessment is done. The report names the scope, the sample, the complete processes, the test environment, the result for each requirement, and the limits of any summarising statement.
This service is not a certification and carries no seal of approval. Where we contributed to the concept or the build, we disclose that earlier work and the roles involved in the report. If your case requires institutional independence or a particular testing or certification scheme, that has to be commissioned separately.
The report stands as documentation of the state that was assessed. It has no blanket expiry date, but it is not a promise about the current or future state either. Release, assessment date and scope must always be quoted alongside it. A sample on its own does not support a conformity statement for an entire website.
These examples show our role in concept work and delivery. An audit or a conformity assessment always needs its own project-specific report.
A university-wide Drupal platform and design system for many faculties and decentralised editorial teams.
We combined UX, the design system and Drupal development with digital accessibility requirements in both concept work and delivery.
User interviews, personas, user journeys, UX workshops and a design system for a public information service.
UX consulting and design treated accessibility as a design goal. The technical development was not carried out by us.
What is needed differs from case to case. We prepare the technical assessment results; publication, legal interpretation and keeping them up to date remain with the organisation responsible.
We prepare the testing method, the results, the known deviations and the alternatives. The feedback mechanism, the reference to the conciliation body and the regular or event-driven updates remain the responsibility of the body publishing the statement.
We can prepare assessment results for the information required about the service. Scope, publication and ongoing compliance remain the responsibility of the service provider.
This support is technical input, not legal advice.
On scope, what the results can tell you, and re-testing.