Einleitung
Automatisierte Tools finden diese Barrieren nicht
Ich habe mir für dieses Jahr einen besonderen Adventskalender ausgedacht: Eine Seite voller Barrieren, bei der du mitraten kannst, was verkehrt ist.
Ich weiß, da kann ich doch jede beliebige Website dafür nehmen, warum extra eine erstellen? Das Besondere ist, dass mit dem Axe DevTool keine Fehler angezeigt werden. Automatisierte Tools finden die Barrieren nicht, aber dennoch sind sie da. Nur weil ein automatisiertes Tool sagt, dass die Seite barrierefrei ist, stimmt das nicht zwangsweise. Automatisierte Tools finden nur ca. 30% aller Barrieren.
Jeden Tag besprechen wir (mindestens) eine Barriere, wo das Problem liegt und was eine barrierefreie Lösung wäre.
- Täglich besprechen wir mindestens eine Barriere auf der Seite.
- Automatisierte Tools finden diese Barrieren nicht.
- Rate mit: Was ist das Problem?
- Ich zeige jeden Tag eine Lösung.
- Am Ende weißt du, was eine Barriere mit einem Murder Mystery zu tun hat.
Praxisbezug
Worum geht es beim Barrieren-Adventskalender überhaupt? Ich sehe viele, richtig gute theoretische Lerninhalte zur digitalen Barrierefreiheit. Beispielsweise hat jeder von uns schon mal gehört, dass der Farbkontrast ausreichend groß sein muss. Das ist so mit das erste, was man lernt, wenn man sich mit digitaler Barrierefreiheit beschäftigt. Aber häufig denken wir nur an die offensichtlichen Stellen wie direkt sichtbarer Fließtext und Überschriften oder Buttons. Demnach sollten auf der Barrieren-Seite keine Farb-Barrieren vorhanden sein, oder? Das Tool Axe DevTools meldet tatsächlich keine Fehler. Und auf den ersten Blick wirkt auch alles gut lesbar.
Um dich zu spoilern: es wird mehr als nur einmal der Farbkontrast nicht eingehalten. Jetzt bist du gefragt: Welche Farbbarrieren findest du?
Genau darum geht es mir. Ich möchte auf die Barrieren aufmerksam machen, die theoretisch bekannt, in der Praxis aber oft übersehen werden, weil sie an unerwarteten Stellen auftauchen oder nicht offensichtlich sind. Denn auch diese Barrieren hindern Menschen daran, die Website zu nutzen.
Newsletter
Möchtest du kein Türchen verpassen? Dann melde dich zum Newsletter an. Du bekommst ab dem 1. Dezember jeden Tag eine E-Mail, in der mindestens eine Barriere besprochen wird. Zudem gehörst du zu den ersten, die von neuen Angeboten und Spielen zu digitaler Barrierefreiheit hören.
Wenn du dich nicht anmelden möchtest, dann kannst du mir auf LinkedIn folgen. Dort veröffentliche ich auch die Türchen.
Sollte es irgendwelche Probleme geben, dann lass es mich bitte wissen. Dazu kannst du mir gerne eine E-Mail schreiben an kontakt@ideenquelle-webdesign.de
Links
Also, bist du bereit?
Türchen
Türchen 1: Animation
Das wohl offensichtlichste, wenn man auf die Seite geht, ist die Schnee-Animation im Hintergrund. Schön? Vielleicht. Barrierefrei? Nicht ganz.
Das Problem: Laut WCAG 2.2.2 müssen länger laufende Animationen (über 5 Sekunden) anhaltbar sein. Hier geht das nicht so einfach.
Die Gefahr: Animationen können nicht nur ablenken, sondern bei stark blitzenden Inhalten im schlimmsten Fall sogar epileptische Anfälle auslösen.
Die Lösung: Animationen sollten pausierbar sein oder du baust statt einer Animation direkt ein Standbild ein.
P.S.: Ich habe doch einen versteckten Stop-Button eingebaut, aber nur, weil es mich selbst so sehr genervt hat. Wer findet ihn?
Türchen 2: Linktexte
Gleich oben im Text ist ein Link eingefügt mit dem Linktext “hier”.
Das Problem: Wenn sich z.B. jemand alle Links als Liste mit dem Screenreader ausgeben lässt, dann ist “hier” nicht verständlich. Doch wohin führt „hier“ eigentlich? Keine Ahnung. Dieser Linktext ist leider immer noch weit verbreitet.
Die Lösung: Beschreibende Linktexte wie in diesem Fall „Newsletter“ verwenden. So weiß jeder, was ihn erwartet!
Türchen 3: Überschriftenstruktur
Das Problem: Der erste Abschnitt enthält zwei Überschriften. “Zum Miträtseln” , welches den HTML-Tag H5 hat und “Barrieren Adventskalender” mit dem HTML-Tag H1. Das nennt man auch Eyebrow-Überschrift. Rein logisch würde ich Inhalt nach der H5 erwarten, der entsprechend zur Struktur passt. Stattdessen gibt es keinen weiteren Inhalt, sondern gleich die H1. Die H1 sagt mir, worum es auf der Seite geht.
Zudem nutzt die H1 eine Font, die man als schwierig lesbar bezeichnen könnte.
Die Lösung: Beide Texte in einer H1 zusammenfassen und nur das Styling anpassen. So bleibt die semantische Struktur erhalten.
WCAG 1.3.1: Informationen und Beziehungen müssen korrekt dargestellt werden.
Türchen 4: Alt-Text
Der Alt-Text ist wichtig für Menschen, die einen Screenreader nutzen. Aber das Bild hat doch einen Alt-Text, wo ist denn das Problem? Das hätte ja sonst auch das automatische Tool erkannt. Das Problem ist, dass der Alt-Text nicht beschreibt, was auf dem Bild zu sehen ist.
Die Lösung: Ein besserer Alt-Text wäre “Schneebedeckte Straße mit Tannen auf beiden Seiten”.
WCAG 1.1.1: Alle Nicht-Text-Inhalte müssen eine Textalternative haben, es sei denn sie sind rein dekorativ.
Türchen 5: Screenreader und Visuelle Information stimmen nicht überein
Na, wer hat schon den Button gefunden, um die Schnee-Animation zu stoppen? Es ist ein unsichtbarer Button im ersten Abschnitt unter dem Text. Du kommst mit der Tastatur dorthin. Der Screenreader liest dir auch den Button-Text vor: “Schnee ausschalten”. Hier ist es mal umgekehrt. Sonst ist es manchmal so, dass der Screenreader bestimmte Teile nicht lesen kann.
Die Lösung: Dem Button eine Text- und Hintergrundfarbe zu geben, statt sie transparent zu machen. Natürlich mit entsprechend großem Kontrast.
Um technisch zu werden: Hier wurde ein Link verwendet und kein Button. Oft sagen wir umgangssprachlich “Button” zu allem, was für uns wie ein Button aussieht, aber semantisch betrachtet handelt es sich um einen Link (<a>) und keinen Button (<button>). In diesem Fall bleiben wir auf der selben Seite und führen eine Funktion aus. Deshalb sollte ein semantischer Button verwendet werden und kein Link. In Bricks kannst du beim Button den benutzerdefinierten HTML-Tag <button> hinzufügen.
Wenn die Animation an- und ausschaltbar sein soll, dann verwende eine Checkbox.
Dass ein Link als Button verwendet wurde, gibt es noch an einer weiteren Stelle auf der Seite. Hast du sie gefunden?
Türchen 6: Seiten-Titel
Der Seiten-Titel lautet “Eine Seite, auf der ganz viele Barrieren zu finden sind”. Um fair zu sein, das beschreibt zum Teil, was auf der Seite ist.
Das Problem: Der Titel ist zu lang und nicht wirklich aussagekräftig.
Die Lösung: Kurz, prägnant und beschreibend: „Barrieren-Adventskalender“ reicht völlig aus.
WCAG 2.4.2: Jede Webseite muss einen beschreibenden Titel haben.
Türchen 7: Header
Der Header sieht auf den ersten Blick voll in Ordnung aus. Aber, es gibt ein Aber.
Das Problem: Der Header-Bereich ist als normale Sektion statt als semantisches <header>-Element umgesetzt.
Die Lösung: Im Bricks-Builder, mit dem ich die Seite erstellt habe, ist es einfach umzusetzen, indem man ein Template erstellt. Dort kann man den Vorlagentyp “Header” auswählen und schon wird er richtig eingesetzt.
Türchen 8: Leerer Link
Im Bereich “Video” ist ein Button mit der Aufschrift “Zum Youtube-Kanal”. Allerdings passiert nichts, wenn man auf diesen Button klickt. Das kann verwirren.
Die Lösung: Korrekte Verlinkung zum Youtube-Kanal. Klingt simpel, passiert aber überraschend oft.
Test-Tipp: Immer alle Links vor dem Go-Live prüfen!
Türchen 9: Video Untertitel
Im ersten Moment könnte man meinen, dass Untertitel vorhanden sind, also alles gut. Doch wenn man das Gesagte und die Untertitel vergleicht, stellt man fest, dass das nicht übereinstimmt. Das kann zum Beispiel passieren, wenn man Untertitel automatisch mit KI erstellen lässt und sie nicht überprüft. Da schleichen sich immer wieder Fehler ein.
Hier steht im Untertitel “Axe Death-Tool”, natürlich sollte es “Axe DevTool” heißen. Wir sind nicht bei einem Murder Mystery, wo es um die Axt als Tötungswerkzeug geht.
Die Lösung: Untertitel immer manuell prüfen und korrigieren. Qualität vor Geschwindigkeit!
WCAG 1.2.2: Untertitel müssen für aufgezeichnete Audioinhalte bereitgestellt werden.
Türchen 10: Video Bedienung
Ich habe beim Video den Standard-Videoplayer von Bricks gewählt. Aber wo ist der Fokus?
Das Problem: Der Fokusrahmen hat einen zu geringen Kontrast und ist schwer erkennbar. Tastatur-Nutzende wissen nicht, wo sie sind.
Die Lösung: Klaren Fokusrahmen mit mindestens 3:1 Kontrast zum Hintergrund implementieren.
Für selbstgehostete Videos bietet Bricks in den Einstellungen – Theme Styles – Elemente – Videos die Möglichkeit den “Benutzerdefinierten Video-Player” zu aktivieren. Dann kannst du den Fokusrahmen mit CSS stylen.
Anders sieht es bei Youtube-Einbettungen aus: Da der Player per iframe eingebunden wird, greifen deine Styles nicht. Was du aber tun kannst, ist Youtube auf das Problem hinweisen. Je öfter die Forderung nach einem barrierefreien Player kommt, desto höher die Chance auf Veränderung.
WCAG 2.4.7: Der Fokus muss sichtbar sein.
Türchen 11: Zitat kennzeichnen
Im Karussell haben wir Zitate.
Das Problem: Die Zitate sind nicht semantisch gekennzeichnet. Screenreader wissen nicht, dass es sich um Zitate handelt.
Die Lösung: Im Bricks-Builder gibt es beim “Rich Text” die Möglichkeit, den Text als Zitat zu kennzeichnen (<blockquote>). So werden Zitate korrekt vorgelesen.
Bonus-Tipp: Technisch gesehen keine Barriere (nach WCAG), aber trotzdem für einige Menschen schwerer bzw. langsamer zu lesen ist es, wenn der Fließtext zentriert geschrieben ist. Richte Fließtext lieber linksbündig aus. Dieses Problem gibt es auch an einer anderen Stelle. Hast du sie gefunden?
Türchen 12: Karussell Fokusrahmen
Das Zitate-Karussell hat ein Problem.
Der Fokusrahmen vom Button im Karussell ist so gut wie gar nicht erkennbar, weil der Kontrast zu klein ist. Tastatur-Nutzende verlieren die Orientierung. Das passiert manchmal, wenn auf einer Seite mal helle und mal dunkle Hintergründe sind und ich den Fokusrahmen nicht entsprechend anpasse.
Die Lösung: In diesem Fall haben wir einen dunklen Hintergrund, also bietet sich ein heller Fokusrahmen an mit einem Kontrast von mindestens 3:1. Du kannst aber auch von Anfang an einen doppelten Fokusrahmen nutzen (hell und dunkel), sodass er auf jedem Hintergrund gut sichtbar ist.
WCAG 2.4.7: Der Fokus muss sichtbar sein.
Türchen 13: Sprache auszeichnen
Englisches Zitat auf deutscher Seite und niemand hat es dem Screenreader verraten.
Wir sind noch im Karussell und haben hier gleich die nächste Barriere gefunden. Es gibt ein Zitat, das Englisch ist, obwohl die gesamte Seite auf Deutsch ist und auch das entsprechende Sprach-Attribut hat.
Die Lösung: Wenn ein Abschnitt in einer anderen Sprache vorhanden ist, dann muss dieser mit dem Language-Attribut gekennzeichnet werden.
<span lang=“en“>English Text</span>
Wenn es sich allerdings um einzelne Worte handelt, die eingedeutscht sind, dann wird oft empfohlen, diese nicht zu kennzeichnen, weil der Screenreader dafür eine kurze Pause macht, was den Lesefluss stören kann.
WCAG 3.1.2: Sprache von Teilen muss gekennzeichnet werden.
Wenn wir schon beim Thema Sprache sind: die Pfeile für “vor” und “zurück” im Karussell haben zwar Aria Label, allerdings nur auf Englisch.
Um das Problem zu lösen, kannst du entweder das Element umständlich anpassen über dein Child-Theme, du verzichtest ganz auf Karussells oder nutzt sie nur auf englischen Seiten. In UX-Kreisen wird aber schon lange von Karussells abgeraten, du tust also dir und deinen Website-Besuchenden einen Gefallen, wenn du sie einfach weg lässt.
Türchen 14: Unerwartete Aktion
Wenn ich mit der Tastatur den Button “Kontakt” fokussiere, dann geht ein Pop-Up auf. Das sollte nicht so sein.
Das Problem: Aktionen werden ohne Absicht ausgelöst. Verwirrend und nervig für Tastatur-Nutzende.
Andere unerwartete Aktionen sind z.B. die Werbungs-Popups, die einfach beim Scrollen auftauchen. Wir sind uns einig, dass das jeden stört.
Die Lösung: Ein solcher Button sollte erst durch klicken/ bei Enter ausgelöst werden und es sollte auch vorher klar kommuniziert werden, was passiert.
WCAG 3.2.1: Bei Fokus keine Kontextänderung auslösen.
Hier haben wir auch wieder das Problem, dass der Schließen-Button vom Popup ein semantischer Link (<a>) ist, obwohl es ein Button sein sollte.
Das nächste Problem ist, dass das Popup nicht die Rolle Dialog und ein Label hat. Das ist wichtig für Screenreader, um zu erkennen, dass es sich um einen modalen Dialog handelt.
WCAG 4.1.2 Name, Rolle, Wert
Türchen 15: Formular Teil 1/4
Farbkontrast
Wir sind beim Formular angekommen. Das Formular hat zwar Rahmen für die Eingabefelder, allerdings ist deren Kontrast viel zu gering.
Das Problem: Die Rahmen der Eingabefelder sind kaum sichtbar, da der Kontrast zum Hintergrund zu gering ist. Nutzende erkennen die Formularfelder nur schwer.
Die Lösung: Ein deutlicher, dunkler Rahmen mit einem Kontrastverhältnis von mindestens 3:1, zum Beispiel in Schwarz oder einem dunklen Grau, schafft hier Abhilfe und macht die Felder für alle gut sichtbar.
Im Zusammenhang mit dem Formular gibt es einen weiteren Kontrastfehler. Findest du ihn?
Türchen 16: Formular Teil 2/4
Platzhalter
Dieses Formular hat keine Beschriftung in Form von Labels, sondern nur Platzhalter. Ein klassischer Fehler mit fatalen Folgen!
Das Problem: Wenn ich in das Feld klicke und anfange zu tippen, dann sehe ich gar nicht mehr, was in dieses Feld gehört. Außerdem lesen Screenreader den Platzhalter oft gar nicht vor und für manche Leute sind Platzhalter einfach nur verwirrend.
In diesem Fall gibt es noch Aria-Labels, sodass der Screenreader zumindest etwas ausgibt, aber sichtbar sind sie nicht.
Die Lösung: Echte Labels verwenden und sie korrekt verbinden. Platzhalter sollte man wenn möglich vermeiden und wenn man sie nutzt, dann sollten sie Labels nicht ersetzen, sondern nur ergänzen.
WCAG 3.3.2: Labels oder Anweisungen müssen bereitgestellt werden.
Semantik
Für den Datenschutz wurde eine Checkbox innerhalb einer Liste verwendet. Da wir hier nur ein Listenelement haben, ist die Liste nicht nötig.
Türchen 17: Formular Teil 3/4
Erforderlich?
Wir haben bei dem Formular Sterne (*) und viele von euch denken vielleicht, dass das bedeutet, dass es sich um ein Pflichtfeld handelt. Allerdings muss das nicht der Fall sein. Es gibt manchmal auch Formulare, wo die mit Stern gekennzeichneten Felder keine Pflichtfelder sind.
Das Problem: Unklare Pflichtfeld-Kennzeichnung verwirrt alle Nutzenden. Hier ist auch das Datenschutz-Feld ein Pflichtfeld, aber nicht gekennzeichnet.
Die Lösung: Deshalb ist es so wichtig zu beschreiben, was der Stern bedeutet. Alternativ kann man auch “Pflichtfeld” oder “erforderlich” bei den entsprechenden Feldern ergänzen. Pflichtfelder sollten auch mit dem Attribut “required” versehen werden.
WCAG 3.3.2: Beschriftungen oder Anweisungen werden bereitgestellt, wenn Inhalte Benutzereingaben erfordern.
Fehlermeldung
Wenn ich einen Screenreader nutze, dann funktionieren die Fehlermeldungen in Abhängigkeit vom Browser nicht immer. Das liegt daran, dass keine Fehlermeldungen mit aria-describedby hinterlegt wurden. Browser übernehmen diese Funktion manchmal, aber eben nicht alle, deshalb ist es notwendig, die Fehlermeldungen maschinenlesbar zu hinterlegen.
Autocomplete
Außerdem fehlt das Autocomplete-Attribut. Autocomplete ist dafür da, um beispielsweise die E-Mail Adresse nicht auf jeder Seite neu eingeben zu müssen, sondern vorgeschlagen zu werden. Heutzutage sind Browser oft in der Lage, die Eingaben automatisch zu vervollständigen. Nichtsdestotrotz ist Autocomplete in den WCAG 1.3.5.
Türchen 18: Formular Teil 4/4
Erfolgsmeldung Farbkontrast
Wer noch dabei ist: Respekt, wir gehen langsam sehr ins Detail.
Formular erfolgreich abgeschickt! Oder?
Heute geht es darum, dass auch der Text der Erfolgsmeldung einen ausreichenden Kontrast braucht. Hier haben wir grünen Text auf hellgrünem Hintergrund und damit ein Kontrastverhältnis von 2,4:1. Das ist zu gering.
Die Lösung: Wir sollten mindestens einen Kontrast von 4,5:1 anstreben.
Das ist eine Barriere, die häufig übersehen wird, weil man sie nicht auf den ersten Blick auf der Website sieht.
Erfolgsmeldung Screenreader
Die Erfolgsmeldung wird direkt unter dem Formular angezeigt, aber wenn ich einen Screenreader verwende, dann bekomme ich keine direkte Rückmeldung, sondern muss erst weiterlesen. Das ist zwar nach den WCAG erlaubt, aber ein besserer Weg ist es, nach dem Senden auf eine neue Seite weiter zu leiten und die Rückmeldung in den Titel oder die Überschrift zu setzen.
Lösung
Wie erstelle ich denn jetzt ein barrierefreies Formular? Ich empfehle dir in WordPress das Plugin WS-Forms. Damit hast du viele Einstellungsmöglichkeiten und kannst dein Formular barrierefrei machen.
Türchen 19: Zu klein
Dies ist nach WCAG keine Barriere, da es unter die Ausnahme „Abstand“ fällt. Wenn ein zentrierter Kreis um die Social Media-Icons mit einem Durchmesser von 25px einen anderen Zielbereich berührt, dann würde das folgende eine Barriere sein.
Das Problem: Die Social Media-Icons sind zu klein. Sie müssen mindestens eine Klickfläche von 24×24 Pixel haben. Das ist sonst eine Barriere für Menschen, die motorische Einschränkungen oder große Finger haben.
Häufig sehe ich dieses Problem wie hier bei Social Media Icons, aber auch bei Seitennummerierungen.
Die Lösung: Die Icons mindestens auf 24×24 Pixel vergrößern.
WCAG 2.5.8: Ein Bedienelement muss mindestens eine Größe von 24×24 Pixel haben.
Türchen 20: Aria-Label Navigation
Auf der Seite haben wir oben ein Menü mit den Punkten “Video, Zitate, Formular” und ganz unten im Footer das Menü mit Datenschutz und Impressum.
Mehrere Navigationen, aber wie unterscheidet sie der Screenreader?
Das Problem: Doppelte Navigationen ohne Beschreibung. Auf einer Seite mit mehr als einer Navigation (Menü), müssen sie auseinander gehalten werden können.
Die Lösung: Aria-Labels hinzufügen. Dem oberen Menü könnte ich das aria-label=“Hauptmenü“ hinzufügen, dem unteren Menü aria-label=“Rechtliches“. So kann ich sie gut auseinanderhalten.
WCAG 1.3.1: Informationen und Beziehungen, die visuell vermittelt werden, können programmatisch bestimmt werden.
Türchen 21: Mobiles Menü
Heute liegt unser Fokus auf dem mobilen Menü. Auf schmalen Bildschirmen wie Smartphones werden die Menüpunkte im Header oft hinter einem Button, dem Hamburgermenü, versteckt.
Das Problem: Wenn ich mit der Tastatur dieses versteckte Menü ausversehen öffne, kann ich es nicht wieder schließen ohne eine Seite auszuwählen, da der Button zum Schließen nicht erreichbar ist. Außerdem ist auch hier der Fokusrahmen nur schlecht sichtbar.
Die Lösung: Einen klaren Fokusrahmen im Menü hinzufügen und den Schließen-Button per Tastatur erreichbar machen. Ich mache das über mein Child-Theme mit einem eigenen Element und entsprechend Abstand.
Im Bricks Builder kannst du die verschachtelte Navigation wählen. Da ist zwar noch das Problem, dass der Schließen-Button als Listenelement mit angezeigt wird, aber wenigstens ist er nutzbar. Padding und Margin kannst du auch einstellen.
Türchen 22: Cookie-Banner Teil 1/2
Ich bin sehr froh, dass das Thema Cookie-Banner im Kontext der Barrierefreiheit etwas präsenter wird. Denn natürlich sollen alle Menschen auf einer Website das Cookie-Banner verwenden können und nicht nur Einige.
Ich habe hier das Real Cookie-Banner mit seinen Standard Einstellungen verwendet.
Farbkontrast
Die Farbkontraste von den hellgrauen Texten sind mit 4,6:1 gerade so über der Grenze von 4,5:1 (nach WCAG 2.2 AA).
Ein Farbkontrast-Problem gibt es, wenn man die Einstellungen individuell einstellt. Dort hat das Kästchen ”Funktional” zum Anklicken nur einen Kontrast von 1,5:1. Für Bedienelemente gilt ein Minimum von 3:1.
Die Lösung: Kontraste konsequent prüfen, auch bei Third-Party-Plugins wie Cookie Banner. Beim Real Cookie Banner kannst du in den Einstellungen (Customizer) die Farben anpassen.
WCAG 1.4.11: Auch UI-Komponenten müssen einen ausreichenden Kontrast haben.
Sticky Elemente
Wenn ich den Cookie-Banner auf 200% vergrößere, dann bemerken wir, dass Header und Footer des Cookie-Banners sticky ist. So bleibt dazwischen weniger Platz, um den Text zu lesen. Das Problem kommt dann, wenn ich die Tastatur nutze, dann sehe ich zwischendrin den Fokusrahmen nicht mehr. Ja, ich kann immer noch dorthin scrollen, aber es ist nicht schön.
Generell sollte man Sticky-Elemente nur bewusst einsetzen, da sie im Zusammenhang mit Vergrößerung sehr schnell Probleme bereiten können.
Türchen 23: Cookie Banner Teil 2/2
Tastaturbedienung
Wenn ich die Cookies ablehne, dann wird ja erstmal das Youtube-Video gesperrt mit einem Cookie-Banner. So weit so gut. Es gibt sogar einen Skip-Link. Das Problem ist, dass dieser Skip-Link nicht mit der Tastatur bedienbar ist. Schade, weil dafür ist er ja eigentlich da.
Zeilenumbruch
Es gibt in den Texten einige Male das Zeilenumbruch-Element <br>. Diese stören, wenn man einen Screenreader nutzt.
Beim Real Cookie-Banner kannst du einige Texte im Customizer bearbeiten und dort die Zeilenumbrüche entfernen.
Lösung
Die Lösung für Cookie-Banner allgemein: Tja, gute Frage… Keine Cookies verwenden? Das geht öfter, als man denkt, wenn man weiß, was man tut. In unserem Fall hätte ich das Video selbst hosten können, dann bräuchte ich keine Youtube-Cookies.
Was wir noch tun können, ist die Hersteller von Cookie Bannern auf die Fehler aufmerksam machen. Ein bisschen Aktivismus für eine inklusivere Welt, das können wir uns doch vornehmen.
Ich muss dazu sagen, dass der Real Cookie-Banner schon Einiges richtig macht und man viele Einstellungsmöglichkeiten hat, mit denen man fast alle Barrieren verhindern kann. Es wäre natürlich noch schöner, wenn die Standardeinstellung barrierefrei ist.
Im Vergleich dazu gibt es andere Anbieter auf dem Markt, die komplett unnutzbare Cookie-Banner vertreiben.
Türchen 24: Skip-Link
Am Anfang der Seite gibt es zwei Skip-Links. Das ist doch erstmal eine tolle Sache. Nur ist der Text kaum lesbar, weil der Kontrast schlecht ist und zudem ist der Skip-Link “Zum Hauptinhalt” komplett sinnlos, weil der Header ja nicht als solcher eingebunden ist. (Siehe Türchen 7) Das bezieht sich auf den Bricks Builder. Man springt also nirgendwo hin, sondern muss die Navigation so oder so durchgehen.
In diesem Fall ist es ein Onepager, deshalb bräuchte man nicht unbedingt einen Skip-Link. Skip-Links sind dafür da, um sich wiederholende Inhalte zu überspringen, meist ist das der Header.
Die Lösung: Skip-Links immer testen und korrigieren.
Abschluss
Das war’s: 24 Tage, über 24 Barrieren, unzählige Learnings! Vielen Dank an alle, die mit gerätselt, kommentiert und gelernt haben.
Was wir gelernt haben:
- Barrierefreiheit betrifft jeden Bereich einer Website. Nicht nur das Offensichtliche, sondern z.B. auch Cookie-Banner und das, was nach dem Abschicken eines Formulars angezeigt wird.
- Auch kleine Details können große Barrieren sein und dafür sorgen, dass der Kontext komplett verändert wird. Denk nur an den Axt-Mörder von Türchen 9.
- Automatisierte Tools finden viele Barrieren einfach nicht. Selbst wenn ein automatisiertes Tool keine Fehler anzeigt, heißt es nicht, dass es keine gibt. Es ist immer notwendig manuell zu testen.
Mein Weihnachtswunsch: Dass 2026 das Jahr wird, in dem mehr Websites für alle Menschen designed werden.
Ich wünsche euch schöne Feiertage und einen guten Rutsch ins neue Jahr!
Eure Olivia