Skip to content

Accessible web development: make your existing code WCAG 2.2 AA compliant

We make your existing website accessible within its current code — semantic HTML, ARIA, keyboard operation and screen reader support retrofitted instead of a costly rebuild. Remediation in existing code from €2,480 net, target conformance WCAG 2.2 AA.

Request a free initial consultation To the WCAG audit
Existing code, no rebuild WCAG 2.2 AA Own accessibility statement published Remediation from €2,480

In short and in plain language

This page is about your website. We make it accessible. Accessible means that all people can use it. This includes people with disabilities.

In most cases, your site does not need a rebuild. We fix the code you already have. Your design and content stay.

People should be able to use the site with a keyboard. Screen readers should read it well. We adjust colours so that text is easy to see.

If a fix is not worth it, a new build is also possible. We decide this with you after we look at your code. At the end, we check the result.

Do you have questions? The first talk is free. Write to us or give us a call.

Key figures

EN 301 549

assessment basis

28 June 2025

BFSG obligation in force

€100,000

fine ceiling (BFSG §37)

WCAG 2.2 AA

remediation target level

Our own status, openly documented

We assess our own website against WCAG 2.2 AA ourselves; status and known limitations are set out in our accessibility statement. We apply accessible web development where it counts: in real, shipped production code. Since 28 June 2025 digital accessibility has been mandatory for many providers (BFSG); violations can lead to official orders and fines of up to €100,000 (BFSG §37).

Not every website needs to be rebuilt to become accessible. In most cases the barriers sit in the markup, in missing ARIA, in keyboard handling and in colour values — all of which can be corrected in the existing code. We make your existing website accessible within its current system: fix semantic HTML, add correct ARIA, establish keyboard operation and focus management, and raise contrasts to WCAG level. Your existing design, content and content management system stay in place. Where retrofitting is no longer economical, we alternatively support an accessible rebuild — a decision we make together after reviewing the code. We also empower your team through code reviews, training and accessible component libraries.

Accessibility from the ground up · retrofit in existing code
Five layers on the way to WCAG 2.2 AA
Retrofitted in the existing code — no rebuild, each layer tested individually
1
Semantic HTML
Landmarks header/nav/main/footer, clean heading hierarchy
1.3.1
2
ARIA roles & states
Names and roles added where native HTML is not enough
4.1.2
3
Colour contrast
Raised from 2.1 : 1 to 8.4 : 1 — without losing the design
1.4.3
4
Visible focus & keyboard
Focus indicator restored, logical keyboard path
2.4.7
5
Screen reader output
Cross-check of keyboard and screen reader output, desktop and smartphone
4.1.3
Concluded with a short audit after implementationTarget: AA across all 4 principles
Remediation in existing codefrom €2,480
Target conformanceWCAG 2.2 AA
Five layers of remediation in the existing code, no rebuild — each with a related WCAG success criterion. Example view — values are illustrative.

Remediation in existing code

from €2,480 net · up to 15 pages
  • Barriers fixed in the existing code — design and CMS stay in place
  • Semantic HTML, WAI-ARIA 1.2, keyboard operation and focus management
  • Keyboard and screen reader output checks included
  • Concluded with a short audit and a documented status against WCAG 2.2 AA
Request a free initial consultation To the WCAG audit

Fixed quote after a brief review of your code. Larger scope as an SME complete package from €4,900 net. A full accessible rebuild is also available from €4,900 when it is technically more sensible than retrofitting.

Prices as of October 2026.

The Pillars of Accessible Web Development

Whether a rebuild or retrofitting in existing code — accessible web development rests on four technical pillars that work together to make a website accessible to all users. Each pillar addresses specific user needs and is essential for conformance with WCAG 2.2 AA.

Semantic HTML

Correct use of HTML5 elements is the foundation of every accessible website. Headings (h1-h6) form a logical hierarchy, landmarks (header, nav, main, aside, footer) enable quick navigation, lists (ul, ol, dl) structure enumerations and forms use correct label-for associations. Screen readers use this semantics to give users an overview of page structure and enable efficient navigation.

