Barrierefreies Webdesign beauftragen: Wichtige Fragen vorab

Stellen Sie sich vor, Sie laden zu einer großen Party ein, aber die Hälfte der Gäste kommt nicht durch die Tür, weil die Stufe zu hoch ist oder die Einladung in einer Sprache verfasst wurde, die niemand versteht. Ziemlich frustrierend, oder?

Im Web ist das nicht anders. Eine Website, die nicht barrierefrei ist, schließt Menschen aus. Barrierefreies Webdesign wird oft zu spät, zu oberflächlich oder mit falschen Erwartungen angegangen. Entweder heißt es »Das machen wir später auch noch« – oder »Unser Theme ist barrierefrei, passt schon«. Beides führt in der Praxis regelmäßig zu Problemen: rechtlich, technisch und finanziell. Dabei ist das Thema seit dem Barrierefreiheitsstärkungsgesetz (BFSG) für viele Unternehmen nicht mehr nur eine Frage der Ethik, sondern eine gesetzliche Pflicht.

Damit Ihr Projekt »Barrierefreiheit« nicht im digitalen Graben landet, sollten Sie Ihrer Agentur oder Ihren Freelancern vorab auf den Zahn fühlen. Hier sind die wichtigsten Fragen.

»Barrierefrei« ist kein geschützter Begriff. Damit Sie am Ende keine böse Überraschung erleben, müssen Sie konkret werden.

• Frage: »Arbeiten Sie strikt nach den WCAG 2.1 (oder 2.2) auf Level AA?«
• Hintergrund: Die Web Content Accessibility Guidelines (WCAG) sind der weltweite Industriestandard. In Europa ist die Norm EN 301 549 relevant, die auf den WCAG aufbaut. Wer hier nur mit den Achseln zuckt, hat das Thema vermutlich noch nicht ganz durchdrungen.

Ohne diesen Bezug gibt es keinen klaren Maßstab, an dem gemessen werden kann, ob die Leistung korrekt erbracht wurde. Nach deutschem Werkvertragsrecht (§ 633 BGB) liegt ein Sachmangel vor, wenn das Werk nicht die vereinbarte Beschaffenheit hat. Die vereinbarte Beschaffenheit ergibt sich aus dem Vertrag bzw. Angebot. Steht dort zum Beispiel »Umsetzung gemäß WCAG 2.2 AA« und ein späterer Test zeigt klare Verstöße gegen definierte Erfolgskriterien (zum Beispiel fehlende Tastaturbedienbarkeit oder unzureichende Kontraste), gibt es gegebenenfalls eine rechtliche Grundlage für eine Nachbesserung. Ohne diese explizite Vereinbarung wird es schwierig bis unmöglich, Ansprüche durchzusetzen.

Ein automatisches Testing-Tool (wie Lighthouse, Wave oder Axe) ist ein guter Anfang, aber es findet nur etwa 30 bis 40 % der Fehler.

• Frage: »Nutzen Sie neben automatisierten Tools auch manuelle Tests mit Screenreadern und Tastaturnavigation?«
• Hintergrund: Automatisierte Tests finden vor allem formale, maschinenlesbare Probleme – etwa fehlende alt-Attribute, unzureichende Kontraste oder fehlerhafte ARIA-Rollen. Was sie kaum erkennen, sind reale Nutzungsprobleme: unklare Fokusreihenfolgen, unlogische Überschriftenstrukturen, schlecht verständliche Linktexte, nicht bedienbare Custom-Widgets oder Formulare, die zwar technisch valide, praktisch aber unbenutzbar sind.

Die WCAG schreiben keine Testmethoden vor, enthalten aber zahlreiche Erfolgskriterien, deren Erfüllung nur durch manuelle Prüfung zuverlässig bewertet werden kann. Typische Beispiele sind:

• 1.1.1 Nicht-Text-Inhalte (Ist der Alt-Text sinnvoll?)
• 2.4.4 Linkzweck (im Kontext)
• 2.4.6 Überschriften und Beschriftungen
• 3.3.2 Beschriftungen oder Anweisungen
• 1.3.1 Info und Beziehungen (inhaltliche Struktur)

Hier kann ein Tool höchstens Hinweise liefern, nicht bewerten, ob das Kriterium erfüllt ist. Wer sich auf »automatische Tests reichen aus« beruft, verkennt den Kern von Barrierefreiheit: Sie ist keine rein technische Eigenschaft, sondern eine Frage realer Nutzbarkeit.

