Schlagwort-Archive: Validierung

Was bringen automatische Testtools für die Barrierefreiheit – die Validierung

Mittlerweile dürfte sich jede Webagentur damit schmücken, barrierefreie Websites zu bauen. Sie machen das sozusagen im Vorbeigehen, ohne Experten zu engagieren, ohne Praxistests mit Betroffenen und ohne großartig Ahnung von BIT-V oder WCAG zu haben – behaupte ich mal, denn viele Websites ob uralt oder nagelneu erfüllen nicht einmal die minimalen Basics, zum Beispiel die Verwendung von HTML-Elementen. Vielleicht greifen einige dieser Agenturen auf mehr oder weniger automatische Testtools zurück – was besser ist als gar nichts zu tun. Grund genug, sich einiger dieser Tools anzugucken und sie hier in lockerer Folge einmal vorzustellen.Ich beginne dort, wo jeder Code-Schreiber anfangen sollte, bei der Validation.

Validatoren

Dirk Jesse hat in seinem Beitrag Alles valide oder was? schon einiges zu dem Thema Validierung gesagt, dem ich nicht viel hinzufügen kann. Dennoch möchte ich das Thema vom Blickwinkel der Barrierefreiheit betrachten.

Im ersten Schritt sollte immer überprüft werden, ob die Seiten validen Code enthalten. Das hilft vor allem dabei, fehlerhafte Tags, Attribute und Werte zu finden,was zu Fehlern in der Darstellung führt.

Valide oder nicht valide – das ist nicht mehr die Frage

Kurioserweise glauben viele Leute, valider Code sei schon barrierefrei. Ergo, nicht valider Code ist eine Barriere. Die letztere Ansicht stimmt heute nicht mehr: Dank HTML5 und WAI ARIA haben sich die Möglichkeiten für barrierefreie Websites entscheidend verbessert. Beide Standards sind allerdings noch nicht verabschiedet und validieren dementsprechend zumindest beim W3C nicht. Es gibt allerdings einen experimentellen HTML5-Validator, der explizit bei der Doctype ausgewählt werden muss, wenn man nicht den neuen Doctype von HTML5 verwendet.

Jeder Code-Leser dürfte aber in der Lage sein, ARIA oder HTML5-Fehlermeldungen von echten Fehlern unterscheiden zu können. Bei CSS3 sieht es ähnlich aus. Ich plädiere stark dafür, stabile Elemente schon heute zu verwenden, weil sie die Benutzerfreundlichkeit und Zugänglichkeit erhöhen. Außerdem wird so Druck auf die Programmierer von Browsern und das W3C ausgeübt, diese Elemente auch zeitnah einzuführen.

Nutzen

Der HTML-Validator stellt zum Beispiel sicher, dass in XHTML alle Bilder einen Alternativ-Text haben. Er kann allerdings nicht beurteilen, ob dieser Text sinnvoll ist oder nicht. Er kann auch nicht sehen, ob jemand HTML für Überschriften verwendet oder sie per CSS gestaltet. div id=”h1″ ist ebenso valide wie “h1″. Die Validierung verhindert allerdings grobe Fehler wie falsche Tag-Attribut-Paare, was kein Browser der Welt korrigieren oder interpretieren kann. Er prüft auch nicht die Trennung von Layout und Struktur, die dank CSS eigentlich Standard sein sollte. Kein Validator der Welt verhindert, dass jemand mit ” ” seine Abstände einstellt oder Absätze über “br” statt über “p” erzeugt, das sind typische Artefakte von WYSIWYG-Editoren.

Fazit

Basis barrierefreier Websites ist fehlerfreier Code. Wer seinen Code nicht prüft, riskiert fehlerhafte Darstellung im Browser, was normalerweise einen Rattenschwanz weiterer Probleme nach sich zieht. Der Validator ist allerdings nur der Anfang und nicht das Ende der Testphase. Er schwächelt dort, wo es um semantisch sinnvolle Auszeichnungen geht und hier kommt es auf das Können des Code-Schreibers an.
Einen recht interessanten Artikel dazu gibt es bei Wait till I come. Chris und Remy Sharp diskutieren über die Bedeutung des Validierens, Chris vertritt als Protagonist der Barrierefreiheit im wesentlichen unseren Standpunkt.

Access News vom 29. Juli 2010 – stumme Spracheingabe

Futurezone stellt eine Technik vor, in der Computer über lautloses Sprechen gesteuert werden können. Das Interface arbeitet über Impulse der Muskulatur, das nennt sich Elektromyographie. Diese Impulse werden zu den entsprechenden Lauten umgerechnet. Die Technologie steckt noch in den Kinderschuhen, hat aber nach der Forscherin Tanja Schulz hohes Potential:

Schultz: Eine der Möglichkeiten ist, Menschen, die krankheitsbedingt nicht mehr sprechen können, eine Stimme zu geben, beispielsweise Kehlkopfkrebspatienten und Menschen, die Probleme mit ihren Stimmbändern haben. Wenn man das Signal über die Muskelaktivität abgreift, kann man ihnen über die lautlose Spracherkennung und anschließende Sprachsynthese die Sprache zurückgeben. Das ist ein großes Anwendungsfeld.

Eine weitere Anwendung bietet die Verbindung von Spracherkennung und Sprachübersetzung. Formuliert man lautlos einen Satz in seiner Muttersprache, erkennt
ihn das System und übersetzt ihn in eine andere Sprache. So könnte man mühelos eine Fremdsprache sprechen, ohne sie zu beherrschen. Quelle

W3C testet mit einem Klick

