Web-Zugänglichkeit: Schlüsselmerkmale im Vergleich
Die Barrierefreiheit im Web wird durch vier messbare Merkmale definiert — wahrnehmbar, bedienbar, verständlich und robust —, die gemäß den 13 Kriterien der Stufen A und AA der WCAG 2.2 artikuliert sind, welche von der Norm EN 301 549 in Europa gefordert werden. Diese vier Merkmale dienen als Bewertungskriterien: Jedes Widget, Tool oder Framework wird danach beurteilt, wie viele davon es erfüllt und mit welcher Solidität.
Die wichtigsten Erkenntnisse
- Die vier WCAG-Merkmale (wahrnehmbar, bedienbar, verständlich, robust) sind der Bewertungsrahmen, kein Slogan: Jedes gruppiert nachprüfbare Kriterien mit dokumentierten Techniken.
- Stufe AA ist das praktische Ziel für die meisten Projekte: Sie umfasst Kontrast, Tastatur, Formularbeschriftungen, Struktur und Fehlermeldungen und ist die Schwelle, die sich auf die europäische Gesetzgebung bezieht.
- Kein automatisches Werkzeug erkennt mehr als einen Bruchteil echter Probleme; manuelle Tests mit Tastatur und Screenreader bleiben unersetzlich.
- Die Auswahl eines “barrierefreien” Widgets oder Frameworks erfordert die Überprüfung seines Verhaltens mit der Tastatur, seines Fokusmanagements und seiner ARIA-Semantik, nicht nur seines Marketings.
- Compliance ist ein fortlaufender Prozess, der mit dem Produktlebenszyklus verbunden ist, kein einmaliges Audit, das archiviert wird.
Was “Merkmale der Webbarrierefreiheit” wirklich bedeuten
Der Begriff “Merkmale” wird in zwei Formen verwendet, die man trennen sollte. Die erste ist normativ: Die WCAG organisieren ihre Erfolgskriterien in vier Prinzipien oder Merkmalen — wahrnehmbar, bedienbar, verständlich und robust —, bekannt als POUR (nach den englischen Initialen).
Die zweite ist praktisch: Wenn ein Entwickler sagt, dass eine Komponente “gute Barrierefreiheitsmerkmale” hat, bezieht er sich normalerweise auf eine Reihe konkreter Verhaltensweisen (Tastaturnavigation, korrekte ARIA-Rollen, ausreichender Kontrast, Alternativtext). Beide Lesarten sind notwendig: Die erste gibt den Bewertungsrahmen vor, die zweite die implementierbaren Details.
Die WCAG 2.2, veröffentlicht vom W3C im Jahr 2023, behalten die vier Prinzipien bei und fügen Kriterien wie die Mindestgröße von Zielbereichen (2.5.8) und die Konsistenz von Hilfe (3.2.6) hinzu. Stufe A gruppiert die Mindestkriterien; AA fügt die für die meisten Websites relevantesten hinzu; AAA ist aspirational und selten in ihrer Gesamtheit gefordert. Für eine XHTML/CSS-Seite, die auf Spanien oder Lateinamerika ausgerichtet ist, ist AA das realistische Ziel, da dies die Stufe ist, auf die sich die europäische harmonisierte Norm EN 301 549 und damit die Richtlinie (EU) 2016/2102 über die Barrierefreiheit von Websites des öffentlichen Sektors bezieht.
Die vier WCAG-Merkmale im Einzelnen
Wahrnehmbar
Das Merkmal “wahrnehmbar” verlangt, dass Informationen in Formen präsentiert werden, die der Nutzer wahrnehmen kann, unabhängig von seinen Sinnen. In der Praxis bedeutet dies Textalternativen für nicht-textuelle Inhalte (1.1.1), Untertitel und Transkripte für Multimedia (1.2.x), eine semantische Struktur, die nicht nur von Position oder Farbe abhängt (1.3.1), ein Mindestkontrast von 4,5:1 für normalen Text und 3:1 für großen Text (1.4.3) sowie Inhalte, die beim Vergrößern auf 200 % ohne horizontales Scrollen lesbar bleiben (1.4.10). Ein häufiger Fehler auf alten XHTML-Seiten ist die Verwendung von Layout-Tabellen oder Text-in-Bildern: Beides bricht die Wahrnehmbarkeit, da die Lesereihenfolge und die Skalierbarkeit verloren gehen.
Bedienbar
Das Merkmal “bedienbar” garantiert, dass alle Komponenten der Benutzeroberfläche mit der Tastatur und mit assistiven Technologien funktionieren. Die Schlüsselkriterien sind vollständige Tastaturbedienbarkeit (2.1.1), das Fehlen von Fokusfallen (2.1.2), anpassbare Zeitlimits (2.2.1), Mechanismen zum Pausieren bewegter Inhalte (2.2.2), Navigation mit Sprunglinks und beschreibenden Seitentiteln (2.4.1, 2.4.2), eine logische Fokusreihenfolge (2.4.3) und eine ausreichende Zielgröße (2.5.8). Hier scheitern die meisten Dropdown-Menüs, Modale und Karussells: Sie fangen den Fokus ein und geben ihn nicht zurück oder hängen von Mausereignissen (onmouseover) ohne Tastaturäquivalent ab.
Verwandte: — Widget für den kostenlosen Zugang mit Plan, damit Sie noch heute dort arbeiten können.
Verständlich
Das Merkmal “verständlich” befasst sich damit, dass die Inhalte und die Funktionsweise der Benutzeroberfläche begreifbar sind. Dazu gehören die mit dem Attribut lang erklärte Sprache der Seite (3.1.1), Beschriftungen und Eingabehilfen in Formularen (3.3.2), die Identifizierung und Beschreibung von Fehlern (3.3.1, 3.3.3), eine konsistente Navigation zwischen den Seiten (3.2.3) und in WCAG 2.2 die Konsistenz von Hilfe (3.2.6). Ein Formular, das ein Feld rot markiert, aber nicht erklärt, was fehlgeschlagen ist, verstößt gegen dieses Merkmal, auch wenn es für jemanden ohne Behinderung visuell klar ist.
Robust
Das Merkmal “robust” verlangt, dass die Inhalte mit einer Vielzahl von User-Agents funktionieren, einschließlich aktueller und zukünftiger. Das zentrale Kriterium ist die korrekte Syntaxanalyse (4.1.1, in WCAG 2.2 veraltet, aber in XHTML relevant) sowie Name, Rolle und Wert für Benutzeroberflächenkomponenten (4.1.2). In der Praxis bedeutet dies, gültiges HTML zu schreiben, native Elemente zu verwenden, wann immer sie existieren, und ARIA nur dann einzusetzen, wenn es keine Alternative gibt, gemäß der ersten ARIA-Regel: Verwenden Sie kein ARIA, wenn ein natives HTML-Element die Aufgabe bereits erfüllt.
Vergleichstabelle: Bewertung von Tools und Widgets anhand der vier Merkmale
| Merkmal | Was bei einem Tool oder Widget zu prüfen ist | Warnsignal |
|---|---|---|
| Wahrnehmbar | Erzeugt Textalternativen, respektiert Kontraste, hängt nicht von Farben ab | Validiert nur Bilder, ignoriert Struktur und Kontrast |
| Bedienbar | Tastaturnavigation, Fokusmanagement, keine Fallen | Erfordert Maus oder schließt nicht mit Escape |
| Verständlich | Beschriftungen, Fehlermeldungen, erklärte Sprache | Markiert Fehler ohne erklärenden Text |
| Robust | Gültiges HTML, korrekte ARIA-Rollen, funktioniert in mehreren Browsern | Verwendet div mit onclick anstelle von button |
Diese Tabelle dient als Kriterienliste für die Entscheidung zwischen Optionen. Ein Tool, das nur die Spalte “wahrnehmbar” abdeckt, ist als erster Filter nützlich, aber nicht als Zertifizierung.
Einen Blick wert: — Zugriffsmöglichkeit: Kombinierte Automatisierung mit menschlicher Revision.
Tools und ihre Beziehung zu den Merkmalen
Automatische Bewertungs-Tools — wie axe DevTools, WAVE oder Lighthouse — erkennen vor allem Probleme der Merkmale “wahrnehmbar” und “robust”: fehlender Alternativtext, unzureichender Kontrast, falsch formatierte ARIA-Attribute, Überschriftenhierarchie. Ihre Abdeckung ist systembedingt nur teilweise: Sie können nicht beurteilen, ob ein Alternativtext beschreibend ist, ob die Fokusreihenfolge sinnvoll ist oder ob eine Fehlermeldung verständlich ist. Die Deque-Dokumentation zu axe und der WebAIM-Leitfaden zur automatischen Bewertung stimmen darin überein, dass kein Tool die menschliche Überprüfung ersetzt.
Manuelle Tests decken ab, was die Werkzeuge nicht sehen. Ein minimaler Vorgang umfasst: Navigieren auf der gesamten Seite nur mit Tab und Umschalt+Tab, Verifizieren, dass der Fokus immer sichtbar ist, Testen mit einem Screenreader (NVDA oder VoiceOver), Zoomen auf 200 % und Verifizieren, dass sich nichts überschneidet, sowie Deaktivieren von CSS, um zu bestätigen, dass die Reihenfolge der Inhalte sinnvoll ist. Dieser letzte Schritt offenbart Probleme des Merkmals “verständlich”, auf die kein Tool hinweist.
Auswahl je nach Projekttyp
Eine institutionelle Seite oder eine Seite des öffentlichen Sektors in Spanien sollte auf AA abzielen und die Konformität dokumentieren, da dies gesetzlich vorgeschrieben ist. Ein persönlicher Blog kann die Priorität auf “wahrnehmbar” und “bedienbar” legen, was die meisten realen Barrieren löst.
Eine komplexe Webanwendung mit interaktiven Komponenten muss in “robust” und “bedienbar” investieren, da benutzerdefinierte Widgets die Hauptquelle für Fehler sind. Die Entscheidung ist nicht “wie viele Merkmale erfülle ich”, sondern “welche Merkmale sind kritisch für meine Nutzer und meine gesetzliche Verpflichtung”.
Bei Frameworks und Komponentenbibliotheken umfasst die praktische Bewertung das Testen der Komponente mit einer Tastatur, bevor sie übernommen wird. Ein benutzerdefiniertes “Select”, das nicht auf Pfeiltasten reagiert, ein Modal, das den Fokus nicht korrekt einfängt, oder ein Tooltip, der nur bei Hover erscheint, sind Signale dafür, dass die Bibliothek das Erscheinungsbild über die Bedienbarkeit stellt. Die Dokumentation des W3C ARIA Authoring Practices Guide beschreibt die erwarteten Muster für jedes Widget und bietet die Grundlage für den Vergleich.
Häufige Fehler bei der Interpretation der Merkmale
Der erste Fehler besteht darin, die vier Merkmale als binäre Checkliste zu behandeln. Die Konformität ist kumulativ und kontextabhängig: Eine Seite kann 40 Kriterien erfüllen und an einem einzigen scheitern, das einen Nutzer komplett blockiert.
Verwandte: — Die erfordert Erfahrung und Zugang.
Der zweite Fehler ist das Vertrauen in “Overlays” oder Barrierefreiheits-Widgets, die versprechen, die Seite mit einem Skript zu reparieren; diese Produkte korrigieren nicht das zugrunde liegende HTML und wurden von der Community und Berichten von Behindertenorganisationen kritisiert. Der dritte Fehler ist, nur einmal zu auditieren: Inhalte ändern sich, Komponenten werden aktualisiert und die Konformität verschlechtert sich. Barrierefreiheit ist ein in den Entwicklungszyklus integrierter Prozess mit Tests bei jeder Auslieferung.
Häufig gestellte Fragen
Was sind die vier Merkmale der Webbarrierefreiheit gemäß WCAG?
Die WCAG gliedern ihre Kriterien in vier Prinzipien: wahrnehmbar, bedienbar, verständlich und robust, bekannt als POUR. Jedes Prinzip gruppiert nachprüfbare Erfolgskriterien mit den Stufen A, AA und AAA. Diese Struktur wird in den WCAG 2.2 beibehalten und ist die Grundlage für die Bewertung jeder Website oder Komponente.
Welche WCAG-Konformitätsstufe sollte meine Website erfüllen?
Für die meisten Websites ist die Stufe AA das praktische Ziel und diejenige, auf die sich die europäische Gesetzgebung über die Norm EN 301 549 bezieht. Stufe A deckt das Minimum ab und AAA ist in seiner Gesamtheit schwer zu erreichen. Wenn Ihre Website zum öffentlichen Sektor in der EU gehört, ist AA zwingend erforderlich.
Reichen automatische Tools aus, um die Barrierefreiheitsmerkmale zu erfüllen?
Nein. Automatische Tools erkennen einen Teil der Probleme, vor allem Kontraste, fehlende Alternativtexte und falsch formatierte ARIA-Attribute, aber sie können nicht bewerten, ob ein Alternativtext angemessen ist oder ob die Fokusreihenfolge sinnvoll ist. Die manuelle Überprüfung mit Tastatur und Screenreader ist für eine echte Konformität unerlässlich.
Was ist der Unterschied zwischen Barrierefreiheit und Usability?
Barrierefreiheit stellt sicher, dass Menschen mit Behinderungen Inhalte wahrnehmen, bedienen, verstehen und nutzen können; Usability zielt darauf ab, sicherzustellen, dass die Erfahrung für jeden Nutzer effizient und zufriedenstellend ist. Sie überschneiden sich: Eine barrierefreie Seite ist in der Regel benutzerfreundlicher, aber eine benutzerfreundliche Seite ist nicht notwendigerweise barrierefrei.
Reparieren Barrierefreiheits-Widgets oder Overlays meine Website automatisch?
Sie korrigieren weder das zugrunde liegende HTML noch Probleme mit der Struktur, dem Fokus oder der Semantik. Die Barrierefreiheits-Community und verschiedene Berichte haben sie infrage gestellt, da sie ein falsches Gefühl von Konformität vermitteln können. Die Lösung besteht darin, den Code und die Komponenten zu korrigieren, nicht darin, ein Skript darüberzulegen.
Wie beginne ich mit der Verbesserung der Barrierefreiheit einer bestehenden XHTML/CSS-Seite?
Beginnen Sie mit dem, was die größte Wirkung hat: gültiges und semantisches HTML, Alternativtexte für Bilder, ausreichender Kontrast, vollständige Tastaturnavigation und Beschriftungen in Formularen. Auditieren Sie anschließend mit einem automatischen Tool und ergänzen Sie dies durch manuelle Tests. Dokumentieren Sie die abgedeckten Kriterien und wiederholen Sie den Prozess bei jeder relevanten Änderung.
Häufig gestellte Fragen
Was sind die vier Merkmale der Web-Barrierefreiheit gemäß den WCAG?
Die WCAG organisiert ihre Kriterien in vier Prinzipien: wahrnehmbar, bedienbar, verständlich und robust, bekannt als POUR. Jedes Prinzip gruppiert überprüfbare Erfolgskriterien mit den Stufen A, AA und AAA. Diese Struktur wird in WCAG 2.2 beibehalten und ist die Grundlage für die Bewertung jeder Website oder Komponente.
Welche WCAG-Konformitätsstufe sollte meine Website erfüllen?
Für die meisten Websites ist Stufe AA das praktische Ziel und diejenige, auf die die europäische Gesetzgebung über die Norm EN 301 549 verweist. Stufe A deckt das Minimum ab und AAA ist in seiner Gesamtheit schwer zu erreichen. Wenn Ihre Website im öffentlichen Sektor der EU angesiedelt ist, ist AA verpflichtend.
Reichen automatisierte Tools aus, um die Barrierefreiheitsmerkmale zu erfüllen?
Nein. Automatisierte Tools erkennen einen Teil der Probleme, vor allem bei Kontrast, Alternativtext und fehlerhaftem ARIA, aber sie können nicht bewerten, ob ein Alternativtext angemessen ist oder ob die Fokusreihenfolge sinnvoll ist. Die manuelle Überprüfung mit Tastatur und Screenreader ist für eine echte Konformität unerlässlich.
Was ist der Unterschied zwischen Barrierefreiheit und Benutzerfreundlichkeit?
Barrierefreiheit stellt sicher, dass Menschen mit Behinderungen Inhalte wahrnehmen, bedienen, verstehen und nutzen können; Benutzerfreundlichkeit zielt darauf ab, dass die Erfahrung für jeden Nutzer effizient und zufriedenstellend ist. Sie überschneiden sich: Eine barrierefreie Website ist in der Regel benutzerfreundlicher, aber eine benutzerfreundliche Website ist nicht unbedingt barrierefrei.
Beheben Barrierefreiheits-Widgets oder -Overlays meine Website automatisch?
Sie korrigieren weder das zugrunde liegende HTML noch Probleme mit Struktur, Fokus oder Semantik. Die Barrierefreiheits-Community und verschiedene Berichte haben sie infrage gestellt, weil sie ein falsches Gefühl der Konformität vermitteln können. Die Lösung besteht darin, den Code und die Komponenten zu korrigieren, nicht darin, ein Skript darüberzulegen.
Wie beginne ich, die Barrierefreiheit einer bestehenden XHTML/CSS-Website zu verbessern?
Beginnen Sie mit dem, was die größte Wirkung hat: gültiges und semantisches HTML, Alternativtext bei Bildern, ausreichender Kontrast, vollständige Tastaturnavigation und Beschriftungen in Formularen. Danach prüfen Sie mit einem automatisierten Tool und ergänzen dies durch manuelle Tests. Dokumentieren Sie die abgedeckten Kriterien und wiederholen Sie den Prozess bei jeder relevanten Änderung.
Möchten Sie die WCAG ohne Code ausfüllen?
Superposición de IA, das die WCAG seit 48 Stunden unterstützt