Dieser Prüfschritt ist anwendbar, wenn die Auszeichnungssprache offengelegt wird.

Wie wird geprüft

Zur Syntaxanalyse von HTML-Anwendungen verwenden Sie die Entwicklertools eines Browsers, einen Syntax Validator und das Bookmarklet „WCAG-Parsing only“. Für Anwendungen im HTML-5 Standard nehmen Sie den „Nu HTML-Checker“ (https://validator.w3.org/nu/, im Bookmarklet „Check serialized DOM of current page“ enthalten, zu finden unter https://validator.github.io/validator/site/nu-about.html), für alle anderen den „W3C-Validator“ (https://validator.w3.org).

  1. Öffnen Sie die Anwendung im Browser Chrome oder Firefox und warten Sie, bis die Anwendung vollständig geladen ist.
  2. Falls verfügbar, Quelltext durch das Bookmarklet „Check serialized DOM of current page“ validieren und mit dem Bookmarklet „WCAG parsing only“ filtern.
  3. Alternativ, den DOM-Code kopieren und direkt im „W3C Validator“/“Nu HMTL-Checker“ im Tab „Validate by direct Input“/ „Check by text input“ einfügen. Das Ergebnis mit dem Bookmarklet „WCAG parsing only“ filtern. (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. Prüfen, ob nach der Anwendung des Bookmarklets noch Fehler vorhanden sind. Syntaktisch korrekt eingesetzte Custom-Attribute gelten dabei nicht als Fehler.
  5. Schritte 1 bis 4 wiederholen, nachdem Sie die Anwendung bedient haben. Nehmen Sie etwa 2 bis 3 Stichproben je Testszenario.

Folgendes ist bei der Syntaxprüfung zu beachten:

  1. Elemente haben komplette Start- und Ende-Tags,
  2. Elemente werden entsprechend ihrer Spezifikationen verschachtelt,
  3. Elemente enthalten keine doppelten Attribute und
  4. alle IDs sind einmalig, außer wenn die Spezifikationen diese Features erlauben.

Für lauffähige XML-Anwendungen erübrigt sich eine Überprüfung der Syntax, da nur korrekter Code von der Anzeigesoftware ausgeführt wird.

Beispiele

Zur HTML-Prüfung:

  • Start- und Ende-Tags, bei denen zueinander passende spitze Klammern oder Anführungszeichen fehlen, sind nicht vollständig und sind eine Einschränkung.
  • 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!

Anforderung (Beschreibung)

Webbasierte Software und Nicht-Web-Software mit offener Funktionalität

Der Prüfschritt ist anwendbar, wenn die Anwendung auf einer Auszeichnungssprache basiert (z.B., aber nicht ausschließlich, HTML, ODF, OOXML) und diese für assistive Technologien bzw. Barrierefreiheits-Features von Software oder für einen vom Benutzer wählbaren Benutzeragenten verfügbar ist.

Beispiele für Auszeichnungssprachen, die separat offengelegt werden, sind unter anderem Dokumente die in HTML, ODF und OOXML kodiert sind. Bei diesen Beispielen können die Auszeichnungen vollständig auf zwei Wege analysiert werden:

  • durch Assistenztechnologien, die das Dokument direkt öffnen können,
  • durch Assistenztechnologien, welche DOM-APIs von Benutzeragenten für diese Dokumentformate benutzen.

Nicht-Web-Software mit geschlossener Funktionalität

Wenn die Anwendung (nicht-Web Software) eine Benutzerschnittstelle bereitstellt, welche für sämtliche assistive Technologien geschlossen ist, muss sie das Erfolgskriterium „Syntaxanalyse“ nicht erfüllen. Der Prüfschritt ist dann nicht anwendbar.

Beispiele für Auszeichnungssprachen, die intern für die Persistenz der Software-Benutzerschnittstelle verwendet werden und die niemals für assistive Technologien offengelegt werden, sind unter anderem: XUL, GladeXML und FXML. Bei diesen Beispielen interagiert die assistive Technologie nur mit der Benutzerschnittstelle von generierter Software.
Auch in diesem Fall ist der Prüfschritt dann nicht anwendbar.

Warum wird das geprüft

Eine saubere Syntax dient dazu, für Konsistenz zu sorgen, damit verschiedene Benutzeragenten und assistive Technologien das gleiche Ergebnis erzielen und damit Anzeigetechniken die Inhalte korrekt darstellen und gliedern können. Manche Benutzeragenten (auch Screenreader) nutzen Reparaturtechniken, um fehlerhaften Code ausgleichen zu können. Diese Reparaturtechniken sind je Benutzeragent unterschiedlich und erzeugen verschiedene Ergebnisse. Die Einhaltung der formalen Syntaxregeln ist für dieses Erfolgskriterium zwingend notwendig (siehe obige Einschränkungen).

Verweise (Referenzen)

  • EN 301549 v3.2.1 Kap. 11.4.1.1 Parsing
  • WCAG v2.1 Kap. 4.1.1 Parsing
  • ISO9241-171 „Leitlinien für Zugänglichkeit von Software“