Es hat lange auf sich warten lassen, aber die Version 2.2 der Web Content Accessibility Guidelines (WCAG) ist fast da! Nein, dieses Mal meinen wir es wirklich ernst. Am 20. Juli, WCAG 2.2 umgezogen zum Vorgeschlagene W3C-Empfehlung Stufe. Eine vorgeschlagene Empfehlung bedeutet, dass das W3C sie akzeptiert hat, und die W3C-Mitglieder werden nun über die Veröffentlichung des Dokuments als W3C-Empfehlung. Die Abstimmung endet zwar am 19. August 2023, und man hofft, dass sie kurz danach veröffentlicht werden kann, aber es ist wichtig zu wissen, dass die Beiträge der W3C-Mitglieder während des Abstimmungsprozesses mehr Arbeit erfordern könnten. Geplant ist jedoch, dass wir bis Ende August tatsächlich eine neue Aktualisierung der WCAG haben werden.
Was sind die Änderungen?
WCAG 2.2 baut auf WCAG 2.1 auf, so wie WCAG 2.1 auf 2.0 aufbaute, und erweitert die Reihe der WCAG 2.x Richtlinien. Sie enthält alle Kriterien der WCAG 2.1, abzüglich 4.1.1 Parsing (mehr dazu später), sowie neun neue Kriterien. Davon sind zwei der Stufe A, vier der Stufe AA und drei der Stufe AAA Erfolgskriterien (SC).
Die meisten Organisationen streben an, die WCAG bis zur Stufe AA zu erfüllen, was bedeutet, dass sie sechs neue Kriterien in ihre Liste aufnehmen werden. Da es sich bei den neuen Erfolgskriterien um Ergänzungen zu den bestehenden Richtlinien handelt, bleiben die bestehende Abwärtskompatibilität und das gleiche Konformitätsmodell erhalten.
Ähnlich wie die unter 2.1 hinzugefügten Kriterien zielen diese darauf ab, Nutzern mit Sehbehinderungen, kognitiven und Lernbehinderungen sowie motorischen Behinderungen zu helfen, mit Vorteilen für Nutzer, die Behinderungen auf mobilen Geräten haben.
Neue Erfolgskriterien
Im Folgenden werden die einzelnen neuen SC, ihre Bezeichnungen und Stufen sowie ihre Auswirkungen auf die Endnutzer näher erläutert.
Leitlinie 2.4 Schiffbar
Unter der Leitlinie 2.4 "Navigable" finden sich drei der neuen SC. Hier finden wir 2.4.11 Focus Not Obscured (Minimum), ein Kriterium der Stufe AA. Für Menschen, die auf eine Tastatur oder ein tastaturähnliches Gerät angewiesen sind, ist es wichtig, den aktuellen Fokuspunkt zu kennen. Dieses neue Kriterium besagt, dass das fokussierte Element nicht verdeckt werden darf, wenn sich andere Inhalte mit dem fokussierten Element überschneiden.
Typische Arten von Inhalten, die fokussierte Elemente überlagern und dadurch ein Problem mit der Zugänglichkeit verursachen können, sind klebrige Fußzeilen oder Kopfzeilen. Wenn ein Benutzer mit der Tabulatortaste durch die Seite blättert, verdeckt z. B. eine Fußzeile Teile des fokussierten Elements.
2.4.12 Focus Not Obscured (Enhanced) ist die Stufe AAA-Version der vorherigen Version und besagt einfach, dass das fokussierte Element beim Abwärtsblättern auf der Seite nicht von anderen Inhalten überdeckt wird.
Der andere SC, der unter der Leitlinie "Navigable" angesiedelt ist, ist 2.4.13 "Focus Appearance". Über diesen Punkt wurde viel geredet, und er wurde während der Entwurfsphase einige Male geändert, aber die Arbeitsgruppe ist der Meinung, dass sie jetzt die richtige Balance gefunden hat.
Die Debatte und in der Tat die Unstimmigkeit darüber, wie der sichtbare Fokus für Tastaturfokusindikatoren als zugänglich oder nicht zugänglich bestimmt wird, dauert schon so lange an, wie ich in der Branche bin (10 Jahre). Obwohl es sich um eine Stufe AAA handelt, beendet diese neue SC endlich jede Debatte, und ehrlich gesagt, ist sie eine sehr willkommene Ergänzung!
Bei diesem Erfolgskriterium wird vor allem das Farbkontrastverhältnis berücksichtigt. Wenn Sie den Fokus anzeigen, müssen Sie mindestens ein Kontrastverhältnis von 3:1 und einen Mindestumfang von 2 CSS-Pixeln haben. So wird sichergestellt, dass Tastaturbenutzer leicht erkennen können, welches interaktive Element den Fokus hat.
Leitlinie 2.5 Eingabemodalitäten
Die Eingabemodalitäten wurden um zwei neue SC erweitert: Ziehende Bewegungen und eine Stufe AA-Version der Zielgröße.
2.5.7 Ziehende Bewegungen sind ein Kriterium der Stufe AA, das sicherstellt, dass ziehende Bewegungen mit einem einzigen Zeiger ohne Ziehen ausgeführt werden können, es sei denn, das Ziehen ist unerlässlich. Es ähnelt den Zeigergesten, bei denen von richtungsbezogenen pfadbasierten und Mehrpunktgesten die Rede ist. Der Unterschied liegt hier in der Definition, was eine Ziehbewegung ist. Beim Ziehen ist nur der Anfangs- und Endpunkt der Bewegung wichtig, nicht der Pfad. Das Konzept ist jedoch dasselbe, und das ist eine gute Garantie dafür, dass es Alternativen für Benutzer gibt, die nicht in der Lage sind, überhaupt oder genau zu ziehen.
2.5.8 Zielgröße (Minimum) ist ein weiteres Kriterium der Stufe AA. Hier soll sichergestellt werden, dass Ziele wie Schaltflächen oder verknüpfte Symbole leicht aktiviert werden können, ohne versehentlich ein benachbartes Ziel zu aktivieren. Eine ausreichende Größe und/oder ein ausreichender Abstand zwischen den Zielen verringert die Wahrscheinlichkeit, dass versehentlich das falsche Bedienelement aktiviert wird. Die Zielgröße muss mindestens 24 x 24 CSS-Pixel betragen. Dazu kann auch der Leerraum um das Ziel herum gehören.
Leitlinie 3.2 Vorhersehbar
Ein SC wird der Vorhersagbaren Leitlinie in 3.2.6 Konsistente Hilfe hinzugefügt, der besagt, dass, wenn Hilfeoptionen verfügbar sind, z. B. Chat, Kontaktdetails für eine Person oder eine Selbsthilfeoption für eine Reihe von Seiten, der Zugang zu mindestens einer Option in der gleichen relativen Reihenfolge auf jeder Seite dieser Reihe enthalten ist.
Das heißt, wenn Sie eine Chat-Option haben, sollte diese auf jeder Seite leicht zu finden sein, z. B. in der rechten unteren Ecke, damit die Hilfeoptionen leicht zu finden sind. Dies ist eine Anforderung der Stufe A.
Leitlinie 3.3 Unterstützung bei der Eingabe
Es gibt einige großartige Ergänzungen zur Eingabehilfe. Hier liegt ein wesentlicher Schwerpunkt auf der Berücksichtigung der kognitiven Belastung beim Ausfüllen von Formularen und der Authentifizierung.
Beginnen wir mit 3.3.7 Redundante Eingabe, die als Kriterium der Stufe A vorgesehen ist. Beim Ausfüllen eines Formulars, in dem Daten abgefragt werden, die bereits zuvor in das Formular eingegeben wurden, müssen die wiederholten Daten durch automatisches Ausfüllen verfügbar sein oder ausgewählt werden können. Dies reduziert den kognitiven Aufwand, wenn Informationen während eines Prozesses mehr als einmal abgefragt werden. Es verringert auch die Notwendigkeit, sich an Informationen zu erinnern, die in einem früheren Schritt eingegeben wurden. Ausnahmen gibt es bei der Bestätigung von Passwörtern und abgebrochenen Formularen.
3.3.8 Zugängliche Authentifizierung (Minimum), ein Kriterium der Stufe AA, besagt, dass ein kognitiver Test in einem Authentifizierungsverfahren nicht erforderlich sein sollte. Gute Nachrichten für die Biometrie! Keine Panik, Sie können immer noch die Eingabe von Benutzernamen (oder E-Mail) und Passwort als Authentifizierungsmethode verwenden, solange Browser und Passwort-Manager nicht blockiert sind und die Felder automatisch ausgefüllt werden können oder Sie das Kopieren und Einfügen erlauben, um die kognitive Belastung durch erneutes Eintippen zu verringern.
3.3.9 Zugängliche Authentifizierung (Erweitert) ist die Stufe AAA, die der obigen Mindestversion entspricht, jedoch ohne Ausnahmen für die Objekterkennung und vom Benutzer bereitgestellte Inhalte. Auch hier soll sichergestellt werden, dass es eine zugängliche, einfach zu bedienende und sichere Methode für die Anmeldung, den Zugriff auf Inhalte usw. gibt.
Was ist mit Parsing?
Zum ersten Mal in der WCAG 2-Reihe hat die Arbeitsgruppe einen SC als überflüssig eingestuft und 4.1.1 Parsing entfernt. Bei dieser Entscheidung wurden mehrere Faktoren berücksichtigt.
Die Arbeitsgruppe kam zu dem Schluss, dass alle tatsächlichen Probleme, die sich auf Benutzer mit Behinderungen auswirken und unter 4.1.1 erfasst werden, durch andere Erfolgskriterien wie 1.3.1 Info and Relationship oder 4.1.2 Name Role Value erfasst werden können/sollten. Die anderen Parsing-Probleme, die häufig auftreten, führen nicht mehr zu Zugänglichkeitsfehlern, wenn man bedenkt, wie die heutigen Browser und unterstützenden Technologien den Code darstellen.
Es ist erwähnenswert, dass Parsing unter das Robustheitsprinzip der WCAG fällt. Bei der Robustheit geht es darum, sicherzustellen, dass die Webinhalte mit verschiedenen Technologien und Hilfsmitteln kompatibel sind. Dies beinhaltet die Verwendung von Kodierungs- und Webentwicklungspraktiken, die Zugänglichkeitsfunktionen unterstützen und von einer Vielzahl von Benutzeragenten verwendet werden können.
Es gibt eine Reihe von Argumenten für dieses Thema, und es hat einige heftige Diskussionen ausgelöst (Wortspiel beabsichtigt). Hier ein paar meiner Gedanken zu diesem Thema:
- Das Scheitern von Parsing hält Organisationen davon ab, Konformität zu beanspruchen; aber wenn es keine Auswirkungen auf die reale Welt hat - ist das eine gute Verwendung von irgendjemandes Zeit?
- WCAG 2.2 soll rückwärtskompatibel bleiben, aber es gibt noch eine Menge Grauzonen, wie es mit WCAG 2.1 und 2.0 und veralteten Standards, die international von Gesetzen und Behörden verwendet werden, funktionieren würde. Dies ist nicht unlösbar, aber es bedarf noch einiger Überlegungen und Diskussionen. Die Arbeitsgruppe denkt bereits darüber nach, aber es ist eine Erwähnung wert, bis eine Lösung gefunden ist.
- Ich habe immer die Analogie verwendet, dass wir keine neue Technologie, sei sie nun unterstützend oder nicht, auf der Grundlage von unsauberem Code (oder Buchstabensuppe, wie ich es gerne nenne) entwickeln, also senken wir durch den Wegfall des Parsing den HTML-Standard insgesamt?
- Machen wir Annahmen darüber, wie viele AT-Nutzer ihre Browser und ihr AT auf dem neuesten Stand halten? Ist dies ein Beispiel dafür, dass wir uns zu sehr auf nordamerikanische oder europäische Statistiken zur AT-Nutzung konzentrieren?
Unterstützende Dokumente
Die Arbeitsgruppe arbeitet weiterhin an der Erstellung von Techniken, die ausreichende und fehlerhafte Beispiele für die WCAG 2 Richtlinienreihe dokumentieren, wobei der Schwerpunkt auf der Erstellung von Techniken für die neuen Kriterien in WCAG 2.2 liegt. Zusätzliche unterstützende Dokumente, einschließlich How to Meet WCAG 2.2 und Verstehen der WCAG 2.2sind jetzt zur Einsichtnahme verfügbar.
Zukünftige Versionen
Schließlich ist es unwahrscheinlich, dass es eine WCAG 2.3 geben wird; aber wie ich vor langer Zeit gelernt habe, sage niemals nie. Nach der Veröffentlichung von Version 2.2 wird erwartet, dass der Großteil der Bemühungen der Arbeitsgruppe in eine künftige Version der Zugänglichkeitsrichtlinien fließen wird, wie WCAG 3.0 oder Silver, wie es in einigen Kreisen immer noch genannt wird. 3.0 wird eine bedeutende Nachfolgerevision der WCAG-Richtlinien sein und wird nicht rückwärtskompatibel sein. Dies ist jedoch noch Jahre entfernt, so dass das Verständnis von 2.2 jetzt und in naher bis mittlerer Zukunft für alle eine hohe Priorität hat.