WAI-ARIA 1.2

Where native HTML is insufficient, ARIA supplements the missing semantics. Roles (role="tablist", role="dialog"), states (aria-expanded, aria-selected) and properties (aria-label, aria-describedby) make interactive widgets understandable for assistive technologies. Important: ARIA is a supplementary tool, not a replacement for semantic HTML. The first rule of ARIA: do not use ARIA if a native HTML element can do the job (Source: W3C WAI).

Keyboard Navigation

All interactive elements must be reachable and operable via keyboard (WCAG 2.1.1). Tab order must match the visual reading order. Focus indicators must be visible with sufficient contrast. Modal dialogs must correctly trap focus and reset it to the triggering element on close. Dropdown menus must be navigable via arrow keys.

Screen Reader Compatibility

Screen readers can only output what the page passes on to them. Screen readers on Windows, macOS and iOS interpret HTML and ARIA partly differently; their common basis is what the browser passes on to the accessibility interface. We check and optimize this output so that content, navigation and interactive elements are passed on with name, role and state and are operable.

Retrofit in existing code instead of a costly rebuild

Accessible without restarting the project

An existing website does not need to be rebuilt to be accessible. In most cases the barriers sit in markup, ARIA, focus management and colour values — all correctable in the existing code. We work in your production codebase, keep the design and feature scope and raise conformance in a targeted way instead of starting over. This preserves the investment in your current website while accessibility is improved step by step towards WCAG 2.2 AA.

  • Remediation in existing code from €2,480 net (up to 15 pages)
  • No rebuild: existing design and CMS stay in place
  • Full accessible rebuild only when more sensible — from €4,900
Relative effort per path to conformance (schematic)existing code cheaper
RemediationOngoing patchRebuild
Remediation in existing codefrom €2,480up to 15 pages, net
Complete rebuildfrom €4,900only when it makes more sense

Accessible Component Development

Modern websites consist of reusable components: navigation, tabs, accordions, modals, dropdowns, carousels, tooltips and forms. Each component has specific accessibility requirements described in the W3C's ARIA Authoring Practices Guide (Source: W3C WAI). We correct these components directly in your existing code or develop them anew so they implement the patterns correctly and fit seamlessly into your design system.

Navigation and Menus

Accessible main navigation with correct role="navigation", aria-label and keyboard submenu support (arrow keys, Enter, Escape). Mobile hamburger menus with aria-expanded and correct focus management on open and close.

Tabs and Accordions

Implementation per WAI-ARIA Authoring Practices: tabs with role="tablist"/"tab"/"tabpanel", arrow key navigation and automatic focus management. Accordions with aria-expanded, aria-controls and correct heading semantics.

Modal Dialogs

Modals with role="dialog", aria-modal="true", correct focus trap keeping tab focus within the modal, closing via Escape key and focus reset to the triggering element after closing.

Autocomplete and Comboboxes

Search fields with autocomplete as role="combobox" with aria-expanded, aria-activedescendant and role="listbox" for the suggestion list. Arrow key navigation through suggestions and ARIA live announcement of result count.

Dynamic Status Messages

ARIA live regions (aria-live="polite" or "assertive") for status messages, form validation, loading progress and notifications. Correct use of role="alert", role="status" and role="log" depending on urgency and context.

Forms and Validation

Accessible forms with visible labels, aria-required for mandatory fields, aria-invalid and aria-describedby for error messages, grouping related fields with fieldset/legend and meaningful error texts with correction hints.

Color Contrasts and Visual Accessibility

Contrast is measurable, not a matter of taste

Colour values at WCAG level without losing the design

WCAG 2.2 requires a minimum contrast of 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold, success criterion 1.4.3). Information must not be conveyed by colour alone (1.4.1), text spacing must be adjustable (1.4.12) and text must be resizable up to 200 percent without loss of content or functionality (1.4.4). When retrofitting we adjust the colour values of your existing palette so these ratios are met while the visual character of your brand is preserved.

