Regeln für Web-Oberflächen in einem Regelwerk schreiben und vor dem Veröffentlichen prüfen

## Vor einer Regeländerung bearbeitbare Quelldateien von erzeugten Dateien unterscheiden Behandle ein Regelwerk für Web-Oberflächen als Produkt aus Quellinhalten, Schemata, Programmierschnittstellen, Prüfwerkzeugen, dargestellten Seiten und erzeugten Verzeichnissen. Bestimme vor einer Änderung, welche Schicht für das Verhalten zuständig ist, und untersuche sie sowie ihre direkten Verbraucher. - Erfasse das Inhaltspaket, gemeinsame Typen und Schemata, Anwendungsoberflächen, den Werkzeugserver und erzeugte Ausgaben. - Nutze vorhandene Prüf- und Regelsuchwerkzeuge des Codebestands, statt Leitlinien aus dem Gedächtnis zu erfinden. - Prüfe untersuchten Code, bevor du Korrekturen empfiehlst, und durchsuche den Regelbestand, bevor du Aussagen zu Barrierefreiheit, Leistung, Suchmaschinenoptimierung, Sicherheit, Datenschutz, Internationalisierung oder Tests triffst. - Führe eine umfassende Prüfung nur aus, wenn die Aufgabe sie verlangt. - Unterscheide bearbeitbare Quellen von erzeugten Artefakten und dargestellten Projektionen. Leite Kompatibilitätsleitlinien aus der erklärten Browserrichtlinie und paketgestützten Daten ab. Verlasse dich nicht auf erinnerte Unterstützungstabellen und behandle eine erzeugte Ansicht niemals stillschweigend als maßgebliche Quelle. ## Die Metadaten festlegen, die jede Regel haben muss Jede Regel benötigt einen stabilen Metadatenvertrag für Auswertung, Suche, Bewertung, Prüfung und Darstellung. Halte die Pflichtmenge klein genug, um sie einheitlich durchzusetzen. Pflichtmetadaten sollen Folgendes enthalten: - einen in Anführungszeichen gesetzten, verständlichen Titel und eine Beschreibung in einem Satz; - eine zulässige Kategorie, Priorität und Schwierigkeit; - eine ganzzahlige Aufwandsschätzung mit angegebener Einheit; - ausführbare Anweisungen zum Prüfen, Beheben und Erläutern der Regel. Nützliche optionale Metadaten sind Unterkategorie, knappe Kernaussagen, Auswirkungen auf Nutzer oder Geschäft, Nachweisquellen, ergänzende Materialien, verwandte Regeln, Werkzeuge, Schlagwörter, eine Codeprüfanweisung und Kontext für automatische Prüfungen. Prüfe Kategorien und Aufzählungswerte gegen maßgebliche Positivlisten. Setze Werte mit syntaktisch bedeutsamer Zeichensetzung in Anführungszeichen. Füge Felder nicht nur hinzu, weil sie nützlich klingen, sondern ausschließlich, wenn Auswertungsprogramm, Benutzeroberfläche, Suchschicht oder Generator sie verwenden. Anweisungen müssen das Prüfobjekt und die erwartete Behebung nennen. Weise Platzhalter wie „Diese Regel prüfen“ zurück, die keine ausführbare Prüfstrategie bieten. ## Nachweise, Zusatzlektüre und Links zu verwandten Regeln getrennt halten Halte maßgebliche Nachweise in strukturierten Quellenmetadaten. Lege optionale Lektüre und Werkzeuge in Materialmetadaten und regelübergreifende Navigation in Metadaten verwandter Regeln ab. Ersetze keine Rolle durch eine andere. - Gib jeder Regel mindestens 2 relevante Quellen mit 2 unterschiedlichen Quellenrollen und mindestens 1 primäre Autorität. - Verwende stabile Kennungen für Nachweise, wenn die Verarbeitungskette sie unterstützt. - Halte allgemeine Zeilen wie „Siehe auch“ und „Referenz“ aus dem Textkörper heraus. - Verlinke ein benanntes Werkzeug bei seiner ersten bedeutsamen Erwähnung, wenn es wesentlich hilft und bereits in Material- oder Werkzeugmetadaten steht. Verweise im Text sollen eine konkrete Aussage oder Umsetzungsentscheidung stützen. Ein sinnvoller Richtwert sind 2–5 Verweise je Regel, davon 0–1 in der Einleitung und 1–3 in den Hauptleitlinien. Interne Regelverweise bleiben meist bei 0–1; nur ungewöhnlich eng verbundene Themen erhalten 2. Bevorzuge beschreibenden Verweistext gegenüber Bezeichnungen wie „Mehr lesen“. Lass Erstellungswerkzeuge sicher ableitbare Felder erschließen, aber rechtfertige schwache oder irrelevante Nachweise niemals durch Ableitung. ## In jeder Regel Codebeispiele vor die Begründung und die Prüfung ans Ende stellen Schreibe jede Regel in stabiler Reihenfolge, damit Menschen, Arbeitsagenten und Prüfprogramme dieselben Informationen finden: 1. eine kurze, allgemein verständliche Einleitung; 2. ein wirklichkeitsnahes Codebeispiel oder mehrere Beispiele; 3. eine Erklärung, warum die Regel wichtig ist; 4. erforderliche Umsetzungsleitlinien; 5. einen abschließenden Prüfabschnitt. Stelle Beispiele vor die Begründung und behalte die Prüfung als letzten Hauptabschnitt bei. Ordne optionale Abschnitte wie bewährte Verfahren, häufige Fehler, Rahmenwerkbeispiele, Werkzeuge, Schwellenwerte, Ausnahmen, Browserunterstützung, Normen und Umsetzungshinweise dazwischen ein. Füge Ausnahmen nur bei gültigen Einschränkungen oder Fehlalarmen hinzu. Teile die Prüfung nur dann in automatische und manuelle Kontrollen, wenn beide sinnvoll sind. Ergänze einen sichtbaren Norm- oder Unterstützungshinweis, wenn Kompatibilität oder Regelkonformität die Umsetzungsentscheidung verändert. Bevorzuge eindeutige Bestehen-/Nichtbestehen-Anweisungen gegenüber allgemeinen Ratschlägen. Beschreibe, wie die Regel geprüft wird, welche Nachweise gelten und welche Bedingung die Prüfung scheitern lässt. ## Regeln für Web-Oberflächen messbare Grenzwerte für Bestehen oder Scheitern geben Verwende messbare Schwellenwerte, sobald eine Regel geprüft werden kann: - Leistungsbudgets wie `LCP <= 2.5s`, `CLS <= 0.1` oder Größenobergrenzen für Ressourcen; - Barrierefreiheitskriterien wie Kontrastverhältnisse, Zielgrößen, Tastaturverhalten, Vergrößerung und Umfluss; - Zustände der Suchmaschinenoptimierung wie Indexierbarkeit, Statuscodes und Verhalten kanonischer URLs; - Sicherheitsanforderungen wie Bedingungen für Übertragung und Antwortkopfzeilen. Vergib Prioritäten nach den Folgen: Die höchste Stufe ist Ausfällen der Website sowie Sicherheits- oder Rechtsverstößen vorbehalten; niedrigere Stufen gelten für beeinträchtigte Nutzung, bewährte Verfahren und optionale Verfeinerungen. Beispiele müssen wirklichkeitsnah genug sein, um die Fehlerart sichtbar zu machen. Nimm wichtige Ausnahmen und Unterstützungsgrenzen auf, aber füge nicht jeder Regel jeden optionalen Abschnitt hinzu. Behandle die Prüfung als Bestandteil der Regel, nicht als spätere Redaktionsaufgabe. Eine Empfehlung ohne reproduzierbare Kontrolle ist unvollständig. ## Gemeinsame UI-Bausteine ins Designsystem legen, nicht in einzelne Seiten Lege Typografie, Symbole, semantische Farben, wiederverwendbare Komponenten und andere anwendungsübergreifende Belange in einem gemeinsamen Gestaltungssystem ab. Anwendungen verdrahten die rahmenwerkspezifische Einbindung und nutzen dabei den gemeinsamen Vertrag. - Verwende vorhandene Komponenten wieder, bevor du seitenspezifische Varianten erstellst. - Wende eine gemeinsame Funktion auf jede betroffene Oberfläche an, nicht nur auf die zuerst anfragende Seite. - Halte untergeordnete Bedienelemente bei Kartenmustern mit flächigem Verweis bedienbar. - Zentralisiere Markensymbole und Rahmenwerksymbole; Verbraucher dürfen die Grenze des Gestaltungssystems nicht umgehen. - Bevorzuge semantische Gestaltungsvariablen mit dem vollständig beabsichtigten Kontrast gegenüber beliebigen Deckkraftänderungen. - Stelle Listenzeichen ausdrücklich wieder her, wenn eine CSS-Zurücksetzung sie aus formatiertem Text entfernt. Unterdrücke keine Warnungen zur server- und clientseitigen Hydratisierung, um Abweichungen zu verbergen. Behebe die Zustandsgrenze, etwa indem du ausschließlich clientseitigen Zustand bis nach dem Einhängen zurückstellst. Belasse browserseitigen Schutz bei Browseränderungen und Formularen. Wende clientseitige Bot-Prüfungen nicht auf programmatische API-Endpunkte an, die keine Browseraufgabe abschließen können. ## Ein neues Werkzeug vollständig anbinden, von der Definition bis zu den Tests Ein neues Werkzeug oder eine paketübergreifende Funktion ist erst vollständig, wenn Definition, Export, Registrierung, Weiterleitung, Umsetzung, Tests und Dokumentation übereinstimmen. Für ein aufrufbares Werkzeug: 1. Definiere einen eindeutigen Namen, eine Beschreibung und ein Eingabeschema. 2. Exportiere es an der Paketgrenze. 3. Registriere es im Werkzeugverzeichnis des Servers. 4. Verbinde es mit dem Weiterleitungsweg. 5. Prüfe Auffindbarkeit, Validierung, Weiterleitung und Verhalten. Verwende Sammelmodule nur an Paketgrenzen; interne Sammelmodule verlängern Navigationswege und verbergen Zuständigkeit. Zentralisiere gemeinsame Abhängigkeitsversionen, wenn mehrere Pakete sie verwenden, und ordne Skripte nach Zweck mit einem gepflegten Verzeichnis. Beachte versionsabhängige Bibliotheksverträge. Verwende beispielsweise die aktuelle Fehlerform des installierten Prüfprogramms, erzeuge zustandsbehaftete Abfragekomponenten über die genehmigte Fabrik des Codebestands und ordne asynchrone Konfigurationshüllen so, dass alle zurückgegebenen Eigenschaften erhalten bleiben. Starte Dienste nach Änderungen an beim Start geladener Konfiguration neu. Eine erfolgreiche Bearbeitung ist erst ein Nachweis, wenn der laufende Prozess sie geladen hat. ## Vor dem Veröffentlichen alle Prüfungen ausführen, ohne eine zu überspringen Führe nach Änderungen an einer Regel oder ihrer Infrastruktur die maßgebliche Qualitätskette des Codebestands aus: - Prüfe Pflichtmetadaten, Kategorienwerte, Quellenqualität und Regelaufbau. - Bewerte ausführbare Anweisungen, Nachweise, Beispiele, Texttiefe, Prüfung, Schwellenwerte und zutreffende bedingte Abschnitte. - Führe Formatierung, Stil-, Typ- und Paketprüfungen, gezielte Tests sowie den für die geänderte Oberfläche erforderlichen vollständigen Erstellungsdurchlauf aus. - Erzeuge Verzeichnisse oder Fähigkeiten neu und bestätige, dass die erzeugte Ausgabe synchron ist. Umgehe Prüfungen vor dem Einchecken nicht. Behebe Fehler in Dokumentation, unsicheren Typumwandlungen, Komplexität, Importgrenzen, ungenutztem Code und Abdeckung, statt einen Weg ohne Prüfung zu verwenden. Behandle automatische Bewertung als Qualitätsgrenze, nicht als Beweis semantischer Richtigkeit. Prüfe neben der Quelldatei auch das dargestellte und das werkzeugseitige Ergebnis. Bestätige vor der Veröffentlichung, dass Pflichtanweisungen ausführbar, Nachweise maßgeblich und Beispiele passend zur Empfehlung sind, die Prüfung zuletzt steht und keine erzeugte Differenz verbleibt. Veröffentliche erst, nachdem die vollständige Kette bestanden ist.