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.
EN 301 549
assessment basis
28 June 2025
BFSG obligation in force
€100,000
fine ceiling (BFSG §37)
50+
web projects supported
The proof runs before your eyes
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.
Remediation in existing code
- Barriers fixed in the existing code — design and CMS stay in place
- Semantic HTML, WAI-ARIA 1.2, keyboard operation and focus management
- Screen reader testing on NVDA, JAWS and VoiceOver included
- Concluded with a short audit and proof of WCAG 2.2 AA conformance
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.
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
A website is only accessible when it is usable with real screen readers. NVDA and JAWS on Windows and VoiceOver on macOS and iOS interpret HTML and ARIA differently. We test and optimize for all three platforms, ensuring content, navigation and interactive elements are correctly outputted and 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 rises to WCAG 2.2 AA level.
- 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
Accessible Component Development
Modern websites consist of reusable components: navigation, tabs, accordions, modals, dropdowns, carousels, tooltips and forms. Each component has specific accessibility requirements defined in the WAI-ARIA Authoring Practices 1.2 (Source: W3C WAI-ARIA Practices). 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 content must remain usable at 200 percent zoom without horizontal scrolling (1.4.10). 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.
Do not forget focus indicators
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 WCAG violations at commit time, long before they reach production — so a new barrier surfaces immediately, not only at the next review.
Automated plus manual
Responsive and Mobile Accessibility
Mobile accessibility poses additional requirements: touch target areas must be at least 24x24 CSS pixels per WCAG 2.5.8. VoiceOver on iOS and TalkBack on Android 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 test on real devices with screen readers enabled, not just browser emulators.
Tested with real screen readers
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 we manually test your retrofitted components with NVDA and JAWS on Windows and VoiceOver on macOS and iOS and listen to what is actually announced: are the role, name and state of each element correct? Only when navigation, forms and status messages are output coherently on all three platforms do we consider a component done.
- Testing on real devices, not just the emulator
- Role, name and state of every interactive element checked
- Output reconciled across NVDA, JAWS and VoiceOver
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
Detect route change
The router signals the change. This is where focus management takes over, instead of relying on the native page load.
- 2
Update page title
The document.title is set to the new content so screen readers and history correctly reflect the context.
- 3
Set focus
Focus jumps to the new main content (or an h1) so keyboard navigation continues at the right point.
- 4
Announce the change
An ARIA live region (aria-live="polite") reports the new page context without abruptly interrupting the reading flow.
| Status message | ARIA mechanism | Behavior |
|---|---|---|
| Loading | role="status" | polite, does not interrupt |
| Success message | aria-live="polite" | informs after current reading flow |
| Error message | role="alert" / aria-live="assertive" | immediate, interrupts |
| Form validation | aria-invalid + aria-describedby | field 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 prove WCAG 2.2 AA conformance — no rebuild, at a fixed price after review.
Design Systems with Accessibility as a Core Principle
If your company uses a design system or component library, integrating accessibility at this level is the most efficient approach. Correctly implemented accessible components are automatically accessible in 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 significantly reduces 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 go hand in hand. Clean, semantically correct code is easier to parse, easier to cache and generates fewer reflows in the browser. Correct heading hierarchies and landmarks reduce complex CSS selectors and JavaScript-based layout adjustments, and avoiding ARIA workarounds in favor of native HTML elements shrinks the JavaScript payload.
LCP
Largest Contentful Paint benefits from optimized images with correct dimension attributes, which are also relevant for alt texts.
CLS
Cumulative Layout Shift improves through correct image sizes and stable layouts that simultaneously meet 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 always optimize websites holistically: accessibility and performance as a shared goal, not 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 with transcripts for NVDA and VoiceOver, 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 develop better code: cleaner, more semantic, more maintainable and more performant. The investment in accessible development competence pays off over years as it improves not just accessibility but the entire technical quality of every project. Contact us to discuss the accessible overhaul of your existing website.
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 cover 30 to 50 percent of barriers (WebAIM 2024) — we check the rest manually
- Tested on real devices with NVDA, JAWS and VoiceOver, the target is WCAG 2.2 AA
- The proof: this website itself meets WCAG 2.2 AA — see our accessibility statement