9.4.1.1 - Definition Custom-Attribut: Syntaxfehler vs, Validierungsfehler

[detlevhfischer]

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 auf span nicht zugelassen, es gehört zum a Element (und zu area). 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.

[johannesFischer84]

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:

elements are nested according to their specifications

Dies sagt für mich klar aus, dass ich z. B. ein h6-Element nicht in ein span-Element schachteln darf, weil h6 nicht dem für span geforderten phrasing content im content model entspricht. Zudem gibt es die WCAG-Technik H88, wo gefordert wird, dass HTML entsprechend seiner Spezifikation genutzt werden.

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 href-Attribut würde sich für der gleiche Fall ergeben.

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 html-Wurzelelement wahrscheinlich der Namespace angegeben sein, oder?

[MarcHaunschild]

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. Mancher Prüfer wird damit überfordert sein. Ich selber verstehe zwar, was gemeint ist in dem Beispiel, habe so eine. Unterscheidung in der Praxis noch nie gesehen. Gibt es die denn irgendwo in der Literatur? Ich höre davon zum ersten Mal. Syntaxfehler und falsche Verschachtelung sind beide nicht valide. Was UAs aus falschem Code machen (werden), ist nicht sicher. Der eine mag ein Span mit href verlinken, ein anderer nicht und auch ein Mensch wird oft nicht entscheiden können, was da eigentlich beabsichtigt war. Gerade so ein uneinheitliches Verhalten ist ja nicht erwünscht. Nutzer von grafischen Browsern und AT sollen ein vergleichbares Nutzererlebnis haben. Das ist bei fehlerhaftem HTML nicht sichergestellt. Die Diskussionen ob etwas Syntax- oder Validierungsfehler ist, möchte ich nicht führen müssen - meines Wissens nach es gibt auch keine solche Unterscheidung.

[cstrobbe]

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 <span href="../seite.html" verstößt schon gegen SC 2.1.1 und eventuell SC 4.1.2, deswegen ist es nicht einmal notwendig SC 4.1.1 auszuweiten, um dieses Element als Verstoß bewerten zu können.

Die Bedingung "elements are nested according to their specifications" ist durch XML-Wellformedness inspiriert, nicht durch (XML-)Validity. Das Beispiel <span><h6>...</h6></span> ist aus der Sicht von XML-Wellformedness überhaupt kein Syntaxfehler. Allerdings basiert HTML5 basiert nicht auf XML, deshalb definiert es keinen klaren Unterschied zwischen Syntax und Validierung, und dies führt dazu, dass es so schwierig ist reine Syntaxfehler von Validierungsfehlern zu unterscheiden.

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 html-Starttag hat.)

[johannesFischer84]

@cstrobbe

Die Bedingung "elements are nested according to their specifications" ist durch XML-Wellformedness inspiriert, nicht durch (XML-)Validity. Das Beispiel

...

ist aus der Sicht von XML-Wellformedness überhaupt kein Syntaxfehler. Allerdings basiert HTML5 basiert nicht auf XML, deshalb definiert es keinen klaren Unterschied zwischen Syntax und Validierung, und dies führt dazu, dass es so schwierig ist reine Syntaxfehler von Validierungsfehlern zu unterscheiden.

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.

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 html-Starttag hat.)

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.

[MarcHaunschild]

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?!?

[cstrobbe]

@johannesFischer84

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.

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.

(...) aber valides HTML nicht "well-formed code" benötigt.

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.

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.

Der Abschnitt Namespaces in HTML 5.2 listet einige "bekannten" Namespaces auf und fügt hinzu:

In the HTML syntax, namespace prefixes and namespace declarations do not have the same effect as in XML. For instance, the colon has no special meaning in HTML element names.

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 x-vendor-feature; die Spezifikation sagt aber nicht, dass solche Attribute (in der HTML-Syntax von HTML 5) außerhalb des HTML-Namespaces stehen.

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. (Die Beschreibung des Parse-Prozesses macht keinen Unterschied zwischen validen und nicht-validen Elementen bzw. Attributen; die landen also einfach alle im DOM.) In der Praxis heißt das, dass solche Elemente und Attribute nicht interpretiert werden (außer bei Browsern, die sie gerade als Erweiterungen implementiert haben, siehe z.B. Web Components).

[johannesFischer84]

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 <span><h6>...</h6></span> tatsächlich kein Fehler nach 4.1.1, <span><h6>...</span></h6> wäre dagegen fehlerhaft zu werten.

Bei <span href="../seite.html"> bin ich mir unsicher. Zwar kann man das falsch verwendete Attribut tatsächlich unter 2.1.1 oder 4.1.2 als fehlerhaft bewerten, aber was ist, wenn ich ein alt-Attribut oder ein type-Attribut (normal bei input verwendet) falsch verwende? Sollte man so etwas unter 1.3.1 oder ggf. 1.1.1 fehlerhaft werten? Ich wäre da schon dafür, auch 4.1.1 als nicht konform zu werten.

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.

Das heißt für mich: Da die Syntax korrekt ist, könnte man Custom-Attribute bzw. in HTML unbekannte Attribute als konform werten.

[cstrobbe]

@johannesFischer84

<span href="../seite.html">nächste Seite</span> ergibt keinen funktionierende Link sondern ganz normalen Text. Personen mit Behinderungen sind hier im Vergleich mit anderen Nutzern nicht benachteiligt.

<span type="submit">Absenden</span> ergibt keinen funktionierenden Button sondern ganz normalen Text. Auch hier sind Personen mit Behinderungen hier im Vergleich mit anderen Nutzern nicht benachteiligt.

<input type="reset" alt="Clear the form" value="Reset" />: Hier wird das alt-Attribut meines Wissens ignoriert (siehe diese Testseite; die Kombination Firefox + NVDA ignoriert das alt-Attribut).

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.

Das heißt für mich: Da die Syntax korrekt ist, könnte man Custom-Attribute bzw. in HTML unbekannte Attribute als konform werten.

Ja, konform zum WCAG-Kriterium, obwohl solche Attribute nicht konform zu HTML 5 sind.

@MarcHaunschild

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?!?

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:

• Korrekte Syntax hilft dem Browser, einen eindeutigen DOM-Tree aufzubauen. (Custom Elemente und Attibute verhindern dies meines Wissens nicht.)
• Eindeutige ID-Werte helfen Browser und technischen Hilfsmitteln, Labels korrekt mit Bedienelementen zu verknüpfen, Tabellenzellen mit Überschriften, usw. damit Beschriftungen eindeutig zugewiesen werden können.

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.

[MarcHaunschild]

@cstrobbe

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.)

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? Ich habe mit solchen Dingen ein Problem, die sich situativ, nach persönlichem Empfinden oder warum auch immer unterschiedlich zu bewerten sind. Es macht dann auch eigentlich Standards überflüssig in der Bewertung. Aber du musst hier nicht drauf antworten (auch wenn mich das freut), denn mein persönliches Problem ist ebenfalls nicht als objektives Kriterium geeignet, den Test anzupassen. Ich möchte es nur als Aspekt in die Diskussion miteinander einbringen.