Das Prüfverfahren zur BITV


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


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
Korrekte Syntax

Technische Angaben

Version bis 10.07.2017 | Aktuell
BITV-Bedingung 4.1.1 Syntaxanalyse
WCAG-Erfolgskriterium 4.1.1 Syntaxanalyse
Bewertungsalternativen ja / nein
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. Dabei muss für jedes Element folgendes gewährleistet sein:

  • Sie besitzen vollständige Start- und Endtags,
  • sie sind gemäß Spezifikation korrekt verschachtelt
  • sie enthalten keine doppelten Attribute
  • alle ihre IDs sind eindeutig, außer dort wo die Spezifikationen etwas anderes erlauben

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. Seite im Chrome-Browser aufrufen.
  2. Bookmarklet "Check serialized DOM of current page" nutzen, um die Validität des geparsten Quelltextes im W3C-Validator zu prüfen.
  3. Falls das Bookmarklet nicht funktioniert, im Validator also nichts angezeigt wird, den DOM-Code kopieren und direkt im W3C Validator im Tab 'Validate by direct Input' eingeben (hier muss ggf. eine nicht mitkopierte DOCTYPE Erklärung der Seite zu Beginn eingefügt werden, z.B. bei HTML5 die Zeile <!DOCTYPE html>).
  4. Falls Fehler angezeigt werden (Error), also die Seite nicht validiert, mit dem WCAG parsing only Bookmarklet die Fehler filtern.
  5. Prüfen, ob nach der Anwendung des Bookmarklets noch Fehler vorhanden sind. Syntaktisch korrekt eingesetzte Custom-Attribute gelten dabei nicht als Fehler.

3. Hinweise

  • Die in HTML5 vorgesehenen validen Custom-Attribute nutzen das Format data-*, zum Beispiel data-platznummer="44". Manche Scripting Frameworks nutzen eigene Formate. Angular.js etwa nutzt das Format ng-*. Trotz fehlender Validität sind solche Custom-Attribute grundsätzlich kein Barrierefreiheits-Problem, solange sie semantisch korrekt (also z.B. mit korrekt öffnenden und schließenden Anführungszeichen) eingesetzt sind. Browser ignorieren Attribute, die nicht zugeordnet werden können.
  • 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!
  • In diesem Prüfschritt wird das vom Browser nach Auswertung von Scripten generierte DOM geprüft, nicht der Seitenquelltext vor Interpretation im Browser.

4. Bewertung

Erfüllt:

  • Das Prüfergebnis des W3C-HTML-Validators ist nach Anwendung des WCAG parsing only Bookmarklet ist positiv. Falls noch Fehler (Errors) auftauchen, sind diese auf den semantisch korrekten Einsatz von Custom-Attributen zurückzuführen.

Nicht erfüllt:

  • Das Prüfergebnis des W3C-HTML-Validators ist auch nach Anwendung des WCAG parsing only Bookmarklet negativ, es gibt Errors (und nicht nur wegen Custom-Attributen).

Einordnung des Prüfschritts

Einordnung des Prüfschritts nach WCAG 2.1

Guideline

Success criterion

Techniques

General Techniques
HTML Techniques
Failures

Quellen

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

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

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