Bei Liberogic setzen wir uns täglich für die Verbesserung der Web-Accessibility ein. Nun haben wir auf dem Tech-Blog-Dienst „Zenn“ eine Artikelserie zu den WCAG (Web Content Accessibility Guidelines), den Richtlinien für Web-Accessibility, veröffentlicht.
In diesem Beitrag stellen wir Ihnen die Hintergründe vor, warum wir diese Artikel verfasst haben, sowie unsere Gedanken dahinter, und geben einen Überblick über die einzelnen Artikel.
Die Fragen rund um die WCAG klären
Bei der täglichen Implementierung und Prüfung von Websites stoßen wir immer wieder auf Punkte, bei denen wir uns fragen: „Wie ist dieses Kriterium der WCAG eigentlich zu verstehen?“ oder „Kann man sagen, dass diese Umsetzung konform ist?“
Diese Artikel dienen zum Teil auch dazu, meine internationale Zertifizierung im Bereich Accessibility, den „IAAP WAS (Web Accessibility Specialist)“, aufrechtzuerhalten und zu erneuern. Noch wichtiger ist mir jedoch der Gedanke, die häufigsten Stolpersteine aus der Praxis zu strukturieren und als Erfahrungswissen zu teilen. Gleichzeitig nutze ich die Gelegenheit, meine eigenen Gedanken zu ordnen.
Das Erreichen der WCAG ist nicht das Ziel, sondern der Startpunkt
Das Wichtigste, was wir mit diesen Artikeln vermitteln möchten, ist: Wer alle WCAG-Kriterien erfüllt, ist damit nicht automatisch zu 100 % barrierefrei.
Die WCAG sind eine „Mindestanforderung“, damit vielfältige Nutzerinnen und Nutzer Inhalte verwenden können. Sie sind lediglich der Startpunkt für Accessibility.
Wenn man Checklisten mechanisch abarbeitet und nur das Ziel verfolgt, die Erfolgskriterien zu erfüllen, kann leicht die Frage aus dem Blick geraten, ob die Website für die Nutzerinnen und Nutzer tatsächlich gut bedienbar ist.
Deshalb beschränken wir uns nicht auf oberflächliches Praxiswissen nach dem Muster "So implementiert man es, dann ist es konform", sondern gehen auch auf die Hintergründe und Absichten ein, warum diese Kriterien überhaupt entstanden sind. Wer die Intention hinter den Kriterien versteht, entwickelt unserer Ansicht nach ein deutlich fundierteres Verständnis von Barrierefreiheit.
Öffentlich auf Zenn veröffentlichte Artikel
Wir haben die Punkte zusammengestellt, bei denen bei der praktischen Umsetzung und Prüfung besonders häufig Unsicherheit entsteht, und sie in fünf Artikel zu einzelnen Themen gegliedert. Schauen Sie gerne bei den Themen vorbei, die Sie besonders interessieren.
WCAG-Unklarheiten ① Sind px-Angaben bei der Schriftgröße eigentlich zulässig?
Wir zeigen, inwieweit px-Angaben in heutigen Browserumgebungen mit den Anforderungen konform sind, und beleuchten das Wesen einer "barrierefreieren Umsetzung", die die Einstellungen zur Schriftgröße der Nutzerinnen und Nutzer respektiert. Zum Zenn-Artikel
WCAG-Unklarheiten ② Verstößt es gegen 2.4.4 (Zweck von Links), wenn mehrere "Details ansehen"-Links vorhanden sind?
Wir erläutern, wo die Grenze liegt, bei der ein Kriterium durch einen "ausreichenden Kontext" erfüllt wird. Darüber hinaus schlagen wir einen weitergehenden, UX-orientierten Ansatz vor, der die Bedienungseffizienz für Screenreader-Nutzerinnen und -Nutzer verbessert. Zum Zenn-Artikel
WCAG-Unklarheiten ③ Gegen welches Kriterium verstößt ein Bildlink ohne Alternativtext?
Der Schwerpunkt liegt auf komplexen Situationen, in denen sich ein einzelnes Problem über mehrere Erfolgskriterien (z. B. 1.1.1, 2.4.4 und 4.1.2) erstreckt. Wir erklären das Zusammenspiel dieser Kriterien und wie man im Prüfalltag zu einer fundierten Beurteilung kommt, da hier oft Verwirrung entsteht. Zum Zenn-Artikel
WCAG-Stolperstelle ④: Identisch aussehend, aber select ist nicht zulässig und ein individuelles Dropdown schon? Die Beurteilung nach 3.2.2 (bei Eingabe)
Eine ausführliche Erklärung des Unterschieds zwischen „Änderung der Einstellung“ und „Aktivierung“, wie es das W3C definiert. Zusammengefasst wird, wie man sich nicht vom äußeren Verhalten täuschen lässt und stattdessen anhand der Semantik des Elements und der Einordnung der Bedienung richtig urteilt. Den Zenn-Artikel lesen
WCAG-Stolperstelle ⑤: Wo ist 4.1.1 geblieben? Nach welchem Kriterium werden HTML-Syntaxfehler behandelt?
Hintergründe zur Streichung von 4.1.1 in WCAG 2.2. Erläutert wird, wie bisherige Syntaxfehler anhand tatsächlicher Auswirkungen auf andere Kriterien (1.3.1 oder 4.1.2) zugeordnet werden sollten, mit Blick auf die Qualität der Website. Den Zenn-Artikel lesen
Hinweis: Die WCAG-Richtlinien sind sehr komplex und enthalten viele schwer verständliche Formulierungen. Daher können die Erläuterungen und Beurteilungskriterien in den einzelnen Artikeln auf eigenen Interpretationen beruhen, die auf unserer bisherigen Praxiserfahrung basieren. Wir empfehlen, diese zusammen mit den WCAG-Richtlinien zu lesen.
Fazit
Web-Barrierefreiheit ist keine Aufgabe, die man einmal erledigt und dann abhakt, sondern etwas, das man kontinuierlich weiterentwickelt.
Wir hoffen, dass diese Ausarbeitung Entwicklerinnen und Entwicklern, Designerinnen und Designern sowie Projektleitungen, die sich täglich mit der Umsetzung und Prüfung von Accessibility beschäftigen, als Anregung dient.
Liberogic wird auch künftig daran arbeiten, Websites und Dienste zu realisieren, die für alle Menschen gut nutzbar sind, und wird dieses fachliche Wissen sowie die praktische Umsetzung weiter teilen. Bei Fragen zur Barrierefreiheit oder Anmerkungen zu unseren Artikeln können Sie sich gerne jederzeit an uns wenden!
Vom DTP in die Webwelt: Heute beherrscht er Markup, Frontend, Projektleitung und Barrierefreiheit gleichermaßen – ein wahrer "Techniker-Guru". Seit den Anfängen von Liberogic vielseitig im Einsatz und heute eine lebende Enzyklopädie im Team. Derzeit tüftelt er mit großer Begeisterung an effizienteren Abläufen durch gezielte Prompts – etwa mit der Frage: "Können wir bei der Barrierefreiheit nicht mehr auf KI setzen?" Technik und Denkweise entwickeln sich weiter.
Ayumu Futamata
IAAP-zertifizierter Web Accessibility Specialist (WAS) / Markup-Entwickler / Frontend-Entwickler / Webdirektor