Der richtige Umgang mit WCAG

WCAG steht für “Web Content Accessibility Guidelines”, zu Deutsch “Richtlinien für barrierefreie Webinhalte”. Obwohl viele mit diesem Begriff vertraut sind oder bereits davon gehört haben, wird der Umgang in der Webentwicklung damit oft vernachlässigt oder missverstanden. In diesem Artikel möchte ich ein wenig in die Tiefe gehen und auf die zunehmende Bedeutung eingehen.

WCAG sind internationale Standards, die vom World Wide Web Consortium (W3C) entwickelt wurden, um sicherzustellen, dass Webinhalte für Menschen mit Behinderungen zugänglich sind. Die WCAG umfassen Richtlinien und Erfolgskriterien, die Webentwickler:innen befolgen sollten, um sicherzustellen, dass Websites und Webanwendungen für alle, unabhängig von ihren Fähigkeiten oder Einschränkungen, nutzbar sind. Diese Richtlinien betreffen Aspekte wie Textverständlichkeit, Bedienbarkeit mit der Tastatur, Bildbeschreibungen und vieles mehr.

Es ist wichtig, dass nicht nur Webentwickler:innen, sondern zum Beispiel auch UX-Designer:innen ein solides Verständnis von WCAG haben. Dies gewährleistet, dass bereits in der konzeptionellen Phase eines Projekts keine unnötigen Barrieren entstehen, die später nur schwer zu beseitigen sind.

Es gibt verschiedene Behinderungen, die sich in Gruppen etwa so zusammenfassen lassen: Sehbehinderungen, Hörbehinderungen, motorische Behinderungen, kognitive und neurologische Einschränkungen und Sensibilität für visuelle oder kognitive Überlastung.

Die Nutzer:innen einer jeden dieser Gruppen haben auch unterschiedliche Anforderungen und Bedürfnisse an Webinhalte:

Menschen mit Sehschwächen oder Blindheit benötigen gut strukturierte Texte und alternative Texte für Bilder, um Webinhalte zu verstehen. Gehörlose oder schwerhörige Nutzer:innen profitieren von Untertiteln oder Transkriptionen in Videos und Audiodateien. Menschen mit motorischen Einschränkungen benötigen z.B. besondere Navigationsoptionen. So fordert WCAG eine Tastatur-Navigationsoption und die Vermeidung von Zeitbegrenzungen, um die Nutzung von Webinhalten für Nutzer:innen mit motorischen Einschränkungen zu erleichtern. Für Nutzer:innen mit kognitiven oder neurologischen Beeinträchtigungen sind klare und verständliche Inhalte sowie die Minimierung von Ablenkungen wichtig. Für Nutzer:innen mit Empfindlichkeiten ist es wichtig, auf visuelle Überlastungseffekte zu achten und benutzerdefinierte Anpassungsoptionen anzubieten.

Bei der Berücksichtigung von Menschen mit Sehschwächen oder Blindheit im Kontext der WCAG gibt es mehrere wichtige Aspekte, die beachtet werden sollten.

Alle nicht rein dekorativen Bilder auf einer Website sollten mit alternativen Texten versehen werden. Diese Texte beschreiben den Inhalt des Bildes und werden von Screen-Readern vorgelesen, um Menschen mit Sehbehinderungen zu informieren, was auf dem Bild dargestellt ist. Auch ist eine klare und logische Strukturierung von Webseiten entscheidend. Dies umfasst die Verwendung von semantischen HTML-Tags wie zum Beispiel header, nav, main, footer, button oder Überschriften (h1, h2, h3 usw.) zur Gliederung des Inhalts. Screen-Reader nutzen diese, um die Seitenstruktur zu vermitteln.

Der Kontrast zwischen Text und Hintergrund sollte ausreichend hoch sein, um eine gute Lesbarkeit zu gewährleisten. Dies hilft bei Farbenblindheit, den Text leichter zu erkennen. Auch sollte Text so gestaltet sein, dass er in Bezug auf Größe und Stil flexibel anpassbar ist.

