Kostenloses Tool: Barrierefreiheit
WCAG-2.2-Check für Ihre Website
Sehen Sie, wo Ihre Website bei jedem der 55 Erfolgskriterien von WCAG 2.2 Stufe A und AA steht. Jedes Kriterium erhält einen von vier Status, sodass Sie erkennen, was automatisierte Tests abgedeckt haben und was noch ein Mensch prüfen muss.
Kostenlos. Testet bis zu fünf wichtige Seiten in etwa einer Minute.
Was dieses Tool prüft
Jedes Kriterium der Stufen A und AA
Alle 55 Kriterien, 31 auf Stufe A und 24 auf Stufe AA, in der Reihenfolge von WCAG mit Nummer und Name. 4.1.1 Parsing fehlt, weil WCAG 2.2 es als überholt kennzeichnet.
Automatisierte Ergebnisse, den Kriterien zugeordnet
Die Regeln von axe-core laufen auf der eingegebenen Seite und bis zu vier weiteren wichtigen Seiten, und jedes Ergebnis wird den Erfolgskriterien zugeordnet, die diese Regel testet. Ein Kriterium gilt als nicht bestanden, sobald eine seiner Regeln auf einer getesteten Seite fehlschlägt.
Belege aus dem Tastaturtest
Ein Test mit 40 Tab-Anschlägen auf der ersten Seite liefert Daten für 2.1.2 No Keyboard Trap und, als Heuristik zur Prüfung angezeigt, für 2.4.7 Focus Visible.
Unentschiedene Ergebnisse getrennt
Kann eine Regel zu keinem Urteil kommen, etwa bei Text über einem Bild, zeigen ihre Kriterien „Zu prüfen“ statt bestanden oder nicht bestanden.
Sichtbare Lücken statt eines Scores
Kriterien, die keine automatisierte Regel abdeckt, werden als „Manuelle Prüfung“ markiert. Nichts wird zu einem Prozentwert gemittelt, der verbergen würde, was nicht getestet wurde.
Was es nicht prüfen kann
- Kriterien entscheiden, die menschliches Urteil erfordern, etwa 1.4.10 Reflow, 1.4.11 Non-text Contrast, die Kriterien unter 1.2 zu Untertiteln und Audiodeskription sowie 3.3.1 bis 3.3.4 zu Formularfehlern.
- Aus „Keine automatisierten Fehler“ ein Bestanden machen. Eine Regel, die gelaufen ist und bestanden hat, deckt nur ab, was diese Regel testet.
- Eine Konformitätserklärung, eine Erklärung zur Barrierefreiheit oder ein VPAT erstellen. Über Konformität urteilen Menschen, anhand vollständiger Seiten und vollständiger Prozesse.
- Stufe AAA testen oder Seiten über die fünf des Scans hinaus.
- Die Schritte hinter einem Login oder in einem Checkout erreichen, wo Kriterien wie 3.3.7 Redundant Entry und 3.3.8 Accessible Authentication meist greifen.
Warum das wichtig ist
WCAG ist in Erfolgskriterien formuliert, und so beschreiben auch Auditoren, Beschaffungsteams und Erklärungen zur Barrierefreiheit eine Website. Eine Liste fehlgeschlagener Regeln sagt Ihnen, was zu beheben ist. Eine Ansicht nach Kriterien sagt Ihnen, was Sie über die Website bereits sagen können und was noch nicht.
Automatisierte Tools berühren weniger als die Hälfte der Kriterien der Stufen A und AA: axe-core ordnet seine Regeln etwa 25 der 55 zu. Für den Rest gibt es keinen zuverlässigen automatisierten Test. Software kann nicht erkennen, ob eine Fehlermeldung eine Korrektur vorschlägt (3.3.3) oder ob eine Seite bei 320 CSS-Pixeln Breite noch funktioniert (1.4.10). Wenn diese als manuelle Prüfungen aufgeführt werden, sehen Sie, wo noch getestet werden muss.
Selbst ein Kriterium ohne automatisierte Fehler kann nicht erfüllt sein. Die Regeln für 1.1.1 Non-text Content prüfen, ob ein Bild einen Alternativtext hat; sie können nicht erkennen, dass alt="IMG_2041.jpg" für jemanden, der das Foto nicht sehen kann, nutzlos ist.
So lesen Sie die Ergebnisse
- Nicht bestanden
- Mindestens eine automatisierte Regel, die zu diesem Kriterium gehört, ist auf einer getesteten Seite fehlgeschlagen. Das ist ein eindeutiges Problem; der Barrierefreiheits-Check zeigt die Elemente und Seiten dahinter.
- Zu prüfen
- Eine automatisierte Prüfung hat etwas markiert, das sie nicht entscheiden konnte, etwa den Kontrast von Text auf einem Farbverlauf. Ein Mensch muss sich das Element ansehen.
- Keine automatisierten Fehler
- Mindestens eine Regel von axe-core, die zu dem Kriterium gehört, ist gelaufen und hat bestanden. Das ist keine Konformität: Die Regeln decken nur einen Teil dessen ab, was das Kriterium verlangt.
- Nicht ausgelöst
- Für dieses Kriterium gibt es automatisierte Regeln, aber auf den getesteten Seiten gab es nichts, was sie prüfen konnten, zum Beispiel kein Video für die Untertitelregeln oder keine Formulare für die Label-Regeln. Testen Sie es von Hand, wenn Ihre Website solche Inhalte an anderer Stelle hat.
- Manuelle Prüfung
- Keine automatisierte Regel deckt dieses Kriterium ab, daher sagt der Scan weder in die eine noch in die andere Richtung etwas darüber. Testen Sie es von Hand.
- Stufe A und Stufe AA
- Stufe A ist das Minimum. Richtlinien, die sich auf WCAG beziehen, nennen meist Stufe AA, die jedes Kriterium der Stufe A einschließt.
So beheben Sie die häufigsten Probleme
4.1.2 Name, Role, Value nicht bestanden
Eigene Bedienelemente aus div- oder span-Elementen (Menüs, Tabs, Akkordeons, Umschalter) teilen assistiven Technologien nicht mit, was sie sind oder ob sie geöffnet sind. Verwenden Sie wo immer möglich ein natives <button>, geben Sie ihm einen Namen und setzen Sie aria-expanded oder aria-pressed, damit sein Zustand angesagt wird.
1.3.1 Info and Relationships nicht bestanden
Die Struktur muss im Markup stehen, nicht nur in der Gestaltung. Verwenden Sie echte h2- und h3-Elemente statt fetter Absätze, ul oder ol für Listen, th mit scope für Tabellenköpfe und Labels oder fieldset mit legend für Gruppen von Formularfeldern.
3.1.1 Language of Page nicht bestanden
Ergänzen Sie ein lang-Attribut am html-Element, zum Beispiel <html lang="en">. WordPress-Themes geben es normalerweise mit language_attributes() aus; in einem Shopify-Theme verwenden Sie <html lang="{{ request.locale.iso_code }}"> in layout/theme.liquid.
2.5.8 Target Size (Minimum) nicht bestanden
Kleine Icons und eng beieinanderliegende Links sind mit dem Finger schwer zu treffen. Machen Sie jedes Ziel mindestens 24 × 24 CSS-Pixel groß, oder lassen Sie so viel Abstand zwischen kleinen Zielen, dass ein Kreis von 24 px um die Mitte jedes Ziels kein anderes Ziel überlappt. Padding vergrößert das Ziel, ohne das Icon zu verändern.
Die manuellen Prüfungen abarbeiten
Beginnen Sie mit den schnellen. Für 1.4.10 Reflow zoomen Sie ein 1280 px breites Browserfenster auf 400 % und prüfen, dass nichts seitliches Scrollen erfordert. Für 2.4.7 und 2.4.11 gehen Sie die Seite mit der Tabulatortaste durch und prüfen, dass der Fokus immer sichtbar ist und nie hinter einem fixierten Header oder einem Cookie-Banner verschwindet. Für 3.3.1 senden Sie ein Formular mit Fehlern ab und sehen, ob die Fehler klar in Textform beschrieben werden.
Fragen zu diesem Tool
Was hat sich in WCAG 2.2 auf den Stufen A und AA geändert?
Sechs Kriterien kamen hinzu: 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry und 3.3.8 Accessible Authentication (Minimum). WCAG 2.2 ergänzt außerdem drei Kriterien der Stufe AAA und streicht 4.1.1 Parsing.
Warum ist 4.1.1 Parsing nicht aufgeführt?
WCAG 2.2 kennzeichnet 4.1.1 Parsing als überholt und streicht es, weil Browser und assistive Technologien nicht mehr von den Markup-Fehlern abhängen, die es abdeckte. Das W3C weist darauf hin, dass es für WCAG 2.0 und 2.1 bei HTML-Inhalten inzwischen als immer erfüllt gilt.
Deckt die Erfüllung von WCAG 2.2 auch WCAG 2.1 ab?
Ja. WCAG 2.2 ist abwärtskompatibel: Inhalte, die 2.2 entsprechen, entsprechen auch 2.1 und 2.0. Ein Test nach 2.2 deckt daher die älteren Versionen ab, auf die sich viele Richtlinien noch beziehen.
Kann ich damit eine Erklärung zur Barrierefreiheit oder ein VPAT erstellen?
Es ist ein Ausgangspunkt, kein Konformitätsbericht. Eine Erklärung oder ein VPAT erfordert, dass jedes Kriterium bewertet wird, die meisten davon durch einen Menschen; die Listen „Manuelle Prüfung“ und „Zu prüfen“ zeigen, bei welchen das noch aussteht.
Warum steht bei so vielen Kriterien „Manuelle Prüfung“?
Weil es für sie keine automatisierte Regel gibt. Fragen wie die, ob sich ein Zeitlimit verlängern lässt, ob Hilfe auf jeder Seite an derselben Stelle erscheint oder ob ein Login einen Gedächtnistest verlangt, hängen davon ab, wie Menschen die Website nutzen, nicht von Markup, das eine Regel auslesen kann.
Quellen
- W3C: Web Content Accessibility Guidelines (WCAG) 2.2(öffnet in einem neuen Tab)
- W3C WAI: What’s New in WCAG 2.2 (Neuerungen in WCAG 2.2)(öffnet in einem neuen Tab)
- W3C WAI: Understanding WCAG 2.2(öffnet in einem neuen Tab)
- W3C WAI: How to Meet WCAG (Kurzreferenz)(öffnet in einem neuen Tab)
- W3C WAI: Understanding 4.1.1 Parsing (überholt und gestrichen)(öffnet in einem neuen Tab)
- W3C: Website Accessibility Conformance Evaluation Methodology (WCAG-EM)(öffnet in einem neuen Tab)
- Deque: Regelbeschreibungen von axe-core(öffnet in einem neuen Tab)
Verwandte Tools
- BarrierefreiheitBarrierefreiheits-CheckTesten Sie Ihre Website im echten Browser nach WCAG 2.2 A und AA und sehen Sie jede Barriere mit Element, Seite und ihrer Bedeutung.Tool öffnen
- TechnikKostenloser Website-CheckEin Scan für Barrierefreiheit, SEO, Ladezeit, Conversion, Sicherheit und E-Mail-Setup, mit den wichtigsten Befunden in jedem Bereich.Tool öffnen
Sie brauchen die Lösungen, nicht nur die Befunde?
Der Barrierefreiheits-Report ($174, einmalig) baut auf dem vollständigen kostenlosen Scan auf und ergänzt weitere Seiten, die nötige Änderung für jeden Befund, ein PDF und Nachtests, mit denen Sie Ihre Korrekturen überprüfen.