Barrierefreies Webdesign, das hochwertig aussieht

Von Manuel Hack, ihp media · Aktualisiert am 16. Juni 2026

Wer zum ersten Mal mit Barrierefreiheit in Berührung kommt, denkt oft an trostlose Hochkontrast-Schemata aus den frühen 2000ern oder an schwarzen Text auf weißem Grund, dem jede Gestaltung fehlt. Dieses Bild hält sich hartnäckig. Es stimmt nicht. Dieser Artikel zeigt, warum Barrierefreiheit und hochwertiges Design dieselbe Sprache sprechen, und zwar mit konkreten Kriterien statt mit allgemeinen Behauptungen.

Das Vorurteil und warum es falsch liegt

Das Missverständnis hat einen Ursprung: Frühe Barrierefreiheits-Tools und behördliche Vorgaben für öffentliche Stellen haben Designs erzeugt, die Funktion über alles andere stellten. Gut gemeint, aber optisch rau. Daraus entstand die falsche Gleichung: barrierefrei gleich hässlich.

Schauen wir uns an, was WCAG 2.2 Stufe AA tatsächlich vorschreibt. Das Dokument regelt vier Prinzipien: wahrnehmbar, bedienbar, verständlich, robust. Es schreibt kein Farbschema vor, keine Schriftart, keinen Stil. Es sagt: Text und Hintergrund müssen ausreichend kontrastieren. Interaktive Elemente müssen per Tastatur erreichbar sein. Fokuszustände müssen sichtbar sein. Animationen müssen sich abschalten lassen.

Was die besten Websites der Welt auszeichnet, deckt sich weitgehend mit diesen Anforderungen. Apple, Stripe oder das Gov.uk-Design-System gelten als Maßstab für modernes, reduziertes Webdesign. Alle drei halten WCAG AA ein oder übertreffen es. Das ist kein Zufall: Klarheit und Bedienbarkeit sind dort nicht als Barrierefreiheits-Kompromiss entstanden, sondern als Designüberzeugung.

Das Barrierefreiheitsstärkungsgesetz (BFSG) verstärkt seit dem 28. Juni 2025 den Druck, sich mit diesen Kriterien zu befassen. Wer Verbrauchern digitale Dienstleistungen oder Waren anbietet, muss die Anforderungen einhalten. Die vollständige BFSG-Einordnung für Onlineshops liefert der Artikel BFSG und Onlineshop: Was Händler wissen müssen.

Kontrast schön lösen: Wie 4,5:1 keine Einschränkung ist

WCAG 2.2 Kriterium 1.4.3 verlangt für normalen Fließtext ein Kontrastverhältnis von mindestens 4,5:1 zwischen Schrift und Hintergrund. Für große Texte (ab 18 Punkt oder ab 14 Punkt fett) genügen 3:1. Der WebAIM Million 2026 zeigt, dass 83,9 % aller analysierten Startseiten diesen Wert nicht erreichen. Das ist kein Designproblem, sondern ein Sorgfaltsproblem.

Was bedeutet 4,5:1 in der Praxis? Die Kombination aus tiefem Marineblau (#0E2F50) auf Warmweiß (#FAF8F5) liegt bei etwa 14:1, also weit über dem Minimum. Dunkelgrau (#333333) auf Hellgrau (#F5F5F5) kommt auf etwa 9,7:1. Selbst ein warmer Cognac-Ton (#8B4513) auf hellem Creme (#FFF8E7) schafft knapp 5:1. Die Palette entscheidet, nicht der Maßstab.

Was tatsächlich fällt: Pastellfarben auf weißem Grund, dünne Schriftschnitte (Thin, ExtraLight) in kleiner Größe, grauer Hilfetext unter Formularfeldern, und die beliebten hellgrauen Platzhaltertexte. Das sind keine großen Designentscheidungen, die zu opfern wären. Es sind Detailfehler in der Farbwahl, die mit einem freien Kontrast-Tool wie dem WAVE-Browser-Plugin in Minuten gefunden werden. Den Prüfprozess mit konkreten Schwellenwerten beschreibt der Ratgeber Farbkontrast nach WCAG richtig prüfen.

Zusätzlich regelt WCAG 2.2 Kriterium 1.4.11 den Kontrast von Nicht-Text-Elementen: Icons, Eingabefeld-Rahmen und Status-Indikatoren brauchen mindestens 3:1. Das fällt in Formularen besonders oft auf, wo hellgraue Feldränder auf weißem Hintergrund kaum sichtbar sind. Auch hier ist die Korrektur kleiner als befürchtet: ein etwas dunklerer Rand-Farbton, der trotzdem in die Palette passt.

Fokus-Stile als Designelement

Kein Thema spaltet Webdesigner mehr als der Fokusring. Standardmäßig zeigt jeder Browser einen Rahmen um das per Tastatur aktive Element. Für rein mausbasierte Nutzer sieht er seltsam aus, wenn er nach einem Klick erscheint. Die Reaktion vieler Designer: outline: none ins globale CSS, und das Problem ist weg. Damit ist auch die Orientierung für alle weg, die auf Tastaturnavigation angewiesen sind.

WCAG 2.2 Kriterium 2.4.7 fordert sichtbare Fokus-Indikatoren auf Konformitätsstufe AA. Mit WCAG 2.2 kommt das verschärfte Kriterium 2.4.13 (Fokus-Darstellung) auf Stufe AAA hinzu, das Kontrast und Mindestgröße des Fokusindikators regelt: mindestens 3:1 zum Hintergrund, und der Fokusindikator muss mindestens so groß sein wie der Umfang des fokussierten Elements mit einem 1 CSS-Pixel Rahmen.

Die Lösung ist einfacher als der Konflikt, der daraus gemacht wird. CSS liefert :focus-visible: Diese Pseudo-Klasse zeigt den Fokusring nur dann, wenn der Browser annimmt, dass er nützlich ist, also bei Tastaturnavigation, aber nicht nach einem Mausklick. Damit ist das optische Problem behoben, ohne die Zugänglichkeit zu opfern.

Und weiter: Ein Fokusring muss nicht der Browser-Standard sein. Er kann und sollte Teil des Designsystems sein. Ein 2 px Offset-Outline in der Akzentfarbe des Brands, ein Box-Shadow in Markenfarbe, ein leichter Hintergrundwechsel am aktiven Element. Das Gov.uk-Design-System zeigt das beispielhaft: ein leuchtend gelber Fokusring, der mit dem schlichten blauen Design kontrastiert und gerade deshalb sofort erkennbar ist. Bei ihp media ist der Fokusring in der Goldfarbe des Systems umgesetzt, konsistent über alle interaktiven Elemente.

Typografie: Wenn Lesbarkeit automatisch gut aussieht

Gute Typografie und barrierefreie Typografie sind fast deckungsgleich. Die Mindestschriftgröße von 16 px für Fließtext, die von Barrierefreiheits-Prüfern empfohlen wird, ist dieselbe, die erfahrene Typografen für Lesetext auf Screens ansetzen. Ein Zeilenabstand von mindestens 1,5-fach, wie er in WCAG 2.2 Kriterium 1.4.12 (Textabstand) als Test-Bedingung auftaucht, entspricht dem, was lesbare Webseiten ohnehin setzen.

Konkret heißt das: Eine Seite, die auf 16–18 px Fließtext, 1,5-fachen Zeilenabstand und ausreichend Absatz-Abstand setzt, braucht für Barrierefreiheit keine separate Anpassung. Der Unterschied zu einer schlecht gestalteten Seite liegt nicht darin, was hinzugefügt wird, sondern darin, was weggelassen wird: zu kleine Schriftgrade, zu enge Zeilenhöhen, zu wenig Weißraum.

Schriftarten mit zu dünnen Strichstärken oder extrem niedriger x-Höhe (das Verhältnis von Kleinbuchstaben zu Großbuchstaben) können auch bei korrektem Kontrast schwer lesbar wirken. Das ist keine WCAG-Pflicht, aber ein handwerklicher Standard. Wer auf System-Fonts oder gut gepflegte Webfonts mit normaler Stärke (Regular, Medium) setzt, trifft damit Zugänglichkeit und Lesbarkeit gleichzeitig.

Ein Punkt, der oft übersehen wird: WCAG 2.2 Kriterium 1.4.4 (Schriftgröße ändern) verlangt, dass Text bis zu 200 % vergrößert werden kann, ohne dass Inhalt oder Funktion verloren geht. Das klingt nach einem technischen Detail, entscheidet aber darüber, ob ältere Nutzer oder Personen mit Seheinschränkungen eine Seite sinnvoll nutzen können. In der Praxis bedeutet das: keine fixen Pixel-Einheiten für Texte in Containern mit fester Breite, sondern relative Einheiten (rem, em) und flexible Layouts.

Bewegung und Animation barrierearm gestalten

Animationen auf einer Website können hochwertig wirken, störend sein oder im schlimmsten Fall gesundheitlichen Schaden verursachen. Menschen mit vestibulären Störungen oder Epilepsie reagieren auf Bewegung, Parallax-Effekte und schnelle Übergänge. Das ist keine Minderheit: Vestibuläre Störungen betreffen schätzungsweise 35 % der Bevölkerung über 40 Jahren in irgendeiner Form.

WCAG 2.2 Kriterium 2.3.3 (Bewegung durch Interaktionen, Stufe AAA) empfiehlt, Animationen auf Anfrage abschaltbar zu machen. Verbindlich auf Stufe AA ist Kriterium 2.2.2: Bewegte oder automatisch aktualisierende Inhalte müssen pausierbar, stoppbar oder ausblendbar sein.

Die praktische Lösung ist eine Media Query, die seit Jahren in modernen Browsern funktioniert:

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Diese sechs Zeilen greifen auf die Systemeinstellung des Nutzers: Wer in macOS, Windows oder iOS „Bewegung reduzieren“ aktiviert hat, bekommt damit eine statische oder sehr kurze Version aller Transitionen. Die Animations-Konzeption bleibt erhalten, die Ausführung passt sich an. Das ist kein Stilopfer, sondern eine responsivere Art zu denken.

Scroll-animierte Elemente, Parallax-Hintergründe und große Hero-Animationen können alle weiterlaufen, wenn das Betriebssystem keine Einschränkung meldet. Wer dagegen die Media Query ignoriert und großzügige Animationen unbegrenzt auf alle ausspielt, riskiert genau die Nutzer zu verlieren, die ohnehin weniger Toleranz für Hürden haben.

Klickziele und Touch-Flächen

Mit WCAG 2.2 kommt Kriterium 2.5.8 (Zielgröße, Minimum) auf Stufe AA neu hinzu. Es verlangt, dass interaktive Elemente mindestens 24 x 24 CSS-Pixel groß sind, oder aber ausreichend Abstand zu benachbarten Elementen haben, damit eine 24 x 24 Pixel große Offsets-Fläche den nächsten Treffer nicht überlappt.

Apple empfiehlt für Touch-Targets mindestens 44 x 44 Pixel. Das ist ein Handwerk-Standard, der seit iOS HIG (Human Interface Guidelines) gilt, nicht eine Barrierefreiheitsforderung. In der Praxis schneiden viele WordPress-Themes schlecht ab: Icon-only-Schaltflächen (Pfeil-Icons in Slidern, X-Buttons in Modals) sind oft 16 x 16 Pixel groß. Sie schaden allen Nutzern auf Touch-Screens und Menschen mit eingeschränkter Motorik gleichzeitig.

Größere Klickziele sehen auf Desktop nicht zwingend anders aus. Padding um ein kleines Icon vergrößert die Trefferfläche, ohne das Icon selbst zu verändern. Das ist eine CSS-Entscheidung, keine Design-Revision. Und sie verbessert die Bedienbarkeit auf Mobilgeräten so messbar, dass Google sie in die Core Web Vitals-verwandten Metriken einbezieht.

Designaspekte im Vergleich

Praxisbeispiel: Wie ein Redesign beides gewinnt

In einem Projekt überarbeiteten wir die Website eines mittelständischen Beratungsunternehmens. Der Auftraggeber hatte eine klare Anforderung: hochwertigeres Erscheinungsbild, moderner, mehr Vertrauen bei Großkunden. Barrierefreiheit stand nicht explizit auf der Liste.

Im Audit vor dem Redesign fanden wir sechs kritische WCAG-Probleme: Kontrastverhältnisse zwischen 2,8:1 und 3,9:1 für Fließtext, entfernter Fokusring mit outline: none, Formularfelder ohne verknüpfte Labels, 14 px Schriftgröße im Haupttext, und Icon-only-Navigation im mobilen Header ohne erkennbare Beschriftung. Das Lighthouse-Barrierefreiheits-Score lag bei 61.

Das Redesign arbeitete mit den gleichen Anforderungen, die gutes Design ohnehin stellt: klarere Hierarchie, mutigere Typografie, ruhigere Farbwelt. Wir setzten auf ein tiefes Navy-Blau und ein gebrochenes Weiß als Basis, 18 px Fließtext in einem modernen Serif mit guter x-Höhe, ausreichend Weißraum zwischen Elementen, und einen Fokusring in der Goldfarbe des Markensystems.

Nach dem Redesign: Lighthouse Barrierefreiheit 98, alle Textkontrastwerte zwischen 7:1 und 14:1, Fokusring präsent und konsistent gestaltet, Formular mit korrekten Labels. Die visuellen Änderungen, die diese Verbesserungen gebracht haben, waren dieselben, die der Auftraggeber für das hochwertigere Erscheinungsbild gefordert hatte. Barrierefreiheit und Designqualität waren hier nicht zwei Projekte, sondern eines.

Mehr zu den greifbaren Vorteilen jenseits der Pflicht liefert der Artikel Barrierefreiheit als Vorteil: Mehr als eine Pflicht.

Sofort-Checkliste

• Fließtext und Hintergrund: Kontrastverhältnis mit WAVE oder Axe messen, Mindestwert 4,5:1 überprüfen?
• Graue Hilfetexte unter Formularfeldern: Kontrast geprüft (fallen meist bei 2–3:1 durch)?
• Globales CSS auf outline: none oder outline: 0 durchsuchen, gefundene Stellen durch :focus-visible-Regeln ersetzen?
• Fokusring gestaltet und in das Designsystem integriert, nicht nur Browser-Standard?
• Fließtext in rem oder em angegeben, keine fixen px-Größen für Body-Text?
• Zeilenabstand mindestens 1,5 im Haupttext gesetzt?
• @media (prefers-reduced-motion: reduce) im Stylesheet vorhanden?
• Touch-Flächen für Buttons und Links mindestens 44 x 44 px (mit Padding)?
• Links durch mehr als Farbe erkennbar (Unterstreichung oder anderes Merkmal)?
• Fehler- und Status-Meldungen durch Icon oder Text, nicht nur Farbe signalisiert?

Häufige Fragen

Schränkt WCAG 2.2 meine Farbwahl ein?

Nein, nicht grundsätzlich. WCAG 2.2 regelt das Verhältnis zwischen Vorder- und Hintergrundfarbe, nicht die Farben selbst. Mit einer bewusst zusammengestellten Palette, die ausreichend Tiefe hat, lässt sich der Mindestwert von 4,5:1 für Fließtext in praktisch jeder Farbwelt einhalten. Was wegfällt: sehr helle oder sehr ähnliche Farbkombinationen, die erfahrungsgemäß ohnehin Lesbarkeit kosten.

Muss ich auf Animationen ganz verzichten?

Nein. Animationen sind erlaubt und können die Qualität einer Website steigern. Was WCAG verlangt: Nutzern muss es möglich sein, Bewegung zu reduzieren oder zu stoppen. Die CSS-Media-Query prefers-reduced-motion löst das technisch elegant, ohne sichtende Nutzer ohne diese Systemeinstellung zu betreffen.

Was ist :focus-visible, und warum ist es besser als :focus?

:focus greift bei jedem Fokus-Ereignis, also auch nach einem Mausklick. Das sieht für Mausnutzer seltsam aus. :focus-visible zeigt den Fokusring nur dann, wenn der Browser die Eingabemethode als nicht-mausbasiert einschätzt. Das liefert den Fokusring für Tastaturnutzer, ohne ihn Mausnutzern aufzuzwingen. Alle modernen Browser unterstützen es.

Wie groß muss ein Button oder Link mindestens sein?

WCAG 2.2 Kriterium 2.5.8 verlangt mindestens 24 x 24 CSS-Pixel als Trefferfläche oder ausreichend Abstand zum nächsten interaktiven Element. Apple und Google empfehlen für Touch-Interfaces 44 x 44 Pixel. Das lässt sich mit Padding um ein kleineres Icon erreichen, ohne das visuelle Design zu verändern.

Wirkt sich Barrierefreiheit auf das Google-Ranking aus?

Nicht direkt. Google bewertet keine WCAG-Konformität als Rankingfaktor. Aber viele barrierefreie Eigenschaften decken sich mit den Signalen, die Google bewertet: semantische Struktur, lesbare Schriftgrößen, schnelle und klare Bedienbarkeit, niedrige Absprungrate durch bessere Nutzererfahrung. Der indirekte Effekt ist real, auch wenn er kein direkter Rankingfaktor ist.

Ich habe ein bestehendes Design. Wie viel muss ich ändern?

Das hängt vom Ausgangszustand ab. Ein Audit mit Axe oder WAVE zeigt innerhalb von Minuten, wo Kontrastwerte und offensichtliche Fehler liegen. Die häufigsten Nachbesserungen, Kontrast-Korrekturen und Fokus-Stile, betreffen meist wenige CSS-Zeilen, kein Redesign. Wie ein solcher Audit strukturiert aussieht, beschreibt die Übersicht der 12 häufigsten Barrieren.