search

BIK-BITV / BIK-Web-Test

Testverfahren zur Prüfung der Barrierefeiheit von Webanwendungen anhand der Kriterien der WCAG 2.1, EN 301 549 und BITV 2.0
71 stars 21 forks source link

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

Closed stefanFarnetani closed 1 year ago

stefanFarnetani commented 1 year ago

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.

This criterion was originally adopted to address problems that assistive technology had directly parsing HTML. Assistive technology no longer has any need to directly parse HTML. Consequently, these problems either no longer exist or are addressed by other criteria. This criterion no longer has utility and is removed.

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.

§ 3 Anzuwendende Standards [..] (2) Die Erfüllung der Anforderungen nach Absatz 1 wird vermutet, wenn diese Angebote, Anwendungen und Dienste

  1. harmonisierten Normen oder Teilen dieser Normen entsprechen, und
  2. die harmonisierten Normen oder Teile dieser Normen im Amtsblatt der Europäischen Union genannt worden sind.

(3) Soweit Nutzeranforderungen oder Teile von Angeboten, Diensten oder Anwendungen nicht von harmonisierten Normen abgedeckt sind, sind sie nach dem Stand der Technik barrierefrei zu gestalten. [...]

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:

  1. Verweis auf Stand der Technik Für den Fall, dass die im Amtsblatt der Europäischen Union bekannt gemachten harmonisierten Normen keine Vorgaben für einzelne konkrete Anforderungen enthalten, ist der „Stand der Technik“ zu berücksichtigen (vgl. § 3 Absatz 3). Der Stand der Technik beschreibt das, was technisch möglich ist, unabhängig davon, ob es sich schon in der Praxis durchgesetzt hat.

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: 1) Wir halten uns bei der Bewertung der Konformität an die harmonisierte Fassung der EN 301 549 2) Erfolgskriteriend der WCAG 2.2 können von jemden Prüfer (freiwillig) als Kommentare oder starke Empfehlungen geäußert. Es gibt keine eigenen Prüfschritte dazu 4) Prüfschritt "9.4.1.1 Korrekte Syntax" verbleibt bis zur neuen Version der EN im BIK BITV- Prüfkatalog 5) Prüfschritt "94.1.1 Korrekte Syntax" ist standardmäßig "nicht anwendbar". Im Kommentar wird erwähnt, das der Prüfschritt technisch nicht mehr relevant ist.

Bin gespannt was ihr dazu sagt. :)

Andreas-Englisch commented 1 year ago

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: https://github.com/BIK-BITV/BIK-Web-Test/issues/269.

sweckenmann commented 1 year ago

@stefanFarnetani zu dem Punkt 4.1.1: Hier hat Detlev schon ein PR für den Übergang gemacht: https://github.com/BIK-BITV/BIK-Web-Test/pull/371

Andreas-Englisch commented 1 year ago

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

Andreas-Englisch commented 1 year ago

@sweckenmann

zu dem Punkt 4.1.1: Hier hat Detlev schon ein PR für den Übergang gemacht

Ja, diese Änderung wird zu weniger Findings führen, ändert aber nichts an der Frage von Stefan und nichts an der Gewichtung des Problems

sweckenmann commented 1 year ago

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.

sweckenmann commented 1 year ago

@Andreas-Englisch Genau, wird schon mal zu weniger Findings führen. Wie die verbleibenden Findings zu gewichten sind, kann ja auch noch diskutiert werden.

marcus-herrmann commented 1 year ago

Ja, diese Änderung wird zu weniger Findings führen, ändert aber nichts an der Frage von Stefan und nichts an der Gewichtung des Problems

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.

MarcHaunschild commented 1 year ago

So lange die EN explizit auf die WCAG verweist, haben wir wirklich ein Problem. Ich finde wir sollten gegenüber den Machern für ein Minor Update auf eine Version 3.2.2 plädieren. Bis dahin: Konformität zu irgendwas kann ja immer mal in teilen sinnlos erscheinen (habe ich schon oft erlebt), dennoch kann man IMHO keine Konformität ohne ein pass bei 9.4.1.1 bescheinigen. Es sind dann nun mal nicht alle Prüfschritte bestanden. Manchmal muss man einfach warten.

johannesFischer84 commented 1 year ago

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.:

We are exploring options for handling 4.1.1 in WCAG 2.0 and 2.1. We plan to update this information in September 2023.

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.

cstrobbe commented 1 year ago

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.

Nicht nur doppel-IDs, sondern auch Syntaxfehler. Siehe die Variable filterStrings im Quellcode des Bookmarklets.

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.

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.

johannesFischer84 commented 1 year ago

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.

Andreas-Englisch commented 1 year ago

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"). Gleichzeitig verlinkt die EN 301 549 in der Referenz (unbeabsichtigt) auf die WCAG 2.1 in der Fassung vom September 2023. Genaugenommen gilt also nach EN 301 549 die alte Fassung der WCAG 2.1 von 2018 und somit bleibt die Frage bestehen, wie mit der alten Anforderung der EN und der neuen WCAG-Regel umzugehen ist.

cstrobbe commented 1 year ago

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 https://www.w3.org/TR/WCAG21/ (also ohne Datum), nicht https://www.w3.org/TR/2018/REC-WCAG21-20180605/. Die Referenz ist also doppeldeutig.

sprungmarker commented 1 year ago

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.

@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?

sprungmarker commented 1 year ago

Ja, diese Änderung wird zu weniger Findings führen, ändert aber nichts an der Frage von Stefan und nichts an der Gewichtung des Problems

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.

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.

