Digital accessibility for websites and apps

We support companies in implementing digital accessibility – from initial testing and prioritization to UX/UI and front-end measures, training and verifiability. The goal is not “checkbox compliance”, but noticeably better usability: clear content, robust technology, simple operation – and a setup that works in the long term.

Where does your company stand?

Perhaps you recognize yourself in one (or more) of these points:

Digital accessibility was “considered”, but never systematically checked (no audit, no evidence)
Design system/components are not consistently barrier-free (contrast, focus, states, labels)
Content has a strong editorial structure but is not barrier-free (headings, lists, alternative texts)
Forms/checkouts have high abandonment rates, especially on mobile or with assistive tech
There is uncertainty as to what the BFSG actually requires and who is responsible
Accessibility bugs are found late (or not at all) – no tests in CI/CD, no “Definition of Done”

Our team will be happy to support you ↓

Success factors for digital accessibility

Accessibility needs clear responsibilities

Product Owner, UX, Dev, QA, Content, Legal/Compliance. Each role has specific tasks and criteria.

“Shift left” instead of reworking

Digital accessibility is ensured during design and development (design tokens, components, guidelines), not just shortly before go-live.

Standards & verifiability

Orientation towards WCAG 2.1/2.2 (AA) or EN 301 549 as a practical reference. Results are documented (audit, action plan, test protocols).

Technology + Content + Process

Accessibility rarely fails just because of the code. Frequent causes: unclear content processes, missing templates, no release criteria.

Measurable & prioritized

Not every deviation is equally critical. We prioritize according to user impact, legal risk and effort (quick wins vs. structural issues).

Goal

A website or app that is demonstrably more accessible (depending on the use case), fulfills legal requirements (BFSG), converts better and is set up internally in such a way that digital accessibility is permanently maintained – even with releases, new content and new features.

Procedure

We implement accessibility projects in phases that build on each other – professionally (UX/content) and technically (frontend/QA) coordinated. Depending on the initial situation, we start lean (quick check) and scale up to full implementation.

1. understanding the status quo (scope & BFSG relevance)

Together we clarify: Which digital services are affected? Which user groups? Which critical journeys (e.g. login, checkout, appointment booking)? What risks since the introduction of the BFSG (28.06.2025)?
Result: Scope, prioritized journeys/pages, initial risk & gap assessment, roadmap (quick wins & next steps).

2. accessibility audit (design, code, content)

We test with a mix of automated checks, manual reviews and screen reader/keyboard tests (e.g. NVDA/JAWS/VoiceOver). Focus: real use, not just tool scores.
Result: Audit report with findings, WCAG/EN references, severity, specific fix recommendations, action backlog.

3. target image & implementation logic (standards, patterns, DoD)

We define how digital accessibility is “done” for you: Design system rules, component standards (e.g. dialogs, menus, forms), content guidelines, definition of done and test criteria.
Result: agreed target image (guidelines/patterns), implementation plan, responsibilities, quality criteria.

4. implementation (remediation) & enablement

We fix prioritized barriers in design and code (e.g. focus guidance, semantics/ARIA, contrasts, error messages, captcha alternatives, PDF/document topics if relevant) and empower teams through pairing, reviews and training.
Result: implemented fixes in the critical journeys, updated components/templates, trained teams.

5. quality assurance, operation & verifiability

We anchor tests in your processes: Accessibility tests in CI/CD, regression checks, editorial test routines, monitoring. Optional: Preparation of declarations/information on digital accessibility and internal documentation (depending on requirements).
Result: Test & release process, governance setup, regular reports, sustainable compliance capability.

Our team will be happy to answer your questions ↓

Titelbild zum Projekt "RWS Cateringservice: Individuallösung zur Abbildung des Kernprozesses"

Development of a user-friendly portal and app solution for managing meal orders for kindergartens, schools and retirement homes.

Details RWS project →

Development of a mobile app that helps users to find suitable sanitary facilities in their area quickly and easily.

health-covery.com →

Michael Berger, UX/UI Designer, will be happy to advise you.

michael.berger@singular-it.de

+49 341 9785210

FAQ – Frequently asked questions

In this FAQ section, we answer the most frequently asked questions about accessibility for websites and applications.

What exactly does accessibility mean for websites and apps?

Digital accessibility means that content and functions are accessible to all people – e.g. via keyboard, screen reader (VoiceOver/TalkBack), with magnification, with impaired vision or cognitive limitations. This includes, among other things, a clear structure, sufficient

Which accessibility standards are relevant (WCAG, EN 301 549, BITV)?

In practice, accessibility is usually based on the WCAG criteria. For many organizations – especially in the public sector – additional requirements such as EN 301 549 are relevant; in Germany, the BITV also plays a central role in projects. Which standards apply in individual cases depends on the offering, target groups and context.

Does digital accessibility only apply to public bodies?

No. Medium-sized companies also benefit greatly (better UX, greater reach, fewer abandonments). In addition, the expectations of customers, partners and employees are increasing – and depending on the industry/application, requirements can also become relevant for private providers (e.g. for customer-critical self-service routes).

Website, app, portal, PDF: What needs to be accessible?

Accessibility should be considered along the entire user journey: Website/portal, mobile app, forms, emails as well as documents (e.g. PDFs) and media (videos with subtitles/transcripts). Barriers often arise precisely at the transitions between these touchpoints.

How long does it take to make a website or app accessible?

This depends on the scope, number of templates/components, technical stack and amount of content. Initial quick wins are often possible in just a few weeks (e.g. contrasts, focus guidance, forms). A complete implementation usually takes place iteratively – along the most important user paths and components.

What does accessibility cost for websites and apps?

The costs are mainly influenced by: Number of page templates, maturity level of the design system, quality of the front end or app architecture, quantity of documents/media and desired target level. A brief assessment typically quickly clarifies the effort, priorities and budget.

Is an automatic accessibility check (tool/score) sufficient?

No. Tools are helpful, but they do not find all critical problems (e.g. meaningful screen reader output, focus sequence, comprehensibility of error messages). Reliable results are achieved through a combination of automated checks, manual tests and clear acceptance criteria.

How do you test the accessibility of websites and apps in a meaningful way?

Typical quick improvements are: visible focus, correct labels in forms, more comprehensible error messages, better contrasts, clean headline structure, meaningful link texts and alt texts for relevant images.

How do we ensure that accessibility is maintained after go-live?

Through process integration: Definition of Done, QA gates in releases, recurring checks, training for editorial/UX/development, as well as accessible components in the design system. In this way, accessibility becomes part of normal product operation instead of a one-off project.

What role does a design system play in accessibility?

An accessible design system is one of the biggest levers: if central components (forms, navigation, dialogs, tables) are implemented correctly, all products and pages benefit automatically. This reduces rework, accelerates projects and prevents “regressions” with new releases.

Does accessibility also improve SEO?

Often yes – indirectly. Structured content, clean semantics, clear headings, good link texts and better usability help search engines to understand content and improve the user experience. Accessibility does not replace an SEO strategy, but often creates the technical and structural basis for it.