Die EN 301549 Version 4.1.1 steht vor der Veröffentlichung. Sie muss im Journal der EU veröffentlicht werden und ist dann automatisch rechtskräftig. Bis dahin gilt die Version 3.2.1 weiterhin. Dennoch ist es sinnvoll, sich bereits jetzt damit zu beschäftigen.
Kleiner Hinweis: Sie werden häufiger von der Version 4.1.1 lesen, das ist die aktuelle Version. Mit der Veröffentlichung wird die Nummer auf 4.1.1 springen (das ist Normierungs-Magie, muss man nicht verstehen).
Was ändert sich
Die größte Änderung ist, dass die WCAG 2.2-Anforderungen aufgenommen werden.
Dadurch kommen insbesondere sechs neue prüfbare WCAG-2.2-Erfolgskriterien auf Level A/AA hinzu. Gleichzeitig wird EN 301 549 an mehreren Stellen deutlich präziser – insbesondere bei Software, mobilen Apps und Dokumenten.
Neue Anforderungen der WCAG 2.2
In V3.2.1 basieren die Anforderungen für Webinhalte auf WCAG 2.1. V4.1.1 verweist dagegen auf WCAG 2.2. ETSI schreibt ausdrücklich, dass WCAG 2.2 die normative Referenz für die Webanforderungen ist.
Für eine Website, die bereits WCAG 2.1 AA erfüllt, bedeutet das praktisch vor allem diese sechs zusätzlichen Anforderungen:
- 2.4.11 Focus Not Obscured (Minimum) (Level AA)
- Der Tastaturfokus darf nicht vollständig von Sticky Headern, Dialogen, Cookie-Bannern etc. verdeckt werden.
- 2.5.7 Dragging Movements (Level AA)
- Drag-and-Drop muss grundsätzlich auch ohne Ziehen mit einer einzigen Zeigeraktion bedienbar sein.
- 2.5.8 Target Size (Minimum) (Level AA)
- Bedienelemente brauchen grundsätzlich mindestens 24 × 24 CSS-Pixel bzw. ausreichenden Abstand, mit Ausnahmen.
- 3.2.6 Consistent Help (Level A)
- Wiederkehrende Hilfeangebote müssen über Seiten hinweg konsistent positioniert sein.
- 3.3.7 Redundant Entry (Level A)
- Informationen sollen innerhalb eines Prozesses nicht unnötig erneut eingegeben werden müssen.
- 3.3.8 Accessible Authentication (Minimum) (Level AA)
- Authentifizierung darf grundsätzlich keine unnötigen kognitiven Tests erzwingen; z. B. sollten Passwortmanager und Copy/Paste funktionieren.
Diese sechs Kriterien sind der größte unmittelbar sichtbare Unterschied für Webteams, die heute bereits WCAG 2.1 AA testen.
Auch PDFs und andere Nicht-Web-Dokumente sind betroffen
V4.1.1 aktualisiert nicht nur Kapitel 9 (Web), sondern auch Kapitel 10 – Non-web documents
Kapitel 11 – Non-web software
Beide Bereiche werden an WCAG 2.2 angeglichen.
Das bedeutet beispielsweise für PDFs, Office-Dokumente und andere digitale Dokumente, dass die neuen WCAG-2.2-Anforderungen nicht einfach nur ein Web-Thema sind.
Besonders relevant: Software und Apps
Für Apps und Desktop-Software ist die Änderung sogar etwas größer als für klassische Websites.
V4.1.1 übernimmt viele Konzepte aus WCAG2ICT, also der Übertragung von WCAG-Anforderungen auf Nicht-Web-Software und Dokumente. Dadurch werden Anforderungen, die bisher für Non-Web-Software teilweise „Void“ oder anders interpretiert waren, konkreter.
Beispiele:
- Fenster bzw. Screens müssen sinnvoll bezeichnet sein.
- Gleichartige Funktionen müssen konsistent identifizierbar sein.
- Focus Not Obscured gilt auch für entsprechende Software-Oberflächen.
- Dragging Movements bekommt eine entsprechende Anforderung für Non-Web-Software.
- Weitere WCAG-2.2-Anforderungen werden auf Software übertragen.
Neue bzw. präzisierte Anforderungen an Assistenztechnologien
Ein weiterer wichtiger Bereich ist Interoperabilität mit Assistenztechnologien.
V4.1.1 enthält weiterhin Kapitel 11.5, präzisiert aber die Anforderungen an die Accessibility Services der Plattformen. Plattformsoftware muss dokumentierte Accessibility Services bereitstellen, über die Assistenztechnologien mit der Software interagieren können.
Die Norm wird damit stärker zu einem Thema der technischen Accessibility-Architektur, nicht nur des UI-Designs.
Nutzerpräferenzen werden anders gefasst
V4.1.1 arbeitet stärker mit dem Konzept „documented accessibility features“ bzw. dokumentierten Accessibility-Funktionen.
Das betrifft beispielsweise:
Die Anforderungen werden dadurch stärker daran geknüpft, welche Accessibility-Funktionen eine Plattform bzw. Software tatsächlich dokumentiert und bereitstellt, statt ausschließlich eine feste Liste von Einstellungen vorzugeben.
Echtzeitkommunikation wird überarbeitet
Ein weiterer großer Block betrifft Real-Time Communication.
Kapitel 6 behandelt unter anderem:
- Echtzeit-Sprachkommunikation
- Real-Time Text (RTT)
- Video
- Untertitel
- Gebärdensprachkommunikation
- Total Conversation
- Kommunikation mit Notruf-/Notfallfunktionen.
V4.1.1 enthält hierzu umfangreiche Anforderungen und Szenarien. Das ist insbesondere für Telekommunikation, Videokonferenzsysteme, Kommunikationsplattformen und Notrufsysteme relevant.
Fazit
Für aktuelle Projekte lohnt sich, bereits die Anforderungen der Version 4.1.1 zu berücksichtigen. Spätestens nächstses Jahr sollte man sich auch die Anforderungen für beretis bestehende Angebote anschauen. Wenn Sie Unterstützung brauchen, Sie wissen ja, wo Sie anrufen sollten.