BITV Reloaded – Anforderung 3

Bedingung 3.2: Valides Markup (Prio. 1)

»Mittels Markup-Sprachen geschaffene Dokumente sind so zu erstellen und zu deklarieren, dass sie gegen veröffentlichte formale Grammatiken validieren.«

Was heißt das?

Eine kurze Anforderung, die es in sich hat. Dies bedeutet, dass Ihre Inhalte mit gültigem, sauberem Code nach den jeweils gültigen Empfehlungen des W3C aufgebaut sein müssen. Ohne wenn und aber.

Das beginnt bei (X)HTML-Dokumenten bereits mit der sogenannten Document Type Definition (DTD), nach der sich ein HTML-Dokument als solches zu erkennen gibt – das ist mit »… und zu deklarieren … « gemeint. Es reicht nicht, HTML-Dokumente mit der Dateiendung .html zu speichern und den Rest dem Browser zu überlassen. Im Dokument steht als Erstes, nach welcher der verschiedenen (X)HTML-Geschmacksrichtungen sich Ihr Dokument richtet. Dies hilft bei der Fehlersuche, wenn sie Ihre Seiten durch eines der verschiedenen Prüfprogramme wie z. B. validator.w3.org oder Validome kontrollieren lassen.

Eine korrekte DTD bringt moderne Browser dazu, sich an die Regeln zu halten und die Angaben z. B. des CSS so umzusetzen, wie vom Seitenbauer gewünscht. Verlassen Sie sich nicht auf die DTDs, die von manchen Programmen eingesetzt werden – diese sind oftmals fehlerhaft. Eine Liste der korrekten DTDs finden Sie beim W3C.

Auch der Rest des HTML-Codes muss bestimmten Qualitätskriterien genügen. Wie Sie diese überprüfen können, erfahren Sie im nächsten Abschnitt.

Wie können Sie das testen?

Werkzeug der Wahl ist die Web Developer Toolbar für Firefox. Im Menü ›Tools‹ finden Sie einige Befehle, um die aktuell angezeigte Seite an den W3C-Validator zur Überprüfung zu schicken. Dabei muss dies nicht mal ein Dokument sein, dass auf einem aus dem Netz erreichbaren Server liegt. In neueren Versionen kann die Toolbar auch lokal gespeichertes HTML an den Validator schicken (›Validate Local HTML‹).

Alternativ können Sie auf lokale Syntax-Checker zurückgreifen, die in so gut wie allen Autorentools wie Dreamweaver oder BBEdit bereits eingebaut sind. Andere Editoren wie TopStyle bieten die Möglichkeit, den Code der erstellten Seiten an eines der Online-Prüfprogramme zu übergeben. Verweise und kurze Erläuterungen zu diesen Werkzeugen finden Sie im Artikel »Links zur Überprüfung Ihrer Website«.

Beispiele:

Dieser Link übergibt die aktuelle Seite an den HTMLValidator des W3C:

Dieser Link übergibt das Style Sheet der aktuellen Seite an den CSS-Validator des W3C:

Für welche der unterscheidlichen Varianten von HTML & XHTML Sie sich entscheiden ist letztendlich Geschmackssache. Wir haben uns beim letzten Relaunch nach reiflicher Überlegung wieder für HTML 4.01 strict entscheiden und die Beweggründe auch in der Dokumentation des Relaunches begründet.

Probleme bei der zukünftigen Bewertung

Während die Forderung nach validem Code in der BITV noch bei Priorität 1 einsortiert ist, wird dieser Punkt bei den in der Entwicklung befindlichen WCAG 2.0 weiterhin nur mit geringerer Priorität bewertet. Dass dieser Punkt auch in der Version 1.0 der WCAG nur bei der Priorität 2 (AA) aufgeführt war ist verständlich, wenn man dies im historischen Kontext betrachtet. Zur Entstehungszeit der WCAG 1.0 waren in der Tat die meisten Browser mit standardkonformem Code überfordert, sodaß man diese Richtlinie nicht als ›muss‹ durchsetzen konnte. Dies ist heute grundsätzlich anders, sodaß es eigentlich keinen vernünftigen Grund gibt, dass eine Arbeitsgruppe des W3C die Spezifikationen aller anderen Arbeitsgruppen für nicht so wichtig erklärt.

Wie zu erwarten war hat diese Entscheidung der Web Accessibility Initiative für Unruhe und Widerspruch in der Szene gesorgt:

• Auf der einen Seite steht das (nachvollziehbare) Argument, dass es im Netz gravierendere Barrieren als unkodierte Ampersands gibt. Das Validität nicht automatisch Barrierefreiheit bedeutet dürfte sich mittlerweile herumgesprochen haben, sonst gäbe es ja auch keinen Bedarf an diesen Richtlinien und man könnte in der BITV kurzerhand auf die Empfehlungen zu HTML und ähnlichem verweisen.
• Auf der anderen Seite steht das (ebenfalls nachvollziehbare) Argument, dass man sich erst mit einer sauberen Grundlage an das Beseitigen dieser Barrieren machen kann, die Verarbeitung des Codes gerade auch für die Hilfsmittel behinderter Menschen vereinfacht wird und vieles mehr.

Einen Überblick über den Stand der Diskussion können Sie sich in unserem Weblog unter dem Tag WCAG verschaffen.