Barrierefreiheit bei Webseiten: Richtlinien für TYPO3 Entwickler

Im Sommer 2025 wird das neue Gesetz für Barrierefreiheit in Kraft treten: Das Barrierefreiheitsstärkungsgesetz (BFSG) gibt es schon seit 2021, nach einer Übergangsfrist von 4 Jahren ist nun der Zeitpunkt gekommen, an dem dieses wirksam wird. Damit können Unternehmen ab einer bestimmten Größe zu Zahlungen verpflichtet werden, wenn Sie bestimmte Standards nicht einhalten. Weitere Informationen gibt es an vielen anderen Stellen im Internet. Dazu zählen Richtlinien für Entwickler. Wie die Umsetzung dieser Guidelines zumindest in wichtigen Punkten mit TYPO3 aussehen kann, ist Thema dieses Artikels.

Was bedeutet das BFSG aber in Detail für Entwickler? Dieser Frage bin ich in den letzten Wochen nachgegangen, und das hatte etwas mit meinem neuen Job als TYPO3 Senior Developer zu tun. Denn das Unternehmen, das ich nun unterstütze, hat das Thema Barrierefreiheit aufgegriffen und geht den Markt an. Also genügend Anlass, sich mit der Accessibility zu beschäftigen. 

Um es hier schon mal auf den Punkt zu bringen: Barrierefreiheit ist ein Thema, das nicht erst spät im Verlauf eines Projekts beim Entwickler aufschlägt. Accessibility muss bereits bei der Konzeptionierung einer Webseite, beim grafischen Entwurf und in der Phase des UI / UX beachtet werden. Zudem zieht die Accessibility eine ganze Reihe von redaktionellen Arbeiten nach sich. Dazu weiter unten mehr.

Was heißt das nun für mich als Entwickler? Es gibt Richtlinien für Programmierer, an die man sich bei der Umsetzung halten kann. Einige Punkte kann man aber quasi sofort anpacken und sich darum kümmern:

Nach bisherigen Standard sollten Schaltflächen bei einer Webseite 24 x 24px bemessen. Die 2.2 Version der WCAG sieht für Links eine Mindestgröße von 44 x 44px vor. Entsprechend müssen Buttons, Links z. B. in Header und Footer sowie Icons gestaltet sein. Dabei ist nicht entscheidend, dass der gesamte Inhalt auf 44 Pixel Größe gezoomt wird. Ein Facebook Icon kann auch per Padding auf den passenden Wert gebracht werden und weiter zart und klein erscheinen.

Vergessen Sie zarte Farbverläufe mit angedeuteten Texten in einem Button! Der WCAG 2.2 verlangt einen Kontrast von mindestens 7:1 bei Texten in einem Link, also auch in einem Button. Meiner persönlichen Meinung nach eine sehr gute Sache, denn auch ohne Einschränkung sieht man nun sofort, wo man klicken muss. Mit dem Contrast Checker lässt sich die Farbwelt einer Webseite prüfen und kann auf einen stärkeren Kontrast geeicht werden. 

Als Entwickler schaltet man gerne den Focus für Links ab. Besonders für Schaltflächen und Cards. In Sachen Barrierefreiheit keine gute Idee. Denn wenn man sich einmal mit der Tastatur durch eine Webseite navigiert, stellt man fest dass man sehr schnell verloren ist. Also sollte man einen Focus einbauen, wenn man ihn nicht übernommen hat. Mit Schattierungen lassen sich wunderbare Effekte zaubern.

Es gab in früheren Zeiten, so ca. 2022, mal die Modewelle, die Eingabefelder in Formularen nur mit einem Placeholder zu beschriften. Aus Gründen der Barrierefreiheit keine gute Idee. Auch ein beweglicher Placeholder, der über das Feld zoomt, ist keine gute Idee. Man sollte jedes Eingabefeld in einem Formular mit einem Label versehen. Bei einer Suche kann man dies für optisch navigierende Benutzer verstecken, Screenreader lesen dann vor, dass es sich um die Suche handelt.

