Schlagwort-Archive: W3C

eLearning oder Webinar – neue Lernformen

Mittlerweile habe ich auch eine von diesen obskuren Lerneinheiten mitgemacht – Webinare sind Seminare, die online abgehalten werden. Um alles zu sehen und zu hören, benötigt man einen Web-Browser mit Adobes Flash und eine Software namens Adobe Connect, die ebenfalls installiert werden muss. Um mitmachen zu können, ist zudem ein Headset optimal. Wer außerdem noch gesehen werden möchte, sollte eine Webcam haben. Natürlich braucht man einen aktuellen Computer mit Breitband-Internet.
Obwohl das Ganze recht technisch unproblematisch ist, würde ich es nicht noch einmal machen. Live-Sessions sind zwar ganz nett, aber zum Einen stören die schlechten Headsets und vor allem die Mikrofone der Teilnehmer. Es ist teilweise recht schwer, etwas zu verstehen. Zum Anderen will das richtige Seminar-Gefühl doch nicht aufkommen. Den Leuten gegenüber zu sitzen ist dann doch etwas anderes. Das ist aber vermutlich Geschmackssache. Viele Anbieter stellen nach den Sessions auch die Aufzeichnungen bereit, was aber wiederum nicht der Sinn von Seminaren ist.
Was mir besser gefällt sind eLearning-Kurse. Beim W3C läuft derzeit ein Training zu SVG an. Bis zum 1. Oktober kostet die Anmeldung 99 Dollar bzw. 99 Euro (mit der Währungsumrechnung scheinen sie es nicht so zu haben).
Einerseits ist das Training im Gegensatz zum Webinar asychron, d. h. die Leute sind nicht alle gleichzeitig online, eine Echtzeitkommunikation ist selten möglich. Andererseits bietet die Plattform mit Foren und Weblogs gute Austauschmöglichkeiten.
Ich hatte vor zwei Jahren schon das Training für Mobile Best Practices beim W3C mitgemacht und fand das ganz spannend. Dabei sind bestimmte Aufgaben, Übungen und Quizes zu absolvieren, damit man ein W3C-Zertifikat erhalten kann.
Es gibt auch andere Formen des Online-Lernens wobei man die Lektionen einzeln mit einem Tutor absolviert. Das ist zwar auch ganz nett, da man aber normalerweise keinen festen Zeitrahmen hat, neigt man ein wenig dazu, die Lerneinheiten andauernd auf später zu verschieben.
Das asynchrone Lernen in der Gruppe scheint mir daher der beste Weg zu sein und ich würde jedem, der an der Materie interessiert ist empfehlen, einmal ein Training beim W3C mitzumachen.

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.