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.

Keep it simple – Verständlichkeit und Barrierefreiheit

Eine Faktor, der bei der Barrierefreiheit praktisch immer vernachlässigt wird ist die Verständlichkeit. Um Verständlichkeit für eine möglichst große Gruppe von Menschen zu erreichen, ist durchaus auch der Einsatz von Bildern sinnvoll. Bilder illustrieren eine Aussage und können, wenn sie sorgfältig ausgewählt wurden, den Beitrag gut ergänzen. Natürlich spielen Bilder auch in der Navigation einer Website eine große Rolle: Pfeile, stilisierte Drucker oder Briefe werden sehr viel schneller aufgenommen als die Zeichenketten „zurück“, „Drucken“ oder „Versenden“.
Daneben zählen natürlich auch die Klassiker des guten Schreibens: Das Erklären von Fremdworten, das Vermeiden von Fachjargon, der Verzicht auf literarische Ausschmückungen, auf komplexe Satzkonstrukte und auf überflüssigen Ballast. Jeder Beitrag muss stets die W-Fragen „Was“, „Wer“, „Wie“, „Warum“ beantworten. Oder anders: der Artikel muss zeigen, was war, was ist und was sein sollte.
Zu einem guten Beitrag gehört eine saubere Gliederung, eine optische Aufteilung mit Absätzen und Zwischenüberschriften und bei entsprechender Länge auch eine Zusammenfassung.
Wer soll damit erreicht werden? Im Grunde jeder, Akademiker vergessen gerne, daß die Mehrheit der Bevölkerung nicht studiert hat und dies auch nicht deshalb tun wird, um einen Text verstehen zu können.
Um es kurz zu machen: öffentliche Behörden schneiden hier am schlechtesten ab. Doch auch andere Seitenbetreiber tun sich schwer damit, sobald man etwa auf die Allgemeinen Geschäftsbedingungen stößt. Dabei sind es gerade die AGB, die jeder lesen und verstehen sollte.
Es ist eher so, daß die bekannten Boulevard-Zeitungen hier am besten abschneiden. Der Erfolg dieser Zeitungen basiert darauf, daß sie die Dinge in einer kurzen Überschrift auf den Punkt bringen können – was immer man von den Zeitungen ansonsten halten mag.
Auch das World Wide Web Consortium hat hier keinen Vorbildcharakter. Die Veröffentlichungen des W3C sind im Techniker-Englisch abgefasste Spezifikationen, die nur für Erfahrene zugänglich sind.
Abschließend muß man feststellen, daß es mehr und nicht weniger Arbeit ist, einen Text allgemeinverständlich zu machen. Es sieht aber nicht so aus, als ob die öffentlichen Einrichtungendie Absicht haben, ihre Webauftritte darauf hin zu überprüfen.
Im Gegenteil, in aller Welt, ob in Deutschland, in Indien oder in England, überall ist die Bürokratie verliebt in ihren Fachjargon: eine Mischung aus Bürokraten-Sprech, Juristen-Jargon und neuerdings auch halbübersetzten angloamerikanischen Modeworten.
Wie man es anders macht, zeigt die englischsprachige Wikipedia, die viele Artikel in simplified English anbietet.