Das waren die schnellen Anpassungen. Jetzt kommen die langwierigen Sachen.

Wie weiter oben schon angeschnitten: Barrierefreiheit muss als Thema bereits bei der Konzeptionierung einer Webseite bereits ganz zu Anfang auftauchen und nicht erst dann, wenn die Arbeit auf die Entwickler abgewälzt wird. Hier ein paar Punkte, die man mit den Kolleginnen und Kollegen aus der Grafik und der UI / UX angehen muss: 

• Wie sind die Links gestaltet? Eine Schaltfläche muss mindestens 44 x 44px groß sein. Was ist mit Links zum Login / Logout, die man früher recht klein gestaltet hatte? Was ist mit Button zu Facebooks und den anderen Netzwerken, die früher als kleine Icons daherkamen und nun größer sein müssen?
• Wie gestalten wir Cards? Diese beliebten Schaltflächen in einer Übersicht bestehen oft aus einem Bild, einer Überschrift, einem kurzen Text als Teaser und einem Button zum Anklicken. Redundante Links sind zu vermeiden. Macht man nun einen großen Button mit 44px Höhe oder legt man gleich das gesamte Element als Schaltfläche an?

Das Thema Barrierefreiheit schlägt sich auch bei redaktionellen Inhalten nieder. Hier zwei Anforderungen: 

• Texte sollten in leicht verständlicher Form zugänglich sein. Technisch lässt sich dies über einen Umschalter zur Sprache wie zwischen Ländern lösen. Redaktionell bedeutet dies einen erheblichen Mehraufwand.
• Bei Elementen wie Cards oder Bildern als Links hat man es früher gerne so gemacht, dass man den ALT-Text auch für den Titel des Bildes und des Links verwendet hat. Das ist nun vorbei. Wenn ein Link um ein Bild liegt, sollte man so vorgehen:
  • Der Link (HREF) enthält die Beschreibung der folgenden Seite mit der Aufforderung zum Klicken im TITLE-Attribut
  • Das Bild bekommt als ALT-Attribut die Beschreibung der Inhalte des Bildes mit Informationen für SEO
  • Das TITLE-Attribut des Bildes ist leer.

Ich habe in den letzten Jahren immer die Meinung vertreten: Wer eine gute SEO macht, der hat auch schon die halbe Barrierefreiheit. Diese Meinung vertrete ich auch jetzt noch, nachdem ich mich mit dem Thema Accessibility tiefer auseinander gesetzt habe. Wer die technischen Voraussetzungen geschaffen hat, um z. B. Bilder und Links mit SEO Texten für ALT und TITLE Attribute zu versehen, der ist in Richtung Barrierefreiheit schon mal recht gut aufgestellt. Wie das Beispiel Cards aber zeigt: Hinter einer kleinen Änderung können auf einer normalen Webseite Stunden oder Tage an redaktionellen Arbeiten hängen. Lohnt sich dann dieser Aufwand? Meiner persönlichen Meinung nach: Ja. 

• Wie in vielen Schulungen zu Barrierefreiheit berichtet wird: Bis zu 30% der potenziellen Nutzenden von Webseiten haben kognitive Einschränkungen. Man erschließt eine riesige neue Nutzergruppe
• Gerade bei SEO zwingen Anforderungen der Barrierefreiheit dazu, die redaktionellen Inhalte von Webseiten deutlich zu überdenken
• Nutzer von Google Lighthouse stellen fest, dass Google Anforderungen an die Barrierefreiheit beachtet – man kann mit einer Optimierung der Webseite sein Page Ranking verbessern. 

Hier geht es ums Geld. Und nicht nur darum, ein paar Menschen, rein rechnerisch weltweit als ca. 2 Milliarden Menschen, die Möglichkeit zu geben, die eigene Webseite zu nutzen.

Übersicht WCAG Guidelines

Web Content Accessibility Guidelines (WCAG) 2.2

Extensions für Ihren Browser zur Überprüfung von Richtlinien zur Barrierefreiheit: 

Silktide Inspextor Extension

WAVE Tool Extension