Too little contrast
Light grey text on white2.1 : 1below 4.5 : 1
Sufficient contrast
Legible text on white8.4 : 1AA met
WCAG thresholds 1.4.3 and 1.4.11 (Level AA)
Normal text≥ 4.5 : 1
Large text from 18 pt≥ 3 : 1
Controls & focus≥ 3 : 1

Do not forget focus indicators

Special attention is required for focus indicators, form error states and interactive elements in the hover, active and disabled states. Every state must have sufficient contrast, and focus indicators must remain visible even on complex backgrounds.

Automated Accessibility Testing in CI/CD

To keep the accessibility you have established, we embed checks in the development process rather than in a downstream step. Automated tests in your CI/CD pipeline detect automatically testable WCAG violations at commit time, long before they reach production — so such barriers surface immediately, not only at the next review.

Accessibility as part of development
Every commit is checked automatically
Commit
Automated check
Manual notes
Merge approved
94 %
Automated check52 rules checked49 passed3 manual notes
Checks in the commit
Semantic landmarks present
All form fields labelled
Logical tab order
Contrast: 2 colour pairs for visual review
Violations caughtalready at commit
Automatically detectablenot everything (WebAIM 2026)
Accessibility tests run with every commit — violations are caught before they go live. Example view — values are illustrative.

Measurement plus assessment

Automated tests detect new barriers immediately but do not replace the assessment of every criterion: not all conformance failures can be detected automatically (WebAIM Million 2026). That is why we combine pipeline tests with regular WCAG 2.2 audits.

Responsive and Mobile Accessibility

Mobile accessibility poses additional requirements: touch target areas must be at least 24x24 CSS pixels per WCAG 2.5.8. Mobile screen readers interpret HTML and ARIA partly differently than desktop screen readers. Gesture-based navigation (swiping, rotating) must be available for users with accessibility features enabled. We also check every view in the smartphone layout, including target sizes and reflow.

What screen readers can announce

What the screen reader announces is what counts

A passing automated result does not yet mean a page is usable with a screen reader. That is why for every retrofitted component we check what it passes on to screen readers: are the role, name and state of each element correct? Only when navigation, forms and status messages are passed on coherently in the desktop and smartphone layout do we consider a component done.

  • Desktop and smartphone layouts checked
  • Role, name and state of every interactive element checked
  • Name, role and state documented per element
Focus
Sign in
Email address
Sign in
Screen reader output
Main navigation, list with 4 items
Email address, input field, required
Sign in, button
Name, role, stateDesktop · smartphone

Responsive design and accessibility overlap in several areas. The reflow requirement (WCAG 1.4.10) demands that content at 400 percent zoom (equivalent to 320 CSS pixel viewport width) remains usable without horizontal scrolling. Mobile-first development with flexible layouts typically fulfills this requirement automatically. Additionally, touch event handlers must also support keyboard interactions, and hover effects need touch equivalents for mobile users.

Using Frameworks and Libraries Accessibly

Modern web applications are built on JavaScript frameworks like React, Vue, Angular or Svelte. These frameworks bring their own accessibility challenges: client-side routing interrupts the natural page navigation of screen readers, dynamically rendered content may not be detected by assistive technologies, and virtual DOM implementations can complicate focus management.

We know the accessibility-relevant specifics of common frameworks and how to correctly address them in existing code. Regardless of framework: client-side routing must update the page title and correctly set focus, dynamic content must be announced via ARIA live regions and state changes must be communicated to assistive technologies. We make these adjustments in a targeted way within your existing application, without overturning the architecture.

Making Single-Page Applications Accessible

Single-page applications (SPAs) replace the traditional page-load model with client-side routing. When a user clicks a link, no new page is loaded; instead content is dynamically replaced. Screen readers do not detect this change automatically: blind users do not know that content has changed. The solution is active focus management on every route change.

  1. 1

    Detect route change

    The router signals the change. This is where focus management takes over, instead of relying on the native page load.

  2. 2

    Update page title

    The document.title is set to the new content so screen readers and history correctly reflect the context.

  3. 3

    Set focus

    Focus jumps to the new main content (or an h1) so keyboard navigation continues at the right point.

  4. 4

    Announce the change

    An ARIA live region (aria-live="polite") reports the new page context without abruptly interrupting the reading flow.

