Das Prüfverfahren zur BITV


Sie sind hier: BITV-Test > Liste der Erfolgskriterien > Prüfkriterium 4.1.1a (48 von 49)


zum WCAG-Test wechseln


Blättern: zum ersten Prüfschritt zum vorhergehenden Prüfschritt zum nächsten Prüfschritt zum letzten Prüfschritt

Prüfschritt 4.1.1a
Valides HTML

Diese Version des Prüfschritts ist nicht mehr gültig!

Technische Angaben

Version bis 10.07.2017 | Aktuell
BITV-Bedingung 4.1.1 Syntaxanalyse
WCAG-Erfolgskriterium 3.2.1 Valides HTML
Bewertungsalternativen ja / nein
Gewichtung mittleres Gewicht (2 Punkte)
Bezieht sich auf einzelne Webseite
Prüfschritt erfüllt Das Prüfergebnis des W3C-HTML-Validators ist positiv.

Was wird geprüft?

Die verwendete Markup-Sprache HTML muss korrekt eingesetzt werden.

Warum wird das geprüft?

Eine saubere HTML-Syntax vereinfacht Browsern oder Screenreadern den Umgang mit der Seite.

Wie wird geprüft?

1. Anwendbarkeit des Prüfschritts:

Der Prüfschritt ist immer anwendbar.

2. Prüfung mit dem W3C-Validator

  1. Die URL der zu prüfenden Seite im W3C-Validator eingeben.
  2. Wenn die Seite nicht validiert, Fehlerliste durchsehen, ob Fehler auftreten, die nicht auf den Einsatz von WAI ARIA-Rollen, Zuständen und Eigenschaften zurückzuführen sind.

3. Hinweise

  • Wenn die Prüfung aufgrund einer fehlenden doctype-Definition nicht ausgeführt werden kann, dann validiert die Seite nicht, der Prüfschritt ist dann nicht bestanden. Der doctype soll nicht manuell eingetragen werden!
  • Der W3C-Validator interpretiert den Einsatz von WAI-ARIA (Accessible Rich Internet Applications) Rollen, Zuständen und Eigenschaften als Fehler. Das betrifft z.B. WAI-ARIA Landmark Roles wie role="navigation". Diese Elemente verbessern die Zugänglichkeit, ihre Verwendung wird deshalb nicht negativ bewertet. Wenn Fehler bei der Validierung nur durch den (korrekten) Einsatz von WAI-ARIA (siehe die aktuelle WAI-ARIA Spezifikation beim W3C) entstehen, gilt der Prüfschritt als erfüllt.
  • CSS wir in diesem Prüfschritt nicht validiert, da nicht valides CCS (CSS-Hacks) häufig genutzt wird, um die Rückwärtskompatibilität und korrekte Darstellung von Seiten in älteren Browsern wie Internet Explorer 6 sicherzustellen.
  • In diesem Prüfschritt wird nicht das vom Browser nach Auswertung von Scripten generierte HTML geprüft (siehe dazu unten die Frage zur Prüfung von geparstem Quelltext.)

4. Bewertung

Erfüllt:

  • Das Prüfergebnis des W3C-HTML-Validators ist positiv.
  • Das Prüfergebnis des W3C-HTML-Validators ist negativ, die Fehler bei der Validierung entstehen ausschließlich durch die Verwendung von WAI-ARIA Rollen, Attributen, Zuständen oder Eigenschaften (Beispiele für Fehlermeldungen: "Attribute "ROLE" is not a valid attribute" oder "Attribute "ARIA-..." is not a valid attribute").

Nicht erfüllt:

  • Das Prüfergebnis des W3C-HTML-Validators ist negativ.

Einordnung des Prüfschritts

Formulierung BITV 2.0

4.1.1 Syntaxanalyse

Inhalte, die mit Markup-Sprachen erstellt werden, bestehen aus Elementen, für die folgende Eigenschaften gelten:

  • Sie verfügen über vollständige Start- und End-Tags,
  • sie werden entsprechend ihren Spezifikationen verschachtelt,
  • sie enthalten keine doppelten Attribute und
  • alle ihre IDs sind eindeutig,

es sei denn, ihre Spezifikationen erlauben diese Besonderheit.

Abgrenzung zu anderen Prüfkriterien

Für die Prüfung der Validität kommt es nicht darauf an, welche HTML-Version verwendet worden ist. Eine Webseite kann also überholte Elemente verwenden (Prüfschritt 4.1.1b "Verzicht auf veraltete Elemente und Attribute") und trotzdem valide sein.

Einordnung des Prüfschritts nach WCAG 2.0

Guideline

Success criterion

Techniques

General Techniques
HTML Techniques
Failures

Quellen

WAI ARIA-Schnellreferenz

WAI-ARIA Role, State, and Property Quick Reference

Bedeutung von validem HTML

Ensuring that Web pages have complete start and end tags and are nested according to specification helps ensure that assistive technologies can parse the content accurately and without crashing.

Quelle: Parsing: Understanding SC 4.1.1, Specific Benefits of Success Criterion 4.1.1

Validation will usually eliminate ambiguities (and more) because an essential step in validation is to check for proper use of that technology's markup (in a markup language) or code (in other technologies). Validation does not necessarily check for full conformance with a specification but it is the best means for automatically checking content against its specification.

Quelle: WCAG 2.0 Technik G134: Validating web pages

Why should I care if my document is in correct HTML? It displays all right on my browser.

