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
67 stars 21 forks source link

Bewertung von 9.4.1.1 #269

Open Andreas-Englisch opened 2 years ago

Andreas-Englisch commented 2 years ago

Korrekte Syntax kann nur mit Ja und Nein bewertet werden. Ich gehe davon aus, dass "Nein" = "Nicht erfüllt" bedeutet, und frage mich, ob das nicht zu hart ist. Ein Syntaxfehler kann dazu führen, dass eine Seite nicht konform ist.

  1. Der Sinn des Kriteriums ist umstritten: https://github.com/w3c/wcag/issues/770 (WCAG plant ggf. Abschaffung)
  2. Der Testumfang ist umstritten: https://github.com/BIK-BITV/BIK-Web-Test/issues/99 (@cstrobbe sagt, dass alle die Verschachtlung von Elementen falsch testen).
  3. Das verwendete Bookmarklet ist fehlerhaft: https://www.bitvtest.de/bitv_test/das_testverfahren_im_detail/werkzeugliste.html#c1356 (fehlerhafte Attribute werden nicht gefiltert).
  4. Die meisten von mir gefundenen Fehler haben keine Relevanz für die Barrierefreiheit. Beispiele:

<button><div>1</div></button> - ein Schalter hat implizites role=presentation, somit hat das div keine Rolle und ist für Accessibility API nicht vorhanden.

<div hidden><ul><span></span></ul></div> - die Liste ist ausgeblendet, somit hat der Syntaxfehler keine Relevanz.

<ul><span role=listitem></span></ul> - das span hat die Rolle Listeneintrag, somit ist an sich alles korrekt, nur der Validator versteht leider kein ARIA.

Vorschlag:

detlevhfischer commented 2 years ago

@Andreas-Englisch Die Ja/Nein Bewertung stammt aus einer Zeit, als Browser noch nicht wie heute in der Lage waren, fehlerhaftem Quelltext bei der Generierung des DOM zu korrigieren. Ich finde den Vorschlag der abgestufen Bewertung im Prinzip gut. Das Problem bleibt, Prüfende bei der Auswertung von Fehlern über das Validate bookmarklet hinaus hinreichend zu unterstützen, so dass nicht komplett unterschiedlich bewertet wird. Also: Wann sind errors gravierend genug für ein FAIL? Sicher nicht bei Custom-Attributen und Attributen wie title auf den faschen Elementen - und ich denke wohl auch nicht bei divs innerhalb von Inhalten, die laut Speziflkation nur inline content haben wollen (obwohl wir das nicht aufgeführt haben - das wäre ggf. zu ergänzen).

Zu Deiner Variante 1: Bedeutet der Vorschlag, dass Du NUR NOCH "erfüllt" und "eher erfüllt" als Optionen anbieten wolltest? Wahrscheinlich nicht, denn es gibt ja klar Fälle wie <button> <h1> bla bla </h1> </button>, wo Semantik verloren geht und der Verlust ggf. ein "nicht erfüllt" rechfertigt. (Obwohl man auch argumentieren könnte, dass das ebenso bei 9.4.1.2 unterzubringen wäre - der Überschrift fehlt dann die Rolle.)

In jedem Fall: wenn es keine FAIL Option gäbe, wäre der Prüfschritt bzw, die zugrundeliegende Anforderung im Grunde aus Konformitätssicht hinfällig. Das mögen viele in der AGWG bereits so sehen, aber bislang steht das Erfolgskriterium 4.1.1 in den aktuellen Guidelines und muss demnach auch mit FAIL bewertet werden können.

Andreas-Englisch commented 2 years ago

@detlevhfischer

Variante 1 wäre einfacher, als immer die Probleme gewichten zu müssen, was ja nicht so einfach ist. Warum schlage ich das vor: Weil <button><h1>bla bla</h1></button> zwar einerseits ein Syntaxfehler nach 9.4.1.1 ist, aber andererseits ein Verstoß gegen 9.1.3.1a - aber nur, wenn der Schalter wirklich eine Überschrift darstellt. Wenn er keine Überschrift darstellt, wäre 9.1.3.1a erfüllt und der Syntaxfehler bei 9.4.1.1 würde sogar etwas Gutes bewirken: nämlich eine korrekte Überschriftenstruktur, die viel wichtiger ist als eine korrekte Syntax. Analog wäre z.B. <details><summary><h1>bla bla</h1></summary>test</details> zwar korrekte Syntax, aber auch ein Verstoß gegen 9.1.3.1a, weil hier aus dem gleichen Grund (summary verhält sich wie ein Schalter) die Überschrift semantisch nicht mehr vorhanden ist. Es wäre eigenartig, das erste Beispiel bei 9.4.1.1 hart zu bewerten und das zweite bei 9.1.3.1a, obwohl die Ursache und die Auswirkung die gleiche ist.

Lange Rede, kurzer Sinn: Relevante Syntaxfehler, die die Barrierefreiheit beeinträchtigen, würde ich eher bei den entsprechenden Prüfkriterien bewerten und alles, was dann noch für 9.4.1.1 übrig bleibt, hat keine oder nur geringe Auswirkungen und kann somit als "eher erfüllt" angesehen werden. Wenn das auf Ablehnung stößt, verweise ich auf Vorschlag 2.

Andreas-Englisch commented 2 years ago

Sicher nicht bei Custom-Attributen und Attributen wie title auf den faschen Elementen

Das sind sowieso keine Fehler nach WCAG 4.1.1. Dass diese jedoch als Fehler gern aufgenommen werden, liegt ja nur am fehlerhaften Parsing Bookmarklet. Deswegen steht ja auch in der Testanleitung: "Falls noch Fehler (Errors) auftauchen, sind diese auf den semantisch korrekten Einsatz von Custom-Attributen zurückzuführen." (https://webtest.bitv-test.de/index.php?a=di&iid=294&s=n). Das ist also keine Entscheidung aus Kulanz, sondern hat einfach damit zu tun, dass WCAG 4.1.1 beliebige Attribute erlaubt, solange sie nicht doppelt vorkommen oder eine bereits verwendete ID enthalten (beim ID-Attribut).

detlevhfischer commented 2 years ago

@Andreas-Englisch Wie oben gesagt, ich denke, wir würden uns zu weit von den geltenden WCAG entfernen, wenn wir die gesamte Anforderung über die Enfernung der FAIL Option eigenmächtig aushebeln würden. Was das Beispiel <button> <h1> bla bla </h1> </button> angeht, wäre die Verwendung der h1 auf etwas, was keine Überschrift ist, wohl unabhängig von der Browser-Ausgabe ein 1.3.1 Fehler (siehe F43), denn es ist gut möglich, dass manche UA die Überschrift dennoch ausgeben (z.B. auch in Screenreader generierten Überschriftenlisten).

Andreas-Englisch commented 2 years ago

Was das Beispiel <button> <h1> bla bla </h1> </button> angeht, wäre die Verwendung der h1 auf etwas, was keine Überschrift ist, wohl unabhängig von der Browser-Ausgabe ein 1.3.1 Fehler (siehe F43)

Das sehe ich anders, weil in F43 steht:

Though an element's semantic meaning is generally exposed to AT, the WAI-ARIA presentation role can be used to suppress the native semantics of an element so that they are not mapped to the accessibility API. Setting an element's role to presentation may avoid this failure by hiding that element's semantics from the user.

Und hier wird (implizit) role=presentation verwendet, d.h. ich kann mich darauf verlassen, dass die Überschrift nicht als solche erkannt wird. Ich kenne auch keinen Screenreader, der eine solche Überschrift erkennt. Sofern er dies macht, wäre dies ein Fehler des Screenreaders. Genau solche Fehler sollen nun mit 9.4.1.1 vermieden werden. Die Frage ist jedoch, ob ähnliche potentielle Screenreader-Fehler, die nicht gleichzeitig einen Syntaxverstoß darstellen, auch als "nicht erfüllt" gewichtet werden.

cstrobbe commented 2 years ago

Weil <button><h1>bla bla</h1></button> zwar einerseits ein Syntaxfehler nach 9.4.1.1 ist,

Ein h1 innerhalb eines button-Elements ist ein Validierungsfehler (ein "semantischer" Fehler); ein Syntaxfehler ist es mitnichten, da das h1-Endtag vor dem button-Endtag kommt. Ein Syntaxfehler ist ohne Verweis auf die Content Models der Elemente zu bewerten. (Siehe "Wellformendness" bei XML, dass als Basis für SC 4.1.1 diente.)

Dass SC 4.1.1 nach 14 Jahren immer noch falsch verstanden wird, kann man als ein Argument benutzen, um es aus WCAG zu entfernen.

Andreas-Englisch commented 2 years ago

@cstrobbe Leider hat sich das W3C WAI meines Wissen noch nicht dazu positioniert, was bei 4.1.1 als Syntaxfehler zu betrachten ist. Ich teile ja Deine Ansicht, aber leider scheint das nicht mehrheitsfähig zu sein. Solange dies in der WCAG nicht klar definiert ist, was "elements are nested according to their specifications" bedeutet, würde ich damit Vorlieb nehmen, zumindest nicht jeden Validierungsfehler als "nicht erfüllt" zu gewichten - siehe dazu insbesondere meine obigen Beispiele.

detlevhfischer commented 2 years ago

@Andreas-Englisch

Ich kenne auch keinen Screenreader, der eine solche Überschrift erkennt. Sofern er dies macht, wäre dies ein Fehler des Screenreaders.

Wie wäre es mit Chrome/NVDA? Beide Rollen werden ausgegeben: http://3needs.org/en/testing/code/test.html .,,und eine Überschrift mit role="presentation" dagegen nicht.

Einfach als Screenreader-Fehler ignorieren sollten wir das bei derart weitverbreiteten UA/AT Kombis nicht. Wo das zu bewerten wäre, ist natürlich eine andere Frage.

detlevhfischer commented 2 years ago

@cstrobbe

Ein Syntaxfehler ist ohne Verweis auf die Content Models der Elemente zu bewerten. (Siehe "Wellformendness" bei XML, dass als Basis für SC 4.1.1 diente.)

Hast Du dazu eine Quelle? Der normative Test von 4.1.1 enthält keine explizite Abgrenzung von syntax und validation errors. Und der Understanding text verweist auf mehrere Sufficient Techniques, die klar validierungsorientiert sind:

Durch den Hinweis "according to specifications" scheint mir impliziert, dass die jeweils im Spec definierten content models schon zu berücksichtigen wären? Wo steht explizit, dass sie zu ignorieren sind?

Mir geht es darum, für 4.1.1 eine handhabbare und relevante Prüfschrittanleitung zu haben, die sich am derzeitigen WCAG SC 4.1.1 orientiert (also auch ein FAIL bei den im normativen Text genannten Fehlern erzwingt) UND Ausnahmen festlegt, wann immer klar ist, dass Code mit Validierungsfehlern KEINE Barrieren irgendwelcher Art erzeugt.

Andreas-Englisch commented 2 years ago

@detlevhfischer

Wie wäre es mit Chrome/NVDA? Beide Rollen werden ausgegeben:

Das ist interessant und scheint neu zu sein. Meines Wissen hat bislang in Chrome und Firefox implizites role=presentation zuverlässig funktioniert. Das ist nicht mehr der Fall. Aber hilft uns das bei 9.4.1.1 weiter?

<button><h2>Überschrift in HTML-Schalter</h2></button> <div role=button><h2>Überschrift in ARIA-Schalter</h2></div>

führt mit NVDA beides Mal zur Ausgabe einer Überschrift, aber nur im ersten Fall zu einem Validierungsfehler. Mit JAWS führt nur das zweite Beispiel zur Ausgabe der Überschrift.

Andreas-Englisch commented 2 years ago

Und der Understanding text verweist auf mehrere Sufficient Techniques, die klar validierungsorientiert sind:

Das stimmt, aber die Techniken gehen oft über die normativen Anforderungen hinaus, was hier eindeutig der Fall ist. Hilfreicher kann ein Blick auf die Fehler-Techniken sein, die sich im Fall 4.1.1 klar an den Wortlaut der WCAG halten und leider nicht erklären, was "elements are nested according to their specifications" bedeutet.

detlevhfischer commented 2 years ago

@Andreas-Englisch Übrigens werden nicht nur in Chrome/NVDA, sondern auch bei Nutzung von Edge/Sprachausgabe beide Rollen (Schalter und Überschrift) ausgegeben. Ob sich das Verhalten kürzlich geändert hat, weiß ich nicht.

cstrobbe commented 2 years ago

Ein Syntaxfehler ist ohne Verweis auf die Content Models der Elemente zu bewerten. (Siehe "Wellformendness" bei XML, dass als Basis für SC 4.1.1 diente.)

Hast Du dazu eine Quelle? Der normative Test von 4.1.1 enthält keine explizite Abgrenzung von syntax und validation errors. Und der Understanding text verweist auf mehrere Sufficient Techniques, die klar validierungsorientiert sind:

  1. Ich war dabei als das Erfolgskriterium geschrieben wurde.
  2. Im Vergleich zu WCAG 1.0 Checkpoint 3.2, das Validierung forderte, wurde SC 4.1.1 deutlich abgeschwächt; daher heißt das Erfolgskriterium auch "Parsing" statt "Validating".
  3. Die Validierung in Techniques G134, G192 und H88 (zu denen ich auch beigetragen habe) kommt daher, dass es außerhalb von XML-basierten Sprachen unmöglich ist, die Syntax zu prüfen ohne einen Validator zu benutzen. (Im Prinzip wäre das beim SGML-basierten HTML 4 noch möglich gewesen, allerdings waren mir damals keine Tools bekannt, die eine Prüfung gegen die SGML Declaration of HTML 4 unterstützten.) HTML 5 basiert weder auf XML noch auf SGML und verhakt Syntax und Semantik auf einer Weise, die eine Prüfung der Syntax ohne Validierung unmöglich macht.
Andreas-Englisch commented 2 years ago

@cstrobbe Für mich klingen Deine Ausführungen plausibel. Problem ist jedoch, dass dies in den WCAG-Gremien derzeit (kaum) niemand mehr zu wissen scheint (https://github.com/w3c/wcag/issues/978#issuecomment-562622970). Deswegen würde ich Dich bitten, zu prüfen: Gibt es außer dem "Ich war dabei" Belege für Deine Interpretation, z.B. interne Beschlüsse in Protokollen aus der Zeit, als die WCAG 2.0 entwickelt wurde?

Falls nicht: @detlevhfischer - vielleicht könntest Du bei einem der nächsten WCAG-Meetings darum bitten, dass Dein Ticket geklärt wird?

Und wenn das alles nichts hilft, wäre ich dafür, Variante 1 oder 2 für den BIK BITV-Test in Erwägung zu ziehen.

cstrobbe commented 2 years ago

Deswegen würde ich Dich bitten, zu prüfen: Gibt es außer dem "Ich war dabei" Belege für Deine Interpretation, z.B. interne Beschlüsse in Protokollen aus der Zeit, als die WCAG 2.0 entwickelt wurde?

Ich habe dasjenige, was ich heute noch dazu finden konnte, unter What does nested according to the specification mean in SC 4.1.1 #978 zusammengefasst.

Andreas-Englisch commented 2 years ago

@detlevhfischer und @cstrobbe Vielen Dank für Eure Bemühungen! Bin gespannt, ob eine Klärung herbeigeführt werden kann.

johannesFischer84 commented 2 years ago

<button><div>1</div></button> - ein Schalter hat implizites role=presentation, somit hat das div keine Rolle und ist für Accessibility API nicht vorhanden.

@Andreas-Englisch Andreas, inwiefern hat ein Schalter implizites role=presentation? Wenn ich in die Spezifikation ARIA in HTML beim button-Element nachsehe, ist dort role=button genannt, nicht role=presentation.

Gar kein FAIL / "nicht konform" von 4.1.1 halte ich nicht für sinnvoll. Denn, so wie ich es verstehe, gibt es Fehler, die wirkliche Probleme verursachen können, unter anderem doppelte <id>-Werte.

Andreas-Englisch commented 2 years ago

@johannesFischer84 Ein Schalter selbst hat die Rolle button, aber alle Nachfahren-Elemente haben implizit role=presentation. Das steht so in der ARIA-Spezifikation: https://www.w3.org/TR/wai-aria-1.2/#childrenArePresentational und hat bislang auch gut funktioniert. Im Zuge der Diskussionen um die vielen role=presentation-Ausnahmen (https://www.w3.org/TR/wai-aria-1.2/#presentation) und der details-summary-Problematik (https://github.com/FreedomScientific/VFO-standards-support/issues/105) wurde dies aber wohl aufgeweicht. Inzwischen ist es so, dass NVDA häufig, aber nicht immer implizites role=presentation ignoriert, hingegen JAWS es meist, aber nicht immer befolgt.

Andreas-Englisch commented 2 years ago

@johannesFischer84

Gar kein FAIL / "nicht konform" von 4.1.1 halte ich nicht für sinnvoll. Denn, so wie ich es verstehe, gibt es Fehler, die wirkliche Probleme verursachen können, unter anderem doppelte id-Werte.

Dann wäre mein Vorschlag:

cstrobbe commented 2 years ago

<button><div>1</div></button> - ein Schalter hat implizites role=presentation, somit hat das div keine Rolle und ist für Accessibility API nicht vorhanden.

Warum versucht man diesen Code unter 9.4.1.1 zu bewerten? Die Verschachtelung ist syntaktisch korrekt; valider Code ist unter 9.4.1.1 nicht erforderlich. Aufgrund des Arguments das "das div keine Rolle [hat] und für Accessibility API nicht vorhanden [ist]", müsste man doch eher 9.4.1.2 (Name, Role, Value) oder 9.1.3.1 (Info and Relationships) in Betracht ziehen?

Andreas-Englisch commented 2 years ago

@cstrobbe

Warum versucht man diesen Code unter 9.4.1.1 zu bewerten?

Weil gemäß Prüfanleitung unter https://webtest.bitv-test.de/index.php?a=di&iid=294&s=n das ein Verstoß gegen 9.4.1.1 ist und dieser kleine Nicht-Fehler ausreicht, um im BIK BITV-Test zu sagen, eine Anwendung sei nicht konform zur BITV. Darum geht es mir hier ja: Etwas ist entweder gar kein Verstoß gegen WCAG 4.1.1 (Deine Meinung) oder kein relevanter Verstoß gegen WCAG 4.1.1 (meine Meinung, solange sich Deine nicht durchgesetzt hat) und trotzdem muss nach dem Prüfverfahren die Anwendung so bewertet werden. Und das scheint bei anderen Prüfverfahren in anderen Ländern ähnlich zu sein, denn es ist ein A-Kriterium und einfach (ggf. sogar automatisiert) zu testen und scheinbar ohne Interpretationsspielraum.

cstrobbe commented 2 years ago

Weil gemäß Prüfanleitung unter https://webtest.bitv-test.de/index.php?a=di&iid=294&s=n das ein Verstoß gegen 9.4.1.1 ist

Ausgerechnet ein Prüfschritt mit dem Namen Korrekte Syntax. <button><div>1</div></button> ist kein Syntaxfehler. Wenn man diesen Code im BIK-BITV-Test als Verstoß wertet, geht man über SC 4.1.1 hinaus.

Andreas-Englisch commented 2 years ago

@cstrobbe

Der Passus "Elemente sind gemäß Spezifikation korrekt verschachtelt" kann halt unterschiedlich ausgelegt werden. In allen Testverfahren, die ich kenne, wird er so ausgelegt wie bei BIK BITV:

Bei dieser Methode ist <button><div>1</div></button> ein Fehler und damit die Seite automatisch nicht konform, egal ob alles andere perfekt ist.

cstrobbe commented 2 years ago

Da das Parsing-Bookmarklet bei manchen Arten von Problemen auch über SC 4.1.1 hinausgeht, kann man sich aktuell nicht völlig darauf verlassen. Steve Faulkner interpretiert SC 4.1.1 strenger als eine Prüfung von Syntaxfehlern.

Andreas-Englisch commented 2 years ago

@cstrobbe Meines Erachtens kann von den Fehlern, die bei 4.1.1 genannt werden, nur die doppelte ID bei der Validierung des DOM gefunden werden, da alle anderen Fehler automatisch vom Browser repariert werden, d.h. sie können nur im Quellcode, aber nie im DOM vorkommen. Dies gilt zumindest, wenn "Elemente sind gemäß Spezifikation korrekt verschachtelt" so verstanden wird, wie Du es vorschlägst. Deswegen ist "nicht völlig darauf verlassen" euphemistisch formuliert, da das Parsing Bookmarklet viele Fehler anzeigt, die keine sind.

MarcHaunschild commented 2 years ago

@johannesFischer84 Ein Schalter selbst hat die Rolle button, aber alle Nachfahren-Elemente haben implizit role=presentation. Das steht so in der ARIA-Spezifikation: https://www.w3.org/TR/wai-aria-1.2/#childrenArePresentational und hat bislang auch gut funktioniert. Im Zuge der Diskussionen um die vielen role=presentation-Ausnahmen (https://www.w3.org/TR/wai-aria-1.2/#presentation) und der details-summary-Problematik (FreedomScientific/VFO-standards-support#105) wurde dies aber wohl aufgeweicht. Inzwischen ist es so, dass NVDA häufig, aber nicht immer implizites role=presentation ignoriert, hingegen JAWS es meist, aber nicht immer befolgt.

Sehr schön dargelegt, warum syntaktisch korrekter, aber invalider Code ein Problem ist. Ja die Probleme werden von den Browsern ziemlich gut gefixt. Das Ergebnis findet sich im DOM, darauf setzt der Accessibility Tree auf, demnächst das AOM und dann kommt der eigentliche Screenreader, der den anderen Entwicklungen hinterherläuft.

Keine Ahnung, warum man glauben kann, das lässt sich beliebig skalieren.

Code sollte valide sein.

MarcHaunschild commented 2 years ago

@cstrobbe

Der Passus "Elemente sind gemäß Spezifikation korrekt verschachtelt" kann halt unterschiedlich ausgelegt werden. In allen Testverfahren, die ich kenne, wird er so ausgelegt wie bei BIK BITV:

Bei dieser Methode ist <button><div>1</div></button> ein Fehler und damit die Seite automatisch nicht konform, egal ob alles andere perfekt ist.

Und das ist auch gar kein Problem. Das div zu entfernen ist eine Sache von Sekunden.

detlevhfischer commented 2 years ago

Wenn klar ist, dass bestimmte Umsetzungen, die jetzt errors generieren, kein Barrierefreiheitsproblem darstellen (etwa div innerhalb von button ), wäre ich schon dafür, diese auszunehmen. Die Frage dabei ist nur, wie man die mögliche Komplexität einer Nachprüfung von gefilterten Validierungsrergebnissen handhabbar macht, ohne ggf. riesigen Zeitaufwand. Es gibt eine große Anzahl von nesting-Kombinationen und unterschiedliche Ausgaben in Screenreadern, wie oben beschrieben (der eine gibt die Rolle aus, der andere nicht). Es ist auch nicht so einfach mögliche Probleme bei der Prüfung in anderen Prüfschritten zu erfassen (z.B. zeigt das gen genutzte headings plugin auch Überschriften innerhalb von button an - siehe Anwendung auf http://3needs.org/en/testing/code/test.html ). Zwei praktische Fragen ergebne sich daraus:

  1. Ist es denkbar, das validate Bookmarklet aufzubohren und ein bookmarklet zu schreiben, dass noch mehr unproblematische Fälle rausfiltert ( @Andreas-Englisch ? ) oder ist es sowieso unmöglich, alle Nesting-Permutationen sinnvoll zu erfassen?
  2. Ist es für Prüfende handhabbar, wie @johannesFischer84 vorschlägt, nach Anwendung des Validate bookmarklets die Errors durchzugehen und zu gucken, ob alle auf Situationen zurückgehen, wo die Syntax stimmt, aber die Validierung (wegen der entsprechenden content models) einen Fehler ergibt? So dass nur doppelte ids übrigbleiben und ggf. nach Laden der Seite dynamisch generierte Inhalte mit Syntaxfehlern)?
cstrobbe commented 2 years ago

@detlevhfischer Ich hätte das Bookmarklet schon längst angepasst, wenn es eine Open Source-LIzenz gehabt hätte. Aktuell ist es streng genommen urheberrechtlich geschützt.

detlevhfischer commented 2 years ago

@cstrobbe Kann man dazu nicht Steve Faulkner konkret ansprechen?

cstrobbe commented 2 years ago

@detlevhfischer Done.

Update: Das Bookmarklet ist jetzt unter einer GNU GPL 2.0-Lizenz verfügbar.

Andreas-Englisch commented 2 years ago

@detlevhfischer Ich denke nicht, dass das Parsing-Bookmarklet so angepasst werden sollte, dass WCAG-relevante Fehler rausgefiltert werden. Darum ging es mir nicht. Es gibt nun mal WCAG 4.1.1 und ob es uns gefällt oder nicht: Das ist der Rahmen, an den wir uns halten müssen. Mir ging es zwei andere Dinge:

Falls @cstrobbe nicht recht hat, wäre es sicherlich sinnvoll, das Parsing-Bookmarklet dahingehend zu verbessern, dass der sowieso vorhandene Fehler bezüglich der Custom Attribute entfernt wird. Dafür gibt es schon ein Issue: https://github.com/stevefaulkner/wcagparsing/issues/6.

Ich bitte zu prüfen, ob eine Gewichtung über "Ja" und "Nein" hinaus für sinnvoll erachtet wird.

cstrobbe commented 2 years ago

Eine Klärung der Frage, was mit "Elemente sind gemäß Spezifikation korrekt verschachtelt" gemeint ist. Wenn @cstrobbe recht hat, wäre einfach https://parsetree.validator.nu/ zu verwenden.

https://parsetree.validator.nu/ scheint ein geeigneteres Tool zu sein als der Validator. Allerdings wird der folgende Code immer noch als Syntaxfehler statt eines Validierungsfehlers betrachtet, obwohl der Code syntaktisch nicht falsch ist:

<a href="https://www.w3.org/">
  <a href="https://www.w3.org/WAI/"><abbr>WAI</abbr></a>
</a>

Fehlermeldung:

Start tag “a” seen but an element of the same type was already open.

Das ist eindeutig das Ergebnis der Prüfung eines Content Models und nicht einer reinen Syntaxprüfung.

Ich habe übrigens eine Umformulierung von SC 4.1.1 vorgeschlagen.

@MarcHaunschild

Sehr schön dargelegt, warum syntaktisch korrekter, aber invalider Code ein Problem ist. (...)
Code sollte valide sein.

Es war nie meine Absicht, invaliden Code zu verteidigen, sondern die korrekte Bedeutung von SC 4.1.1 klarzustellen. Manchmal frage ich mich in diesen Diskussionen, ob man den Unterschied versteht zwischen "SC 4.1.1. bedeutet X" und "invalider Code ist okay".

MarcHaunschild commented 2 years ago

@MarcHaunschild

Sehr schön dargelegt, warum syntaktisch korrekter, aber invalider Code ein Problem ist. (...) Code sollte valide sein.

Es war nie meine Absicht, invaliden Code zu verteidigen, sondern die korrekte Bedeutung von SC 4.1.1 klarzustellen. Manchmal frage ich mich in diesen Diskussionen, ob man den Unterschied versteht zwischen "SC 4.1.1. bedeutet X" und "invalider Code ist okay".

Ja, den versteht man. so kompliziert ist das nicht. Es war etwas off-topic, keine Kritik an dir, eher am Status quo der Webentwicklung. Bin gespannt auf die weitere Entwicklung. Vermutlich wird dem mit AI und noch mehr rechen- und ressourcenintensivem Aufwand begegnet. Sauberen Code zu schreiben scheint längst keine Option mehr (auch dafür könnte man AI einsetzen, statt für nachträgliche Reparaturen). Aber wie gesagt: anderes Thema.

Andreas-Englisch commented 2 years ago

@cstrobbe

Allerdings wird der folgende Code immer noch als Syntaxfehler statt eines Validierungsfehlers betrachtet, obwohl der Code syntaktisch nicht falsch ist:

Das sind allerdings Fehler, die vom Browser automatisch repariert werden, d.h. sie tauchen im DOM nicht auf (meines Erachtens betrifft dies ja alle Fehler, die die WCAG bei 4.1.1 benennt - bis auf doppelte IDs). Da im BIK BITV-Test nicht der Quellcode, sondern das DOM getestet wird, stellt dies somit kein Problem dar. Im DOM werden aus den zwei verschachtelten Links einfach zwei Links, die nacheinander stehen (Geschwisterelemente). Die DOM-Syntaxprüfung Deiner Datei ergibt keine Fehler.

cstrobbe commented 2 years ago

Ich habe Steve Faulkners Bookmarklet angepasst. Vorläufig ist es auf dieser Seite über das Erfolgskriterium verfügbar. Ich kümmere mich später um eine Seite speziell für das Bookmarklet.