Barrierefreiheit ist kein einzelner Arbeitsschritt, sondern ein durchgängiger Prozess. Sie beginnt bei Struktur und Konzept, setzt sich im Design fort und muss im Code und in den Inhalten konsequent umgesetzt werden. Wenn eine dieser Ebenen fehlt, entstehen zwangsläufig Barrieren.

• Frage: »Ist das Designteam für barrierefreies UI/UX geschult, oder wird die Barrierefreiheit erst nachträglich vom Development drübergebügelt?«
• Hintergrund: Nachträgliche Korrekturen sind teurer und oft nur unzureichende Flicken. Barrierefreiheit muss von der ersten Skizze an Teil des Konzepts sein.

Viele Barrieren entstehen nicht im Code, sondern deutlich früher: durch unklare Seitenstrukturen, fehlende Hierarchien, zu geringe Kontraste, ungeeignete Schriftgrößen oder visuelle Interaktionen, die ohne Maus nicht funktionieren. Diese Probleme lassen sich später nur eingeschränkt oder gar nicht sauber beheben.

Wird Barrierefreiheit erst in der Entwicklungsphase berücksichtigt, bleiben dem Development oft nur technische Workarounds (zum Beispiel zusätzliche ARIA-Attribute), die grundlegende konzeptionelle oder gestalterische Mängel nicht ausgleichen können. Das Ergebnis wirkt formal korrekt, ist aber für Menschen weiterhin schwer bedienbar.

Ein professioneller Anbieter kann erklären, wann und wie Barrierefreiheit über den Prozess berücksichtigt werden.

Selbst ein perfekt barrierefreies Template verliert seinen Wert, wenn Inhalte ohne Grundwissen zu Barrierefreiheit eingestellt werden.

• Frage: »Bieten Sie eine Schulung für unser Content-Team an, damit die Website auch nach dem Go-Live barrierefrei bleibt?«
• Hintergrund: Viele Barrieren entstehen durch redaktionelle Arbeit.

Technik und Design können vieles absichern – sie können aber nicht verhindern, dass Barrieren durch redaktionelle Arbeit neu entstehen. Viele WCAG-relevante Barrieren entstehen nicht im Code, sondern im Alltag der Redaktion: fehlende oder ungeeignete Alternativtexte, unstrukturierte Überschriften, nicht barrierefreie PDFs, unklare Linktexte oder eingebettete Medien ohne Untertitel. Diese Punkte lassen sich technisch nur begrenzt absichern.

Seriöse Anbieter benennen klar, welche Inhalte in der Verantwortung der Redaktion liegen, stellen praxisnahe Schulungen, Checklisten oder Guidelines bereit und bauen Systeme so auf, dass typische Fehler möglichst schwer zu machen sind. Teilweise müssen Content-Management-Systeme auch im Backend für die Barrierefreiheit entsprechend vorbereitet werden. Ein barrierefreies CMS (Content Management System) sollte beispielsweise so konfiguriert sein, dass es Pflichtfelder für Alternativtexte gibt.

Reden kann jeder – zeigen ist besser.

• Frage: »Können Sie mir eine bereits umgesetzte, barrierefreie Website zeigen und uns eine Barrierefreiheitserklärung für unser Projekt erstellen?«
• Hintergrund: Eine professionelle Agentur dokumentiert, welche Kriterien erfüllt sind und wo es eventuell begründete Ausnahmen gibt.

Barrierefreiheit ist in der Praxis kein Zustand, der sich pauschal mit »erfüllt« oder »nicht erfüllt« beschreiben lässt. Selbst bei sehr sorgfältiger Umsetzung ist eine kompromisslose, 100-prozentige Barrierefreiheit realistischerweise oft nicht erreichbar – etwa bei eingebetteten Drittinhalten, externen Tools oder gewachsenen Content-Beständen. Entscheidend ist daher nicht die Marketing-Behauptung absoluter Barrierefreiheit, sondern die transparente Dokumentation. Eine professionelle Agentur verschweigt diese Punkte nicht, sondern hält sie sauber fest.

Wer absolute Barrierefreiheit garantiert oder Dokumentation für unnötig hält, verkennt die Realität – und schafft falsche Erwartungen.

Barrierefreies Webdesign zu beauftragen, erfordert ein wenig Vorbereitung, zahlt sich aber doppelt aus: Sie erreichen mehr Kunden, verbessern Ihr SEO-Ranking und sind rechtlich auf der sicheren Seite.