Nutzer:innen mit Sehschwächen oder Blindheit, ebenso wie Nutzer:innen mit motorischen Einschränkungen, sind darauf angewiesen, eine Website mittels Tastatur bedienen zu können.
Daher sollten alle Interaktionselemente, wie Links, Buttons und Formulare per Tastatur navigierbar sein. Elemente wie die Navigation sollten konsistent und vorhersehbar sein, um Verwirrung zu vermeiden. Videos sollten Untertitel oder Transkriptionen haben, damit Menschen mit Sehbehinderungen den gesprochenen Inhalt verstehen können. In bestimmten Fällen ist die Verwendung von ARIA-Attributen (ARIA steht für “Accessible Rich Internet Applications”) entscheidend, insbesondere wenn es um interaktive Webinhalte geht und herkömmliches HTML allein nicht ausreicht, um Screen-Readern verständlich zu machen, worum es genau geht.

Das ist schon einiges, was man allein für Menschen mit Sehschwächen oder Blindheit beachten muss, um Web-Inhalte zugänglich zu machen. Andere Einschränkungen haben wir uns im Detail noch gar nicht angeschaut.

Auf der Website european-accessibility-act.de wird die Adressierung all dieser Anforderungen völkerrechtlich festgehalten:

“Die völkerrechtliche Verpflichtung zur Barrierefreiheit leitet sich aus dem „Übereinkommen über die Rechte von Menschen mit Behinderungen“ der UNO ab. Dieses trat 2008 in Kraft und wurde seither von knapp 180 Ländern ratifiziert. Es fordert ein umfassendes Diskriminierungsverbot, oder, positiv formuliert, die volle Verwirklichung aller Menschenrechte und Grundrechte für alle Menschen mit Behinderungen.“

