Im Vorgriff auf die irgendwann anstehende WCAG 2.2 hat die WAI einen ungewöhnlichen Schritt gemacht. Sie hat den Prüfschritt 4.1.1 für obsolet erklärt. Hinweis: Die WCAG 2.2 wurde im Hrbst 2023 veröffentlicht, wird aber erst für Deutschland gültig, wenn das in die entsprechende Richtlinie EN 301549 übernommen wird.

How and why is success criteria 4.1.1 Parsing obsolete?
Success criteria 4.1.1 Parsing is obsolete. That’s documented in:
• WCAG 2.2 4.1.1 Parsing (Obsolete and removed)
• updated WCAG 2.1 that incorporates errata, 4.1.1 Parsing Notes, WCAG 2.1 changelog
• WCAG 2.0 errata
• Understanding documents
Parsing was included in WCAG 2.0 to ensure that browsers and assistive technologies could accurately parse markup and content. Since then, specifications (such as HTML) and browsers have improved how they handle parsing errors. Also, previously assistive technology did their own markup parsing. Now they rely on the browser.
With today’s technology, accessibility issues that would have failed 4.1.1, will fail other criteria, such as Info and Relationships (SC 1.3.1) or Name, Role, Value (SC 4.1.2). Therefore 4.1.1 is no longer needed for accessibility.

Quelle
Der Schritt ist ungewöhnlich, weil an der bestehenden WCAG eigentlich ebensowenig geführt wird wie am Neuen Testament.
Bei dem Kriterium 4.1.1 bzw. 9.4.1.1 wird überprüft, ob der HTML-Code valide ist. Wenn Sie schon mal einen Prüfbericht bekommen haben, haben Sie sicher schon mal diese oft sehr lange Liste von Fehlern im Quellcode bekommen, die dann mühsam abgearbeitet werden musste. Mich hat diese Prüfung nie so richtig überzeugt und es tat mir immer leid, dass ich das den Kunden aufdrücken musste. Nun hat selbst die WAI erkannt, dass das überflüssig ist.
Nun wurde es sogar rückwirkend für 2.1 abgeschafft. Das hat dazu geführt, dass viele Webseiten und PDF auf einen Schlag barrierefreier geworden sind.
Hintergrund ist, dass viele der „Studien“ zur Barrierefreiheit auf automatisierten Tools basieren. Diese Tools können exzellent messen, was automatisch messbar ist, also etwa nicht-validen Code. In der Tat ist das einer der häufigsten Fehler bei Webseiten oder PDF.
Während das an einigen Stellen sinnvoll ist, führt es an anderen zu zeitaufwendigen Mikro-Optimierungen vor allem bei PDF. Das liegt auch daran, dass Prüftools wie der PDF Accessibility Checker gerne selbst Bugs enthalten, die Umsetzenden sind dann gezwungen, die PDFs für den PAC zu optimieren weil das der Maßstab für Leute ist, die keine Ahnung von barrierefreien PDF haben. Fehlerhaft verschachtelte Tags kommen auf Webseiten heutzutage hingegen selten vor, da die Tags durch Software erzeugt oder durch Editoren automatisch korrigiert werden. Außerdem, so die WAI, sind Browser und assistive Technologien inzwischen besser darin, die Codefehler aufzufangen.
Ich kenne zahlreiche Kunden, die jetzt aufatmen werden, nicht weil ihnen Barrierefreiheit nicht liegt, sondern weil diese Mikro-Optimierungen viel Zeit und Ressourcen verschlungen haben, die man sinnvoller investieren kann. Verstehen Sie mich nicht falsch: Es ist sinnvoll, den HTML und CSS-Code auf Fehler hin zu validieren. Aber ein fehlender Schrägstrich hat meines Wissens selten die Barrierefreiheit wesentlich beeinflusst. Ebenso sinnfrei sind viele Rückmeldungen des PDF Accessibility Checkers. Diese Tools zwingen uns dazu, für möglicherweise schlecht gemachte Algorithmen zu optimieren statt für die Nutzenden. Beim PDF Accessibility Checker ist bekannt, dass er zahlreiche Bugs hat, die nach Jahren oder auch nie repariert werden. Dennoch wird ein sauberer PAC-Bericht als Qualitäts-Merkmal eines barrierefreien PDF betrachtet.
Das überflüssige Language-Attribut aka Sprachwechsel 3.1.2: Language of Parts bleibt leider bestehen. Irgendwer in der WAI hat offenbar ein Herz für Mikro-Optimierungen.