Accessibility training: Your team as the strongest barrier against barriers

We offer various training formats aligned to your team size, existing knowledge level and specific project requirements. Every training course is individually tailored to your technology stack and workflows.

Our developer training is the most comprehensive and technically deep course in our program. It targets frontend developers, fullstack developers and QA engineers who develop and test accessible web applications. The training teaches not only WCAG criteria theory but shows through concrete code examples how accessible components are implemented in practice.

A central component of the developer training is hands-on work with screen readers. Every participant learns to install NVDA, use basic navigation commands and experience their own website from a screen reader user's perspective. This experience is often the decisive moment that motivates developers to take accessibility seriously: when you experience firsthand how frustrating a website without correct semantics and ARIA is, your attitude changes permanently.

Accessible design does not mean making visual compromises. On the contrary: accessibility requirements like sufficient contrasts, clear information hierarchies and consistent interaction patterns lead to better designs for all users. Our designer training shows how to seamlessly integrate accessibility into the design process without restricting creative freedom.

The training covers accessible color palette creation with tools like the Colour Contrast Analyser and Figma plugins, designing focus indicators that are both functional and aesthetic, touch target sizes and spacing for mobile interfaces, accessible typography with adjustable text sizes and line spacing, and structuring content for different display sizes and zoom levels.

The best technical accessibility is useless if the content itself is not accessible. Missing or meaningless alt texts, missing heading hierarchy, incomprehensible language and non-accessible documents are common content barriers that can only be avoided by trained editors. Our content training provides practical knowledge immediately applicable in your CMS.

Participants learn how to write descriptive alt texts that meaningfully convey image content to screen reader users. How to use a logical heading hierarchy that enables structured navigation for screen readers. How to use plain language and clearly formulate complex topics. How to create accessible tables and lists. And how to provide multimedia content with captions and transcripts. All exercises take place directly in your company's CMS so participants can immediately apply what they learn.

Our training materials are regularly updated to account for new WCAG techniques, current browser changes and developments in assistive technologies. This ensures that the content delivered always reflects the current state of technology and your team is equipped with up-to-date knowledge.

Every training concludes with a feedback round and handover of all materials as a digital reference guide. On request, we offer follow-up sessions where we clarify open questions and accompany the knowledge transfer into practice.

The cost of retroactively fixing accessibility issues increases with every phase of the development process. A contrast problem that a designer catches in the design phase is fixed in seconds: a color value change. The same problem in production requires a design review, code change, testing and deployment. Multiplying these additional costs by the number of barriers typically occurring in a project (we identify an average of 80 to 150 individual findings per audit) makes clear why training is the most cost-effective accessibility measure: it prevents problems before they arise (project experience).

Our experience shows that teams that have completed an accessibility training produce 40 to 60 percent fewer barriers in subsequent audits than before. The greatest improvement appears in the most common barrier types: missing alt texts, insufficient contrasts, missing form labels and poor keyboard navigation. These four categories account for over 70 percent of all audit findings and are almost completely avoided after training (project experience). The training investment therefore typically pays for itself within the first project after training.

A single training course conveys the basics but sustainable knowledge is built through regular application and deepening. That is why we offer long-term accompaniment complementing our workshops: monthly office hours for technical questions, code reviews for critical components and semi-annual refresher sessions where we teach new developments (updated WCAG criteria, new browser features, improved testing methods). This model ensures accessibility knowledge in your team does not stagnate but continuously evolves.

For larger companies we recommend establishing an internal accessibility community: a group of interested developers, designers and editors who regularly exchange knowledge, learn from each other and serve as accessibility contacts in their respective teams. We support building this community, regularly provide current topics and best practices and moderate the first meetings. Experience shows that such a community develops its own momentum after six to twelve months, sustainably changing the accessibility culture in the company.

Generic accessibility training conducted identically in every context dissipates in practice. Our approach is different: before every training we conduct a briefing conversation capturing the technology used, existing code structure and your team's specific challenges. Training content is then individually adapted: for a team working with Shopware Community Edition we show accessibility optimizations directly in Twig templates and Shopware plugins. For a React team we demonstrate accessible component development with specific React hooks and patterns. For a content team we create exercises directly in your CMS so participants immediately experience the transfer to their daily work.

To make the success of our training measurable, we offer optional before-after comparisons: before training we conduct a brief baseline audit of a representative page. After training your team independently creates a new page or reworks an existing one. We audit the result and compare accessibility quality. This comparison concretely shows what improvements the training achieved and identifies areas where deepening is sensible. In practice we typically observe a reduction of audit findings by 40 to 60 percent after comprehensive training (project experience).

Additionally after every training we provide a compact accessibility checklist that your team can use as a daily work tool. The checklist contains the most important checkpoints for each area of responsibility: developers check semantics, ARIA and keyboard navigation, designers check contrasts, focus indicators and touch target sizes, editors check alt texts, headings and language clarity. This checklist is individually created for your technology and most common content types and can be directly integrated into existing quality assurance processes.

Accessibility training achieves its full impact only when the knowledge conveyed is integrated into existing processes and quality standards. That is why we recommend connecting training with concrete process adjustments: supplementing the code review checklist with accessibility criteria, integrating automated axe-core tests into the CI/CD pipeline, including accessibility checks in acceptance processes for new features and defining accessibility requirements as a fixed part of the specification for new projects.

For the design area we recommend extending the design system with accessibility specifications: contrast ratios as mandatory components of every color definition, touch target sizes as minimum specifications for interactive elements, focus indicator styles as documented standards and screen reader output annotations as part of every component documentation. These structural anchors ensure accessibility does not depend on the goodwill of individual team members but is systematically integrated into every work step. Our training courses convey not just the expertise but also the methods to successfully implement this process integration.

In the content area we recommend creating editorial guidelines that bindingly specify accessibility requirements: minimum requirements for alt texts (descriptive, not just filenames), specifications for heading hierarchy, rules for link labeling (not just generic click here) and standards for creating accessible tables and lists. These guidelines are directly integrated into your CMS workflows so editors are automatically reminded of accessibility requirements during content creation.