Ergebnis und Verantwortung definieren
Das messbare Ziel dieses Leitfadens lautet: Ein viersprachiges Template mit korrektem lang, einer H1, lückenloser Hierarchie und benannten Kontrollen samt Fehlerhilfe veröffentlichen.
Verantwortung, Fehlwirkung, Stoppbedingung und nicht automatisierte Endfreigabe vor der Dateneingabe festlegen. Statt „lief“ Schwellen für Aufgabe, Genauigkeit, Zeit, Reversibilität und Erklärbarkeit definieren.
- Ein viersprachiges Template mit korrektem lang, einer H1, lückenloser Hierarchie und benannten Kontrollen samt Fehlerhilfe veröffentlichen.
Eingabevertrag vorbereiten
Dokumentsprache am Root und Sprachwechsel am Abschnitt markieren. Titel an der Nutzeraufgabe ausrichten, H2 für Hauptschritte, H3 für Unterentscheidungen. Labels statt Placeholder und Fehlerhilfe per aria-describedby verbinden.
Nur synthetische, eigene oder klar nutzbare Daten verwenden. Feld, Typ, Einheit, Sprache, Zeitzone, Sensibilität, Leerwert und Duplikatregel getrennt dokumentieren und Rohdaten schreibgeschützt bewahren.
Erfolgspfad kleinteilig aufbauen
aria-erisebilir-ad-envanteri, html-dil-baslik-yapisi-denetleyici, renk-kontrast-denetleyici, baslik-hiyerarsisi-denetleyici als Eingabeprüfung, Transformation, Ergebniskontrolle und Übergabe statt als Blackbox ordnen. Pro Gate Ausgabe, Fehler, Fortsetzung und Verantwortung festlegen.
Mit einem Datensatz oder kleiner Probe beginnen. Vor Abgleich und sichtbaren Annahmen nicht zu großen Dateien, automatischem Release oder echten Personendaten wechseln.
Fehlerpfade bewusst testen
Häufige Fehler: Status nur per Farbe, fehlender Fokus, wiederholte aria-labels, abweichende sichtbare/versteckte Namen und Fokusverlust nach Fehlern. Zusätzlich 200 % Zoom, lange deutsche Texte, chinesische Umbrüche und Bildschirmtastatur testen.
Leere, fehlerhafte, übergroße, doppelte, ungeordnete, mehrsprachige und absichtlich widersprüchliche Eingaben als Negativtests speichern. Fehler nennen Feld, Grund und Korrektur ohne stille Reparatur.
Nutzer- und Systemwirkung prüfen
Nutzeraufgabe per Tastatur, Mobil-Breakpoint und begrenztem Gerät vollständig prüfen. Zahlen, Summen, Identitäten, Leerwerte und Änderungen zwischen Quelle und Ergebnis abgleichen.
Gute Optik beweist keine Richtigkeit. Wichtige Aussagen an Primärquelle, Sicherheit an Bedrohungsmodell, Inhalt an Nutzeraufgabe und Performance an Browsermessung binden.
Release-Nachweis dokumentieren
Abnahmenachweise verbinden Inventar mit Tastaturaufgabe, Fokusfolge, Screenreader-Name/-Status, Fehlerbehebung und 320–1440-px-Breakpoints. Automatik und Nutzertest getrennt berichten.
Datum, Werkzeug-/Datenversion, Schwellen, Negativtests, Ergebnis, Risiko, Freigabe und Rollback dokumentieren. Screenshot allein ist nicht reproduzierbar; Konfiguration und Probe gemeinsam sichern.
Grenze und nächste Prüfung nennen
Statische HTML-Prüfung misst CSS-Sichtbarkeit, Shadow DOM, Hydration und Assistenztechnik nicht vollständig; ein Werkzeug beweist keine WCAG-Konformität.
Grenzen gleich sichtbar wie Ergebnisse machen und nächste Prüfung datieren. Bei Rechts-, Sicherheits-, Gesundheits- oder Finanzwirkung qualifizierte Prüfung mit aktuellen Primärquellen verpflichtend machen.
- Statische HTML-Prüfung misst CSS-Sichtbarkeit, Shadow DOM, Hydration und Assistenztechnik nicht vollständig; ein Werkzeug beweist keine WCAG-Konformität.
Den Ratgeber sicher ausprobieren
Testen Sie die Schritte aus „Barrierefreies HTML: Sprache, Überschriften, Formulare und Namen“ zuerst mit synthetischen Daten in ARIA-Namensinventar. Häkchen bleiben nur in diesem Tab.
Den Ratgeber in eine wiederholbare Prüfung überführen
Nutzen Sie diesen Prüfplan mit 4 Werkzeugen für „Barrierefreies HTML: Sprache, Überschriften, Formulare und Namen“. Ziel: Über visuelle Qualität hinaus Sprache, Überschriften, Namen, Tastatur und Fehler anhand echter Aufgaben prüfen. Praxisleitfaden mit Aufgaben, Fehlerszenarien, Abnahmenachweisen und Vertrauensgrenzen. Beginnen Sie mit einem sicheren Beispiel statt Echtdaten und dokumentieren Sie Sollergebnis und Abnahmeentscheidung jedes Schritts.
ARIA-Namensinventar
- Vorbereitung
- Beispiel laden oder die klar beschrifteten Felder für das eigene Szenario ausfüllen.
- Durchführung
- Lokal prüfen und Kennzahlen, Warnungen sowie Korrekturen gemeinsam auswerten.
- Abnahmekontrolle
- Ergebnis in der Zielumgebung bestätigen und Annahmen dokumentieren.
- Erwartete Ausgabe
- ein Inventar mit Elementtyp, Selektorhinweis, Namensquelle und Status für unbenannte oder verdächtige Elemente. Buttons, Links und Formularfelder samt zugänglichem Namen inventarisieren und unbenannte Elemente finden.
HTML-Sprach- und Überschriftenprüfung
- Vorbereitung
- Beispiel laden oder die klar beschrifteten Felder für das eigene Szenario ausfüllen.
- Durchführung
- Lokal prüfen und Kennzahlen, Warnungen sowie Korrekturen gemeinsam auswerten.
- Abnahmekontrolle
- Ergebnis in der Zielumgebung bestätigen und Annahmen dokumentieren.
- Erwartete Ausgabe
- eine Übersicht der Dokumentsignale, geordneter Überschriftenbaum und Korrekturhinweise je Quellenelement. HTML-lang, title, Meta-Beschreibung, einzelnes H1 und Überschriftenfolge gemeinsam prüfen.
Farbkontrast-Prüfer
- Vorbereitung
- unterstützte Farb-, CSS-, SVG-, Bild- oder Maßwerte Prüfen Sie das Format zuerst mit einem synthetischen Beispiel statt mit sensiblen Echtdaten.
- Durchführung
- Lokale Verarbeitung starten. Werte werden mit Browser-APIs und offengelegten Umrechnungen verarbeitet; die Quelle bleibt erhalten.
- Abnahmekontrolle
- Abnahmekriterium: visueller Vergleich auf hellen und dunklen Flächen, mehreren Bildschirmgrößen, in der Zielanwendung und mit der Quelle Bewahren Sie die Quelle auf und prüfen Sie die Ausgabe in der Zielanwendung.
- Erwartete Ausgabe
- Vorschauwert, Maß- oder Formatübersicht und kopier- beziehungsweise ladbares Ergebnis. Zwei Farben anhand von WCAG-Kontrast und Textschwellen vergleichen.
Überschriftenhierarchie-Prüfung
- Vorbereitung
- Sicheres Beispiel laden oder eigene Daten eingeben.
- Durchführung
- Lokal ausführen und Fehler, Warnungen und Kennzahlen prüfen.
- Abnahmekontrolle
- Ausgabe im Zielsystem und mit Grenzfällen validieren.
- Erwartete Ausgabe
- bearbeiteter Text, Änderungsübersicht und messbare Sprach- oder Strukturindikatoren. Sprünge, Duplikate und leere Markdown-Überschriften finden.
Für ARIA-Namensinventar gilt folgende Grenze: Ein statisches HTML-Inventar sieht CSS-verdeckten Text, Shadow DOM, Laufzeitzustände oder Screenreader-Verhalten nicht vollständig und ist kein WCAG-Nachweis. Ist diese Bedingung nicht erfüllt, darf die Ausgabe nicht an den nächsten Arbeitsschritt übergeben werden.
Dokumentieren Sie für „Barrierefreies HTML: Sprache, Überschriften, Formulare und Namen“ Werkzeug, Einstellung, Browserversion und den Abnahme- oder Ablehnungsgrund für „Formularprüfung vor Release“ – nicht den sensiblen Inhalt. So bleibt die Prüfung ohne Echtdaten wiederholbar.