Barrierefreies Webdesign: Was braucht es zur Zertifizierung für Barrierefreiheit nach WCAG 2.2 Standards.

In der heutigen digitalen Landschaft ist es oftmals nicht nur eine Frage der Corporate Responsibility oder gar eine legale Verpflichtung, sondern grundsätzlich eine sinnvolle Strategie, sicherzustellen, dass die Website für alle Benutzer:innen zugänglich ist. Dieses Whitepaper beschreibt die Bedeutung der WCAG 2.2-Konformität, ihre Vorteile, die Sie Ihrem Unternehmen bringt, und praktische Schritte, diese um zusetzen.

Verständnis von WCAG 2.2

Die Web Content Accessibility Guidelines (WCAG) 2.2 sind eine Reihe von Standards, die darauf abzielen, Webinhalte für Menschen mit Beeinträchtigungen zugänglicher zu machen. Barrierefreiheit ist wichtig, da sie Inklusivität gewährleistet, die Benutzererfahrung verbessert und den gesetzlichen Anforderungen entspricht.

Bei der Accessibility ist es zentral, dass Inhalte und Komponenten der Website auf möglichst vielen Endgeräten wiedergegeben werden können und dass Benutzer ihre Endgeräte konfigurieren können und die Websites und WebApps in möglichst vielen Szenarios funktionieren. Ein einfaches Beispiel: Benutzer A hat eine Sehschwäche und muss die Schriften verkleinern um den Inhalt gut lesen zu können, Benutzer B muss die Schriften vergrössern können um den Inhalt gut lesen zu können.

Websites von Dream Production

Seit Mitte 2024 stellen wir bei der Implementierung von neuen Websites sicher, dass die Website gemäss Level A compliant mit dem WCAG 2.2 entwickelt werden. Wichtig ist, dass Accessibility auch im Design Prozess und bei der Inhaltseingabe berücksichtigt wird (siehe Punkt “Integration in das Projekt).

Die vier Grund-Prinzipien „POUR“

Die vier Grundsätze für Web Accessibilty bekannt als “POUR” sind:

1. “Perceivable” (= Wahrnehmbar): Informationen und Benutzeroberflächen müssen so präsentiert werden, dass sie für Benutzer (mit Einschränkungen) wahrnehmbar und konsumierbar sind. Das heisst zum Beispiel, dass Bilder mit alternativ-Texten versehen werden und Multimedia-Elemente wie Videos Untertitel und Audio-Dateien Transkripte aufweisen. Generell sollen Inhalte so präsentiert werden, dass auf allen möglichen Endgeräten (Screen-Reader inklusive) keine Informationen verloren gehen.
2. “Operable” (= Bedienbar): Die Webseite oder Applikation soll auf allen Endgeräten bedienbar sein. Das heisst zum Beispiel, dass die Navigationen per Tastatur, Sprachsteuerung oder anderen Eingabegeräten bedienbar ist. Ebenfalls muss die Struktur der Navigation und Inhalte verständlich sein.
3. “Understandable” (= Verständlich): Die Informationen und Bedienung sind leicht konsumierbar aufbereitet. So soll zum Beispiel eine einfache Sprache verwendet werden die leicht verständlich ist, die Navigation soll konsistent aufgebaut werden und Eingabehilfen helfen dem Benutzer, Fehler zu vermeiden.
4. “Robust” (= Robust): Inhalte müssen “robust” genug sein, um zuverlässig von einer Vielzahl von Endgeräten und Clients, einschließlich unterstützender Technologien, interpretiert zu werden. Hier geht es zum Beispiel darum, dass HTML, CSS und JavaScript den Standards folgen, keine Fehler generieren und semantisch aufgebaut sind.

WCAG Level A – Grundlegende Barrierefreiheit

Dies sind essenzielle Accessibility Anforderungen an jede Website. Websites, welche nicht mit den WCAG-Anforderungen der Stufe A compliant sind, weisen in der Regel schwerwiegende Barrierefreiheitsprobleme auf. Dies macht es Menschen mit Einschränkungen meist unmöglich die Website zu nutzen.

Das Level A umfasst innerhalb der WCAG 2.2 Richtlinien 30 Kriterien, die es zu beachten gibt.

Beispiel Kriterien für das Level A (WCAG 2.2)

• Nicht-textuelle Inhalte (Bilder und Videos) müssen eine textliche Entsprechung haben.
• Die Website muss nur mit der Tastatur alleine, ohne Maus, bedienbar sein
• Formulare müssen korrekte Labels enthalten, damit sie unter anderem auf Screen Readern korrekt wiedergegeben werden
• Bildschirmlesegeräte (Screen Reader) und sonstige unterstützende Technologien müssen auf die Inhalte zugreifen und diese wiedergeben können.

und weitere (insgesamt 30)