(Quelle: https://www.european-accessibility-act.de/)

Im weiteren Verlauf ergeben sich hieraus nicht nur Verpflichtungen zur digitalen Barrierefreiheit für öffentliche Anbieter, auch die Privatwirtschaft wird adressiert:

“In den vergangenen zehn Jahren wurde digitale Barrierefreiheit für öffentliche Anbieter mit Hilfe gesetzgeberischer Maßnahmen vorangetrieben. Aktuell rücken nun privatwirtschaftliche Unternehmen verstärkt ins Blickfeld.”

“Der „European Accessibility Act” („Europäischer Rechtsakt zur Barrierefreiheit”) wurde im Frühjahr 2019 als EU-Richtlinie 2019/882 verabschiedet. Die Bandbreite der Richtlinie ist beträchtlich: Sie umfasst digitale Endgeräte und zahlreiche Anwendungen wie öffentliche Selbstbedienungsterminals, audiovisuelle Medien, eBooks, Kommunikations-, Bank- und Verkehrsdienstleistungen. Die Richtlinie muss bis zum 28. Juni 2022 in nationales Recht überführt und ab dem 28. Juni 2025 angewendet werden.“

(Quelle: https://www.european-accessibility-act.de/)

Spätestens jetzt ist klar, dass sich alle, die sich mit der Erstellung von Webinhalten beschäftigen, intensiver mit WCAG auseinandersetzen müssen. Auch Konsequenzen bei Missachtung des European Accessibility Act sind bereit jetzt vorhersehbar:

“Noch ist keine strikte Konformitätsprüfung nach WCAG 2.1 bzw. EU-Norm EN 301 549 vorgesehen, aber die Richtung ist klar: In absehbarer Zeit werden auf Unternehmen in der EU einklagbare Verpflichtungen zukommen.”

(Quelle: https://www.european-accessibility-act.de/)

Wir wissen das im US-amerikanischen und kanadischen Markt WCAG für private Unternehmen bereits gelten. Der ADA (Americans with Disabilities Act) hat in den USA die Zahl der Klagen wegen mangelhafter digitaler Barrierefreiheit in jüngster Zeit dramatisch ansteigen lassen.

Die EU zieht nach und es ist nur eine Frage der Zeit, wann die ersten Klagen hierzulande reinkommen.

Puhh. Das sitzt. Als Webentwickler sehe ich da Einiges an Herausforderungen auf die Entwicklung zu kommen. Für UX und Design gilt dies uneingeschränkt ebenso. Aber auch alle anderen Stakeholder, die sich mit der Erstellung von Webinhalten beschäftigen, etwa Tester:innen, Product Owner oder Entscheider:innen werden sich mit dem Thema nachhaltig beschäftigen müssen.

Deswegen gilt, wie bei allen großen Initiativen, am besten loslegen, Schritt für Schritt. Irgendwo muss man ja mal anfangen.

Am besten startet man damit schon bei der Konzeption eines Projekts. Wenn noch keine Expertise vorhanden ist, sollte man sich gleich mit allen Gewerken (Product Ownership, Project Management, Design, UX, Test etc.) an WCAG heranzutasten. Workshops helfen, ein gemeinsames Verständnis über WCAG und ihre Bedeutung zu erlangen:

• Zunächst sollte WCAG erklärt werden und die Erkenntnis vermittelt werden, dass WCAG in Zukunft zunehmend an Bedeutung gewinnen wird.
• Im zweiten Schritt sollten sich Teams mit den konkreten Anforderungen, die sich durch WCAG für Ihr Produkt ergeben, auseinandersetzen.
• Anschließend gilt es, die Sicherstellung dieser Anforderungen fest in den Produkt- oder Projektzyklus zu integrieren und zu bestimmen, wie und was designt, umgesetzt und getestet werden muss.

Natürlich bedeutet dies eine Investition, insbesondere in der Anfangsphase oder wenn in einem Projekt noch keine Expertise vorhanden ist. Doch lohnt sich die intensive Beschäftigung mit diesem Thema. Nicht nur, um geltendes Recht anzuwenden oder mögliche Klagen abzuwenden. Letztendlich profitieren alle Beteiligten davon, da jeder am Ende das Produkt nutzen kann.

Es gibt zahlreiche Websites die Anleitungen im Detail bieten und Entwickler:innen klare Vorgaben an die Hand geben um die Entwicklung WCAG konform zu gestalten. Hier ein paar Beispiele:

• Seite des W3C: https://www.w3.org/
• WCAG: https://www.w3.org/WAI/standards-guidelines/wcag/
• Patterns: https://www.w3.org/WAI/ARIA/apg/patterns/

Auch Tools im Frontend Kontext können bei der Entwicklung unterstützen:

• Unit Testing: https://github.com/chaance/vitest-axe
• e2e Testing: https://playwright.dev/docs/accessibility-testing
• Storybook Addon: https://storybook.js.org/addons/@storybook/addon-a11y

Dies sind lediglich einige Beispiele. Zu entdecken gibt es noch viel mehr.

Dieser Blogbeitrag soll einen Überblick über die Bedeutung und die Wichtigkeit von WCAG in der Zukunft, vor allem im privaten Sektor, vermitteln.

Je intensiver man sich mit WCAG auseinandersetzt, desto klarer wird einem, dass es nicht darum geht, einen festgelegten Kriterienkatalog zu erfüllen oder eine starre Checkliste abzuarbeiten, die immer und überall absolut gültig ist. Die WCAG sind vielmehr ein lebendiges Regelwerk, das kontinuierlich vom W3C weiterentwickelt wird, um dabei zu helfen, Webinhalte für alle Menschen zugänglich zu machen.

Wenn man es vereinfacht betrachtet, gibt es Menschen, die Computer auf unterschiedliche Weisen nutzen, unabhängig davon, ob dies aus Notwendigkeit oder freiwillig geschieht. Eine tiefere Sensibilisierung für diese Tatsache ist bereits ein wichtiger Schritt in die richtige Richtung.