stefanFarnetani commented 1 year ago

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 wusste nicht von dieser Entwicklung und dass die Problematik WCAG 2.2 im BIK bereits diskutiert wurde. Entschuldigt, wenn das an mir vorbeigegangen ist. Auf github gab es zumindest Infos.

Ich fasse nochmal zusammen, was ich verstanden habe:

Was wir damit nicht geklärt haben ist: Wonach genau müssen testen bis 2025, um eine Konformität nach deutschen Recht zu bescheinigen. Insofern hat @Andreas-Englisch recht. Aber ich denke, wir werden das in diesem Forum nicht final klären können. Ich will es dennoch wissen, auch für die Zukunft und werden mich weiter durchfragen. Wenn ich etwas erfahre, informiere ich hier wieder.

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. Wie gesagt, eine gute Lösung.

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.

johannesFischer84 commented 1 year ago

@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. Ein Kompromiss könnte meiner Meinung nach so aussehen: Fehler bei 4.1.1 werden informativ noch gemeldet, ein nicht konformes Erfolgskriterium wird aber nur gesondert mit dem Hinweis aufgeführt, dass der Fehler zukünftig voraussichtlich kein Fehler mehr ist. Eine öffentliche Stelle darf ihre Seite ausnahmsweise als barrierefrei erklären, wenn nur WCAG-Kriterium 4.1.1 nicht konform sein sollte.

MarcHaunschild commented 1 year ago

Es ist aktuell nicht eindeutig. Einerseits der wörtliche Verweis auf 2018, andererseits der link auf die aktuelle Version. Ich habe Susanna Laurin dazu angefragt, aber es gab wohl ein Missverständnis. Sie hat mich auf den offiziellen Zeitplan verwiesen, der eine aktualisierte Fassung der EN für Ende 2024 vorsieht. Ich habe noch mal auf explizit den Punkt mit dem Datum hingewiesen und warte noch auf eine Reaktion. Ich hoffe sie kommt nach dem Wochenende. Sonst kann vielleicht @detlevhfischer noch mal nachhören. Ich denke, er kennt Susanna besser als ich.

cstrobbe commented 1 year ago

@MarcHaunschild

Sie hat mich auf den offiziellen Zeitplan verwiesen, der eine aktualisierte Fassung der EN für Ende 2024 vorsieht.

Wo findet man diesen offiziellen Zeitplan?

@johannesFischer84

Rechtlich könnte man es also tatsächlich so auslegen, dass WCAG 4.1.1 auch nach der Änderung verpflichtend ist.

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...

stefanFarnetani commented 1 year ago

@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?

sweckenmann commented 1 year ago

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

stefanFarnetani commented 1 year ago

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. Wenn ich den Zeitplan richtig lese, ist sogar Ende 2025 schon nicht mehr aktuell. Lese ich das richtig, dass die Veröffentlichung für den 2026-02-15 geplant ist?

MarcHaunschild commented 1 year ago

@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?

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.

sweckenmann commented 1 year ago

@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).

johannesFischer84 commented 1 year ago

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.

MarcHaunschild commented 1 year ago

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. Auch die BITV spricht ja von Einhaltung harmonisierter Normen. Als solche kann man sicher auch die WCAG verstehen. Grundsätzlich warne ich immer davor, sich von so etwas zu entfernen, da die Einhaltung solch eines Standards wie der EN allen Beteiligten (Rechts-) Sicherheit gibt.

Ich meine aber wir können bezogen auf den Prüfschritt (9.)4.1.1 hier eine Ausnahme begründen:

  1. die EN verweist auf die WCAG 2.1 - die WCAG 2.1 ist mit einer NOTE versehen, die den Wegfall (bzw generell positive Bewertung) von 4.1.1 zulassen würde.
  2. im Wortlaut der EN steht zwar Juni 2018, aber der Link verweist auf eine aktuelle Version der WCAG. Hier ist unklar, was gefordert ist. Außerdem steht dort nicht WCAG vom Juni, auch die Angabe eines genauen Datums (Tag, Monat, Jahr) fehlt, was man eigentlich erwarten könnte. Insofern kann man meiner Meinung nach hier keine Ausschließlichkeit mit Sicherheit voraussetzen.
  3. Die Forderung der EN lautet wörtlich: "9.4.1.1 Parsing Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 4.1.1 Parsing." Der Verweis führt auch hier tatsächlich zu der aktuellen WCAG mit der bekannten Notiz.

Mein Fazit

Mir 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. Wenn in der Anforderung 9.4.1.1 steht, dass ein bestimmtes SC einzuhalten ist und auf das SC verlinkt wird, dann gilt IMHO das, worauf der Link verweist. Sonst wäre kein Link nötig.

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:

Please remember that European directives are (obviously) mandatory for organisations in scope, but European standards, even so called European Norms (EN) are voluntary. The EN301549 acts as presumed conformance to WAD, but if you can meet the requirements in another way, you are welcome to.

There are several layers here: What should the public sector body do to meet WAD? What should the industry provide when developing for public sector? What should third party auditor test for? What should the monitoring agencies monitor?

When it comes to the EN, it is true that you would “have to wait for the update”. But that is not really relevant if the context is WAD: When there is a discrepancy between the current EN and WCAG, and the context is WAD, the monitoring agencies in each member state need to decide how to determine compliance. Unfortunately, some (many?) of them don’t really have the capacity to do so.

In order to support them, I will suggest a statement as the chair of JTB and see if I can get ETSI/CEN/CENELEC to agree on making this official. Otherwise, I will just publish it myself and send it out to the monitoring agencies (and you).

sweckenmann commented 1 year ago

@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.