Kontraste, Vergrößerung und schmale Ansichten testen
WCAG-Kriterien mit echten Browserwerten untersuchen und Vergrößerungswege präzise auseinanderhalten.
Lesbarkeit umfasst Farbe, Platz und tatsächliche Bedienung
Eine gut lesbare Webseite braucht mehr als eine gefällige Schrift. Menschen müssen Text erkennen, ihn vergrößern und dabei weiterhin die zugehörigen Funktionen erreichen können. Kontrast, Schriftvergrößerung und schmale Ansichten hängen zusammen, besitzen aber unterschiedliche Prüfbedingungen. Ein kräftiger Farbwert verhindert keinen abgeschnittenen Absatz. Ein umbrechender Absatz beweist wiederum nicht, dass eine wichtige Schaltfläche ausreichend sichtbar bleibt.
Unser eigener Entwurf enthält eine fiktive Kursinformation mit Absätzen, einem langen Begriff, einem Link, einem Eingabefeld und einer kleinen Beispielaktion. Er nimmt keine Anmeldung entgegen und sendet keine Daten. Die Gestaltung verwendet warme helle Flächen, dunkle Schrift und ein deutliches Rot. Eine zusätzliche dunkle Darstellung erhält passende eigene Farbwerte. Der Beitrag zeigt die vollständigen Dateien und die tatsächlich daran ausgeführten Untersuchungen.
192 Bedingungen wurden in Node und Edge ausgeführt. Dazu gehören berechnete Farbpaare, drei Inhaltsbreiten, fünf Schriftstufen und wirkliche Bedienhandlungen. Bewusst eingebaute Gegenbeispiele prüfen außerdem, ob unsere Instrumente schlechte Kontraste, eine zu breite Mindestfläche und abgeschnittenen Text überhaupt erkennen. Die Ergebnisse beziehen sich auf diesen kleinen Entwurf. Sie sind kein vollständiger Nachweis aller WCAG-Kriterien oder der rechtlichen Konformität einer ganzen Webseite.
Drei Fragen mit drei passenden Nachweisen beantworten
Die erste Frage lautet, ob die relevante Information gegenüber ihrer Umgebung ausreichend unterscheidbar ist. Dazu werden tatsächlich berechnete Vordergrund- und Hintergrundfarben untersucht. Die zweite betrifft die Vergrößerbarkeit des Textes. Dafür verändert unser Versuch die Wurzelschrift und beobachtet Umbrüche sowie Bedienung. Die dritte Frage betrifft den verfügbaren Raum: Bleibt der Inhalt in einem schmalen Bereich ohne waagerechtes Lesen erreichbar?
Diese Fragen sind nicht austauschbar. Eine auf 320 CSS-Pixel gesetzte Ansicht ist keine tatsächlich ausgeführte Browserzoomhandlung. Eine Verdoppelung der Wurzelschrift ist ebenfalls kein Vollseitenzoom. Unser Bericht nennt genau den jeweiligen Eingriff. Dadurch lässt sich beurteilen, welche Aussage das Ergebnis trägt und welcher zusätzliche Benutzerweg für eine reale Abnahme noch auszuführen ist.
Die WCAG verstehen Barrierefreiheit als Verbindung vieler überprüfbarer Anforderungen. Hier konzentrieren wir uns auf die zusammenhängenden visuellen Bedingungen. Tastaturbedienung und sichtbarer Fokus werden ergänzend im konkreten Beispiel erprobt. Eine kleine erfolgreiche Auswahl darf trotzdem nicht als Ersatz für eine vollständige Prüfung von Struktur, Alternativtexten, Fehlern, Hilfstechnologien oder komplexen Dialogen ausgegeben werden.
Textkontrast anhand der tatsächlichen Farben berechnen
Für gewöhnlichen Text fordert WCAG 2.2 in Erfolgskriterium 1.4.3 grundsätzlich mindestens 4,5 zu 1. Für entsprechend großen Text gilt ein niedrigerer Grenzwert von 3 zu 1. Der Versuch verwendet für seine ausgewählten Textpaare durchgehend den strengeren Wert 4,5 zu 1. So muss die kleine Berechnung nicht selbst entscheiden, ob ein bestimmter Schriftschnitt bereits als großer Text einzuordnen ist.
Die Werte werden aus getComputedStyle gelesen. Es geht also um die vom Browser berechneten Farben des aktuellen Zustands und nicht nur um eine nicht verwendete Variable in einer Gestaltungsdatei. Der Text eines Buttons wird gegen seine eigene Fläche geprüft. Ein Link auf der Seite wird gegen die tatsächliche Seitenfläche geprüft. Die Zuordnung des richtigen Hintergrunds ist ein ausdrücklich entwickelter Teil jedes Falls.
Unser kleiner Parser akzeptiert nur aufgelöste deckende rgb-Farben. Transparenz, Bilder, Verläufe und überlagerte Flächen werden nicht automatisch verrechnet. Bei einer solchen Eingabe bricht er mit einem Fehler ab. Das ist ehrlicher als eine scheinbar genaue Zahl aus einem unbekannten Hintergrund. Eine reale Komponente mit anderen Darstellungsbedingungen braucht eine entsprechend erweiterte Ermittlung ihrer tatsächlich angrenzenden Farben.
Die Rechnung erklären und Grenzwerte nicht schönrunden
Die Hilfsfunktion wandelt drei sRGB-Kanäle zunächst in lineare Werte um. Daraus entsteht die relative Leuchtdichte mit den dafür festgelegten Gewichtungen. Das Verhältnis der helleren zur dunkleren Fläche wird anschließend mit dem vorgesehenen Zuschlag berechnet. Die vollständige Funktion ist kurz genug, um ihre Eingabegrenzen und den Rechenweg direkt nachzuvollziehen. Sie untersucht ausdrücklich deckende sRGB-Farbpaare.
Schwarz auf Weiß ergibt im Test genau 21 zu 1. Zwei gleiche Farben ergeben 1 zu 1. Das Vertauschen von Vordergrund und Hintergrund verändert das Verhältnis nicht. Auch ungültige Werte außerhalb des Kanalbereichs und NaN werden tatsächlich abgewiesen. Diese Fälle prüfen die Berechnung selbst, bevor sie zur Bewertung der Browserwerte verwendet wird.
Die Entscheidung verwendet den ungerundeten Wert. Erst für eine Tabelle wird die Zahl lesbar formatiert. Das Paar aus dem Grauwert 119 und Weiß bleibt unter 4,5, auch wenn eine ungeschickte Rundung einen günstigeren Eindruck erzeugen könnte. Ein Grenzwert darf nicht durch die Zahlendarstellung überschritten werden. Gleichzeitig ersetzt ein rechnerisch ausreichendes Verhältnis keine visuelle Beurteilung sehr feiner oder schwer erkennbarer Schrift.
Gemessene Textpaare sinnvoll interpretieren
Im hellen Entwurf erreicht die gewöhnliche Schrift gegen die warme Fläche rund 14,03 zu 1. Der zurückhaltendere Hinweis liegt bei rund 6,34. Der rote Link erreicht rund 6,04. Weiße Schrift auf der roten Schaltfläche liegt bei rund 6,73. Diese Zahlen stammen aus den tatsächlich berechneten Farbwerten des ausgeführten Beispiels. Sie beschreiben keine fremde Produktionsseite und keine allgemein vorgeschriebene CI-Palette.
Im dunklen Entwurf bleiben die gewöhnlichen Textfarben umgekehrt bei rund 14,03. Der hellere Hinweis erreicht rund 8,49. Der helle rote Akzent gegen die dunkle Fläche liegt bei rund 7,69. Die Schaltfläche verwendet dort dunkle Schrift auf diesem Akzent. Einfach dieselbe rote Textfarbe aus der hellen Darstellung weiterzuverwenden wäre keine ausreichende Gestaltungsentscheidung. Beide Zustände besitzen deshalb eigene überprüfte Zuordnungen.
Die Berechnung erfasst ausgewählte repräsentative Elemente und den untersuchten Hoverzustand des Buttons. Sie behauptet keine automatische vollständige Suche nach jedem denkbaren Text auf der Seite. Für größere Systeme wird eine solche Paarliste um Varianten, Fehlermeldungen, Platzhalter, ausgewählte Zustände und weitere Flächen ergänzt. Ein kleiner überprüfbarer Bestand ist ein sinnvoller Anfang, wenn seine Grenzen ausdrücklich erhalten bleiben.
Feldgrenzen und Fokus als eigene Information behandeln
Neben Text braucht auch relevante nichttextliche Information einen erkennbaren Unterschied zur angrenzenden Umgebung. Erfolgskriterium 1.4.11 beschreibt hierfür grundsätzlich 3 zu 1. Nicht jede dekorative Linie besitzt dieselbe Aufgabe. In unserem Beispiel wird die Feldumrandung ausdrücklich gegen die angrenzende Seitenfläche untersucht. Der sichtbare Fokus erhält zusätzlich eine eigene kontrastreiche Farbe und einen klaren Abstand zum Element.
Die Prüfung betätigt Tab tatsächlich. Zuerst wird der Inhaltslink erreicht, danach das Eingabefeld und anschließend die Schaltfläche. Für die Schaltfläche wird der Zustand focus-visible sowie eine mindestens drei Pixel breite Kontur beobachtet. Auch ihr Verhältnis zur umgebenden Fläche wird berechnet. Die Kontur liegt durch den Abstand sichtbar außerhalb der Schaltfläche und verliert sich nicht in deren eigener Füllfarbe.
Daraus folgt keine vollständige Aussage über jede Fokusanforderung der WCAG. Überdeckungen durch feste Kopfzeilen, andere Dialoge und zusätzliche Komponenten fehlen in diesem kleinen Entwurf. Wichtig ist die Verbindung von tatsächlicher Tastaturhandlung und überprüfter Darstellung. Eine deklarierte Outline in einer Datei wäre wenig wert, wenn sie am wirklichen Element überschrieben oder abgeschnitten würde.
Mit relativen Schriftgrößen einen untersuchbaren Entwurf bauen
Die Oberfläche verwendet rem für die grundlegenden Schriftgrößen. Ihre Absätze erben die Wurzelschrift, während die Überschriften darauf aufbauen. Das Eingabefeld und die Schaltfläche übernehmen mit font inherit die vorhandene Schrift. Es gibt keine feste Texthöhe, die einen mehrzeiligen Inhalt verdeckt. Die Abstände können mit dem Inhalt wachsen und die Buttonbeschriftung darf umbrechen.
Eine maximale Inhaltsbreite begrenzt lange Zeilen, ohne eine große Mindestbreite zu erzwingen. Die innere Fläche verwendet einen begrenzten flexiblen Abstand. Die kleinen Informationsfelder wechseln über das Raster in eine passende Spaltenzahl. min-width null erlaubt den betroffenen Bereichen, tatsächlich kleiner als eine lange untrennbare Inhaltsannahme zu werden. Damit arbeiten Größen und Umbrüche zusammen, statt sich gegenseitig zu blockieren.
Relative Einheiten sind keine automatische Garantie. Auch rem-basierte Elemente können sich durch unpassende Mindestbreiten, feste Höhen oder Überlagerungen gegenseitig verdecken. Deshalb wird der fertige Browserzustand untersucht. Der Nutzen der Einheiten liegt darin, einen nachvollziehbaren Zusammenhang zwischen Text und Platz zu entwickeln. Die eigentliche Abnahme betrifft weiterhin den sichtbaren Inhalt und die erreichbare Funktion.
Die Schrift tatsächlich in fünf Stufen verändern
Der Versuch setzt die Wurzelschrift nacheinander auf 100, 125, 150, 175 und 200 Prozent. Für jeden Zustand liest er die berechnete Größe des Einleitungsabsatzes zurück. Sie steigt tatsächlich von 16 auf 32 CSS-Pixel. Dieselben Schritte werden bei 320, 390 und 1440 Pixeln Breite in heller und dunkler Darstellung durchgeführt. So entstehen 30 klar zugeordnete Kombinationen.
Zu jeder Kombination gehören Prüfungen auf Seitenüberlauf, die beobachtete Blockgeometrie, den unveränderten Überschriftentext und eine tatsächliche Beispielhandlung. Der Button wird nicht nur auf einem Bild gesucht. Ein fiktiver Wert wird eingetragen und die Auswahl tatsächlich ausgeführt. Danach erscheint die erwartete Statusmeldung. Größerer Text soll die Anwendung weiterhin nutzbar lassen und nicht bloß in einem isolierten Absatz gut aussehen.
Dieser Eingriff ist eine kontrollierte Veränderung der Wurzelschrift über eine zusätzliche Stilregel. Er ist ausdrücklich kein ausgeführter Browserzoom und keine vollständige Nachbildung jeder persönlichen Schriftkonfiguration. Für eine reale Freigabe kommen die tatsächlich angebotenen Vergrößerungswege der unterstützten Browser hinzu. Der kleine Versuch bleibt trotzdem nützlich, weil er seine Veränderung exakt dokumentiert und deren Wirkung am ausgeführten Inhalt nachweist.
Den Bezug zwischen 320 Pixeln und 400 Prozent richtig verwenden
Erfolgskriterium 1.4.10 beschreibt für vertikal gelesene Inhalte eine Breite entsprechend 320 CSS-Pixeln ohne Verlust von Information oder Funktion und ohne notwendiges Scrollen in zwei Richtungen. Die WCAG erläutern den Bezug zu einer ursprünglich 1280 Pixel breiten Ansicht bei 400 Prozent Zoom. Dieser Zusammenhang erklärt die Prüfbreite. Er macht aus jeder schmalen Vorschau jedoch noch keinen tatsächlich ausgeführten Zoomtest.
Unser Browser bekommt eine Inhaltsbreite von 320 CSS-Pixeln. Der Bericht bezeichnet das genau so. Es wird weder die physische Displayauflösung verändert noch eine bestimmte Vergrößerung in der Browseroberfläche vorgetäuscht. Damit lässt sich die schmale Layoutvariante verlässlich untersuchen. Die zusätzliche manuelle Zoomhandlung auf der wirklichen Zielumgebung bleibt ein eigener sinnvoller Prüfschritt.
Für Inhalte, deren Bedeutung eine zweidimensionale Anordnung erfordert, nennt das Kriterium Ausnahmen. Eine gewöhnliche Kursbeschreibung benötigt diese Ausnahme nicht. Ihre Absätze, Bezeichnungen und Aktion ordnen sich untereinander an. Eine echte große Datentabelle wäre anders zu beurteilen als ein bloß aus Gewohnheit zu breites Textfeld. Die Ausnahme wird deshalb anhand des Inhalts begründet und nicht pauschal für jede schwierige Komponente verwendet.
Lange Begriffe und echte Inhalte nicht aus der Prüfung entfernen
Der Entwurf enthält absichtlich einen langen deutschen Beispielbegriff. Solche Wörter verschwinden in Gestaltungsvorlagen mit kurzen Platzhaltertexten leicht. overflow-wrap anywhere erlaubt nötigenfalls einen Umbruch. Der Text wird weder mit drei Punkten gekürzt noch durch eine kleinere Schrift versteckt. Die Reihenfolge und der vollständige Inhalt bleiben im Dokument erhalten.
Auch eine mehrzeilige Buttonbeschriftung ist zugelassen. white-space normal verhindert, dass die Aktion nur wegen ihres längeren Namens eine feste Mindestbreite fordert. Eingabefelder erhalten eine passende Breite und übernehmen die Schrift. Ein gewöhnliches einzeiliges Textfeld besitzt weiterhin seine eigene Bedienlogik. Der Versuch behauptet nicht, jeder eingegebene längere Wert werde vollständig in einer einzigen Zeile gleichzeitig sichtbar.
Für die eigene Webseite gehören später echte Produktnamen, lange Adressen und sprachliche Varianten in die Prüfung. Technische Zeichenfolgen können andere Bedürfnisse als Fließtext haben. Bei Quellcode oder vergleichenden Daten ist ein gezielt bedienbarer eigener Scrollbereich manchmal sinnvoller. Entscheidend ist, dass die umgebende Seite lesbar bleibt und die betreffende Inhaltsart bewusst beurteilt wird.
Zusätzliche Textabstände als eigenen Belastungsfall prüfen
Der Versuch verändert ergänzend Zeilenhöhe, Absatzabstand, Buchstabenabstand und Wortabstand. Er verwendet dafür die in Erfolgskriterium 1.4.12 beschriebenen Werte: mindestens 1,5-fache Zeilenhöhe, zweifachen Absatzabstand, 0,12 em Buchstabenabstand und 0,16 em Wortabstand. Diese Werte sind ein Prüfzustand für Anpassbarkeit. Sie sind keine Forderung, jede Webseite von Anfang an genau so zu gestalten.
Bei 320 Pixeln Breite werden die vier Veränderungen gemeinsam angewendet. Die beobachteten Textblöcke bleiben ohne den erfassten Überlauf und die Beispielaktion funktioniert weiterhin. Anschließend werden die zusätzlichen Regeln entfernt. So bleibt klar, welches Ergebnis zur gewöhnlichen Darstellung und welches zur gezielten Abstandsanpassung gehört. Der Test überschreibt nicht heimlich auch die Inhaltsbreite oder verkleinert anschließend wieder die Schrift.
Die zusätzliche Bedingung untersucht nur den gezeigten kleinen Inhalt. Andere Schriften, Schreibrichtungen oder komplexe eingebettete Komponenten können weitere Prüfwege verlangen. Die reine Anzahl bestandener Fälle ersetzt diese Auswahl nicht. Der wertvolle Befund ist, dass die tatsächlich vorgenommenen Änderungen und die danach ausgeführte Funktion zusammen dokumentiert sind.
Gegenproben zeigen, ob die Instrumente reagieren
Für eine negative Farbprobe wird der Einleitungsabsatz in der hellen Darstellung auf ein zu schwaches Grau gesetzt. Die Berechnung erkennt das zu geringe Verhältnis. Für einen zweiten Gegenfall erhält die Hauptfläche absichtlich eine Mindestbreite von 600 Pixeln. Bei der 320-Pixel-Ansicht meldet die Geometrie den waagerechten Überlauf. Der Test kann somit einen bekannten Breitenfehler tatsächlich unterscheiden.
Ein dritter Gegenfall begrenzt den Einleitungsabsatz auf zwölf Pixel Höhe und blendet den Überstand aus. Die Prüfung erkennt die Abweichung zwischen Inhalt und verfügbarer Blockhöhe. Danach wird jede injizierte Regel wieder entfernt. Diese Fehler werden nicht veröffentlicht und nicht als Eigenschaften der fertigen Beispielgestaltung dargestellt. Sie prüfen ausschließlich, ob unsere gewählten Instrumente auf diese bekannten Probleme reagieren.
Auch gute Gegenproben ergeben keinen universellen Fehlerdetektor. Nicht jede Überlagerung oder jedes schlecht lesbare Detail erzeugt einen solchen Größenunterschied. Die wirklichen Browserbilder werden deshalb zusätzlich angesehen. Rechnerische Werte, Geometrie und visuelle Beurteilung ergänzen sich. Wer nur einen grünen automatischen Bericht liest, könnte sonst eine Situation freigeben, die vom Instrument überhaupt nicht erfasst wird.
192 ausgeführte Bedingungen und ihre Grenzen lesen
Der gespeicherte Bericht nennt Browserstand, Farbpaare, Inhaltsbreiten, Schriftstufen und den konkreten Ausgang jeder Bedingung. Zehn ausgewählte Textpaare gehören zu heller und dunkler Darstellung. Weitere Fälle prüfen Feldgrenze, Hover und Fokus. Die 30 Layoutkombinationen verbinden berechnete Größen mit tatsächlicher Bedienung. Die negativen Proben bestätigen die Reaktion auf drei bewusst erzeugte Probleme.
Die Abbildung enthält unveränderte Ausschnitte aus dem wirklichen Browser. Links und rechts wurde derselbe 620 Pixel breite Inhalt mit gewöhnlicher beziehungsweise verdoppelter Wurzelschrift aufgenommen. Die Farbtabelle stammt aus den zurückgelesenen berechneten Werten. Sie ist keine künstlich erzeugte Messgrafik und zeigt keine behauptete Verbesserung um einen erfundenen Prozentsatz.
Eine solche Dokumentation erleichtert spätere Gestaltungsänderungen. Neue Farben werden an den tatsächlich verwendeten Flächen geprüft. Längere Texte werden in den relevanten Größen ausgeführt. Veränderte Abstände erhalten eigene Beobachtungen. Der Maßstab bleibt die Information und Handlung, die ein Mensch tatsächlich erkennen und erreichen muss. Ein ansprechendes CI und belastbare Lesbarkeit werden so gemeinsam entwickelt.
Den kleinen Entwurf als Ausgangspunkt verwenden
Die folgenden Dateien enthalten die vollständige Oberfläche, ihre Gestaltung, die reine Beispielaktion und die begrenzte Kontrastfunktion. HTML, CSS und Modul werden über einen gewöhnlichen eigenen HTTP-Dienst unter demselben Ursprung ausgeliefert. Die Aktion ändert nur den sichtbaren Status. Es gibt weder eine Buchung noch einen Versand oder eine versteckte Speicherung der eingegebenen Notiz.
Für eine wirkliche Webseite wird der Bestand um ihre tatsächlichen Zustände und Inhalte erweitert. Dazu gehören Fehlermeldungen, Navigation, feste Elemente und die tatsächlich verwendeten Vergrößerungswege. Welche gesetzlichen Anforderungen für das konkrete Angebot gelten, wird anhand seines Anwendungsbereichs gesondert beurteilt. Ein kleines erfolgreiches Muster ersetzt diese Bewertung nicht.
Der praktische Einstieg bleibt überschaubar: relevante Farbpaare benennen, echte Textveränderungen ausführen, schmale Ansichten bedienen und Gegenproben erhalten. Damit werden CI-Entscheidungen nachvollziehbar. Eine Farbe bleibt nicht nur deshalb bestehen, weil sie in einer Palette steht. Sie muss in ihrer konkreten Aufgabe lesbar funktionieren und mit dem verfügbaren Platz sowie der tatsächlichen Bedienung zusammenpassen.
example.html
<!doctype html><html lang="de"><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>Lesbar und bedienbar</title><link rel="stylesheet" href="example.css"><main><header><p class="eyebrow">Fiktive Kursinformation</p><h1>Lesbar und bedienbar</h1><p id="intro">Informationen sollen auch mit größerer Schrift und in einer schmalen Ansicht verständlich bleiben.</p></header><section aria-labelledby="course-title"><h2 id="course-title">Digitale Gestaltung verstehen</h2><p>Der Beispielkurs zeigt, wie klare Absätze, sichtbare Schaltflächen und passende Umbrüche zusammenwirken.</p><dl><div><dt>Dauer</dt><dd>Zwei Stunden</dd></div><div><dt>Format</dt><dd>Gemeinsame Übung</dd></div></dl><p>Ein langer Beispielbegriff: <span class="long">Benutzeroberflächengestaltungsprüfung</span></p><p><a id="details" href="#requirements">Voraussetzungen für die Übung lesen</a></p></section><section id="requirements" aria-labelledby="requirements-title"><h2 id="requirements-title">Voraussetzungen</h2><p>Sie benötigen nur Interesse an verständlichen digitalen Angeboten. Die Beispielauswahl löst keine Anmeldung aus.</p><form id="demo"><label for="note">Eigene Notiz</label><input id="note" name="note" autocomplete="off" maxlength="120" aria-describedby="hint"><p id="hint" class="hint">Eine beliebige fiktive Notiz, keine persönlichen Daten.</p><button id="apply" type="submit">Beispielauswahl übernehmen</button><p id="result" role="status">Noch keine Beispielauswahl übernommen.</p></form></section></main><script type="module" src="example.mjs"></script></html>example.css
:root{font-size:100%;--paper:#f8f2e8;--ink:#202428;--muted:#55595d;--accent:#bb0011;--button:#bb0011;--button-ink:#ffffff;--edge:#686868;--focus:#9e0010}*{box-sizing:border-box}body{margin:0;background:var(--paper);color:var(--ink);font:1rem/1.55 Arial,sans-serif}main{max-width:58rem;margin-inline:auto;padding:clamp(1rem,4vw,3rem)}h1{font-size:2.25rem;line-height:1.2}h2{font-size:1.5rem;line-height:1.3}p,h1,h2,dt,dd,label,button,a{overflow-wrap:anywhere}header,section,form{min-width:0}section{border-top:.25rem solid var(--accent);margin-block:2rem;padding-block:1rem}.eyebrow,.hint{color:var(--muted)}.eyebrow{font-weight:bold}dl{display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,12rem),1fr));gap:1rem}dl div{min-width:0;padding:1rem;border:1px solid var(--edge)}dt{font-weight:bold}dd{margin:0}a{color:var(--accent);text-decoration:underline;text-underline-offset:.2em}form{display:grid;gap:.75rem}label{font-weight:bold}input,button{font:inherit;max-width:100%;min-width:0;border:2px solid var(--edge);border-radius:.25rem;padding:.7em .8em;min-height:3rem}input{width:100%;background:var(--paper);color:var(--ink)}button{justify-self:start;white-space:normal;background:var(--button);color:var(--button-ink);border-color:var(--button);cursor:pointer}button:hover{background:#8d0010;border-color:#8d0010}a:hover{text-decoration-thickness:.15em}:focus-visible{outline:3px solid var(--focus);outline-offset:4px}.hint{margin:0;font-size:1rem}#result{font-weight:bold}@media(prefers-color-scheme:dark){:root{--paper:#202428;--ink:#f8f2e8;--muted:#c6beb3;--accent:#ff9b90;--button:#ff9b90;--button-ink:#202428;--edge:#b6b0a7;--focus:#ffb7ad}button:hover{background:#ffc1b9;border-color:#ffc1b9}}example.mjs
document.querySelector('#demo').addEventListener('submit',event=>{event.preventDefault();document.querySelector('#result').textContent='Die Beispielauswahl wurde übernommen. Es wurde nichts versendet.';});contrast.mjs
export function luminance(rgb) {
if(!Array.isArray(rgb)||rgb.length!==3||rgb.some(v=>!Number.isFinite(v)||v<0||v>255))throw new TypeError('Expected opaque sRGB channels');
const linear=rgb.map(value=>{const s=value/255;return s<=0.04045?s/12.92:((s+0.055)/1.055)**2.4;});
return 0.2126*linear[0]+0.7152*linear[1]+0.0722*linear[2];
}
export function contrast(a,b){const x=luminance(a),y=luminance(b);return(Math.max(x,y)+0.05)/(Math.min(x,y)+0.05);}
export function opaqueRGB(css){const match=/^rgb\(\s*(\d+)\s*,\s*(\d+)\s*,\s*(\d+)\s*\)$/.exec(css);if(!match)throw new TypeError('Only resolved opaque rgb() values supported');return match.slice(1).map(Number);}
Berechnete Textkontraste im wirklichen Browser
| Darstellung | Rolle | Vordergrund / Hintergrund | Verhältnis, nur für Anzeige gerundet |
|---|---|---|---|
| Hell | Fließtext | rgb(32, 36, 40) / rgb(248, 242, 232) | 14,03 : 1 |
| Hell | Hinweis | rgb(85, 89, 93) / rgb(248, 242, 232) | 6,34 : 1 |
| Hell | Link | rgb(187, 0, 17) / rgb(248, 242, 232) | 6,04 : 1 |
| Hell | Buttontext | rgb(255, 255, 255) / rgb(187, 0, 17) | 6,73 : 1 |
| Hell | Feldtext | rgb(32, 36, 40) / rgb(248, 242, 232) | 14,03 : 1 |
| Dunkel | Fließtext | rgb(248, 242, 232) / rgb(32, 36, 40) | 14,03 : 1 |
| Dunkel | Hinweis | rgb(198, 190, 179) / rgb(32, 36, 40) | 8,49 : 1 |
| Dunkel | Link | rgb(255, 155, 144) / rgb(32, 36, 40) | 7,69 : 1 |
| Dunkel | Buttontext | rgb(32, 36, 40) / rgb(255, 155, 144) | 7,69 : 1 |
| Dunkel | Feldtext | rgb(248, 242, 232) / rgb(32, 36, 40) | 14,03 : 1 |
Checkliste für lesbare Ansichten
- Tatsächlich relevante Farbpaare und Flächen festhalten.
- Ungerundete Verhältnisse mit passenden Grenzwerten vergleichen.
- Hover, Fokus und wichtige nichttextliche Information prüfen.
- Den wirklich verwendeten Vergrößerungsweg dokumentieren.
- Gewöhnliche und dazwischenliegende Schriftstufen ausführen.
- Schmale Ansichten mit vollständigen sinnvollen Inhalten bedienen.
- Lange Wörter und Aktionsbezeichnungen passend umbrechen lassen.
- Textabstände ohne heimliche ausgleichende Änderungen überschreiben.
- Tatsächliche Gegenproben und Sichtbeobachtungen erhalten.
- Weitere WCAG- und Rechtsanforderungen gesondert beurteilen.
Primärquellen und Prüfstand
Primärquellen am 09.11.2026 geprüft. Eigene fiktive Kursoberfläche mit 192 ausgeführten Node-/Edge-Bedingungen, 30 Layoutkombinationen und zehn ausgewählten berechneten deckenden Textpaaren. Eine Wurzelschriftänderung ist kein Browserzoom. Eine 320 CSS-Pixel breite Ansicht ist kein ausgeführter 400-Prozent-Zoom. Keine vollständige WCAG- oder Rechtsfreigabe.