Das W3C bietet jetzt alle seine Validierungsdienste aus einer Hand an. Damit lassen sich in einem Schritt HTML, CSS, eine mobile Version und der RSS-Feed auf einmal testen. Die einzelnen Validatoren stehen aber weiterhin zur Verfügung.

224 Websites wollen eine BIENE

Zugänglichkeit könnte doch noch ein Mainstream-Thema werden: 118 der 224 eingereichten Websites stammen aus der freien Wirtschaft, also von Einrichtungen, die nicht zur Barrierefreiheit verpflichtet sind.

Dies und das

Nach Hyperkontext verarbeiten nur Screenreader Sprachauszeichnungen. Ich hatte in einem Beitrag geschrieben, dass ich Sprachauszeichnung für überflüssig halte, was allerdings meine persönliche Meinung ist und nicht repräsentativ sein muss.
Die FAZ schwärmt für eine Spracherkennungsapp für iPad und iPhone. Anbieter ist Nuance, der Entwickler von Dragon NaturallySpeaking für den PC. Das könnte vor allem für Menschen interessant sein, die Probleme mit der Touchscreen-Eingabe haben. Wenn die Geräte einmal leistungsfähiger sein werden, dürfte das der erste Schritt zur Sprachsteuerung werden, was für viele Menschen mit motorischen oder anderen körperlichen Einschränkungen interessant werden könnte.

SEO IV – schwerer wirds immer – technische Aspekte

Laden Sie alle Beiträge zur Suchmaschinenoptimierung als PDF herunter

Der Titel “SEO leicht gemacht”, den ich bisher verwendet habe, war irreführend. SEO ist zumindest zeitaufwendig und ein Prozess, der genau genommen nie ganz abgeschlossen ist.

Die technische Ebene ist dabei die wahrscheinlich komplexeste Ebene. Hier kommt man ohne HTML-Kenntnisse nicht weit.

Die Bots und Crawler der Suchmaschinen können zwar nicht denken, sie sind aber keine totalen Authisten. Deswegen kann man ihnen auch so leicht nichts vormachen.

Sie können zum Beispiel erkennen, ob eine Seite sauber geschrieben ist. Viele der älteren WYSIWYG-Editoren wie Frontpage 2000, aber auch NVU X.X produzieren schlechten Code. Das hat sich wohl gebessert, auch beim Dreamweaver, ein weiteres Manko des WYSIWYG wird sich wohl nie beheben lassen – die Produktion von redundantem und kompliziertem  Code.

Das mag auch daran liegen, dass Stylesheets auf dieser Ebene eher schwierig zu implementieren sind.

Clean the code

Mit sauberem und schlankem HTML-Code kann man das Herz jedes Bots gewinnen. Eine vom WYSIWYG produzierte Seite ist trotz Optimierung doppelt oder dreimal so groß wie eine Handgeschriebene. Der Grund ist ganz einfach: Obwohl z. B. alle Absätze gleich formatiert sind, schreibt der optische Editor in jeden Absatz Schriftart, Schriftyp, Schriftgröße und weitere Informationen rein. Er weiß nicht, dass wir alle Absätze gleich formatieren wollen, weil wir das nicht vroher festgelegt haben.
Ein weiterer Grund sind Layouttabellen, die aus vielerlei Gründen von Webdesignern nach wie vor verwendet werden. Der Vorteil von Tabellen liegt tatsächlich darin, dass sich Elemente recht genau platzieren lassen und dass die Seiten auch dann strukturiert sind, wenn man sie als HTML abspeichert und offline anguckt. Stylesheets werden normalerweise nicht abgespeichert, wodurch natürlich alles verloren geht, was darin festgelegt wurde.
Aber: Layouttabellen vervielfachen den Quellcode.

Pflegeleichter Quellcode

Korrigieren lässt sich das Ganze nur auf Quelltextebene, den Quelltext muss man aber lesen können. Das beste ist wohl, parallel auf beiden Ebenen zu arbeiten, wem phase5, Notepad++ oder HTML-Studio zu spartanisch erscheint.

Banalitäten wie korrekte Dokumentendeklaration, Meta-Description, keine toten Links, Sitemaps, keine Links in JavaScript-Code, Titel für Images, Validierung des Quelltextes und des Style Sheets sollten eigentlich nicht mehr erwähnt werden. Viele Webdesigner vertrauen allerdings eher auf ihre Design- als auf technische Fähigkeiten.

Das alles ist aus einem simplen Grund wichtig: der Bot kann durchaus erkenen, ob eine Seite valides HTML ist, ob Links tot sind oder ob man sich Mühe gegeben hat, sauberen Code zu erstellen. Für den Bot ist es irrelevant, er weiß dann nur, dass da ein Profi am Werk war und das sie Seite nutzerfreundlich ist.

Meta und mehr

Obwohl Meta-Tags heute an sich für die Suchmaschinenoptimierung nicht mehr die Bedeutung wie einst hatten, müssen auch sie gepflegt werden. Der Webdesigner muss sich bemühen, einen ordentlichen Eindruck auf den Bot zu machen. Google und andere beschweren sich durchaus, wenn doppelte Meta-Descriptions vorhanden sind oder wenn die Keywords nicht mit dem Inhalt des Body übereinstimmen.
Ebenso benötigt man auch dann eine robots.txt, wenn man dem Robot eigentlich nichts mitteilen will, wenn man ihm also erlauben will, alle Verzeichnisse zu durchsuchen.

Weiterführendes

SEO VI – Web 2.0 fürs Optimieren
SEO IV – die Strukturebene

SEO leicht gemacht III – Verlinkungen

SEO für alle II – die Inhaltsebene

SEO leicht gemacht – Suchmaschinenoptimierung für alle I