Bei der Implementierung neuer Websites, stellen wir von Dream Production sicher, dass diese mit dem Level A von WCAG 2.2 compliant sind.

WCAG Level AA – Erweiterte Barrierefreiheit

Das WCAG Level AA deckt alles ab vom Level A und beinhaltet 20 zusätzliche Anforderungen. Die Webinhalte und Komponenten werden in diesem Level noch weiter optimiert um noch mehr Accessibility Use Cases zu berücksichtigen. Auch wenn es um gesetztes Konformität geht, wird dieses Level angestrebt.

Beispiele für Anforderungen aus dem Level AA

• Mindest Farbkontraste (Text/Hintergrund)
• Logische Header Struktur, bspw. muss sich ein H3 auf ein vorheriges H2 beziehen und sollte nicht nur für eine visuelle Gestaltung verwendet werden H3 usw.
• Konsistenz bei Navigations- und Interaktions-Elementen auf der gesamten Website

und weitere (insgesamt 50)

WCAG Level AAA – Ausgezeichnete Barrierefreiheit

Dies ist die höchste Konformatitätsstufe in den WCAG 2.2 Richtlinien. Die Website Inhalte und Komponenten erfüllen sämtliche Kriterien der Stufen A, AA und AAA.
Da dies nicht für alle Website realistisch oder in einem vernünftigen Budget Rahmen umsetzbar ist, sollte es hier das Ziel sein, möglichst viele zu erfüllen.

Die Stufe AAA umfasst 28 zusätzliche Anforderungen zu denen der Stufe AA.

Beispiele für das Level AAA sind:

• Mindest Farbkontrast von Text zu Hintergrund von 7:1
• Videos müssen eine Übersetzung in die Gebärdensprache enthalten
• Videos müssen eine erweiterte Audiobeschreibung bereit haben, nicht nur Übersetzungen der gesprochenen Texte

und weitere (insgesamt 78)

Stufe AA+

Wie Stufe AA aber Dokumente (wie PDFs) müssen ebenfalls barrierefrei sein.

Natürlich geht es bei Accessibility primär darum, dass Applikationen und Inhalte von Menschen mit Behinderungen und Einschränkungen genauso bedient und konsumiert werden können wie von allen anderen Benutzer. Accessibility-Praktiken bringen aber auch andere Vorteile mit sich.

Gesetzliche Konformität

2025 werden auf EU-Ebene strengere Gesetze für Unternehmen eingeführt in Bezug auf Accessibility und (auch private) Firmen müssen ihre Services barrierefrei anbieten. Das wird auch für schweizer Firmen gelten, die in der EU aktiv sind.

Generell bessere UX

Barrierefreie Websites bieten allen Benutzern, nicht nur Menschen mit Behinderungen, eine bessere Erfahrung.

SEO-Vorteile

Verbesserte Barrierefreiheit bringt in den meisten Fällen Verbesserungen im Bereich SEO mit sich, da zum Beispiel HTML semantisch aufgebaut wird.

Markenreputation

Das Demonstrieren des Engagements für Inklusivität kann die Markentreue stärken und ein breiteres Publikum anziehen.

Integration in das Projekt

Bei digitalen Projekten besteh die Herausforderung, Accessibility im Projekt zu integrieren und umzusetzen, sicherlich darin, dass Accessibility alle Aspekte der Projektes betrifft, das heisst das Screen-Design, die Inhalte sowie die technische Umsetzung von Front- und Backend und natürlich die QA Prozesse und Testing.

Die Integration von Accessibility muss ab Start des Projektes in alle Phasen und Prozesse einfliessen. Accessibility kann nicht einfach gegen das Ende des Projektes noch umgesetzt werden – oder zumindest nicht ohne erhebliche Aufwände.

Alle beteiligen Teams müssen von Anfang an ins Boot geholt werden und es muss sichergestellt werden, dass alle Parteien das nötige Verständnis haben und Zugang zu Resourcen und Tools haben, um die Accessibility relevanten Themen umzusetzen.

Es kann zum Beispiel vorkommen, dass bei Start des Projektes klar wird, dass bereits das CI/CD des Kunden nicht accessible ist, da die im Branding definierten Farben zu wenig Kontrast aufweisen.

Management des Prozesses

Da die Themen rund um die Accessibility alle Aspekte des Projektes betreffen ist wiederum das Management der Prozesse recht komplex und muss gut organisiert werden. Oft braucht es diverse Feedbackloops zwischen verschiedenen Parteien. Lösungsansätze sind nicht immer 100% sicher und brauchen zunächst konzeptionelle Arbeit.

Identifizierung von Barrieren

Einer der grössten Challenges ist bestimmt, die eigentlichen Probleme in Bezug auf die Accessibility festzustellen und zu identifizieren. Hier braucht es wiederum ein breites Spektrum an Know-How und Erfahrung sowie eine Vielzahl an Testgeräten und Tools.

