Direkt zum Hauptinhalt

WCAG 2.2 · Level A · Robust · VeraltetBarrierefreiheit als Cloud-Service

4.1.1 Syntaxanalyse (veraltet)

In WCAG 2.2 entfernt. Korrektes HTML war Pflicht.

Auf einen Blick

Was bedeutet dieses Kriterium?

Kurz gesagt

In WCAG 2.2 entfernt. Korrektes HTML war Pflicht.

Aufwand

Einfach umzusetzen, schnell erledigt

Betrifft Rolle

Entwicklung

Konformitätsstufe

Level A · In WCAG 2.2 entfernt

EN 301 549

Abschnitt 9.4.1.1 · BITV 2.0 · BFSG

Verständlich erklärt

Was heißt 4.1.1 für die Praxis?

In WCAG 2.2 entfernt. Korrektes HTML war Pflicht.

Obwohl in 2.2 entfernt, bleibt valides HTML Best Practice. Browser korrigieren Fehler inzwischen zuverlässig.

Technisch formuliert: In WCAG 2.2 entfernt. Galt in WCAG 2.0/2.1: Elemente haben vollständige Tags, korrekte Verschachtelung, keine doppelten IDs.

Wer ist betroffen?

Ein Alltagsbeispiel

Nicht jeder Nutzer öffnet Ihre Seite im neuesten Chrome auf dem Desktop. Screenreader, Sprachsteuerungen, ältere Browser, Tablets oder Spezial-Hardware sollen die Seite alle gleich gut darstellen können. Dieses Kriterium stellt sicher, dass das funktioniert. Besonders betroffen sind: Nutzer assistiver Technologien, Blinde Menschen.

Die Lösung

So setzen Sie es richtig um

Obwohl in 2.2 entfernt, bleibt valides HTML Best Practice. Browser korrigieren Fehler inzwischen zuverlässig.

In WCAG 2.2 entfernt. Galt in WCAG 2.0/2.1: Elemente haben vollständige Tags, korrekte Verschachtelung, keine doppelten IDs.

Umsetzung

Schritt für Schritt

Konkrete Anleitung zur praktischen Umsetzung dieses Kriteriums.

  1. 1

    HTML validieren

    W3C HTML Validator nutzen — auch wenn nicht mehr WCAG-Pflicht, hilft es der Robustheit.

Typische Fehler

Das wird häufig falsch gemacht

Diese Fehler sehen wir in der Praxis besonders oft — und wie Sie sie vermeiden.

ARIA als Allheilmittel

ARIA wird oft eingesetzt, wo einfaches HTML ausreichen würde. Falsche ARIA ist schlimmer als keine ARIA.

Nur in einem Browser testen

Verschiedene Browser und Hilfsprogramme interpretieren Code unterschiedlich. Tests in mindestens 2 Browsern mit mindestens einem Screenreader sind Pflicht.

Selbst prüfen

So testen Sie dieses Kriterium

Mit diesen Methoden können Sie selbst prüfen, ob Ihre Webseite das Kriterium erfüllt.

Mit verschiedenen Browsern testen

Chrome, Firefox, Safari — alle sollten die Seite gleich interpretieren. Unterschiede weisen oft auf falsches HTML oder ARIA hin.

Screenreader-Kompatibilität prüfen

VoiceOver, NVDA und JAWS verhalten sich unterschiedlich. Testen Sie mit mindestens einem, idealerweise zwei.

HTML validieren

Der W3C Validator zeigt strukturelle Fehler im HTML. Valides HTML ist die Grundlage für robuste Barrierefreiheit.

Häufige Fragen

Fragen und Antworten

Ist dieses Kriterium wirklich Pflicht?
Ja. Level A ist die Grundlage jeder Barrierefreiheit. Ohne Level A ist eine Website für bestimmte Nutzergruppen komplett unzugänglich. BITV 2.0, EN 301 549 und BFSG verlangen mindestens Level AA — was Level A einschließt.
Wie kann ich prüfen, ob meine Seite dieses Kriterium erfüllt?
Nutzen Sie einen Test-Mix: automatisierte Tools wie Pa11y oder axe DevTools finden viele Probleme zuverlässig, aber nicht alle. Ergänzen Sie mit manuellen Tests — Tastaturnavigation, Screenreader-Test und eine visuelle Prüfung der relevanten Seitenbereiche.
Welche anderen Kriterien hängen damit zusammen?
Dieses Kriterium steht in engem Zusammenhang mit 4.1.2. Diese Kriterien sollten gemeinsam geprüft werden, weil sie sich gegenseitig ergänzen.

Verwandte Kriterien

Weiterführende Erfolgskriterien

Diese Kriterien stehen in engem Zusammenhang mit 4.1.1 und sollten gemeinsam betrachtet werden.