Barrierefreiheit in freier Wildbahn: Pro Helvetia, ein Schweizer Beispiel
Dies ist der begleitende Blogpost zu meinem Talk Accessibility in Reality: Pro Helvetia, a Swiss case study» auf dem WordCamp Europe 2025 in Basel. Er enthält zusätzliche Links zu Quellen, die ich auf der Bühne zitiert habe. Alle Links wurden zuletzt am 04.06.2025 geprüft.
Video-Aufnahme
Präsentation
Auch meine Original-Slides sind hier zu finden. Schaut euch unbedingt die Speaker Notes an, denn die Slides selbst enthalten kaum Text.
Vorträge machen euch müde und Lesen ist das Medium eurer Wahl? Dann seid ihr hier richtig: Der folgende Artikel enthält alle Inhalte meines Talks, aber neu formuliert als – hoffentlich – lesenswerter Blogpost.
Hallo, wer spricht da?
Ich bin mir sicher: Viele von euch fühlen sich überfordert, wenn es um das Thema Barrierefreiheit im Web geht. Ich weiss das, weil ich mich selbst oft so gefühlt habe. Und ehrlich gesagt – ich bin selbst kein «richtiger» Accessibility-Experte. Ich habe keine offiziellen Zertifizierungen, bin kein Kenner aller Gesetze und kann auch die WCAG-Kriterien nicht auswendig runterbeten. Ich bin ein einfacher Frontend-Entwickler, so wie viele von euch.
Ich bin kein Experte, aber ich habe durchaus eine gewisse Erfahrung: Denn ich habe viele Accessibility-Kurse besucht, an etlichen Accessibility-Konferenzen teilgenommen und unzählige Accessibility-Artikel gelesen. Vor allem aber habe ich ganz praktische Erfahrungen, durch das Bauen von barrierearmen Websites seit über 10 Jahren – damals, als kaum jemand wusste, dass man sich um so etwas wie Web-Accessibility überhaupt kümmern müsste.
Im Jahr 2025 ist Barrierefreiheit für mich keine «Zusatzfunktion». Wenn ich heute absichtlich eine nicht barrierefreie Website bauen würde, würde sich das in etwa so anfühlen, wie eine zu bauen, die nicht responsiv ist – viel Spass, die irgendjemandem anzudrehen.
Heisst das, alle meine Projekte sind sofort konform gemäss den Standards WCAG AA oder AAA? Schön wäre das, aber ich vermute wohl eher: Nein, sind sie nicht. Und trotzdem bin ich mir sicher, dass meine Seiten viele Aspekte abdecken, die auf fast allen anderen Websites fehlen. Denn schockierende 96 % aller Websites treffen überhaupt keine Accessibility-Massnahmen! (Quelle: https://webaim.org/projects/million/)
Dieser Artikel soll nicht das übliche Accessibility-Thinkpiece sein, in dem ich erkläre …
- … warum Accessibility wichtig ist.
- … warum es nicht nur um Screenreader für blinde Menschen geht.
- … warum man seinen Umsatz ganz toll steigern könnte, wenn man Menschen mit Behinderungen in seine Zielgruppe aufnimmt.
- … warum man nicht 16 % der Weltbevölkerung vom Internet ausschliessen sollte. Immerhin so viele Menschen leben mit einer Behinderung in irgendeiner Form.. (Quelle: https://www.who.int/news-room/fact-sheets/detail/disability-and-health)
Ich möchte über etwas anderes sprechen: über Angst. Ich selbst hatte ziemlich Angst vor dem Thema Web-Accessibility, bevor ich mich besser auskannte. Ich dachte, ich müsste von Anfang an alles perfekt machen – und habe deshalb oft gar nicht erst angefangen.
Aber das ergibt gar keinen Sinn! Denn jede noch so kleine Verbesserung bringt echten Nutzen für echte Menschen. Jeder noch so kleine Bugfix ist ein grosser Schritt für sich. Ich präsentiere euch in diesem Artikel zehn Beispiele für solche «grossen kleinen» Verbesserungen. Es sind alles echte Beispiele aus einem echten Kund:innen-Projekt. Nichts davon ist höhere Mathematik – und erst recht nichts, das ihr als Frontend-Entwickler:innen nicht leicht umsetzen könntet.
Und alle Besucher:innen des WordCamp Europe haben sowieso schon eine gute Entscheidung in Sachen Accessibility getroffen. Denn WordPress ist als CMS ziemlich barrierefrei. Der Block Editor geht da mit gutem Beispiel voran, sowohl im Backend als auch sein Frontend-Output. In einem CMS-Vergleich von 2022 landete WordPress auf Platz 4 für Barrierefreiheit. Daher ein grosses Lob an dieser Stelle an das WordPress-Community-Accessibility-Team – schaut da gerne mal rein, wenn ihr auch mit anpacken wollt!
Quellen:
Barrierefreie Förderung für Kunst & Kultur
Für den besonderen Anlass, dass das WordCamp Europe zum ersten Mal in die Schweiz kommt, wollten wir bei required als Schweizer Agentur passenderweise ein Schweizer Projekt vorstellen: den Relaunch von prohelvetia.ch.
Pro Helvetia ist die Schweizer Stiftung für Kulturförderung im In- und Ausland. Sie betreibt Büros in sieben Ländern auf vier Kontinenten. Ihre Website muss also global funktionieren – für viele verschiedene Menschen an unterschiedlichen Orten.
Der Relaunch war ein grosses Projekt, das fünf beteiligte Organisationen über ein Jahr lang beschäftigt hat. Unsere Rolle bei required war die technische Umsetzung auf Basis der bestehenden WordPress-Installation. Dabei haben wir eng mit der Design-Agentur zusammengearbeitet, und mit unserem gemeinsamen Kunden Pro Helvetia, welcher von Anfang an seine neue Website so barrierearm wie möglich gestalten wollte. Apropos Arbeitsteilung: Wenn ich kein Accessibility-Profi bin – wer könnte diese Aufgabe in diesem Projekt übernehmen?
Stellt euch folgendes vor: Eure Mutter ruft euch an, denn ihre Waschmaschine ist kaputt. Was tun? Ich gebe zu: Wahrscheinlich würde ich einen halben Tag vor Google und im Baumarkt verbringen, und das Problem dabei extrem verschlimmern. Aber ihr seid klüger als ich und hättet sicherlich sofort Expert:innen kontaktiert. Machen wir also das Gleiche für Pro Helvetia.
Ihr möchtet mehr über den Relaunch von Pro Helvetia erfahren? Wir haben dazu eine ausführliche Fallstudie auf dieser Website!
-
Pro Helvetia: Schweizer Kulturstiftung in neuem Gewand
Ein globaler Hub für Kunst und Kultur Pro Helvetia ist die Schweizer Kulturstiftung, die im Auftrag des Bundes zeitgenössisches und professionelles Kunst- und Kulturschaffen von…
Zugang für alle
Zugang für alle ist eine Schweizer Non-Profit-Organisation mit dem Ziel, das Internet barrierefreier zu machen. Sie bieten Website-Reviews nach WCAG 2.1 und 2.2 AA an – das sind auch die Standards, die viele internationale Gesetze vorschreiben, wie der European Accessibility Act. (Quelle: https://access-for-all.ch/der-european-accessibility-act-bekanntes-prinzip-neue-pflichten/)
Ihre Reviews führen Expert:innen mit Behinderungen und ohne durch. Dabei passen sie sich euren Budgets an, testen also ganze Multisites oder auch nur erste Design-Entwürfe.
«Schon wenige Stunden reichen, um die wichtigsten Hürden eines Projekts zu identifizieren.»
Andreas Uebelbacher,
Zugang für alle
Wenn man so ein Review bestellt, erstellt Zugang für alle ein Dokument mit konkreten Befunden und Verbesserungsvorschlägen. Das Beste daran: Wenn ihr diese umsetzt, verbessert ihr nicht nur eure Website, sondern lernt dabei enorm viel über Web-Accessibility im Allgemeinen. Deshalb habe ich für diesen Blogpost zehn Beispiele aus unserem Review herausgesucht, die ich euch in der folgenden Struktur vorstellen werde: «Problem – Lösung – Lehre». Dabei bemerkt ihr hoffentlich schnell, wie viel man schon von kleinen Beispielen lernen kann.
Zugang für alle ist in der Schweiz tätig, aber weltweit gibt es viele ähnliche Organisationen. Eine (sehr unvollständige) Auswahl:
- Access for all (Schweiz)
- Stiftung Pfennigparade (Deutschland)
- AnySurfer (Belgien)
- Inclusive Design Research Centre at OCAD University (Kanada)
- Knowbility (USA)
- Access Audit (UK)
- …
Fehlt hier jemand? Dann meldet euch!
1. Falscher Alternativtext für verlinktes Logo
Problem
«Das verlinkte Seiten-Logo muss einen Alternativtext aufweisen, welcher der Doppelfunktion des Logos gerecht wird (Vermittlung der Absenderinformation und Hinweis aufs Ziel der Verlinkung).»
Das Logo von Pro Helvetia hatte als Alternativtext die Worte «Logo von Pro Helvetia» und war verlinkt auf die Startseite. Für sich genommen ist das beides nicht falsch – kombiniert aber ein Fehler. Screenreader lesen dann vor: «Link, Logo von Pro Helvetia». Hier könnte man denken, der Link würde zu einer Bilddatei des Logos führen.
<a href="[…]">
<img alt="Logo von Pro Helvetia" />
</a>Code-Sprache: HTML, XML (xml)Lösung
Im Review wurde vorgeschlagen, den alt-Text «… zurück zur Startseite» zu ergänzen.
<a href="[…]">
<img alt="Logo von Pro Helvetia, zurück zur Startseite" />
</a>Code-Sprache: HTML, XML (xml)An dieser Lösung gibt es nichts auszusetzen. Wir haben uns für eine andere entschieden, die ebenso funktioniert: Wir setzen das Attribut aria-label für das Anker-Element, mit den Worten «Zurück zur Startseite von Pro Helvetia», und lassen das alt-Attribut bewusst leer. Wenn es aria-label gibt, werden Screenreader den Alternativtext ohnehin ignorieren.
<a href="[…]" aria-label="Zurück zur Startseite von Pro Helvetia">
<img alt="" />
</a>Code-Sprache: HTML, XML (xml)Lehre
Bilder brauchen Alternativtexte und Links brauchen Link-Texte. Verlinkte Bilder können als Link-Texte fungieren.
2. Listen mit nur einem Element
Problem
«Der Link ‹Förderung finden› ist als Liste mit nur einem Eintrag umgesetzt.»
Der Call-to-Action-Button im Hauptmenü war ein einzelnes li in einer ul. Screenreader lesen das wie folgt vor: «Link, Förderung finden, Liste, ein Element». Ziemlich viel überflüssiger Output.
<div class="custom-block">
<ul class="menu">
<li class="menu-item">
<a href="[…]">Förderung finden</a>
</li>
</ul>
</div>Code-Sprache: HTML, XML (xml)Lösung
Anfangs hatten wir den Button mit wp_nav_menu() gerendert, damit man ihn im WordPress-Backend pflegen kann. Doch diese Funktion gibt immer eine Liste aus, auch wenn es nur einen einzelnen Eintrag gibt.
wp_nav_menu( [
'theme_location' => 'ph-call-to-action',
'container' => '',
'level' => 1,
] );Code-Sprache: PHP (php)Deshalb holen wir uns die Menüpunkte jetzt mit wp_get_nav_menu_items() und rendern sie manuell mit zusätzlichem Block-Editor-Markup. Auf diese Weise ist das Ergebnis im Frontend genau das gleiche, als hätte man im Block Editor den Buttons-Block eingefügt.
Input
$menu_items = wp_get_nav_menu_items( $menu_id );
$block_content = '<!-- wp:buttons --><div class="wp-block-buttons">';
foreach ( $menu_items as $menu_item ) {
$block_content .= sprintf(
'<!-- wp:button -->
<div class="wp-block-button">
<a class="wp-block-button__link" href="%s">
%s
</a>
</div>
<!-- /wp:button -->',
$menu_item->url,
$menu_item->title
);
}
$block_content .= '</div><!-- /wp:buttons -->';
echo do_blocks( $block_content );Code-Sprache: PHP (php)Output
<div class="custom-block">
<div class="wp-block-buttons">
<div class="wp-block-button">
<a href="[…]" class="wp-block-button__link">
Find support
</a>
</div>
</div>
</div>Code-Sprache: HTML, XML (xml)Lehre
Benutzt keine Listen, wenn es nichts aufzulisten gibt.
3. Gruppierte Eingabefelder haben keine Beschriftung
Problem
«Die häufig gesuchten Begriffe sind visuell gruppiert mit der Überschrift ‹Vorschläge› versehen, diese ist jedoch nicht als
legendzurfieldsetformatiert.»
Im Such-Dialog gibt es eine Auswahl beliebter Suchbegriffe mit der Überschrift «Vorschläge». Im HTML war das aber nur ein p vor einer ul, ohne semantischen Zusammenhang.
<div class="[…]">
<p class="[…]">
Vorschläge
</p>
<ul class="[…]">
<li>[…]</li>
<li>[…]</li>
<li>[…]</li>
</ul>
</div>Code-Sprache: HTML, XML (xml)Lösung
Einfach div und p ersetzen durch fieldset und legend. Zwischen diesen beiden Elementen gibt es einen klaren semantischen Zusammenhang. (Quelle: https://www.w3.org/WAI/tutorials/forms/grouping/)
<fieldset class="search-suggestions">
<legend class="search-form__label">
Vorschläge
</legend>
<ul class="search-suggestions__list">
<li>[…]</li>
<li>[…]</li>
<li>[…]</li>
</ul>
</fieldset>Code-Sprache: HTML, XML (xml)Lehre
p beschriftet nichts. legend beschriftet fieldset.
Das ist eine tolle Überleitung zur Semantik von HTML-Elementen, dem Inhalt unseres nächsten Beispiels.
4. Text nicht semantisch strukturiert
Problem
«Es finden sich Texte, die nicht korrekt in die HTML-Struktur eingebunden sind, sondern nur über
divundspan,»
Im Footer geben wir redaktionellen Text aus dem Dashboard aus. Dieser Text wurde direkt innerhalb eines div-Elements gerendert – aber ein div ist ein reines Struktur-Element ohne semantische Bedeutung. Für Screenreader ist also unklar, was für eine Rolle der ausgegebene Text spielen soll.
<div>
PRO HELVETIA<br />
Schweizer Kulturstiftung
</div>Code-Sprache: HTML, XML (xml)Quellen:
- https://www.w3.org/TR/2011/WD-html5-author-20110809/the-div-element.html
- https://www.w3.org/TR/2011/WD-html5-author-20110809/the-span-element.html
Lösung
Im Template haben wir den Text mit der Funktion nl2br() ausgegeben, um die Zeilenumbrüche in br-Elemente umzuwandeln. Aber das war nicht genug.
echo wp_kses_post( nl2br( $column ) );Code-Sprache: PHP (php)Mithilfe der WordPress-Function wpautop() kann der Text zusätzlich in p-Elemente aufgeteilt werden. Dadurch wissen Screenreader, dass es sich um allgemeinen Text handelt, der von den User:innen gelesen werden soll.
Input
echo wp_kses_post( wpautop( $column ) ); Code-Sprache: PHP (php)Output
<div>
<p>
PRO HELVETIA<br />
Schweizer Kulturstiftung
</p>
</div>Code-Sprache: HTML, XML (xml)Lehre
div und span haben keine semantische Bedeutung. Versucht stets die passenden Elemente zu wählen, um eure Informationen zu strukturieren, wie p, blockquote, address und so weiter …
Das ist ein grossartiges Beispiel dafür, wie die praktischen Review-Ergebnisse zu wichtigen Erkenntnissen über Web-Accessibility im Allgemeinen führen können. Wenn ihr bisher nicht mit semantischem HTML vertraut wart, ist das ein Anstoss, sich in diese Richtung fortzubilden. (Quelle: https://www.w3.org/TR/WCAG20-TECHS/G115.html)
5. Fehlerhafte Überschriften-Hierarchie
Problem
«Die Newsletter-Anmeldung und der Footer-Inhalt sind visuell klar abgetrennt, aber semantisch der letzten vorausgehenden Überschrift untergeordnet, zu der sie nicht gehören.»
Auf der Startseite gab es eine allgemeine h1, dann eine h2 für den News-Bereich «What’s on» und darunter mehrere h3 für die einzelnen Beiträge. Die letzte h3 «Bleiben Sie auf dem Laufenden.» gehörte jedoch gar nicht zu den News, sondern bezog sich eigentlich auf das Newsletter-Formular – war also hierarchisch falsch eingeordnet.
<h1>Herzlich willkommen bei Pro Helvetia.</h1>
<h2>What's on</h2>
<h3>Pavillon of …</h3>
<h3>Illustration …</h3>
<h3>How do cross …</h3>
<h3>Annual report …</h3>
<h3>Sélection …</h3>
<h3>She Got Game …</h3>
<h3>Rewilding the …</h3>
<h3>Interview with …</h3>
<h3>Bleiben Sie auf dem Laufenden.</h3>Code-Sprache: HTML, XML (xml)Lösung
Im Block Editor konnten wir ganz einfach die Überschrift von h3 auf h2 ändern. Dort konnten wir auch einstellen, dass sie weiterhin genauso aussieht wie vorher, trotz veränderter Hierarchie.
<h1>Herzlich willkommen bei Pro Helvetia.</h1>
<h2>What's on</h2>
<h3>Pavillon of …</h3>
<h3>Illustration …</h3>
<h3>How do cross …</h3>
<h3>Annual report …</h3>
<h3>Sélection …</h3>
<h3>She Got Game …</h3>
<h3>Rewilding the …</h3>
<h3>Interview with …</h3>
<h2>Bleiben Sie auf dem Laufenden.</h2>Code-Sprache: HTML, XML (xml)Lehre
Denkt immer daran, eure Überschriften im Kontext der gesamten Seite zu prüfen. Trennt die visuelle Ansicht von der strukturellen Hierarchie.
6. Aktueller Menüpunkt nicht hervorgehoben
Problem
«Visuell klar als aktiv hervorgehobene Elemente müssen auch mittels Screenreader als solche erkennbar sein.»
Die Schnellnavigation im Header ermöglicht es, direkt zu bestimmten Seiten zu springen. Der aktuell aktive Menüpunkt ist visuell hervorgehoben durch einen dunklen Hintergrund, aber diese Information war nur für sehende User:innen erkennbar.
Lösung
Wir haben dem aktiven Link das Attribut aria-current="page" hinzugefügt. Dadurch wissen Screenreader, dass sie den Menüpunkt mit dem zusätzlichen Text «Aktuelle Seite» ansagen sollen.
<a href="[…]" aria-current="page">
Unsere Förderbereiche
</a>Code-Sprache: HTML, XML (xml)Lehre
Fragt euch jederzeit: Wie wird sich dieses Element verhalten, wenn wir es nicht sehen können und nur mit dem Text interagieren?
7. Button hat keine aussagekräftige Beschreibung
Problem
«Der Schalter zum Auslösen der Suche ist mit ‹Absenden› beschriftet, was nicht sinnvoll ist.»
Im Such-Dialog gibt es einen Such-Button, der durch das bekannte Icon einer Lupe hervorgehoben ist. Aber der versteckte Screenreader-Text lautete lediglich «Absenden». Ohne also das Icon zu sehen, blieb unklar, was dieser Button tun würde.
<button type="submit">
<span class="screen-reader-text">Absenden</span>
<svg>[…]</svg>
</button>Code-Sprache: HTML, XML (xml)Lösung
Änderung des Textes zu «Suchen» – oder «Finden».
<button type="submit">
<span class="screen-reader-text">Suchen</span>
<svg>[…]</svg>
</button>Code-Sprache: HTML, XML (xml)Lehre
Beschriftet eure interaktiven Elemente mit Worten, die beschreiben, was sie tatsächlich tun. Achtet auf alles Versteckte.
Dies ist eine klassische Situation, in der wir natürlich nicht mit Absicht einen unklaren Text verwendet haben. Aber weil es sich um einen verstecken Text handelte, war es sehr einfach, ihn während der Entwicklung der Website zu übersehen.
8. Sichtbare Outline fehlt
Problem
«Auf den beiden Dropdowns ‹Sparte› und ‹Aktivität› ist der Tastaturfokus nicht sichtbar.»
Das Formular zur Suche von Förderungen auf der Startseite befindet sich vor einem pinken Hintergrund. Dies führte zu Problemen mit dem generellen Fokus-Stil der Website, der aus einer pinken Outline besteht.
Lösung
Wir haben die Outline-Farbe zu Schwarz geändert für die Dropdowns. Und da diese einen schwarzen Hintergrund erhalten, wenn sie aktiv sind, änderten wir die Farbe für diesen Fall zu Weiss.
Lehre
Wenn wir Fokus-Stile definieren, müssen wir sie für alle Fälle und alle Elemente testen. Wenn wir neue Elemente hinzufügen, müssen wir sichergehen, dass die bestehenden Fokus-Stile weiterhin funktionieren.
9. Filterergebnisse für Screenreader ansagen
Problem
«Bei Anwenden des Filters werden die Ergebnisse gefiltert und visuell wird die Trefferzahl angezeigt. Davon erfahren Screenreader-Anwender:innen nichts.»
Wenn wir nach Förderungen von Pro Helvetia filtern, wird die Anzahl der Suchergebnisse dynamisch aktualisiert. Visuell ist das leicht zu erkennen, aber für Nutzer:innen von Screenreadern ist es schwierig, von diesen Veränderungen zu erfahren.
Theoretisch wäre dieses Problem wesentlich komplexer zu lösen als die vorherigen, da es auf JavaScript basiert. Aber wie eingangs erwähnt, ist es eine kluge Entscheidung hinsichtlich Accessibility, sich für WordPress als CMS zu entscheiden.
Lösung
Wir mussten nur das Paket @wordpress/a11y importieren, eines von vielen bestehenden WordPress–JavaScript-Modulen. Dadurch entsteht ganz einfach eine sogenannte «Live-Region», die automatisch Inhalte an Screenreader sendet. Wir müssen lediglich die Funktion speak() aufrufen.
import { speak } from '@wordpress/a11y';
speak(
sprintf(
_n(
'%s result found.',
'%s results found.',
results.length,
'ph-one-factsheets'
),
results.length
)
);Code-Sprache: JavaScript (javascript)Lehre
Wenn ihr dynamische Änderungen per JavaScript vornehmt, informiert auch Screenreader darüber. In komplexen Situationen sucht nach vorgefertigten Hilfsmitteln.
10. «Ich hab’s euch gesagt»
Zum Schluss eine kleine «Bonus»-Kategorie. Wie bereits erwähnt, stammt das Design von prohelvetia.ch nicht von uns bei required, auch wenn UX- und Web-Design zu unseren Leistungen gehören. Natürlich haben wir während der Designphase unseren Input gegeben. Aber wie es eben so ist: Bei vielen Beteiligten und vielen Meinungen geht so mancher Aspekt mal unter.
Es folgen Beispiele für Fehler, die schon vor Beginn der Entwicklung hätten verhindert werden können.
10.1 Inkonsistente Header-Navigation
Problem
«In der Service-Navigation findet sich teils ein Eintrag ‹Förderung finden›, teils aber auch nicht.»
Inzwischen kennt ihr den Call-to-Action-Button im Hauptmenü gut. Dieser Button war auf der Startseite früher tatsächlich ausgeblendet – vermutlich für ein «cleaneres» Erscheinungsbild. Aber Änderungen an zentralen Navigationselementen sind keine gute Idee, da diese sehr verwirrend sind für Menschen, die Schwierigkeiten haben, sich auf komplexen Websites zu orientieren. Damit sind nicht vorrangig User:innen von Screenreadern gemeint, sondern vor allem Personen mit Lernbeeinträchtigungen oder Konzentrationsschwierigkeiten.
Lösung
Den Button einfach immer anzeigen. Nicht einfach Elemente ausblenden, obwohl mehr als genug Platz da ist, um sie darzustellen.
Lehre
Verändert keine Hauptelemente der Navigation, wenn es keinen Grund dafür gibt.
10.2 Farbkontraste
Dies ist wahrscheinlich die bekannteste Barriere im Bereich Accessibility, und trotzdem wird sie besonders oft falsch gemacht. Tatsächlich ist mangelnder Farbkontrast sogar das häufigste Barrierefreiheitsproblem im gesamten Internet – 79 % aller Websites waren 2024 davon betroffen. (Quelle: https://webaim.org/projects/million/)
Problem
«Teils ist das Kontrastverhältnis von Inhalten unzureichend, so bei den Fehlermeldungen im Newsletter-Formular.»
Lösung
Den Rotton etwas dunkler machen.
Problem
«Teils fällt das Kontrastverhältnis von Inhalten auf unzureichende 2.4:1.»
Der Kontrast muss 4.5:1 betragen um den Standard WCAG 2.0 AA zu erfüllen. (Quelle: https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html)
Lösung
Statt pinkem Text auf bläulichem Hintergrund verwenden wir nun schwarzen Text. Ein positiver Nebeneffekt: Die Designer:innen mussten sich jetzt einen anderen Ansatz überlegen, um die Informationen zu differenzieren, was zu einem insgesamt besseren Ergebnis führte.
Problem
«Die pinke Farbe funktioniert bei nicht-weissem Hintergrund nicht mehr, das Kontrastverhältnis wird dort mit 2.8:1 unzureichend.»
Diesen Button habt ihr jetzt bereits mehrfach gesehen. Vielleicht habt ihr euch schon gedacht, dass auch er gar nicht so leicht zu lesen ist. Es liegt also auf der Hand, hier ebenfalls die Farben anzupassen – oder?
Lösung
Statt die Farben zu verändern, hat sich jemand durch verschiedene Metriken gewühlt und ausgerechnet, dass der Kontrast gerade so ausreichen könnte, wenn der Text fett gesetzt ist. Deshalb müssen wir jetzt immer, wenn weisser Text auf pinkem Hintergrund steht, die Schriftstärke auf «fett» ändern – zum Zeitpunkt des Reviews wurde der Button bereits als so zentrales Gestaltungselement angesehen, dass man sich nicht mehr traute, ihn zu verändern.
Lehre
Hört auf die Personen, die so etwas schon einmal gemacht haben. Veränderungen während der Entwicklung können zu spät kommen, wenn es um grundlegende Design-Entscheidungen geht.
Bestellt jetzt sofort ein Accessibility-Review!
Euer Projekt – und ihr selbst als Entwickler:innen – werdet auf vielen Ebenen davon profitieren:
- Wenn mehrere Parteien an einem Projekt beteiligt sind, kommt es oft zu Diskussionen. Ein Review beendet diese – es sollte so gemacht werden, wie die Expert:innen es empfehlen.
- Ein Review findet besonders gut Flüchtigkeitsfehler. Die meisten Beispiele in diesem Artikel sind nicht aus Unwissenheit entstanden, sondern aus Versehen.
- Ihr könnt unglaublich viel lernen, nur durchs Machen! Statt durch Bedenken gelähmt kaum starten zu können, solltet ihr einfach anfangen und eure Arbeit dann echten Expert:innen zeigen. Je mehr Reviews ihr lesen werdet, desto mehr Wissen werdet ihr erlangen und umso sicherer werdet ihr in zukünftigen Projekten sein.
- Nachdem wir mit dem Review für prohelvetia.ch gearbeitet hatten, bestellten wir bei required direkt ein weiteres für unsere eigene Website, um zu sehen, wo wir uns selbst auch noch verbessern können.
- To-do-Listen sind toll! Kaum etwas befriedigt mehr, als Schritt für Schritt alle Boxen abzuhaken. Ein Accessibility-Review gibt euch also das perfekte Format, um euer Projekt zu verbessern.
- Niemand ist perfekt und niemand baut von Anfang an perfekte Websites. Besonders nicht in einem so veränderlichen und komplexen Feld wie der Barrierefreiheit. Deshalb ist das Mindeste, das wir tun können: Versuchen, mit jedem Tag und jedem Projekt ein wenig besser zu werden.
Ich weiss, dass ich das tun werde. Und ich hoffe, ihr macht es auch so!