Grundsätzlich werden die Probleme in Audits erkannt und dokumentiert und dann iterativ, diskutiert und implementiert.

Bei Dream Production sind unsere Tester auf Accessibility geschult und verfügen über die nötigen Tools für die Identifizierung von Accessibility Problemen. Die Accessibility ist in unsere QA-Prozesse eingebunden. Wir haben bereits viel Erfahrung in der Implementierung von Lösungen, welche von Access-for-All Accessibility Reviews und Audits vorgeschlagen werden.

Generell empfiehlt es sich Reviews, Tests und Audits von Access-for-All durchführen zu lassen. Falls eine Zertifizierung durch Access-for-All angestrebt wird, ist es zwingend von Anfang an mit Access-for-All zusammenzuarbeiten.

Lösung sind nicht immer klar definiert

Wie schon erwähnt können die Probleme sehr komplex werden und sind oft interdisplizinärer Natur. Daher sind auch oft die Lösungen nicht einfach klar. Lösungsansätze müssen oftmals durch den Input von verschiedenen Parteien definiert, umgesetzt und validiert werden. Der Findungs-Prozess erfordert Know-How und konzeptionelle Arbeit da es oft kein “one-fits-all” Rezept oder Ansatz gibt.

1. Zertifizierung

Die offizielle Zertifizierung durch Access-for-All ist natürlich die höchste Stufe der Verifizierung und Ihr Projekt (Webseite, App) erhält das offizielle Zertifikat, dass das Produkt durch Access-for-All eingehend gemäss der gewählten Konformitäts-Stufe geprüft wurde.

Die Zertifizierung macht dann Sinn, wenn diese entweder gesetzlich vorgeschrieben ist oder es die Unternehmens-Ziele vorgeben.

Die Ablauf der Zertifzierung sieht ungefähr so aus:

Der Prozess der Zertifizierung ist iterativ und es ist schwierig einzuschätzen, wieviele Iterationen nötig sind. Je nach Problemstellung braucht es Austausch in einem interdisziplinären Team. Das heisst auch, dass es schwierig ist, eine genaue Timeline und Budget festzulegen.

2. Audit und Implementierung nach Budget und Priorisierung

Dieser Ansatz ist vereinfacht und erreicht keine offizielle Zertifizierung. Dieser Ansatz macht bei Projekten Sinn, bei denen Accessibility wichtig ist aber eben eine Zertifizierung nicht nötig oder vorgeschrieben ist.

Hier wird bereits während des Projektes mit Accessibility im Auge gearbeitet. Wenn das Projekt in die Abschlussphase kommt wird ein offizieller Audit oder Review durch Access-for-All vorgenommen.

In der Regel geschieht dies auf dem Release Candidate oder der Live Website, direkt nach dem Go-Live.

Die Resultate werden dann diskutiert, priorisiert und eingeschätzt. Dann wird ein Budget-Rahmen definiert und innerhalb des Budgets werden dann die Accessibility-Verbesserung nach Priorisierung umgesetzt. Hier werden zum Beispiel “low hanging Fruits” – also Anforderungen, die einen grossen Impact haben aber wenig Aufwand benötigen – zuerst angegangen.

Nach Bedarf kann natürlich jederzeit ein Retesting von Acess-for-All und eine zusätzliche Iteration vorgenommen werden.

Nach diesem Ansatz gehen wir häufig vor. So auch in diesen Projekten:

Bestehende Websites

Für Bestehende Websites, die auf Accessibility optimiert werden sollen, empfehlen wird mit einem Review von Access-for-All zu starten.
In einem weiteren Schritt wird der Aufwand für die Umsetzung der nötigen Massnahmen dann geschätzt und nach Priorisierung umgesetzt.

Anforderungen, die einen grossen Impact haben aber wenig Aufwand benötigen – können zuerst angegangen.

Nach Bedarf können dann ein weiteres Retesting von Acess-for-All und eine zusätzliche Iteration vorgenommen werden.

Proof of Accessibility Efforts bei nicht zertifizierten Websites

• Eine dezidierte Page mit der Beschreibung der umgesetzten Accessibility Massnahmen wird auf der Website aufgeschaltet

3. Best Practices nach Best Effort

Hier wird kein offizieller Audit gemacht, es wird aber bei Projekt-Start festgelegt, dass Wert auf Accessibility gelegt wird. Dream Production alloziert dann einen Teil der Aufwände in die Implementierung und Testing von Best Practices nach dem best-Effort Prinzip. Standard-Anwendungen sind hier zum Beispiel:

• Validierung von Design nach Accessibilty-Vorgaben
• Navigation über Tastatur
• Semantisch korrektes HTML und Schema.org
• Alternativ Texte für Medien

Diese Liste ist nicht abschliessend.

Auch hier wird eine Page mit der Beschreibung der umgesetzten Accessibility Massnahmen auf der Website aufgeschaltet.