-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wie gehen wir mit Prüfschritt 9.4.1.1 Korrekte Syntax um, nachdem die WCAG 2.2 den recommendation-status hat, aber die EN 301 549 noch nicht aktualisiert ist #373
Comments
Es würde schon helfen, wenn die Gewichtungsmöglichkeit geändert wird. Ein Verstoß gegen 4.1.1 könnte dann als "eher erfüllt" gewichtet werden. Siehe: #269. |
@stefanFarnetani zu dem Punkt 4.1.1: Hier hat Detlev schon ein PR für den Übergang gemacht: #371 |
Die (falsche) Relevanz des Prüfschritts sollte m.E. nicht unterschätzt werden. Alle oder die meisten Prüfungen der Überwachungsstelle BFIT, die die Einhaltung der EN 301 549 für die EU überprüft, finden nach dem BIK BITV-Prüfverfahren statt. Das Ergebnis der ersten Überwachung ist, dass bei der eingehenden Überwachung das häufigste (und damit scheinbar schlimmste) Problem 4.1.1 ist: Siehe https://www.bfit-bund.de/DE/Downloads/eu-bericht-pdf.pdf?__blob=publicationFile&v=2, S. 33 |
Ja, diese Änderung wird zu weniger Findings führen, ändert aber nichts an der Frage von Stefan und nichts an der Gewichtung des Problems |
Außerdem planen wir ein zusätzliches Verfahren "BITV (+ WCAG 2.2)" für die Zeit, in der die EN noch nicht die WCAG 2.2 Prüfschritte enthält. Die Kunden können sich dann entscheiden, ob sie sich nach der aktuellen EN testen lassen, oder ob die neuen Prüfschritte mitgetestet werden sollen. |
@Andreas-Englisch Genau, wird schon mal zu weniger Findings führen. Wie die verbleibenden Findings zu gewichten sind, kann ja auch noch diskutiert werden. |
Wenn ich das richtig sehe, stutzt @cstrobbe's Bookmarklet die 4.1.1 auf doppelte IDs herunter, was mir wie ein pragmatischer (kein formaljuristischer) Kompromiss erscheint, da ja auch in 2.2 dieses Doppel-ID-Problem noch getestet, aber 1.3.1 zugeordnet wird, wenn ich mich richtig erinnere. |
So lange die EN explizit auf die WCAG verweist, haben wir wirklich ein Problem. |
Die WCAG Working Group ist selbst schon auf dieses Problem gestoßen, siehe die Question zu 4.1.1 in den WCAG 2 FAQ. Dort steht u. a.:
Ich meine, vorher mal gelesen zu haben, dass eventuell in WCAG 2.0 und 2.1 eine NOTE oder Ähnliches nachträglich eingesetzt wird, dass 4.1.1 wegen der Ungültigkeit in WCAG 2.2 auch in den Vorversionen nicht mehr erfüllt werden muss. Wenn das der Fall wäre, könnte man aus meiner Sicht auf 4.1.1 verzichten, ohne die neuen Kriterien der WCAG 2.2 prüfen zu müssen. Ich würde vorschlagen, zunächst das Ergebnis der WCAG Working Group abzuwarten und danach zu entscheiden. |
Nicht nur doppel-IDs, sondern auch Syntaxfehler. Siehe die Variable
Wenn es um die Konformität von Websites und Apps öffentlcher Stellen geht, haben wir nicht das Recht unsere eigenen Standard zusammenzubasteln. Man könnte eventuell den Prüfschritt immer als "nicht anwendbar" bewerten, aber so tun, als ob er gar nicht bestünde, würde ich nicht. |
Heute Nachmittag kam über die WAI Announce Mailinglist, dass die WCAG 2.1 aktualisiert wurde. Es wurde tatsächlich eine NOTE eingefügt, dass WCAG 4.1.1 immer mit konform bewertet werden soll. Eine NOTE mit Hintergrundinfos kam auch noch dazu. @stefanFarnetani Stefan, aus meiner Sicht müsste deine Frage damit gelöst sein, außer ich denke in irgendeiner Weise zu einfach. |
Die EN 301 549 verweist nicht auf die WCAG 2.1, sondern auf die WCAG 2.1 in der Fassung vom Juni 2018 (siehe S. 11 der EN, Kapitel "Normative references"). |
Der Text sagt 'W3C Recommendation (June 2018): "Web Content Accessibility Guidelines (WCAG) 2.1".' (also mit Datum); die URL ist aber |
@sweckenmann wird das dann auch für den BIK-Test so angepasst. Klingt ja ganz danach, dass man diesen Prüfschritt nun einfach nur noch positiv bewertet in die WCAG 2.2. mitschleift? |
Ja, ist mir auch aufgefallen - im vorherigen Bookmarklet wurde noch explizit diverse fehlehafte Verschachtelungen mitgeprüft, was auch in WCAG 2.1 auch explizit als Fehler stand. |
Danke an alle für die Antworten. Vor allem Danke an @sweckenmann für die Information, dass eine weitere Variante des BIK Prüfzeichens geplant ist: EN + WCAG 2.2. Dies ist eine elegante Lösung des Problems innerhalb des Prüfverbundes. Ich fasse nochmal zusammen, was ich verstanden habe:
Was wir damit nicht geklärt haben ist: Ich vermute, dass so lange wir die Frage nicht beantwortet können, die meisten nach dem neuen Prüfkatalog (EN + WCAG 2.2) testen werden. Damit zieht man sich aus der Verantwortung und tut keinem weh. Die WCAG 2.2 kommt ja sicher ab 2025, legt schonmal los. Und der umstrittene Prüfschritt 9.4.1.1 ist raus. Mein Hinweis, dass wir sofort aufhören müssen auf 9.4.1.1 irgendwelche Fehler zu melden, wird durch die neue Situation (nach Einführung den neuen Test) entschärft. Ich schließe also dieses Issue. Nochmal vielen Dank für alle Beiträge. |
@Andreas-Englisch Andreas, danke, dass du die Verweise von der EN 301 549 auf die WCAG 2.1 so genau im Kopf hast :-) Rechtlich könnte man es also tatsächlich so auslegen, dass WCAG 4.1.1 auch nach der Änderung verpflichtend ist. Vermutlich konnten sich die Autoren der EN auch nicht vorstellen, dass eine WCAG-Version nochmal geändert werden könnte und dabei eine bisherige Prüfung ungültig werden könnte. Neben der rechtlichen Strenge gibt es die Strenge/Lockerheit der Durchsetzung des Rechts. Ich kann mir persönlich nicht vorstellen, dass zum Beispiel Überwachungsstellen oder andere zertifizierende Stellen einer öffentlichen Stelle "etwas reindrücken wollen", was eigentlich für die Barrierefreiheit nicht mehr relevant ist bzw. zukünftig sowieso auch rechtlich mit größter Wahrscheinlichkeit ungültig wird. Die öffentlichen Stellen sollen sich lieber darauf konzentrieren, andere Fehler zu beseitigen. |
Es ist aktuell nicht eindeutig. Einerseits der wörtliche Verweis auf 2018, andererseits der link auf die aktuelle Version. |
Wo findet man diesen offiziellen Zeitplan?
Da die "Notes" in WCAG 2.1 gar nicht normativ sind, hat sich am normativen Teil des SC 4.1.1 auch nichts geändert... |
@MarcHaunschild @cstrobbe Der offizielle Zeitplan würde mich auch interessieren. Alle meine bisherigen Informationen besagen, dass die EN nicht vor Herbst 2025 aktualisiert wird. Ende 2024 wäre ein ganzes Jahr vorher. Oder ist das ein Tippfehler? |
Nach Aktualisierung muss noch die Veröffentlichung im offiziellen Journal der EU erfolgen. Erst dann ist es eine "harmonisierte Norm". Selbst wenn die Arbeit an der Norm Ende 2024 abgeschlossen wird, dauert es ja noch, bis sie als harmonisierte Norm veröffentlicht wird. Zeitplan https://portal.etsi.org/eWPM/index.html#/schedule?WKI_ID=64282 |
@sweckenmann Danke für den Zeitplan. Ich bin davon ausgegangen, dass wir alle immer den Zeitpunkt meinen, ab dem die neue EN gilt. Wie du schreibst: Veröffentlichungstermin und damit "harmonisierte Norm". Alles davor ist für mich im Prozess und uninteressant für die obige Diskussion. |
Susanna hat mir den weiteren Fortschritt (vermutlich aus dem Kopf) geschrieben, ohne einen Verweis auf ein offizielles Dokument. Ich habe hier auch absichtlich nicht eine nur an mich geschriebene Mail zitiert, zumal mich das ja auch nicht hauptsächlich interessiert hat, sondern die Klärung der Frage, ob wir jetzt schon der Note in der WCAG 2.1 folgend den Prüfschritt als bestanden werten sollten. Mal sehen, ob und wann sie Zeit findet, darauf zu antworten. Erst mal wäre das ja auch nur eine Meinung ohne rechtliche Relevanz. Aber natürlich schon eine wichtige Meinung. Unser Problem besteht ja darin, dass im Text Juni 2018 steht, die Verlinkung aber auf die aktuelle Version verweist. Insofern würde es uns helfen, wenn die verlinkte Version diejenige ist, die wir beachten müssen. Diese Aussage müsste offiziell sein. Dann wäre 9.4.1.1 für uns erst mal geklärt und uns könnte in dieser Hinsicht egal sein, wann die nächste Version der EN raus kommt. Vielleicht gibt es irgendwo in begleitenden Dokumenten Hinweise dazu, die keiner von uns auf dem Schirm hat. |
@stefanFarnetani Ich bin mir nicht ganz sicher, wie man den Zeitplan lesen soll. Ob "Publication" (02-2026) oder "Citation in the OJ" (OJ bedeutet wohl "Offical Journal") (05-2026) das relevante Datum ist (ab dem dann die WCAG 2.2 Anforderungen gelten). |
Das relevante Datum ist aus meinem Überwachungsstellen-Wissen heraus die Veröffentlichung im Amtsblatt (Citation in the OJ). Ab dann bzw. dem dort angegebenen Datum (in der Regel sofort) ist die Anwendung verpflichtend. |
Hallo zusammen, Hier die Einschätzung von Susanna Laurin (am Ende), die die Auffassung vertritt, dass die EN kein Hindernis sein muss, neues aus der WCAG zu übernehmen, zumindest aus Sicht der WAD. Diese empfiehlt die Einhaltung der EN, wenn man eine andere Art kennt, Barrierefreiheit zu belegen, ist das durchaus möglich. Ich meine aber wir können bezogen auf den Prüfschritt (9.)4.1.1 hier eine Ausnahme begründen:
Mein FazitMir scheint die Absicht der EN in Bezug auf die Version der WCAG unklar, allerdings deutet vieles darauf hin, dass die Autoren sich die Unterstützung der aktuellsten Version wünschen. Zusammen mit der Auffassung, von Susanna, dass die Einhaltung der WAD-Vorgaben (und in logischer Folge der BITV, die auf "harmonisierte Normen" verweist und nicht auf die EN), halte ich das von uns mehrheitlich als sinnvoll erachtete Vorgehen, 9.4.1.1 immer als bestanden zu bewerten, für begründbar. Und zwar im Rahmen des normalen Tests, nicht nur in BITV+WCAG 2.2 Hier die versprochene Antwort von Susanna Laurin, die ich mit ihrer Erlaubnis hier anfüge:
|
@MarcHaunschild Danke für die Infos. Die EN ist zwar "voluntary", aber die BITV führt (als Verordnung) unter "anzuwendender Standard" die harmonisierte Norm auf (welche im Amtsblatt veröffentlicht wurde). Trotzdem bleibt die Uneindeutigkeit (textlicher Verweis und Link auf die aktuelle WCAG). Detlev hatte in seinem PR die Prüfschrittbeschreibung dahingehend geändert (neues Bookmarklet etc.), dass wie oben erwähnt, weniger Fehler verbleiben, vermutlich meistens doppelte ids. Und wir schlagen vor, diese mit "eher erfüllt" zu bewerten. Gleichzeitig haben wir über unsere Kanäle angeregt, dass die Überwachungsstellen das Thema auf ihrer nächsten Sitzung mit aufnehmen. |
Bald ist es soweit und die lange diskutierte WCAG 2.2 ist fertig.
Bis vor kurzem war mir die Implikationen nicht bewusst, dadurch, dass die WCAG 2.2., neben neuen Erfolgskriterien, auch das Kriterium "4.1.1 Parsing" streicht (https://www.w3.org/TR/WCAG22/#parsing).
Hintergrund EN 301 549:
Die EN 301 549 wird bis Herbst 2025 überarbeitet. Davor ist keine neue Version geplant. Im Zuge der nächsten Überarbeitung soll auch die WCAG 2.2 eingearbeitet werden. Bis dahin gilt in Europa die EN 301 549 in der aktuellen, harmonisierten Version 3.2.1. Und damit gilt auch weiterhin das Kriterium "9.4.1.1 Parsing".
Hintergrund: In der EU gilt immer die aktuellste, harmonisierte Fassung der EN 301 549. Dafür muss kein Gesetz erneut angepasst werden. Sie gilt automatisch in der ganzen EU.
Dieser Teil der Information ist soweit gesichert.
Das ist normal, dass solche Prozesse etwas dauert. Weltweit gibt es ja viele Länder, in der sogar noch die WCAG 2.0 gilt. Als Tester kann ich zusätzlich als Kommentar darauf hinweisen und empfehlen schonmal für die WCAG 2.2 hinzuarbeiten. Der Test muss aber immer offiziell die Konformität nach der aktuelle gültigen EN 301 549 bescheinigen.
In meinem Verständnis gilt die neue Version der WCAG 2.2 nicht automatisch. Zuerst muss die WCAG in die EN eingearbeitet werden (Siehe dazu auch Stand der Techink weiter unten).
Der Wegfall des Kriteriums wird in der WCAG 2.2 damit begründet, dass er nicht mehr technisch notwendig ist. Man kann auch sagen der Prüfschritt ist veraltet.
Wir sollten eigentlich bereits heute diesen Prüfschritt gar nicht mehr anwenden, da er in heutigen Screenreadern keine Auswirkung auf die Barrierefreiheit hat. In Gegensatz zu anderen "angestaubten" Prüfschritten wie "Image of Text" kann auch kein Nachteil mehr für Nutzer*innen daraus entstehen.
Quelle: https://www.w3.org/WAI/WCAG22/Understanding/parsing.html
Wir müssen nunmal das Kriterium in einem Konformitätstest (dazu zähle ich den BIK BITV-Test mit Prüfzeichen) solange weitertesten, bis er in der EN 301 549 offiziell entfernt wurde. Jetzt noch etwas zu melden, was unwichtig ist, nur weil es noch in der Norm steht, ist in meinen Augen nicht professionell.
Fehler in diesem Bereich sind seltener geworden, aber auch ich habe in den letzten 6 Monaten bestimmt in einem Bericht dazu Fehler gemeldet.
Stand der Technik
@jörg Morsbach hat mich vor ein paar Tagen auf den "Stand der Technik" in der BITV hingewiesen.
Wir hatten eine kleine Diskussion. Konnten dies aber nicht abschließend klären.
Die frage ob die WCAG 2.2. gilt oder nicht ist dadurch erschwert.
Quelle: https://www.gesetze-im-internet.de/bitv_2_0/BJNR184300011.html#BJNR184300011BJNE000403126
Interessant ist Absatz 3. "soweit nicht von harmonisierten Normen abgedeckt".
Ich interpretiere dies, dass Zusatzstandards wie PDF/UA, WAI-ARIA aber auch HTML, EPUB oder mobile App Plattform Standard gemeint sind. Also Technologien zu denen die EN bzw. WCAG keine konkreten Aussagen trifft wie man Barrierefreiheit erreichen kann. Die WCAG ist ja mit Absicht agnostisch formuliert. Wenn also unter "9.4.1.2 Name, Rolle, Wert verfügbar" nur gefordert wird, dass das Name, Rolle und Werte programmatisch verfügbar sind, ist nicht definiert, was eine Angemessene Rolle für eine Überschrift (HTML-Standard) oder für ein Acoordion (WAI-ARIA Standard) ist.
Es besteht auch die Auslegung, dass die WCAG 2.2. automatisch Stand der Technik wird und wir nicht abwarten bis die EN 301 549 aktualsiert wurde.
Wenn dem So ist, müssten wir alle neuen Prüfschritte der WCAG 2.2. testen und "9.4.1.1 Korrekte Syntax" dann raulassen. Es würde also meiner Interpretation entsprechen. Ich habe nur große Probleme in bezug auf das zusammenspeil mit dem Konformitätsnachweis nach EN.
Ich muss es an dieser Stelle einräumen das obere Auslegung, die WCAG 2.2. gelte über den Stand der Technik sofort, mir kontraproduktiv und etwas praxisfern erscheint; sollte der Gesetzgeber mit diesem Abschnitt tatschälich dieses Vorgehen gewünscht haben.
Die Angaben in der BITV sind, wie so oft, unklar (ich erinnere an viele Diskussionen zum höchstmöglichen Maß). Wenn jemand Klarheit (Schriftliche auslegungen, nachweise) in das Thema bringen kann, freue ich mich.
Vermutlich müssen wir warten bis es eine offizielle Auslegung vom der Bundesfachstelle Barrierefreiheit oder der Überwachungstelle des Bundes für Barrierefreiheit von Informationstechnik gibt. Ich stehe der nächste Arbeitsgruppe als (oft nervende) Stimme aus der Praxis zur Verfügung.
Die Bundesfachstelle schreibt bisher nur dazu:
Quelle: https://www.bundesfachstelle-barrierefreiheit.de/DE/Fachwissen/Informationstechnik/EU-Webseitenrichtlinie/BGG-und-BITV-2-0/Die-neue-BITV-2-0/die-neue-bitv-2-0_node.html
Ist das leider nicht sehr deutlich. Ich vermute dass jede Position ihre jeweilige Interpretation dadurch bestärkt sieht.
Mir ist bewusst, dass der Umgang mit Prüschritt 9.4.1.1 Korrekte Syntax auch bedeutet, dass wir uns mit dem Umgang der WACG 2.2 beschäftigen müssen. Sorry.
Wir haben das Dilemma bei uns intern diskutiert und ich mache einen ersten Vorschlag:
Bin gespannt was ihr dazu sagt. :)
The text was updated successfully, but these errors were encountered: