-
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
9.4.1.1 - Definition Custom-Attribut: Syntaxfehler vs, Validierungsfehler #99
Comments
Ich verstehe nicht, warum ein Validierungsfehler in Bezug auf falsche Verwendung von HTML-Elementen oder -Attributen konform sein sollte. Im WCAG-Kriterium 4.1.1 steht unter anderem:
Dies sagt für mich klar aus, dass ich z. B. ein Zwar ist die Technik nicht normativ, aber mir scheint es keine alternative Möglichkeit zu geben, die Forderung des Erfolgskriteriums anders zu erfüllen. Für das Bei Elementen und Attributen, die nicht der jeweiligen Spezifikation wie HTML oder SVG entsprechen, also den Custom-Attributen würde ich auch nicht auf Fehler entscheiden, denn da kann es zumindest keine Kollision mit aus dem Standard Bekanntem und zugehörigen Regeln geben. Eine Sammlung wäre tatsächlich hilfreich. Bei Elementen, die nicht aus dem HTML-Standard kommen, war ich mir zuletzt auch unsicher, was man damit macht. Da müsste im |
Meiner Meinung sollte man noch einen anderen Aspekt berücksichtigen: Falsches HTML ist falsches HTML. Was die hierfür verwendeten Tools zurück geben ist eindeutig. Ich würde bei so was (gerade wenn die Fehlerliste mal lang wird) es bei dieser Einfachheit lassen. |
Ich war Mitglied der WCAG-WG als WCAG 2.0 geschrieben wurde und habe meine Sicht auf SC 4.1.1 unter Understanding and Testing WCAG 2.1 Success Criterion 4.1.1 dokumentiert. Custom Attributes sind eindeutig keine Verstöße gegen SC 4.1.1. Ein Element wie Die Bedingung "elements are nested according to their specifications" ist durch XML-Wellformedness inspiriert, nicht durch (XML-)Validity. Das Beispiel Die Technique H88: Using HTML according to spec ist strenger als SC 4.1.1, weil es auch bei HTML 4.1 keinen einfach zu überprüfenden Unterschied zwischen Syntax und Validierung (d.h. DTD) gab; man müsste schon verstehen was eine SGML Declaration ist, um überhaupt über gültigen Syntax sprechen zu können. Was Elemente, die nicht aus dem HTML-Standard kommen, betrifft: Als HTML5 XML verworfen hat, hat es eigentlich auch Namespaces zu Grabe getragen. Wer Namespaces benutzen will, ohne vom Validator gerügt zu werden, muss eigentlich XHTML 1.x benutzen, d.h. eine veraltete Spezifikation. (Und wenn man WAI-ARIA-Attribute in XHTML 1.0 benutzen will, meckert der Validator über die WAI-ARIA-Attribute, auch wenn man eine Namespace Declaration im |
Inwiefern sagt das WCAG-Kriterium 4.1.1 denn aus, dass man nur im Hinblick auf XML-Formung prüfen müsste? Für mich ist das nicht klar. Zwar steht in der NOTE des Understanding-Dokuments, dass "well-formed" nah dran am Ziel des Erfolgskriteriums ist, aber valides HTML nicht "well-formed code" benötigt. Das kommt mir dann doch so vor, dass man sich an der HTML-Spezifikation orientieren sollte.
Wie kommt denn der Browser mit der Interpretation zurecht, wenn keine Namespaces zur Verfügung stehen? "Errät" er quasi, zu welchem Standard ein HTML-fremdes Element gehört? Das muss doch aber auch fehlerbehaftet sein, oder? Ist mir nicht ganz klar. |
Hallo @cstrobbe, Dein Beitrag ist eine echte Überraschung für mich, da ich so eine feine Unterscheidung zwischen falscher Syntax und unvalidem HTML trotz korrekter Syntax aufgrund eines Verstoßes gegen die DTD in diesem Prüfschritt nie vermutet habe. Nun warst du ja an der WCAG beteiligt und wirst wissen, was gemeint war. Ich war der Meinung, dass man als Verstoß gegen diesen Prüfschritt schlicht jeden Fehler aus dem Validator bezeichnet. Auch wenn es Syntaxfehler sind. Deshalb war ich schon über vermeintliche Spitzfindigkeit diese Diskussion generell verwundert. Jetzt verstehe ich den Gedankengang dahinter. Für das resultierende DOM, den Accessibility tree und die Software, die daraus etwas machen muss, ist es aber doch unerheblich, wie die Fehler benannt werden, die gleichwertigen Zugang für alle zu den Inhalten verhindern?!? |
Das steht tatsächlich nicht im Erfolgskriterium, weil WCAG auch funktionieren muss für Markupsprachen, die nicht auf XML basieren. Deswegen hat man einige wichtige Merkmale von XML-Wellformedness direkt in dem Kriterium aufgenommen.
Wellformedness (d.h. korrekte Syntax) ist eine niedrigere Schwelle als Validität (welche Elemente, Attribute und Attribut-Werte bzw. -Datentypen erlaubt sind, usw.). Aus der Sicht von XML gibt es keine Validität ohne Wellformedness. Erfolgskriterium 4.1.1 erfordert keine Validität sondern im Prinzip "Wellformedness" (wenn das in HTML 5 überhaupt ein Konzept wäre, das unabhängig von Validität definiert wäre) plus die Bedingung, das die gleichen ID-Werte nur einmal im Dokument vorkommen.
Der Abschnitt Namespaces in HTML 5.2 listet einige "bekannten" Namespaces auf und fügt hinzu:
Elemente und Attribute, die ohne Namespace-Prefix in einem HTML5-Dokument benutzt werden, landen eigentlich im HTML-Namespace und sind dann nicht-valide (und laut HTML 5.2 nicht konform), auch wenn die daraus resultierende Syntax korrekt ist. HTML 5.2 macht lediglich eine Ausnahme für Attribute in der Form Die HTML5-Spezifikation beschreibt nicht, was Browser Elemente und Attribute interpretieren sollten, die nicht in der Spezfikation definiert sind (außer Bemerkungen zu SVG, MathML und WAI-ARIA); das ist meines Wissens den Browsern überlassen. |
Vielen Dank für die Erklärungen, Herr Strobbe. Ich habe mir mal ein Test-HTML-Dokument mit unbekanntem Element erstellt. Tatsächlich stellen es Browser wie einfachen Text dar, mit CSS lässt es sich auch separat gestalten. Die Semantik geht ggf. verloren, aber das wäre dann ein Fehler nach Kriterium 1.3.1. In diesem Sinn wäre Bei
Das heißt für mich: Da die Syntax korrekt ist, könnte man Custom-Attribute bzw. in HTML unbekannte Attribute als konform werten. |
Das sind Probleme, die man bei einem Audit unter "eher erfüllt" in einem Kommentar erwähnen kann, aber keine Verstöße gegen SC 4.1.1.
Ja, konform zum WCAG-Kriterium, obwohl solche Attribute nicht konform zu HTML 5 sind.
Wenn die Syntaxfehler oder die Validierungsfehler tatsächlich einen gleichwertigen Zugang zu den Inhalten verhindern, stellen sie in der Regel schon einen Verstoß gegen ein anderes Erfolgskriterium dar. ("In der Regel", d.h. wenn man Lücken in WCAG außer Betracht lässt.) Viele reine Syntaxfehler verhindern den gleichwertigen Zugang nicht, weil Browser schon lange über Mechanismen verfügen, um mit solchen Fehlern umzugehen. (Die strenge Syntaxprüfung, die von XML-Wellformedness erfordert wird—"Violations of well-formedness constraints are fatal errors."—hat sich in HTML5 nicht durchgesetzt.) Was man mit SC 4.1.1 erreicht sind die zwei folgenden Ziele:
Andere Probleme sollten durch andere Erfolgskriterien abgedeckt werden. SC 4.1.1 ist weder als Verlegenheitslösung für Lücken in anderen Kriterien gedacht, noch als Kriterium, das durch die Hintertür die Validierung von erlaubten Elementen und Attributen erfordert. |
Wird das tatsächlich so gesehen? - Was ist, wenn ein Hersteller mit einer Neuentwicklung um die Ecke kommt und sich (meiner Meinung nach sinnvollerweise) zunächst einmal um eine vollständige Implementierung der Standards kümmert und den Umgang mit fehlerhaftem HTML erst in späteren Versionen nachliefert? - Wäre dann, wenn es solch einen Browser gibt, dieser Prüfschritt nicht bestanden? |
Es kam aus dem Kontext einer Qualitätssicherung der Vorschlag, zwischen Validierungs- und Syntaxfehler zu unterscheiden.
Danach wäre z.B.
<span><h6>...</h6></span>
ist ein Validierungsfehler, aber kein Syntaxfehler im Sinne von SC 4.1.1.<span><h6>...</span></h6>
wäre dagegen eindeutig ein Syntaxfehler.Zur Zeit werden nach Anwendung der Bookmarklets "Check serialized DOM of current page" gefolgt von dem "Validate" Bookmarklet Fehler angezeigt, die nach obiger Interpretation kein Syntaxfehler wären und deshalb bei Prüfschirtt 4.1.1 nicht zu einem "nicht erfüllt" führen würden.
Ein Bespiel war auch die Nutzung von HTML_Attributen auf dafür nicht vorgesehenen Elementen, z.B.
<span href="../seite.html">
Der Validator sagt dazu: "Attribute href not allowed on element span at this point.”
Ein Argument lautet: dies ist kein Syntaxfehler,
href
ist hier ein Custom-Attribut. Prüfschritt 4.1.1a wäre "erfüllt".Ein Gegenargument lautet:
href
ist aufspan
nicht zugelassen, es gehört zuma
Element (und zuarea
). Prüfschritt 4.1.1a wäre "nicht erfüllt".Der Wunsch wurde geäußert, in der Prüfschrittbeschreibung den Begriff "Custom-Attribut" genauer zu definieren. Dies würde helfen zu entscheiden, welche Fehler, die nach dem Validate-Bookmarklet noch angezeigt werden,ignoriert werden können.
The text was updated successfully, but these errors were encountered: