Home Blog Barrierefreiheit in freier Wildbahn: Pro Helvetia, ein Schweizer Beispiel

Barrierefreiheit in freier Wildbahn: Pro Helvetia, ein Schweizer Beispiel

Avatar von Jeff Chi
Eine Illustration einer Hand, die eine Backsteinmauer durchschlägt.

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.

Das Video meines Vortrags wird in Kürze hier veröffentlicht!

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?

Eine Illustration einer Person, die eine Papiertüte über dem Kopf trägt, auf welche ein Fragezeichen gezeichnet ist.

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.

Eine Illustration eines Mannes, der lustig lächelt, während er mit einem Hammer auf einen alten Computer schlägt.

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)
Eine Illustration eines Mannes, der sich hinter einer Ziegelmauer versteckt.

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.

Eine Illustration einer Hand, die eine Backsteinmauer durchschlägt.

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.

Eine Illustration der Schweiz, überlagert von einer Weltkarte. Die Pfeile zeigen von der Schweiz weg zu Punkten in Südamerika, Afrika und Asien.

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.

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.

Eine Animation, die einen Zoom auf das Logo der Pro-Helvetia-Website zeigt.
<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.

Eine Animation, die einen Zoom auf den Call-To-Action-Button «Förderung finden» in der Hauptnavigation zeigt.
<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 legend zur fieldset formatiert.»

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.

Eine Animation, die das Öffnen des Such-Dialogs und dann einen Zoom auf Schaltflächen mit Suchvorschlägen unter der Bezeichnung «Vorschläge» zeigt.
<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 div und span

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.

Eine Animation, die einen Zoom auf den Text «Pro Helvetia, Schweizer Kulturstiftung» im Footer zeigt.
<div>
  PRO HELVETIA<br />
  Schweizer Kulturstiftung
</div>Code-Sprache: HTML, XML (xml)

Quellen:

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.

Ein Screenshot der Pro-Helvetia-Homepage mit einer News-Rubrik «What's on» und einem Pre-Footer-Bereich mit Newsletter-Anmeldeformular «Bleiben Sie auf dem Laufenden.».
<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.

Eine Animation, die zeigt, wie eine Überschrift im WordPress-Blockeditor von h3 auf h2 geändert wird. Anschließend wird die Schriftgröße auf Extra-Gross gesetzt.
<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.

Eine Animation, die zeigt, wie ein Link in der Schnellnavigation angeklickt wird und einen schwarzen Hintergrund erhält, sobald er aktiv ist.

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.

Eine Animation, die das Öffnen des Such-Dialogs und dann einen Zoom auf die Suchschaltfläche mit Lupensymbol zeigt.
<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.»

Ein Screenshot eines weissen und eines schwarzen Dropdown-Elements auf einem rosa Hintergrund.

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.

Eine Animation, die das Umschalten zwischen zwei Buttons zeigt und die pinke Outline als Fokusstil demonstriert.

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.

Eine Animation, die das Umschalten zwischen zwei Dropdowns zeigt, mit einer schwarzen Outline als Fokusstil für das weisse Dropdown und einer weissen als Fokusstil für das schwarze.

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.

Eine Animation, die das Filtern einer Ergebnisliste mithilfe eines Dropdowns zeigt. Die Anzahl der angezeigten Ergebnisse ändert sich von 100 auf 20.

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 WordPressJavaScript-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.

Ein Screenshot eines Newsletter-Anmeldeformulars mit leuchtend rotem Text als Fehlermeldung.
Ein Screenshot eines Newsletter-Anmeldeformulars mit dunkelrotem Text als Fehlermeldung.

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.

Ein Screenshot eines Karten-Elements mit einem pinken Link auf bläulichem Hintergrund.
Ein Screenshot eines Karten-Elements mit schwarzem Text und Links in verschiedenen Größen auf bläulichem Hintergrund.

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.

Ein Screenshot eines pinken Call-To-Action-Buttons mit weissem Text.
Ein Screenshot eines pinken Call-To-Action-Buttons mit fettem, weissem Text.

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.