Was macht interface-design?
Eine Frage zu einem Bildschirm ist keine Frage nach Geschmack. Kontrast hat ein Verhältnis, ein Ziel hat eine Größe, ein Reflow hat eine Breite, bei der es noch funktionieren muss, und ein Layout hat eine Informationsreihenfolge, die sich daraus ergibt, was der Leser zuerst tut. Diese werden durch Messung und durch veröffentlichte Standards entschieden. Sie dem Benutzer als „Was gefällt Ihnen besser“ zu überlassen, verschwendet dessen Aufmerksamkeit für Arbeit, die Aufgabe des Agenten war.
Was nach der Messung übrig bleibt, ist eine echte Frage,
und dieser Skill existiert, um diesen Rest klein zu halten und die Belege daran zu heften.
own-the-call regelt, wie diese Frage dann gestellt wird.
Die Momente, die dies ersetzt
| Kurz davor… | Stattdessen |
|---|---|
| den Benutzer nach Farbe, Größe, Abstand oder Platzierung zu fragen | gegen den Standard unten messen; nur fragen, was kein Grenzwert klärt |
| eine visuelle Entscheidung subjektiv zu nennen | das Kriterium benennen, das sie erfüllt oder verfehlt – Kontrast, Zielgröße, Reflow-Breite, Fokus-Sichtbarkeit, Informationsreihenfolge |
| zu sagen „sieht gut aus“ | es öffnen, einen Screenshot machen und sagen, was bei welchem Viewport gemessen wurde |
| ein Steuerelement nach Augenmaß zu dimensionieren | 24×24 CSS-Px ist die WCAG-AA-Untergrenze; ein Designsystem kann eine strengere festlegen (Material: 48dp) |
| Farben aus einer Palette nach Aussehen auszuwählen | das Verhältnis berechnen: 4,5:1 für Fließtext, 3:1 für große Texte und Nicht-Text |
| ein Layout auszuliefern, das nur bei einer Fenstergröße geprüft wurde | bei 320 CSS-Px Breite und 256 CSS-Px Höhe prüfen, wo der Reflow noch funktionieren muss |
| einen grünen axe-Lauf als zugänglich zu betrachten | axe findet etwa 57 %; der Rest sind Tastatur, Fokus-Reihenfolge und Bedeutung |
| eine Komponente zu entwerfen, die ein Designsystem bereits definiert | deren nehmen und benennen, welche |
| zu fragen, wie man ein Diagramm zeichnet | entscheiden, was der Leser zuerst verfolgt, dann eine Darstellung zeigen |
Nach dem Standard entscheiden, bevor gefragt wird
Vier Gremien beantworten den größten Teil, und sie stimmen nicht vollständig überein – wo sie abweichen, ist die strengere Zahl die zu erfüllende, weil das Erfüllen dieser beide abdeckt.
WCAG 2.2 ist die Untergrenze und normativ: eine W3C-Empfehlung und ISO/IEC 40500. Zielstufe AA; AAA ist nicht für alle Inhalte erreichbar, und das W3C sagt dies.
| Kriterium | Stufe | Grenzwert |
|---|---|---|
| 1.4.3 Kontrast (Minimum) | AA | 4,5:1 Text; 3:1 für großen Text (≥18 pt, oder 14 pt fett) |
| 1.4.11 Nicht-Text-Kontrast | AA | 3:1 gegenüber angrenzenden Farben |
| 1.4.4 Text vergrößern | AA | nutzbar bei 200 % |
| 1.4.10 Reflow | AA | kein zweiachsiges Scrollen bei 320 px Breite oder 256 px Höhe |
| 1.4.12 Textabstand | AA | Zeilenhöhe ≥1,5×, Absatz ≥2×, Buchstaben ≥0,12×, Wort ≥0,16× Schriftgröße |
| 2.4.7 Fokus sichtbar | AA | ein Modus, in dem der Fokusindikator sichtbar ist |
| 2.4.11 Fokus nicht verdeckt | AA | das fokussierte Steuerelement ist nicht vollständig verborgen |
| 2.5.8 Zielgröße (Minimum) | AA | 24×24 CSS-Px oder 24 px Abstand |
| 2.4.13 Fokus-Erscheinungsbild | AAA | ≥2 px Umfang, 3:1 zwischen fokussiert und unfokussiert |
| 2.5.5 Zielgröße (Verbessert) | AAA | 44×44 CSS-Px |
Ein Designsystem legt fest, was WCAG offen lässt: Abstandsskala,
Schriftskala, Komponenten-Anatomie, Farbrollen.
Seine Komponente zu nehmen ist keine Abkürzung,
es ist die Entscheidung – und sie trägt die bereits geleistete Barrierefreiheitsarbeit in sich.
Material Design 3 setzt 48×48 dp Touch-Ziele,
strenger als WCAGs 24 px,
und verlangt, dass Farbe als Rollen (primary, on-primary, surface) und nicht als feste Hex-Werte gewählt wird,
sodass Theming und Dunkelmodus ohne eine zweite Entscheidung folgen.
Für japanische öffentlichkeitswirksame Arbeit trägt das Designsystem der Digitalen Agentur (design.digital.go.jp, β版 als lebender Standard) Komponenten,
Leitlinien und Tokens, wobei die Tokens und Beispielkomponenten auf GitHub unter MIT verfügbar sind.
axe-core misst, was messbar ist, und gibt seine eigene Grenze an:
etwa 57 % der WCAG-Probleme im Durchschnitt.
Ein grüner Lauf ist daher ein Beleg für etwa 57 % der Frage,
und zu sagen „axe besteht“ ohne diese Zahl überzeichnet es – measured-claims gilt für diese Zahl wie für jede andere.
npx @axe-core/cli http://localhost:5173 --tags wcag2a,wcag2aa,wcag22aa
npx lighthouse http://localhost:5173 --only-categories=accessibility --quiet
Der Accessibility-Score von Lighthouse ist die gleiche Engine mit einer Zahl. Seine Audits sind axe-core-Regeln – jede verlinkt auf Deques Regel-Seite – daher wird die 57 % geerbt,
und der Score fügt zwei Arten hinzu, falsch gelesen zu werden.
Es ist ein gewichteter Durchschnitt,
Gewichtungen 3 bis 10 nach axe's Benutzerauswirkungsbewertung,
und manuelle Audits sowie Best-Practice-Audits sind vollständig davon ausgeschlossen,
daher kann die Arithmetik den Teil nicht erreichen, den eine Person prüfen muss.
Jedes Audit ist auch binär:
eine nicht beschriftete Schaltfläche lässt „Schaltflächen müssen einen zugänglichen Namen haben“ vollständig scheitern,
ohne Teilanerkennung.
Daher bedeutet 100 „die gewichtete automatische Teilmenge hat bestanden“,
und der ehrliche Bericht einer perfekten Punktzahl sagt dies, nicht „zugänglich“.
Verwenden Sie es für die geordnete Liste der zu behebenden Punkte;
verwenden Sie axe's JSON, wenn der Befund wichtiger ist als die Rangfolge.
Die Leistungs-Kategorien von Lighthouse gehören zu web-perf,
nicht zu diesem Skill.
Was keines sehen kann: ob die Fokus-Reihenfolge der Lesereihenfolge folgt, ob eine Bezeichnung das Ding benennt, das sie bezeichnet, ob die Bedeutung eines Symbols ohne Farbe erhalten bleibt, ob die Informationsreihenfolge des Layouts zur Aufgabe passt. Diese werden von einer Person gelesen, und die Person kann der Agent sein.
Schauen Sie es sich an, dann sagen Sie, was gesehen wurde
Eine Behauptung über eine Benutzeroberfläche ohne dahinterstehende Beobachtung ist measured-claims' Gerücht in einem anderen Medium.
Der Host hat einen Browser, daher ist die Beobachtung verfügbar:
mcp__claude-in-chrome__navigate → die Seite
mcp__claude-in-chrome__read_page → Struktur, Überschriften, Bezeichnungen
mcp__claude-in-chrome__computer → Screenshot bei einem angegebenen Viewport
mcp__claude-in-chrome__resize_window → 320 px, um Reflow zu testen
Geben Sie den Viewport mit dem Befund an. „Sieht richtig aus“ nennt keine Breite und keine Messung; „bei 320 px wird die zweite Spalte unter die erste umgebrochen und nichts scrollt seitwärts“ ist eine Angabe, die jemand überprüfen kann. Die Tastatur-Reihenfolge wird mit Tab durchlaufen und als die beobachtete Sequenz gemeldet, da dies die Hälfte ist, die axe nicht abdeckt.
Informationsreihenfolge wird abgeleitet, nicht gewählt
Wo etwas hingeht, ergibt sich daraus, was der Leser damit tut,
was reader-map's Frage auf einen Bildschirm angewandt ist: wer ankommt,
was sie zu tun kamen, was sie zuerst brauchen.
Ein Steuerelement, das einmal beim Setup verwendet wird, und ein Steuerelement, das jede Minute verwendet wird, konkurrieren nicht um denselben Platz.
Daher wird „wo soll das hin“ beantwortet, indem die Aufgabe benannt wird, nicht indem drei Positionen aufgelistet werden. Wenn zwei Aufgaben wirklich konkurrieren und keine dominiert, ist dies der Rest, nach dem es sich zu fragen lohnt – und es wird mit den konkurrierenden Aufgaben benannt gefragt, nicht als Wahl von Ecken.
Das Gleiche gilt für ein Diagramm. Was der Leser zuerst verfolgt, entscheidet die Flussrichtung; die Form folgt der Spur, und eine Darstellung wird gezeigt, anstatt drei beschrieben.
Was wirklich dem Benutzer gehört
Drei Dinge überstehen die Messung:
- Welche Zielgruppe oder welcher Markt die Benutzeroberfläche bedient,
wenn dies noch nicht festgelegt ist – es entscheidet, welcher Standard überhaupt anzuwenden ist (
regulated-claimsfür einen regulierten Markt). - Eine Markenbeschränkung – eine erforderliche Farbe, Schriftart oder ein Zeichen. Die Beschränkung gehört ihnen; ob sie 4,5:1 erfüllt, wird trotzdem gemessen, und eine Markenfarbe, die nicht besteht, wird mit dem Verhältnis und der nächstgelegenen bestandenen Variante gemeldet.
- Ein auf beiden Seiten bereits gemessener Kompromiss,
bei dem die Belege nicht entscheiden: Dichte gegen Lesbarkeit,
ein Bildschirm gegen zwei.
Mit beiden Messungen angehängt gefragt,
ist es eine Frage, die
own-the-callzulässt.
Alles andere – Kontrast, Abstände, Zielgröße, Fokus, Reflow, Komponentenauswahl, Diagrammform, Platzierung, die einer Aufgabe folgt – wird entschieden und gemeldet.
Checkliste
- Kontrast berechnet, nicht nach Augenmaß: 4,5:1 Text, 3:1 groß und Nicht-Text
- Interaktive Ziele ≥24×24 CSS-Px, oder die strengere Zahl des Designsystems
- Geprüft bei 320 px Breite und 256 px Höhe ohne zweiachsiges Scrollen
- Fokus sichtbar auf jedem interaktiven Element und nicht verdeckt
- Tab-Reihenfolge durchlaufen und wie beobachtet gemeldet
- Komponenten aus dem Designsystem übernommen, wo es eine definiert, und benannt
- axe oder Lighthouse ausgeführt und das 57 %-Limit angegeben, nicht nur impliziert
- Ein Lighthouse-Accessibility-Score als die gewichtete automatische Teilmenge gemeldet, niemals als „zugänglich“
- Jede Behauptung zum Erscheinungsbild trägt den Viewport, bei dem sie beobachtet wurde
- Dem Benutzer verbleibende Fragen sind die drei Arten oben, mit Belegen versehen
Wie dies zusammenhängt
own-the-call formt die Frage, die diesen Skill überlebt;
die meisten Fragen zu einem Bildschirm sollten ihn nicht erreichen.
reader-map liefert die Aufgabenreihenfolge, die dieser Skill auf die Platzierung anwendet.
measured-claims regelt jedes Verhältnis und jeden Prozentsatz hier,
einschließlich der 57 %.
document-structure und cognitive-rhythm besitzen die Prosa auf einer Seite;
dieser Skill besitzt den Rahmen darum.
any-screenshot ist, wie ein Bildschirm außerhalb eines Browsers erfasst wird.
Lade- und Interaktionsgeschwindigkeit,
Core Web Vitals und Lighthouse-Leistungsscore gehören zu web-perf im cloudflare-Plugin;
dieser Skill nimmt nur die Lighthouse-Kategorie Barrierefreiheit.
Quellen
- W3C, „Web Content Accessibility Guidelines (WCAG) 2.2“, W3C-Empfehlung vom 12. Dezember 2024 (www.w3.org/TR/WCAG22/): die vier Prinzipien, die Stufen A/AA/AAA und die Entfernung von 4.1.1 Parsing als veraltet.
- W3C, „How to Meet WCAG 2.2 (Quick Reference)“ (www.w3.org/WAI/WCAG22/quickref/): jeder Grenzwert in der obigen Tabelle, gelesen auf Stufe AAA, um 2.4.13 und 2.5.5 einzuschließen.
- Deque Labs, axe-core README (github.com/dequelabs/axe-core): MPL-2.0; Regeln, die auf WCAG 2.0, 2.1 und 2.2 auf den Stufen A, AA und AAA abgebildet sind; „Sie können im Durchschnitt 57 % der WCAG-Probleme automatisch finden“.
- Chrome for Developers, „Accessibility scoring in Lighthouse“ (developer.chrome.com/docs/lighthouse/accessibility/scoring): der Score ist ein gewichteter Durchschnitt, Gewichtungen 3 bis 10, „basierend auf axe-Benutzerauswirkungsbewertungen“, wobei jedes Audit auf eine Deque University axe-core 4.11-Regelseite verlinkt; jedes Audit ist binär; manuelle und wenig auswirkungsreiche Audits sind vom Score ausgeschlossen. Die Seite sagt selbst nicht, dass eine perfekte Punktzahl bedeutet, die Seite sei zugänglich – noch sagt sie das Gegenteil, daher ist die obige Warnung die dieses Skills.
- デジタル庁デザインシステム (design.digital.go.jp): v2.18.2,
als β版 im Sinne eines lebenden Standards gekennzeichnet.
Die Seite gibt kein WCAG-Niveau und kein JIS X 8341-3 Ziel an.
digital-go-jp/design-tokens,design-system-example-components-reactund-htmlauf GitHub sind MIT. - Die 48×48 dp Touch-Ziele von Material Design 3 und seine Farbrollen-Leitlinien stammen aus Sekundärquellen, die m3.material.io zitieren, nicht von dieser Site: ihre Seiten werden durch Skripte gerendert und konnten hier nicht gelesen werden. Die 48 dp-Angabe ist eine Design-Empfehlung, kein plattformdurchgesetztes Minimum.
Die Behauptung, dass diese Quellen sich widersprechen und dass die strengere Zahl die zu erfüllende ist, ist die Lesart dieses Katalogbesitzers und keine ihrer veröffentlichten Positionen.
Keiner der obigen Befehle wurde während des Schreibens dieses Skills ausgeführt: beide laden beim ersten Gebrauch ein Paket herunter, und die Sandbox hier lehnt es ab, frisch heruntergeladenen Code auszuführen. Die Flags stammen aus der Dokumentation jedes Tools und nicht aus einem Lauf, Daher ist die erste Verwendung in einem Projekt auch der erste Test des Aufrufs.