All browsers know how to deal with correct HTML. However, if it is incorrect, the browser has to repair the document, and since not all browsers repair documents in the same way, this introduces differences, so that your document may look and work differently on different browsers. Since there are hundreds of different browsers, and more coming all the time (not only on PCs, but also on PDAs, mobile phones, televisions, printers, even refrigerators), it is impossible to test your document on every browser. If you use incorrect HTML and your document doesn't work on a particular browser, it is your fault; if you use correct HTML and it doesn't work, it is a bug in the browser.

Quelle: http://www.w3.org/MarkUp/2004/xhtml-faq

Prüfung von generiertem Quelltext

Auf Stackoverflow.com gibt es eine ausführliche Diskussion der Schwierigkeiten, den generierten Quelltext auf verschiedenen Wegen zu extrahieren und zu validieren (auf Englisch)

Quelle: Best way to view generated source of web page (stackoverflow.com)

Fragen zu diesem Prüfschritt

Scripts, die beim Laden der Seite ausgeführt werden, verändern den ursprünglichen Quelltext. Auch AJAX-Anfragen können den Quelltext noch nach dem Laden der Seite erweitern und ändern. Warum wird nicht der geparste (also veränderte) HTML-Code validiert?

Tatsächlich wäre es wünschenswert, die Validität des geparsten Quelltextes zu prüfen, einschließlich späterer Modifikationen des DOM durch AJAX-Anfragen. Es gibt zur Zeit aber keine handhabbare Möglichkeit, das zu tun: Browser verändern und reparieren den ursprünglichen Quelltext, und Werkzeuge, die den generierten Quelltext anzeigen, enthalten nicht die doctype-Deklaration des Quelltexts. Deshalb wird lediglich der ungeparste Quelltext validiert.

Was ist, wenn ältere Spezifikationen verwendet werden?

Der Verzicht auf veraltete, in neueren Spezifikationen nicht mehr unterstützte Elemente und Attribute ist Gegenstand von Prüfschritt 4.1.1B. Hier geht es jedoch nur darum, ob die Webseite überhaupt valide ist. Die Version spielt für die Bewertung in diesem Prüfschritt keine Rolle.

Warum werden Fehler bei der Validierung in Zusammenhang mit WAI-ARIA (Accessible Rich Internet Applications) Rollen, Attributen, Zuständen oder Eigenschaften nicht negativ bewertet?

Der HTML-Validator des W3C identifiziert die WAI-ARIA-Elemente als Fehler, weil die der Validierung als Basis dienenden Dokumenttypdefinitionen (DTD) noch nicht um WAI-ARIA erweitert wurden. Das wird spätestens dann passieren, wenn WAI-ARIA ein offizieller W3C Standard ist. Momentan hat WAI-ARIA noch den Status eines "Last Call Working Draft".

Trotzdem kann und soll WAI-ARIA schon produktiv eingesetzt werden. Einige Hilfsmittel unterstützen WAI-ARIA bereits.

Der Einsatz von WAI-ARIA Techniken verbessert die Zugänglichkeit. Der BITV-Test bewertet die praktische Zugänglichkeit. Es wäre nicht nachvollziehbar, wenn der Einsatz von Techniken zur Verbesserung der Zugänglichkeit im BITV-Test zu Punktabzügen führen würde.

Was ist, wenn die Seite aufgrund von Fremdinhalten, zum Beispiel wegen von einem fremden Server gelieferter Werbung nicht validiert?

Die Zugänglichkeit von deutlich abgegrenzter Werbung wird im BITV-Test nicht geprüft. Geprüft wird aber, ob die Werbung die Nutzung der anderen Seiteninhalte einschränkt. Das ist der Fall, wenn sie blinkt oder sich bewegt (Prüfschritt 2.2.2a "Bewegte Inhalte anhaltbar") oder nicht valide ist.

Was ist, wenn der HTML-Validator fehlerhaft arbeitet?

"Anerkannte" Fehler bestehen nicht dauerhaft, sie werden vom W3C bearbeitet und behoben. Gegebenenfalls ist die Prüfung zu wiederholen, nachdem der Fehler gemeldet und behoben worden ist. Für die Bewertung des Prüfschritts ist allein das Ergebnis relevant. Auf welcher Basis es zustande kommt, spielt keine Rolle!

Was ist, wenn der HTML-Validator wegen unwichtigen Details zu einer negativen Bewertung kommt?

Ob ein Detail erheblich ist oder nicht ist schwer zu entscheiden. Allgemein anerkannte Gewichtungen verschiedener Verstöße gibt es nicht. Daher zählt in diesem Fall das negative Ergebnis, auf welcher Basis es zustande kommt, spielt keine Rolle.

Was ist, wenn das verwendete CMS nicht validen Code produziert?

In diesem Fall liegt die Schuld für die Nichterfüllung des Prüfschritts möglicherweise beim Anbieter des CMS. Nichtsdestoweniger validiert die Seite nicht. Das negative Ergebnis zählt, wie es zustande kommt, spielt keine Rolle.

Sollte der Prüfschritt nicht als teilweise erfüllt bewertet werden, wenn der W3C-Validator nur wenige Fehler anzeigt?

Die Anzahl der vom W3C-Validator angezeigten Fehler ist nicht aussagekräftig. Denn im Unterschied zu gängigen Browsern versucht der W3C-Validator nicht, aus fehlerhaften Seiten irgendwie etwas Brauchbares heraus zu holen. Ein einzelner Fehler kann dazu führen, dass der Validator den Rest der Seite nicht mehr richtig liest und endlose Listen von vermeintlichen weiteren Fehlern erzeugt.

Blättern: zum ersten Prüfschritt zum vorhergehenden Prüfschritt zum nächsten Prüfschritt zum letzten Prüfschritt