-
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
Bewertung von 9.4.1.1 #269
Comments
@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 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 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. |
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 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. |
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). |
@Andreas-Englisch |
Das sehe ich anders, weil in F43 steht:
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. |
Ein 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. |
@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. |
Wie wäre es mit Chrome/NVDA? Beide Rollen werden ausgegeben: 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. |
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. |
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?
führt mit NVDA beides Mal zur Ausgabe einer Überschrift, aber nur im ersten Fall zu einem Validierungsfehler. |
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. |
@Andreas-Englisch |
|
@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 (w3c/wcag#978 (comment)). 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. |
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. |
@detlevhfischer und @cstrobbe Vielen Dank für Eure Bemühungen! Bin gespannt, ob eine Klärung herbeigeführt werden kann. |
@Andreas-Englisch Andreas, inwiefern hat ein Schalter implizites role=presentation? Wenn ich in die Spezifikation ARIA in HTML beim button-Element nachsehe, ist dort 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 |
@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/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. |
Dann wäre mein Vorschlag:
|
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.
|
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. |
Ausgerechnet ein Prüfschritt mit dem Namen Korrekte Syntax. |
Der Passus "Elemente sind gemäß Spezifikation korrekt verschachtelt" kann halt unterschiedlich ausgelegt werden.
Bei dieser Methode ist |
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. |
@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. |
Sehr schön dargelegt, warum syntaktisch korrekter, aber invalider Code ein Problem ist. Keine Ahnung, warum man glauben kann, das lässt sich beliebig skalieren. Code sollte valide sein. |
Und das ist auch gar kein Problem. Das div zu entfernen ist eine Sache von Sekunden. |
Wenn klar ist, dass bestimmte Umsetzungen, die jetzt errors generieren, kein Barrierefreiheitsproblem darstellen (etwa
|
@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. |
@cstrobbe Kann man dazu nicht Steve Faulkner konkret ansprechen? |
Update: Das Bookmarklet ist jetzt unter einer GNU GPL 2.0-Lizenz verfügbar. |
@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: stevefaulkner/wcagparsing#6. Ich bitte zu prüfen, ob eine Gewichtung über "Ja" und "Nein" hinaus für sinnvoll erachtet wird. |
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:
Fehlermeldung:
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.
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. |
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. |
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. |
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.
<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:
The text was updated successfully, but these errors were encountered: