![\"Screenshot](\"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-content\/uploads\/vali.jpg\")
\nIm Vorgriff auf die irgendwann anstehende WCAG 2.2 hat die WAI einen ungew\u00f6hnlichen Schritt gemacht. Sie hat den Pr\u00fcfschritt 4.1.1 f\u00fcr obsolet erkl\u00e4rt. Hinweis: Die WCAG 2.2 wurde im Hrbst 2023 ver\u00f6ffentlicht, wird aber erst f\u00fcr Deutschland g\u00fcltig, wenn das in die entsprechende Richtlinie EN 301549 \u00fcbernommen wird. <\/p>\n
\nHow and why is success criteria 4.1.1 Parsing obsolete?
\nSuccess criteria 4.1.1 Parsing is obsolete. That\u2019s documented in:
\n\u2022 WCAG 2.2 4.1.1 Parsing (Obsolete and removed)
\n\u2022 updated WCAG 2.1 that incorporates errata, 4.1.1 Parsing Notes, WCAG 2.1 changelog
\n\u2022 WCAG 2.0 errata
\n\u2022 Understanding documents
\nParsing 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.
\nWith today\u2019s 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.\n<\/p><\/blockquote>\nQuelle<\/a>
\nDer Schritt ist ungew\u00f6hnlich, weil an der bestehenden WCAG eigentlich ebensowenig gef\u00fchrt wird wie am Neuen Testament.
\nBei dem Kriterium 4.1.1 bzw. 9.4.1.1 wird \u00fcberpr\u00fcft, ob der HTML-Code valide ist. Wenn Sie schon mal einen Pr\u00fcfbericht bekommen haben, haben Sie sicher schon mal diese oft sehr lange Liste von Fehlern im Quellcode bekommen, die dann m\u00fchsam abgearbeitet werden musste. Mich hat diese Pr\u00fcfung nie so richtig \u00fcberzeugt und es tat mir immer leid, dass ich das den Kunden aufdr\u00fccken musste. Nun hat selbst die WAI erkannt, dass das \u00fcberfl\u00fcssig ist.
\nNun wurde es sogar r\u00fcckwirkend f\u00fcr 2.1 abgeschafft. Das hat dazu gef\u00fchrt, dass viele Webseiten und PDF auf einen Schlag barrierefreier geworden sind.
\nHintergrund ist, dass viele der „Studien“ zur Barrierefreiheit<\/a> auf automatisierten Tools basieren. Diese Tools k\u00f6nnen exzellent messen, was automatisch messbar ist, also etwa nicht-validen Code. In der Tat ist das einer der h\u00e4ufigsten Fehler bei Webseiten oder PDF.
\nW\u00e4hrend das an einigen Stellen sinnvoll ist, f\u00fchrt es an anderen zu zeitaufwendigen Mikro-Optimierungen vor allem bei PDF. Das liegt auch daran, dass Pr\u00fcftools wie der PDF Accessibility Checker gerne selbst Bugs enthalten<\/a>, die Umsetzenden sind dann gezwungen, die PDFs f\u00fcr den PAC zu optimieren weil das der Ma\u00dfstab f\u00fcr 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\u00dferdem, so die WAI, sind Browser und assistive Technologien inzwischen besser darin, die Codefehler aufzufangen.
\nIch 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\u00e4gstrich hat meines Wissens selten die Barrierefreiheit wesentlich beeinflusst. Ebenso sinnfrei sind viele R\u00fcckmeldungen des PDF Accessibility Checkers. Diese Tools zwingen uns dazu, f\u00fcr m\u00f6glicherweise schlecht gemachte Algorithmen zu optimieren statt f\u00fcr 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\u00e4ts-Merkmal eines barrierefreien PDF betrachtet.
\nDas \u00fcberfl\u00fcssige Language-Attribut aka Sprachwechsel<\/a> 3.1.2: Language of Parts bleibt leider bestehen. Irgendwer in der WAI hat offenbar ein Herz f\u00fcr Mikro-Optimierungen. <\/p>\n","protected":false},"excerpt":{"rendered":"Im Vorgriff auf die irgendwann anstehende WCAG 2.2 hat die WAI einen ungew\u00f6hnlichen Schritt gemacht. Sie hat den Pr\u00fcfschritt 4.1.1 f\u00fcr obsolet erkl\u00e4rt. Hinweis: Die…<\/p>\n