Status messageARIA mechanismBehavior
Loadingrole="status"polite, does not interrupt
Success messagearia-live="polite"informs after current reading flow
Error messagerole="alert" / aria-live="assertive"immediate, interrupts
Form validationaria-invalid + aria-describedbyfield and error text linked

These patterns require a systematic concept for the status message architecture of the entire application, not just point fixes.

Make your existing website accessible

We review your code, fix the barriers in the existing system and document the resulting status against WCAG 2.2 AA — no rebuild, at a fixed price after review.

Request a free initial consultation Call now: +49 5123 9579000

Design Systems with Accessibility as a Core Principle

If your company uses a design system or component library, integrating accessibility at this level is usually the most efficient approach. Correctly implemented accessible components carry their keyboard operation, roles and states into every instance without developers manually adding ARIA attributes at each use. We support the development of accessible component libraries that correctly implement WAI-ARIA Authoring Practices: tabs with automatic focus management, modals with correct focus trapping, dropdown menus with arrow key navigation and forms with programmatically linked validation.

An accessible design system documents for each component not just visual specifications (colors, spacing, typography) but also accessibility requirements: which ARIA roles and attributes are required, how keyboard interaction works, what screen reader output is expected and which variants are available for different contexts. Long-term an accessible design system can significantly reduce costs for accessibility audits and remediations as systemic issues are fixed at a central point.

Performance and Accessibility: Two Sides of One Coin

Accessible web development and performance optimization often go hand in hand. Native HTML elements already come with semantics and keyboard operation; avoiding ARIA workarounds in favor of native elements often shrinks the JavaScript payload as well.

LCP

Largest Contentful Paint benefits from optimized images; when the image elements are reworked anyway, suitable alt texts can be added in the same step.

CLS

Cumulative Layout Shift improves through correct image sizes and stable layouts; a flexible layout also helps with the WCAG 1.4.10 reflow requirement.

INP

Interaction to Next Paint improves through efficient event handlers that correctly process both mouse and keyboard events.

We therefore treat accessibility and performance as a shared goal, not as competing requirements.

Documentation and Knowledge Transfer

Accessible web development requires specialized knowledge that must be shared within the team. That is why we place great emphasis on documentation and knowledge transfer. For every accessible component we correct in the existing code or develop anew, we create documentation covering: ARIA roles and attributes with explanations, expected keyboard behavior with an overview of all supported keys, expected screen reader output: name, role and state, visual specifications for focus indicators and contrast ratios and component variants and states.

Accessible web development is not a restriction of creative or technical possibilities but an expansion of quality standards. Teams that understand accessibility as a natural part of their craft usually develop better code: cleaner, more semantic and more maintainable. The investment in accessible development competence can pay off over years as it often improves not just accessibility but the overall technical quality of a project. Contact us to discuss the accessible overhaul of your existing website.

Technical depth on common problem areas

We have described three topics that come up frequently in remediation in detail: keyboard navigation in web development as the basis of all operability, ARIA roles, states and live regions for dynamic components, and focus management in single-page apps, where framework routing regularly loses the focus. Which priorities apply in your field is set out in the overview accessibility by industry.

Key takeaways

  • Accessible web development as remediation in your existing code — no rebuild, from €2,480 net (up to 15 pages)
  • Four pillars: semantic HTML, WAI-ARIA 1.2, keyboard operation and screen reader compatibility
  • Automated tests in the CI/CD pipeline do not detect all conformance failures (WebAIM Million 2026) — we assess the rest per criterion
  • Keyboard and screen reader output checked, in the desktop and smartphone layout, the target is WCAG 2.2 AA
  • We assess our own website against WCAG 2.2 AA ourselves; status and known limitations are set out in our accessibility statement

Frequently Asked Questions About Accessible Web Development

How the customer portal of a municipal utility could look

The draft shows structure and handling: short paths to meter reading and instalment, a form naming the error at the field, plain language and text size in the header. The utility in it is invented.

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

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.