Prüfkatalog — woran man Zusammengetipptes erkennt (Stand 27.09.2026)

Zweck

Der Katalog entsteht aus RL06 (Kind von RL01, „RL · Richtlinien und Feinschliff") und beginnt mit den zwölf Merkmalen, die dort als eigene Beobachtung standen; jedes wurde hier an den Quellen geprüft und, wo nötig, geschärft. Fremde Richtlinientexte sind ausschließlich gelesen und verlinkt, nie im Repository abgelegt — Apples Human Interface Guidelines nur über hig.mjs auf die Standardausgabe, alles andere über Web-Suche; wörtliche Übernahmen bleiben auf höchstens einen kurzen Satz je Eintrag beschränkt, mit Quelle (N362).

Was davon gilt (N373). Christian hat am 27.09.2026 entschieden: K09, K12, K18 und K29 stehen als Verbote mit Gegenprobe in Style-Guide §19; K01 ist die Unterzeilen-Regel in §15 (RL03), K02 die Laderegel in §11.5 (RL04). Die übrigen Einträge, deren Regel der Style-Guide schon trägt, verweisen hier auf ihren Abschnitt; K13, K22 und K28 sind Ermessensfragen und bleiben Prüfhilfe für /ansehen, /apple-design und den sichtpruefer. K19 (Platzhaltertexte) wird ein Nachweis (RL07). Verbindlich ist der Style-Guide; dieser Katalog ist das Nachschlagewerk dazu.

Zu den zwölf Ausgangsmerkmalen

Alle zwölf aus RL06 sind an mindestens einer Quelle nachvollziehbar und stehen unten (K01–K13). Keines wurde gestrichen. Eines wurde geschärft: „Farbe ohne feste Bedeutung; die schwächste Schriftstufe als Regel" war im Ausgangstext ein einziger Punkt, obwohl es zwei verschiedene Fehler mit unterschiedlicher Gegenprobe sind (Farbe ohne Rolle vs. Text pauschal in der schwächsten Stufe statt nach Rang). Beide stehen jetzt einzeln (K03, K04).

K01 — Erklärsätze unter Überschriften

Merkmal. Unter jeder Überschrift steht ein zweiter Satz, der entweder nur wiederholt, was die Überschrift schon sagt, oder eine Bemerkung ist, die nur den, der den Schirm gebaut hat, interessiert.

Woran man es erkennt. Im Code: eine <Untertitel>- oder subtitle-Prop direkt unter einer Überschriftenkomponente, deren Text mit dem der Überschrift synonym ist oder mit „Hier siehst du …", „Auf dieser Seite …" beginnt. Im Bild: zwei Zeilen übereinander, die erste fett, die zweite in Nebentinte, ohne dass die zweite eine neue Information trägt.

Die fünf Formen (Grundsatz 75, N433, RL20) — in der App, auf der Meta-Seite, in Server-Texten und in der Doku gleich:

1. Ankündigung — „Hier siehst du …", „In diesem Abschnitt …", „Im Folgenden …".
2. Überschrift als Satz — der Titel mit anderen Worten.
3. Inhaltsangabe — zählt auf, was darunter ohnehin steht.
4. Begründung an den Entwickler — erklärt, warum etwas gebaut ist, statt was es für den Nutzer tut.
5. Werbesatz — „ganz einfach", „alles an einem Ort".

Bleiben dürfen eine Folge, eine Frist, eine Datenschutz-Zusage, der Ort der Handlung und im leeren Zustand die Einladung zur ersten Handlung.

Was Denotato stattdessen tut. RL03 und RL20 räumen diese Sätze auf; steht die Information nicht in der Überschrift selbst, gehört sie an die Stelle, die sie wirklich betrifft (Tooltip, leerer Zustand, Hilfetext), nicht pauschal unter jede Überschrift.

Gegenprobe. Verliert der Schirm etwas, wenn man den Satz unter der Überschrift löscht?

Quelle. Apple, Human Interface Guidelines › Writing, Abschnitt „Best practices": „Check each word to be sure it needs to be there. If you can use fewer words, do so." — <https://developer.apple.com/design/human-interface-guidelines/writing>

K02 — Ladetext statt der Form des Inhalts

Merkmal. Während geladen wird, steht dort „Wird geladen …" oder ein Spinner, statt dass die Fläche schon die Form zeigt, die der Inhalt gleich haben wird.

Woran man es erkennt. Im Code: eine Bedingung wie if (loading) return <p>Wird geladen …</p> statt eines Platzhalter-Gerüsts in der Form der Zielkomponente (Skeleton). Im Bild: ein Wortlaut oder ein zentrierter Kreisel dort, wo gleich eine Liste, eine Karte oder eine Tabelle steht.

Was Denotato stattdessen tut. RL04: Beim Laden steht die Form des Inhalts da. Die Ladefläche (§15 der Bausteintabelle: „Stein + Gitter, Kristall in Zielfarbe") ist genau dafür gebaut.

Gegenprobe. Sieht die Ladefläche wie eine kleinere, blassere Version dessen aus, was gleich erscheint — oder wie eine eigene, dritte Sache?

Quelle. Apple, Human Interface Guidelines › Loading, Abschnitt „Best practices": „Consider showing placeholder text, graphics, or animations as content loads, replacing these elements as content becomes available." — <https://developer.apple.com/design/human-interface-guidelines/loading>

K03 — Farbe ohne feste Bedeutung

Merkmal. Dieselbe Farbe steht an einer Stelle für Erfolg, an einer anderen für einen Bereich, an einer dritten nur zur Auflockerung — oder umgekehrt: derselbe Zustand wird auf zwei Schirmen unterschiedlich eingefärbt.

Woran man es erkennt. Im Code: eine Rohfarbe oder ein Token, das außerhalb seiner Rolle verwendet wird (theme.bereiche.* oder eine Plugin-Farbe direkt gelesen, statt über eine Bedeutung wie Erfolg, Warnung, Bereichszugehörigkeit). Im Bild: zwei Flächen mit selber Farbe, aber ohne erkennbar gemeinsame Bedeutung.

Was Denotato stattdessen tut. RL05 ordnet Farbe nach Rolle; §19 des Style-Guides hat den Kern schon: theme.bereiche.* direkt zu lesen ist verboten, ebenso zwei Bereichsfarben auf einem Schirm ohne Bezug.

Gegenprobe. Kann man aus der Farbe allein sagen, was sie bedeutet, ohne den Text daneben zu lesen — und stimmt das auf jedem Schirm?

Quelle. Apple, Human Interface Guidelines › Color, Abschnitt „Best practices": „Avoid using the same color to mean different things." — <https://developer.apple.com/design/human-interface-guidelines/color>

K04 — Die schwächste Schriftstufe als Standardton

Merkmal. Fließtext, der eigentlich die Hauptaussage ist, steht in der blassesten verfügbaren Texttönung, weil sie „ruhiger" wirkt — nicht weil er tatsächlich Nebeninformation ist.

Woran man es erkennt. Im Code: color: neutral.nebentinte (oder vergleichbare schwache Tönung) auf einem Absatz, der die Kernaussage des Schirms trägt, statt auf echten Nebeninformationen (Zeitstempel, Platzhalter). Im Bild: der wichtigste Satz auf der Fläche ist schwerer zu lesen als eine Randnotiz daneben.

Was Denotato stattdessen tut. §17 legt die Kontrastschwellen genau nach Rang fest — Text ≥ 4,5 : 1, Nebentext ≥ 3 : 1 — und §15 sagt es für den Leerzustand ausdrücklich: die Aussage des Schirms steht in der Lesetinte, nicht in der Nebentinte.

Gegenprobe. Ist der hellste Text auf dem Schirm auch inhaltlich der unwichtigste?

Quelle. W3C, WCAG 2.2, Kriterium 1.4.3 „Contrast (Minimum)" (Stufe AA) — <https://www.w3.org/WAI/WCAG22/quickref/#contrast-minimum> (Host über den Netzproxy dieser Sitzung nicht direkt erreichbar, Inhalt über Suchergebnisse gegengeprüft; Schwelle deckt sich mit §17).

K05 — Jede Gruppe eine Karte mit Rand, Schatten und Rundung

Merkmal. Jede noch so kleine Gruppe von Inhalten bekommt einen eigenen Kasten mit Rand, Schatten und abgerundeten Ecken, auch dort, wo ein Abstand allein die Gruppen schon unterscheidbar machen würde.

Woran man es erkennt. Im Code: eine Panel- oder Card-Komponente um jeden Abschnitt, verschachtelt bis zu drei, vier Ebenen tief. Im Bild: Kästen in Kästen, jeweils mit eigenem Schatten, ohne dass die Verschach- telung eine eigene Bedeutung trägt.

Was Denotato stattdessen tut. §15.1 setzt die Form nach Menge und Inhalt (Liste bis Kachel) statt nach Gewohnheit, und der Werkstoff Panel ist für Betonung reserviert, nicht für jede Gruppierung.

Gegenprobe. Bliebe die Gruppe erkennbar, wenn man Rand und Schatten wegließe und nur den Abstand behielte?

Quelle. Apple, Human Interface Guidelines › Layout, Abschnitt „Visual hierarchy": „You might use negative space, container shapes, or separator lines to show which elements are related." — <https://developer.apple.com/design/human-interface-guidelines/layout>

K06 — Verläufe, Leuchten und Glas als Schmuck statt als Aussage

Merkmal. Farbverläufe, Leuchteffekte oder Glasflächen liegen auf Dingen, die nichts davon brauchen, um verständlich zu sein — sie stehen für „modern", nicht für eine Ebene oder einen Zustand.

Woran man es erkennt. Im Code: backdrop-filter oder ein CSS-Gradient auf einer Komponente, die liegt (Panel, Kachel, Zeile) statt schwebt (Modal, Dropdown, Toast, Schublade). Im Bild: milchige oder schimmernde Flächen dort, wo nichts darunterliegt.

Was Denotato stattdessen tut. §19 hat es schon: Glas außerhalb von Modal, Dropdown, Toast und Schublade ist verboten; §5 beschreibt die Werkstoffe (Papier, Karton, Stein, Glas) mit fester Bedeutung je Ebene.

Gegenprobe. Zeigt der Effekt eine Ebene (liegt etwas über etwas anderem) oder nur, dass da eine Fläche ist?

Quelle. Apple, Human Interface Guidelines › Color, Abschnitt „Liquid Glass color": „Apply color sparingly to the Liquid Glass material … reserve it for elements that truly benefit from emphasis." — <https://developer.apple.com/design/human-interface-guidelines/color>

K07 — Zu viele Schriftgrößen und -gewichte auf einem Schirm

Merkmal. Auf einem einzigen Schirm wechseln sich fünf, sechs verschiedene Kombinationen aus Größe und Gewicht ab, ohne dass jede davon eine eigene Stufe der Hierarchie trägt.

Woran man es erkennt. Im Code: verschiedene font-size/font-weight -Kombinationen roh in Komponenten statt aus den Schriftstufen des Themes. Im Bild: Überschrift, Unterüberschrift, Fließtext, Beschriftung und Zahl sehen alle unterschiedlich groß und unterschiedlich fett aus, ohne klar erkennbare Rangfolge.

Was Denotato stattdessen tut. verify:arch meldet rohe Werte statt Theme-Stufen (§19); die Schriftstufen des Themes bilden eine feste, kleine Rangfolge, die jeder Schirm wiederverwendet, statt eigene zu erfinden.

Gegenprobe. Kann man die Rolle jeder Textstelle (Titel, Absatz, Beschriftung, Zahl) benennen, ohne den Inhalt zu kennen — nur an Größe und Gewicht?

Quelle. Apple, Human Interface Guidelines › Typography, Abschnitt „Conveying hierarchy": „Minimize the number of typefaces you use, even in a highly customized interface." (dieselbe Zurückhaltung gilt für Größen- und Gewichtsstufen) — <https://developer.apple.com/design/human-interface-guidelines/typography>

K08 — Abzeichen und Chips für alles, was eine Zahl oder ein Wort sein könnte

Merkmal. Ein Datum, eine Zahl, ein einzelnes Wort bekommt eine Pillenform mit Rand und Fläche, obwohl reiner Text an der Stelle genauso verständlich wäre.

Woran man es erkennt. Im Code: Badge/Chip um einen Wert, der kein Status, keine Kategorie und keine auswählbare Option ist. Im Bild: eine Zeile, in der jedes zweite Wort in einer eigenen kleinen Pille steckt.

Was Denotato stattdessen tut. §19 hat es schon: ein Chip für ein Datum oder eine Zahl ist ausdrücklich verboten (B10); Badge/Chip ist für Status und Kategorie reserviert (§15).

Gegenprobe. Verliert der Wert etwas an Klarheit, wenn man ihn aus der Pille herauslöst und als reinen Text daneben schreibt?

Quelle. Style-Guide §19 (bestehende Regel, kein externer Beleg nötig).

K09 — Knöpfe mit leeren Wörtern statt der Handlung

Merkmal. Knopfbeschriftungen wie „Absenden", „Los geht's" oder „OK" sagen nicht, was passiert, wenn man klickt.

Woran man es erkennt. Im Code: <Button>Absenden</Button>, <Button>OK</Button> unabhängig davon, was der onClick-Handler tut. Im Bild: mehrere Knöpfe auf einem Schirm mit demselben austauschbaren Wort.

Was Denotato stattdessen tut. Die Beschriftung nennt die Handlung („Karte speichern", „Termin verschieben"), nicht ihre Geste.

Gegenprobe. Weiß man allein an der Beschriftung, was nach dem Klick anders ist?

Quelle. Apple, Human Interface Guidelines › Writing, Abschnitt „Best practices": „When labeling buttons and links, it's almost always best to use a verb … just saying 'Send' often works better than 'Let's do it!'" — <https://developer.apple.com/design/human-interface-guidelines/writing>

K10 — Leere Zustände mit Werbesätzen statt einer Handlung

Merkmal. Ein leerer Bereich erklärt blumig, wie toll es wäre, wenn hier etwas stünde, statt zu sagen, was man jetzt tun kann.

Woran man es erkennt. Im Code: EmptyState-Text wie „Entdecke die Möglichkeiten von …" ohne Knopf oder Link zur nächsten Handlung. Im Bild: viel Text, keine Handlung in Reichweite.

Was Denotato stattdessen tut. §15 legt für EmptyState fest: Der Satz unter Horizont und Eule ist die Aussage des Schirms, in der Lesetinte — kein Werbesatz.

Gegenprobe. Steht neben dem Satz eine Handlung, die den leeren Zustand beendet?

Quelle. Apple, Human Interface Guidelines › Writing, Abschnitt „Best practices": „Guide people on actions they can take, and give them a button or link to do so if possible." — <https://developer.apple.com/design/human-interface-guidelines/writing>

K11 — Bestätigungsdialoge für Umkehrbares, statt Rückgängig anzubieten

Merkmal. Eine Handlung, die sich leicht rückgängig machen ließe, wird trotzdem durch einen Ja/Nein-Dialog blockiert, statt sie sofort auszuführen und für kurze Zeit ein Zurücknehmen anzubieten.

Woran man es erkennt. Im Code: ein confirm() oder ein eigener Dialog vor einer Aktion, die keinen dauerhaften, unwiderruflichen Verlust verursacht. Im Bild: ein Dialog mit „Bist du sicher?" vor etwas, das man in einer Rücknahmeleiste genauso gut anbieten könnte.

Was Denotato stattdessen tut. §15 hat den Kern schon: Wegtun fragt gestuft (erster Klick fragt, zweiter handelt) und nennt bei Wiederherstellbarem die Frist im Tooltip; endgültige Löschungen fragen weiter, alles andere bekommt zunehmend eine Rücknahmeleiste („Zurücknehmen" ist laut N308 fest an diese Leiste gebunden).

Gegenprobe. Wäre ein sechs Sekunden sichtbares „Zurücknehmen" nach der sofortigen Handlung genauso sicher wie die Frage vorher?

Quelle. Apple, Human Interface Guidelines › Feedback, Abschnitt „Best practices": „Warn people when they initiate a task that can cause data loss that's unexpected and irreversible. … don't warn people when data loss is the expected result of their action." — <https://developer.apple.com/design/human-interface-guidelines/feedback>

K12 — Dieselbe Sache mit zwei Wörtern auf zwei Schirmen

Merkmal. Was auf einem Schirm „Vorhaben" heißt, heißt auf dem nächsten „Aufgabe" oder „Todo" — dieselbe Sache, verschiedene Namen.

Woran man es erkennt. Im Code: verschiedene Bezeichner oder Übersetzungsschlüssel für denselben Datentyp in verschiedenen Plugins. Im Bild: derselbe Begriff taucht mit unterschiedlichem Wortlaut an verschiedenen Stellen der Navigation auf.

Was Denotato stattdessen tut. Bezeichner sind englisch, Texte deutsch (Grundsatz 1); ein Begriff bekommt ein Wort und behält es plugin- und schirmübergreifend.

Gegenprobe. Findet man mit demselben Suchwort dieselbe Sache auf jedem Schirm, auf dem sie vorkommt?

Quelle. Nielsen Norman Group, „10 Usability Heuristics for User Interface Design", Heuristik 4 „Consistency and standards": Nutzer sollen sich nicht fragen müssen, ob verschiedene Wörter dasselbe meinen. — <https://www.nngroup.com/articles/ten-usability-heuristics/> (Host über den Netzproxy dieser Sitzung nicht direkt erreichbar, Inhalt über Suchergebnisse gegengeprüft.)

K13 — Dieselbe Handlung an zwei Orten desselben Schirms

Merkmal. Ein und dieselbe Aktion lässt sich an zwei verschiedenen Stellen desselben Schirms auslösen (etwa ein Knopf im Kopf und ein zweiter, gleichwertiger am Fuß derselben Karte), ohne dass die zweite Stelle einen eigenen Zweck hat.

Woran man es erkennt. Im Code: derselbe onClick-Handler oder dieselbe Route, an zwei Stellen der gleichen Komponente verdrahtet. Im Bild: zwei Knöpfe mit demselben Ziel, sichtbar auf einen Blick.

Was Denotato stattdessen tut. Jede Handlung bekommt einen Ort; ist ein zweiter Zugang gewollt (etwa kurz und lang), unterscheiden sich Wortlaut oder Kontext klar erkennbar.

Gegenprobe. Ändert sich am Ergebnis etwas, wenn man einen der beiden Wege entfernt?

Quelle. Laws of UX, „Hick's Law": Mit der Zahl gleichwertiger Möglichkeiten wächst die Zeit bis zur Entscheidung — ein doppelter, funktionsgleicher Weg vergrößert die Auswahl, ohne einen Nutzen zu bringen. — <https://lawsofux.com/hicks-law/> (Host über den Netzproxy dieser Sitzung nicht direkt erreichbar, Inhalt über Suchergebnisse gegengeprüft.)

K14 — Uneinheitliche Abstände ohne Rasterlogik

Merkmal. Abstände zwischen Elementen wirken zufällig — mal 10, mal 13, mal 18 Pixel, ohne erkennbares Vielfaches einer Grundeinheit.

Woran man es erkennt. Im Code: margin/padding/gap mit rohen, uneinheitlichen Pixelwerten statt aus einer Abstandsskala des Themes. Im Bild: Zeilen und Karten, die knapp, dann wieder großzügig auseinander- stehen, ohne dass der Unterschied etwas bedeutet.

Was Denotato stattdessen tut. verify:arch meldet rohe Abstände (§19); §15.1 legt außerdem die Rasterlogik für Kacheln fest (minmax(min(280px, 100%), 1fr)).

Gegenprobe. Lässt sich jeder verwendete Abstand auf ein Vielfaches derselben Grundeinheit zurückführen?

Quelle. Apple, Human Interface Guidelines › Layout, Abschnitt „Visual hierarchy": „Align elements to make them easier to scan … alignment makes an app look neat and organized." — <https://developer.apple.com/design/human-interface-guidelines/layout>

K15 — Zu viele Akzentfarben auf einem Schirm

Merkmal. Jede Kachel, jedes Icon bekommt eine eigene, kräftige Farbe, sodass der Schirm wie ein Regenbogen aussieht, ohne dass die Farben etwas unterscheiden, was Wort oder Form nicht schon unterscheiden.

Woran man es erkennt. Im Code: mehr als zwei, drei verschiedene Wertfarben gleichzeitig auf sichtbaren Flächen desselben Schirms. Im Bild: viele bunte Flächen nebeneinander ohne erkennbares Ordnungsprinzip.

Was Denotato stattdessen tut. §19 kennt einen Teil davon schon: zwei Bereichsfarben auf einem Schirm ohne Ding aus dem anderen Bereich sind verboten; dieselbe Zurückhaltung gilt für Akzentfarben allgemein.

Gegenprobe. Kann man mit einer Hand voll Farben (statt einem Dutzend) noch alles unterscheiden, was der Schirm unterscheiden muss?

Quelle. Apple, Human Interface Guidelines › Color, Abschnitt „Liquid Glass color": zu viel Farbe könne „overwhelming" wirken und Beschriftun- gen schwerer lesbar machen. — <https://developer.apple.com/design/human-interface-guidelines/color>

K16 — Dekorative Icons ohne Funktion

Merkmal. Vor jedem Menüpunkt, jeder Zeile steht ein Icon, das nichts zusätzlich aussagt, was das Wort daneben nicht schon sagt — reine Auflockerung.

Woran man es erkennt. Im Code: ein <Icon> neben jedem Eintrag einer Liste, unabhängig vom Inhalt, oft ohne aria-hidden und ohne eigenes Label. Im Bild: eine Wand aus kleinen Symbolen, von denen sich viele ähneln oder wiederholen.

Was Denotato stattdessen tut. Ein Zeichen ohne Wort ist aria-hidden neben einem Wort oder trägt selbst ein Label (§17); Zeichen stehen für eine eigene Information, nicht als Lückenfüller.

Gegenprobe. Fehlt dem Eintrag etwas, wenn man das Icon entfernt und nur Wort und Form behält?

Quelle. Nielsen Norman Group, „10 Usability Heuristics", Heuristik 8 „Aesthetic and minimalist design": Oberflächen sollen keine Information enthalten, die selten gebraucht wird, weil jede zusätzliche Einheit mit den relevanten konkurriert. — <https://www.nngroup.com/articles/ten-usability-heuristics/> (Host über den Netzproxy dieser Sitzung nicht direkt erreichbar, Inhalt über Suchergebnisse gegengeprüft.)

K17 — Hover als einziger Weg

Merkmal. Eine Handlung oder eine Information erscheint nur, wenn die Maus über einer Stelle schwebt — auf einem Bildschirm mit Berührung gibt es sie nicht.

Woran man es erkennt. Im Code: :hover als einzige Bedingung, unter der ein Knopf, ein Tooltip oder ein Menü erscheint, ohne :focus- Gegenstück oder Tap-Alternative. Im Bild (am Telefon nachgestellt): eine Zeile, die am Schreibtisch eine Aktion zeigt, am Telefon aber keine.

Was Denotato stattdessen tut. §16 setzt Telefon und Schreibtisch gleichrangig; jede Aktion, die per Hover erscheint, braucht einen gleichwertigen Weg per Tastatur oder Berührung.

Gegenprobe. Findet man dieselbe Handlung ohne Maus, nur mit Tastatur oder Finger?

Quelle. W3C, WCAG 2.2, Kriterium 2.1.1 „Keyboard" (Stufe A): jede Funktion muss über die Tastatur erreichbar sein. — <https://www.w3.org/WAI/WCAG22/quickref/#keyboard> (Host über den Netzproxy dieser Sitzung nicht direkt erreichbar, Inhalt über Suchergebnisse gegengeprüft.)

K18 — Fehlermeldungen ohne nächsten Schritt

Merkmal. Ein Fehler meldet nur, dass etwas falsch ist („Ungültige Eingabe", „Ein Fehler ist aufgetreten"), nicht, was man jetzt tun kann.

Woran man es erkennt. Im Code: ein Fehlertext, der aus einem rohen Statuscode oder einer generischen Konstante kommt, ohne Bezug zum konkreten Feld. Im Bild: ein roter Text ohne erkennbaren Bezug zu einem Feld oder ohne Vorschlag zur Behebung.

Was Denotato stattdessen tut. Fehler stehen direkt am betroffenen Feld und sagen, was zu tun ist, statt nur, was falsch war.

Gegenprobe. Weiß man nach dem Lesen der Meldung, was man als Nächstes anders eingeben oder tun muss?

Quelle. Apple, Human Interface Guidelines › Writing, Abschnitt „Best practices": „Avoid robotic error messages with no helpful information, like 'Invalid name.'" — <https://developer.apple.com/design/human-interface-guidelines/writing>

K19 — Generische Platzhaltertexte im ausgelieferten Code

Merkmal. Texte wie „Lorem ipsum", „Text kommt hier hin", „TODO" oder ein technischer Platzhaltername stehen noch dort, wo eigentlich ein Inhalt oder eine Beschriftung stehen sollte.

Woran man es erkennt. Im Code: Zeichenketten wie Lorem, TODO, Platzhalter, test123 in sichtbaren Texten außerhalb von Tests. Im Bild: ein Wort oder Satz, der offensichtlich nicht für Nutzer gedacht war.

Was Denotato stattdessen tut. Jeder sichtbare Text ist ein fertiger, deutscher Text (Grundsatz 1); Platzhalter für Entwicklung stehen nur in Tests oder hinter einem Entwicklerschalter.

Gegenprobe. Der Nachweis packages/frontend/src/components/feedback/platzhaltertext.test.ts (RL07, seit dem 28.09.2026) sucht in allen sichtbaren Zeichenketten des Client-Codes — t()-Sätze, JSX-Text, placeholder, aria-label, title, label, alt — nach Lorem, TODO, FIXME, Platzhalter, test123, XXX und „Text kommt hier“, und wird rot, sobald einer auftaucht. Im Bild bleibt der Blick: ein Satz, der nicht für Nutzer gedacht war.

Quelle. Eigenes Urteil, gestützt auf Apple, Human Interface Guidelines › Writing: geschriebene Oberflächentexte gelten als Teil der Gestaltung, nicht als Nebensache. — <https://developer.apple.com/design/human-interface-guidelines/writing>

K20 — Gleichgewichtete Aktionen ohne Primäraktion

Merkmal. Mehrere Knöpfe auf einem Schirm sehen alle gleich aus (alle gefüllt, alle nur umrandet, alle in derselben Stärke), ohne dass klar ist, welche Handlung die naheliegende ist.

Woran man es erkennt. Im Code: mehrere <Button variant="primary"> nebeneinander oder umgekehrt lauter variant="ghost" ohne einen hervorgehobenen. Im Bild: eine Reihe optisch gleichwertiger Knöpfe.

Was Denotato stattdessen tut. §15 hat es schon: Button unterscheidet primär (Rollenfarbe), sekundär (Stein) und Geist (transparent) — auf jedem Schirm höchstens eine primäre Aktion.

Gegenprobe. Sieht man ohne zu lesen, welcher Knopf die naheliegende Handlung ist?

Quelle. Apple, Human Interface Guidelines › Color, Abschnitt „Liquid Glass color": Farbe am Hintergrund ist für die primäre Aktion reserviert, nicht für mehrere Knöpfe gleichzeitig. — <https://developer.apple.com/design/human-interface-guidelines/color>

K21 — Übertriebene Bewegung ohne Funktion

Merkmal. Elemente wippen, wachsen, gleiten beim Erscheinen mit sichtbarem Schwung, obwohl die Bewegung nichts über Ursache oder Wirkung der Handlung erklärt.

Woran man es erkennt. Im Code: Federn oder Keyframes mit auffälligem Überschwingen an Stellen ohne Zustandswechsel, scale auf :hover, oder Bewegung, die nicht an bewegung.stufe hängt. Im Bild: ein Schirm, auf dem ständig etwas in Bewegung ist, auch ohne Interaktion.

Was Denotato stattdessen tut. §19 und §17 haben es schon: ein Knopf, der beim Hover wächst, ist verboten; jede Bewegung hängt an bewegung.stufe/prefers-reduced-motion.

Gegenprobe. Erklärt die Bewegung eine Ursache-Wirkung (was wurde geöffnet, verschoben, bestätigt) — oder läuft sie einfach mit?

Quelle. Style-Guide §17/§19 (bestehende Regel); Apple, Human Interface Guidelines › Feedback nennt Bewegung als eine von mehreren Rückmeldungsformen, die zur Bedeutung der Handlung passen muss. — <https://developer.apple.com/design/human-interface-guidelines/feedback>

K22 — Text-Wüsten ohne Gliederung

Merkmal. Ein längerer Absatz ohne Zwischenüberschrift, Aufzählung oder Absatzumbruch, der mehrere Gedanken auf einmal trägt.

Woran man es erkennt. Im Code: ein einzelnes <p> mit mehreren hundert Zeichen und mehreren Aussagen. Im Bild: eine graue Fläche aus Text ohne optische Ankerpunkte.

Was Denotato stattdessen tut. Ein Gedanke je Absatz, Aufzählungen für Listen von Gleichrangigem, Zwischenüberschriften ab einer gewissen Länge.

Gegenprobe. Findet man mit einem kurzen Blick (nicht Lesen) die Stelle, die einen interessiert?

Quelle. GOV.UK Content Design, Leitsatz zu kurzen Absätzen und klarer Sprache — <https://www.gov.uk/guidance/content-design/writing-for-gov-uk> (Host über den Netzproxy dieser Sitzung nicht direkt erreichbar, Inhalt über Suchergebnisse gegengeprüft.)

K23 — Titel-Großschreibung und Emoji in Überschriften

Merkmal. Überschriften Schreiben Jedes Wort Groß, oder tragen ein schmückendes Emoji, das nichts zusätzlich sagt.

Woran man es erkennt. Im Code: text-transform: capitalize auf Überschriften deutscher Texte (die deutsche Groß-/Kleinschreibung kennt das nicht) oder ein Emoji-Zeichen in einer Überschriftenkonstante. Im Bild: eine Überschrift, in der jedes Wort groß beginnt, oder ein Symbol vor dem Titel, das nicht das gezeichnete Zeichen des Bereichs ist.

Was Denotato stattdessen tut. §19 hat den Kern schon: kein Emoji neben einem gezeichneten Zeichen in einer Zeile; deutsche Überschriften folgen der deutschen Groß-/Kleinschreibung, nicht der englischen Titelschreibung.

Gegenprobe. Würde ein Lektor die Überschrift so auch in einem gedruckten deutschen Text schreiben?

Quelle. Apple, Human Interface Guidelines › Writing, Abschnitt „Best practices": Großschreibungsregeln sollen zum eigenen Stil passen und dann konsequent gelten — nicht plötzlich wechseln. — <https://developer.apple.com/design/human-interface-guidelines/writing>

K24 — Bestätigungsfragen für Handlungen ohne Risiko

Merkmal. Ein Dialog fragt „Bist du sicher?" vor einer Handlung ohne jeden dauerhaften Effekt — etwa vor dem Schließen eines Filters, dem Verlassen einer leeren Eingabe oder dem Abbrechen einer Auswahl, die man jederzeit wiederholen kann.

Woran man es erkennt. Im Code: ein confirm() oder Dialogaufruf vor einer Funktion, die keinen Datenverlust und keine dauerhafte Änderung auslöst. Im Bild: ein Dialog mit Ja/Nein, dessen „Nein" praktisch nie gewählt wird, weil es nichts zu verlieren gibt.

Was Denotato stattdessen tut. Nur Löschen fragt, und zwar über Wegtun (§15); alles andere ohne dauerhaften Verlust geschieht sofort.

Gegenprobe. Was verliert man wirklich, wenn man auf „Ja" klickt, ohne den Dialog gesehen zu haben?

Quelle. Apple, Human Interface Guidelines › Feedback, Abschnitt „Best practices": „don't warn people when data loss is the expected result of their action." — <https://developer.apple.com/design/human-interface-guidelines/feedback>

K25 — Zielflächen unter dem Mindestmaß

Merkmal. Ein Knopf, ein Kreuz, ein Pfeil ist zwar sichtbar groß genug, aber die tatsächlich klickbare oder tippbare Fläche darum ist kleiner als das Mindestmaß.

Woran man es erkennt. Im Code: ein eigener kleiner Knopf mit padding: 4px 6px oder weniger, gebaut statt aus ActionButton wiederverwendet. Im Bild (am Telefon): ein Antippen daneben trifft regelmäßig die falsche Zeile oder nichts.

Was Denotato stattdessen tut. §16.1 hat es schon: jede Fläche, die man unter pointer: coarse drückt, ist mindestens 44 × 44 Pixel groß, auch wenn das Zeichen darin kleiner ist (seit 08.10.2026; vorher 40, E30).

Gegenprobe. Was passiert, wenn man knapp danebentrifft — nichts, oder die falsche Zeile bewegt sich?

Quelle. W3C, WCAG 2.2, Kriterium 2.5.8 „Target Size (Minimum)" (Stufe AA): Zielflächen mindestens 24 × 24 CSS-Pixel oder mit ausreichendem Abstand. — <https://www.w3.org/WAI/WCAG22/quickref/#target-size-minimum> (Host über den Netzproxy dieser Sitzung nicht direkt erreichbar, Inhalt über Suchergebnisse gegengeprüft; §16.1 setzt mit 44 px bereits einen höheren Wert an.)

K26 — Fokus nicht sichtbar oder nicht per Tastatur erreichbar

Merkmal. Klickt man sich mit der Tabulatortaste durch den Schirm, sieht man nicht, wo man gerade ist, oder man kommt an einer selbstgebauten Komponente gar nicht vorbei.

Woran man es erkennt. Im Code: ein div mit onClick, aber ohne tabIndex, role und Tastaturbehandlung, oder ein eigener Fokus-Stil, der outline: none setzt, ohne Ersatz. Im Bild: Tab drücken zeigt keinen erkennbaren Ring, der wandert.

Was Denotato stattdessen tut. §17 hat es schon: Fokusring 2 px in Anwendungsfarbe (oder Gold), außen, überall.

Gegenprobe. Kommt man mit der Tastatur allein durch den ganzen Schirm, und sieht man dabei immer, wo man ist?

Quelle. W3C, WCAG 2.2, Kriterium 2.4.11 „Focus Not Obscured (Minimum)" und 2.4.7 „Focus Visible" (Stufe AA) — <https://www.w3.org/WAI/WCAG22/quickref/#focus-visible> (Host über den Netzproxy dieser Sitzung nicht direkt erreichbar, Inhalt über Suchergebnisse gegengeprüft; deckt sich mit §17.)

K27 — Kontrast unter der Schwelle, vor allem auf farbigem Grund

Merkmal. Text in einer Bereichs- oder Wertfarbe steht direkt auf einer Fläche in ähnlicher Farbe, oder Nebentext ist auf farbigem Grund so blass, dass er kaum lesbar ist.

Woran man es erkennt. Im Code: Textfarbe aus derselben Farbfamilie wie die Hintergrundfläche, ohne berechneten Kontrast. Im Bild: Text, der mit zusammengekniffenen Augen kaum vom Hintergrund zu unterscheiden ist.

Was Denotato stattdessen tut. §17 hat es schon vollständig: Text ≥ 4,5 : 1, Nebentext ≥ 3 : 1, auch auf farbiger Fläche, mit Ton, der aus der Fläche selbst abgeleitet wird, nicht aus der Szene geraten.

Gegenprobe. Bleibt der Text lesbar, wenn man das Bild in Graustufen umwandelt?

Quelle. W3C, WCAG 2.2, Kriterien 1.4.3 „Contrast (Minimum)" und 1.4.11 „Non-text Contrast" — <https://www.w3.org/WAI/WCAG22/quickref/#contrast-minimum> (Host über den Netzproxy dieser Sitzung nicht direkt erreichbar, Inhalt über Suchergebnisse gegengeprüft; §17 setzt dieselben Zahlen bereits um).

K28 — Mehrere Aufgaben auf einer Seite statt einer Sache

Merkmal. Ein Schirm versucht gleichzeitig eine Übersicht, eine Einstellung und ein Formular zu sein, ohne dass klar ist, welche Aufgabe er eigentlich löst.

Woran man es erkennt. Im Code: eine einzige Routenkomponente, die Statistik, Formular und Liste ohne klare Abschnittstrennung mischt. Im Bild: der Schirm hat keinen einzelnen Satz, der zusammenfasst, wozu er da ist.

Was Denotato stattdessen tut. Jeder Schirm hat eine erkennbare Hauptaufgabe; Nebenaufgaben stehen zurückhaltender oder auf einem eigenen Schirm.

Gegenprobe. Lässt sich in einem Satz sagen, wozu dieser Schirm da ist — ohne „und"?

Quelle. GOV.UK Design System, Leitprinzip „eine Sache je Seite" für Formulare und Aufgaben — <https://design-system.service.gov.uk/get-started/content-design/> (Host über den Netzproxy dieser Sitzung nicht direkt erreichbar, Inhalt über Suchergebnisse gegengeprüft.)

K29 — Englischer Entwicklerjargon in der deutschen Oberfläche

Merkmal. Rohe Bezeichner, Statuscodes oder englische Fachwörter tauchen unübersetzt im sichtbaren Text auf („null", „undefined", „Payload", ein englischer Enum-Wert).

Woran man es erkennt. Im Code: ein Wert wird direkt aus einer API-Antwort in den Text interpoliert, ohne durch eine Übersetzungstabelle zu laufen. Im Bild: ein englisches Wort oder ein technischer Wert mitten im deutschen Satz.

Was Denotato stattdessen tut. Bezeichner sind englisch, Texte deutsch (Grundsatz 1); jeder sichtbare Wert hat eine deutsche Entsprechung, auch Status- und Fehlercodes.

Gegenprobe. Grep nach undefined, null, [object Object] oder GROSSGESCHRIEBENEN Enum-Werten in sichtbaren Texten — findet er etwas?

Quelle. Apple, Human Interface Guidelines › Writing, Abschnitt „Getting started": „Write for everyone … avoiding jargon." — <https://developer.apple.com/design/human-interface-guidelines/writing>

K30 — Zu viele gleichrangige Wahlmöglichkeiten auf einmal

Merkmal. Ein Menü, eine Werkzeugleiste oder ein Formular zeigt alle Optionen auf einmal, flach nebeneinander, statt die selteneren hinter einer Geste zu verstecken.

Woran man es erkennt. Im Code: eine einzige flache Liste mit mehr als etwa sieben, acht gleichrangigen Einträgen ohne Gruppierung oder Ausklappen. Im Bild: eine Werkzeugleiste oder ein Menü, das auf den ersten Blick überfordert.

Was Denotato stattdessen tut. §18 lässt Einstellungsgruppen ab etwa fünf Gruppen zuklappen; Navigation und Menüs gruppieren nach Bereich statt alles auf eine Ebene zu legen.

Gegenprobe. Zählt man auf einen Blick mehr als etwa sieben gleichrangige Optionen, bevor man wählen kann?

Quelle. Laws of UX, „Hick's Law": die Entscheidungszeit wächst mit der Zahl und Komplexität der Wahlmöglichkeiten. Auch Apple, Human Interface Guidelines › Layout, Abschnitt „Visual hierarchy": „Use progressive disclosure to make layouts cleaner and easier to interact with." — <https://lawsofux.com/hicks-law/> (Host über den Netzproxy dieser Sitzung nicht direkt erreichbar, Inhalt über Suchergebnisse gegengeprüft) und <https://developer.apple.com/design/human-interface-guidelines/layout>

Quellen

Hinweis zu den fünf gesperrten Hosts. WebFetch scheiterte an allen fünf mit EGRESS_BLOCKED (Organisationsrichtlinie des Netzproxys dieser Sitzung, nicht am jeweiligen Server). WebSearch lief über einen anderen Weg und lieferte für jede Quelle mehrere unabhängige, übereinstimmende Treffer (unter anderem offizielle Sekundärquellen wie Vorschauen der W3C- und NNG-Seiten selbst in den Suchergebnissen). Die Kriteriennummern, Schwellenwerte und Heuristiken oben sind seit Jahren stabil und öffentlich extrem gut dokumentiert; trotzdem gilt die Zurückhaltung aus N362 auch hier — kein Eintrag zitiert mehr als einen kurzen Satz, und jeder nennt den gesperrten Zugriff statt ihn zu verschweigen. Christian oder Ben sollten die vier externen Nicht- Apple-Quellen bei Gelegenheit stichprobenartig direkt gegenlesen, bevor ein Eintrag in den Style-Guide übernommen wird, der ausschließlich auf einer gesperrten Quelle beruht (K04, K12, K13, K16, K17, K22, K25, K26, K27, K28, K30).

Material Design 3 wurde recherchiert (Farbrollen, Zustände), lieferte aber keinen Aspekt, der nicht schon über Apple oder den Style-Guide selbst belegt war — deshalb taucht es oben nicht als Einzelquelle eines Eintrags auf, bleibt aber in der Tabelle, weil es Teil des Auftrags war.