Sun, 27 Jul 2008 11:46:18 +0200Aktion Mensch, Sprecher: Manfred Heinze, Text: Tomas Caspershttp://www.einfach-fuer-alle.de/podcast/Podcast Maker v1.3.8b - http://www.lemonzdream.com/podcastmakerDer accessCast bringt wöchentliche Infos zum Thema barrierefreies Webdesign von ›Einfach für Alle‹, einer Initiative der Aktion MenschDer accessCast bringt wöchentliche Infos zum Thema barrierefreies Webdesign von Einfach für Alle, einer Initiative der Aktion MenschdeCreative Commons, s. http://www.einfach-fuer-alle.de/lizenz/http://creativecommons.org/licenses/by-nc-nd/2.0/de/Aktion Menschiris.cornelssen@aktion-mensch.dehttp://www.einfach-fuer-alle.de/podcast/enhanced/efa-accesscast_144.jpghttp://www.einfach-fuer-alle.de/podcast/144144Software How-ToTech NewsNationalNon-ProfitDesignRegionalbarrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcagnoAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersHeute geht's um ein Thema, das in der letzten Zeit bei engagierten Web-Entwicklern wieder für lange Debatten gesorgt hat: darf man CSS-Frameworks verwenden oder nicht?accessCast – CSS-Frameworks Hallo, hier ist der Podcast von ›Einfach für Alle‹, der Aktion Mensch-Initiative für barrierefreies Webdesign. Heute geht's um ein Thema, das in der letzten Zeit bei engagierten Web-Entwicklern wieder für lange Debatten gesorgt hat: darf man CSS-Frameworks verwenden oder nicht? Dirk Jesse, Entwickler des YAML CSS-Frameworks hatte sich vor einiger Zeit öffentliche Gedanken zum Pro und Contra von Frameworks gemacht und uns freundlicherweise erlaubt, diesen Text als Basis für unseren heutigen Podcast zu nehmen. Am Mikro wie immer Manfred Heinze und die Links gibt's wie immer in der Mitschrift. Ein CSS-Framework – was ist das eigentlich? Ein CSS-Framework ist zunächst einmal nur eine Sammlung von Routinen und Modulen mit gängigen Code-Konstruktionen. Diese kann man als Basis für die weitere Entwicklung eines Web-Auftrittes nehmen und sich damit eine Menge immer wiederkehrender Tipparbeiten für Dinge ersparen, die bei jedem Web-Projekt annähernd gleich sind. Die einfacheren Frameworks bestehen nur aus ein Grundgerüst, mit dem die wichtigsten Darstellungsunterschiede in den gängigen Browsern auf eine gemeinsame Basis gesetzt werden. Darauf bauen dann üblicherweise einige simple Layout-Varianten auf (einspaltig, zweispaltig, dreispaltig und so weiter) und ab da beginnt dann die eigentliche Arbeit des Webdesigners. Streng genommen hat man ja schon ein Framework, wenn man im HTML- und CSS-Editor ständig wiederkehrende Codeschnipsel ablegt und per Knopfdruck einfügt. Komplexere CSS-Frameworks wie YAML oder YUI Grids gehen noch einige Schritte weiter und geben dem Webdesigner weitergehende, komplexe Formatierungsmöglichkeiten an die Hand. Gute Frameworks decken schon von sich aus die weitaus meisten Anwendungsfälle ab. Man kann sich mit ihnen beliebige Layouts zusammenstellen und muss nicht immer wieder bei Null anfangen. Wobei hier die Einschränkung auf reines CSS schon falsch ist - diese Frameworks sind ja streng genommen bereits (X)HTML- und CSS-Frameworks, weil sie das benötigte HTML-Gerüst schon mitbringen. Und genau hier setzen viele Kritiker an. Des Web-Entwicklers liebste Linkschleuder, das Smashing Magazine hat den Überblick über aktuelle CSS-Frameworks und die Diskussionen um diese prägnant zusammengefasst: Deutliche Vorteile sind demnach … - das Vermeiden von alltäglichen Fehlern, - eine einheitliche Code-Basis, - ein verbesserter Workflow in Teams und damit - eine Steigerung der Produktivität. Dem gegenüber stehen die Nachteile … - das Erlernen der Arbeitsweise eines Frameworks kostet Zeit, - das Verstehen der Code-Architektur kostet Zeit, - Fehler in der Codebasis werden unerkannt mitgeschleift, - man vertaut dem Framework und nicht seinen eigenen CSS-Kenntnissen, - Frameworks erzeugen zu viel unnötigen Code. Nun sind wir hier bei Einfach für Alle keine Außenstehenden, denn das Layout dieser Seiten basiert ebenfalls auf einem Framework – einer älteren Version von YAML. Damit wäre auch klar, warum wir den genannten Vorteilen vorbehaltlos zustimmen. Zu den genannten Nachteilen möchten wir jedoch etwas anmerken. Nicht, um sie weg zu diskutieren, sondern weil wir denken, dass die Ursachen dafür woanders zu suchen sind. Das Kennenlernen ist schwierig Jeder Mensch hat seine persönliche Handschrift. Das gilt auch für die Erstellung von HTML- und CSS-Code sowie die Art und Weise, in der der eigene Code dokumentiert und weiterentwickelt wird. Der Einsatz eines CSS-Frameworks erfordert das Arbeiten mit fremdem Code und vorgegebenen Strukturen. Das Verstehen und der Umgang mit einer fremden Codebasis kosten den Programierer verständlicherweise Zeit. Innerhalb einer professionellen Webagentur sollte dieser Prozess allerdings zum Alltag gehören. Die Zusammenarbeit mehrerer Abteilungen oder externer Firmen und damit auch mehrerer Webdesigner ist dort die Regel. Der mögliche Vorteil eines Frameworks: die Einarbeitung in die Arbeitsweise ist ein einmaliger Aufwand - anschließend kommt der Vorteil einer einheitlichen Codebasis und einer einheitlichen Sprache bei der Umsetzung von Projekten zum tragen. Speziell bei Teamarbeit kann Arbeit und Pflege damit einfacher und leichter werden. Es ergeben sich damit keine ungewollten Zwänge. Ansätze mit einer willkürlichen Struktur werden auf Dauer kaum Bestand haben. Logische und praxisorientierte Strukturen in die eigene Arbeit zu übernehmen, fällt hingegen leicht. Den meisten Webseiten liegen solche allgemeinen Stukturen zu Grunde. Je universeller und logischer diese durch das Framework abgebildet werden, desto einfacher lässt sich damit arbeiten. Der oft geäußerte Aussage Das bekommt man (i.d.R gemeint: der Autor selbst) selbst schneller und mit weniger Code hin! kann man so pauschal nichts entgegnen. Allerdings ist dies eine rein subjektive Einschätzung der eigenen Fähigkeiten und Ansprüche an den erzeugten Code, sodass es als objektives Kriterium pro oder contra Frameworks nicht taugt, denn sie basiert nicht auf einem konkreten Anwendungsfall, sondern auf verallgemeinerten Regeln. Frameworks wie YUI Grids, Blueprint oder YAML setzen jeweils unterschiedliche Schwerpunkte. YUI Grids ist klar auf starre Layouts und die Zusammenarbeit mit den JavaScript-Bibliotheken von Yahoo! ausgelegt. Blueprint verfolgt ein streng visuelles Konzept und kombiniert ein pixelbasiertes Gestaltungsraster mit typographischen Vorgaben. YAML hingegen setzt auf flexible Layouts und Gestaltungfreiheit für den Entwickler. Sie haben also alle ihre individuelle Stärken und Schwächen. Die Bedenken, Fehler in der Codebasis unerkannt mitzuschleifen, sind nachvollziehbar. Die Chance auf bugfreien Code stehen jedoch für den Anwender sehr gut, denn Fehler in der Codebasis werden von der Community meist schnell entdeckt gemeldet und repariert. Dies ist also keine Kritik an Frameworks sondern an der teilweise mangelnden Dokumentation. Wie jede Software müssen sich auch CSS-Frameworks ihre Reputation in der Community zunächst verdienen. Und das kann nur über fehlerfreien Code und eine entsprechende Dokumentation erfolgen. Es ist ein Unterschied, ob man eine Codebasis verwendet, ohne sie zu verstehen und dem Ergebnis blindlings vertraut oder ob man alltäglich wiederkehrende Arbeitsschritte automatisiert und doch genau weiß, was dabei passiert. Wer keine Browsertest mit fremdem Code macht, macht vermutlich auch keine mit dem eigenen Code. Zum Thema »unnötig großer Code« kann man sagen, dass der durch ein Framework generierte Wasserkopf verhältnismäßig gering ist und bei anspruchsvolleren CSS-Layouts praktisch nicht Gewicht fällt. Wenn Ladezeiten und Traffic wirklich systemkritisch sind, bestehen sowohl bei CSS-Frameworks als auch bei indivuellem Code ähnliche Optimierungspotentiale, denn auch die Erstellung von Hand führt nicht im automatisch zur optimalen Lösung. Und ob eine CSS-Datei nun 21 oder 11 Kilobyte groß ist spielt spätestens dann keine Rolle mehr, wenn ein Redakteur ein 120 Kilobyte großes Bild in einen Artikel einpflegt – die wirklichen Optimierungspotenziale liegen also meist woanders. Es geht noch besser Sind Frameworks der Heilige Gral der Web-Entwicklung? Vielleicht werden sie es eines Tages, wer weiß? Derzeit sind sie es jedoch sicherlich noch nicht – zumal niemand bisher so richtig weiß, wie dieser Gral aussehen könnte. Ungeachtet dessen sind sie schon heute eine enorme Arbeitserleichterung für gestresste Web-Entwickler. Was man durchaus als Nachteil vieler aktueller Frameworks empfinden kann – und was die angesprochenen Kritikpunkte durchaus verständlich macht – ist die mangelhafte Dokumentation. So hat man oftmals den Eindruck, im luftleeren Raum zu arbeiten. Gerade bei YUI Grids erinnert die Arbeit manchmal an Voodoo – man piekst irgendwo rein, es passiert was, aber warum etwas passiert ist nicht nachvollziehbar. Diese Tatsache ist für den produktiven Einsatz nicht gerade vertrauensbildend und führt zu den geäußerten Bedenken. Hier sind die Framework-Entwickler gefragt, Ihre Lösungen vollständig und für Anwender verständlich zu dokumentieren. Gerade bei den heutigen Anforderungen in Sachen Usability, Zugänglichkeit und den Anforderungen an modernes Webdesign sollten der inhaltliche Schwerpunkt professioneller Arbeit nicht mehr im mühsamen Erstellen von validem Markup und dem Umschiffen von Browser-Bugs liegen. CSS-Frameworks greifen dem Webdesigner in genau diesem Punkt unter die Schultern, damit der Blick wieder frei wird für das Wesentliche der Arbeit.  Warum also diese Aversion gegen Frameworks? Könnte es sich dabei in Wahrheit nicht um eine Aversion gegen strukturiertes und methodisches Arbeiten handeln? Sicher, künstlerisch anspruchsvolle Websites sind so höchstindividuell, dass sie wahrscheinlich in kein Framework-Gerüst passen. Und sicher gibt es auch Kolleginnen und Kollegen, die das Anordnen von spitzen und geschweiften Klammern selbst schon als künstlerische Ausdrucksform sehen. Aber seien wir doch mal ehrlich: wie viele Brot- und Butter-Webseiten eines Webdesigners sind künstlerisch anspruchsvoll? Vielleicht liegt die verbreitete Ablehnung aber auch nur daran, dass das ganze Konzept, die Idee hinter Frameworks für viele CSS-Schreiber einfach unbekannt und neu ist. In der Programmierung richtiger Applikationen werden schon seit Jahrzehnten externe Code-Bibliotheken verwendet und niemand käme auf die Idee, jedesmal wieder ganz unten bei Maschinencode anzufangen. JavaScript-Bibliotheken verfolgen dasselbe Konzept und in der Entwicklung von Web-basierten Aplikationen sind Frameworks wie Ruby on Rails oder CakePHP nicht mehr wegzudenken. Ehrlicherweise muss man aber anmerken, dass es auch bei »richtigen« Programmierern die gleichen Diskussionen um die Verwendung von Frameworks gibt – im Sinne des Kunden und seiner Nutzer kann das aber alles nicht sein. Und was hat das überhaupt mit dem Thema Barrierefreiheit zu tun? Oberflächlich betrachtet zunächst einmal nicht viel. Die BITV schreibt den Gebrauch von CSS vor; woher dies kommt ist der Verordnung egal, geregelt wird nur die Art der Verwendung. Wir sind aber der festen Überzeugung, dass Frameworks bei sachgemäßem Gebrauch wichtige Ressourcen freisetzen können, die eher in eine wirkliche Verbesserung der Inhalte gesteckt werden sollten. Schließlich kommen die weitaus meisten Besucher einer Website nicht wegen der hübschen geschweiften und spitzen Klammern im Quelltext, sondern wegen der eigentlichen Inhalte und Funktionen des Angebots. Wo Nutzer und gerade Menschen mit Behinderungen jedoch einen echten Vorteil aus Frameworks ziehen können ist, wenn diese halb-automatisch für die Verbreitung von Accessibility-Features sorgen. Die zunehmende Verbreitung solcher Frameworks als Basis für Layouts von verbreiteten Weblog- und Content Management-Systemen sorgt quasi durch die Hintertür für eine bessere Zugänglichkeit, wenn Frameworks diese Merkmale bereits eingebaut haben und Autoren sich somit nicht mehr darum kümmern müssen. Ein praktisches Beispiel hierfür findet sich im YAML-Framework bei den bereits ab Werk eingebauten Methoden zur Sprungnavigation für Tastatur-Nutzer. So, das war die neueste Ausgabe unseres Podcasts zum Thema barrierefreies Webdesign. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags CSS und Design. Bis zum nächsten Mal.http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Frameworks.m4aTue, 04 Dec 2007 08:00:00 +0100Tech Newsno00:13:01barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcag, css, webstandards, designAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersDiesmal geht's wieder um das Aufspüren von Barrieren in Webangeboten. Dazu schauen wir uns ein paar gängige Prüfwerkzeuge an und geben Praxistipps zu deren sinnvollem Einsatz.Hallo, hier ist der Podcast von ›Einfach für Alle‹, der Aktion Mensch-Initiative für barrierefreies Webdesign. Diesmal geht's wieder um das Aufspüren von Barrieren in Webangeboten. Dazu schauen wir uns ein paar gängige Prüfwerkzeuge an und geben Praxistipps zu deren sinnvollem Einsatz. Am Mikrofon wie immer Manfred Heinze, die Musik im Hintergrund kommt diesmal von opsound.org, am Schluss gibt's noch mehr davon. In der letzten Folge haben wir eine Reihe Hinweise gegeben, wie man als Entscheider oder Kunde die Qualität dessen überprüfen kann, was der Dienstleister bzw. die Agentur abgeliefert hat. Das ist natürlich nur die halbe Wahrheit, denn irgendwann in einem Projekt kommt mal der Zeitpunkt, wo man die Einhaltung bestimmter Vorgaben nachweisen muss. Dabei sollte dies nicht erst am Ende des Projekts geschehen - wenn ein Test grundlegende Fehler aufdeckt ist es dann meistens für große Änderungen zu spät. Deswegen stellen wir heute empfehlenswerte Testwerkzeuge vor, die in keiner Design- und Entwicklungsabteilung fehlen sollten. Die speziellen Fähigkeiten dieser Testwerkzeuge kann man generell in drei Kategorien einsortieren: - sie ermöglichen die Analyse von potenziellen Fehlern direkt im Kontext der Seite; - sie simulieren bestimmte Ein- und Ausgabe-Szenarien; - sie übergeben die Seite an dritte Prüftools, die dann nach einer Liste von Kriterien maschinell testen. Und dann gibt es noch Werkzeuge, die alles auf einmal können, und manche davon sogar richtig gut. In der Regel sind dies so-genannte Toolbars oder Erweiterungen bzw. Add-Ons, die man in seinen Web-Browser installiert. Dazu gehören Erweiterungen, die bei keinem ernsthaften Web-Entwickler fehlen sollten wie die Web Developer Toolbar für Firefox und deren Pendant für den IE, die Developer Toolbar von Microsoft. Mit diesen können sie die üblichen Tests wie Validierung und ähnliches vornehmen, aber auch schon einige Dinge im Bereich Accessibility testen. So kann man durch das Abschalten von CSS testen, ob die Seite dann immer noch eine sinnvolle Struktur aufweist. Bei diesem Test sollten Sie darauf achten, ob sich die Struktur einer Seite durch geeignete Elemente wie z.B. Überschriften erschließen lässt. Hilfsmittel wie Screenreader bieten Ihren Nutzern Funktionen, mit denn sich alle Überschriften eines Dokumentes isolieren lassen; der Nutzer kann hiermit eine Seite akustisch überfliegen. Die praktische Erfahrung hat gezeigt, dass von solchen Funktionen in Hilfsmitteln reger Gebrauch gemacht wird; eine Seite sollte also entsprechend gut strukturiert sein. Ein anderer einfacher Test, den Sie mit diesen Werkzeugen durchführen können ist das Aufspüren von fehlerhaften oder ›vergessenen‹ Alternativtexten. So können Sie in der Web Developer Toolbar mit dem Befehl »Replace Images with Alt-Attributes« herausfinden, ob sich alle relevanten Inhalte noch erschließen lassen, wenn man nur den zusätzlichen Alternativtext zur Verfügung hat. Vor diesen Tests sollte aber immer eine Validierung ihrer Dokumente erfolgen, d.h. die positive Antwort auf die Frage, ob sich Ihr HTML & CSS an die vom W3C vorgegebenen Regeln hält. Wenn Seiten nicht mal ansatzweise in die Nähe von syntaktisch einwandfreiem HMTL kommen braucht man sich auch keinerlei Hoffnungen zu machen, diese jemals barrierefrei zu bekommen. Ein Tipp: der WDG HTML Validator unter htmlhelp.com testet in einem Rutsch bis zu 100 Seiten auf einmal. Neben den genannten Universal-Schweizermessern gibt es auch einige spezialisierte Werkzeuge, die wir Ihnen vorstellen wollen. Allerdings, das muss man einschränkend hinzufügen, haben alle diese Werkzeuge einem starken Fokus auf technische Barrieren, die vorzugsweise blinde Nutzer betreffen sowie verschiedene gestalterische Kriterien, wie sie für stark sehbehinderte Nutzer relevant sind. Inhaltliche Barrieren lassen sich – das liegt leider in der Natur der Dinge – mit keinem der heute vorgestellten Werkzeuge finden. Übrigens: dass wir hier das direkte Testen in Hilfsmitteln wie zum Beispiel in verbreiteten Screenreadern nicht auflisten hat einen einfachen Grund: diese gehören nicht in die Werkzeugkiste eines Web-Entwicklers, sondern in die Hände von erfahrenen Nutzern solcher Hilfsmittel. Ein Screenreader ist kein Prüftool wie ein Validator. Ein Screenreader ist streng genommen ja noch nicht mal ein Hilfsmittel, sondern der übliche Zugang eines blinden oder stark sehbehinderten Nutzers zum Computer – vergleichbar der grafischen Oberfläche für sehende Nutzer. Und genau wie diese grafische Oberfläche setzt ein Screenreader eine gewisse Einarbeitungszeit voraus, um die nötigsten Befehle zu beherrschen. Und selbst dann bekommt man als sehender Tester nicht unbedingt brauchbare Ergebnisse und oftmals sogar schlichtweg unbrauchbare, weil irreführende Testergebnisse. Die ganz spezifischen Usability-Probleme eines blinden Nutzers findet man nämlich auf diese Art und Weise nicht – dafür muss man mit echten Nutzern testen. Tools speziell für den Firefox Die Firefox Accessibility Extension der Universität von Illinois hat ihre klaren Stärken in der Simulation von bestimmten typischen Nutzungsszenarien, die typisch für Menschen mit Behinderungen sein können. Hier sind insbesondere die beiden linken Menüs »Navigation« und »Text Equivalents« von Bedeutung. Im ersten Menü finden sich eine ganze Reihe von Einträgen, die zum Beispiel die Möglichkeiten zur strukturierten Navigation per Überschriften-Elementen anzeigen. Es lassen sich sämtliche Links, Image Maps, Formulare und Datentabellen einer Seite zusammenfassen, aber auch Sprachwechsel und Accesskeys in einem separaten Fenster auflisten. Ebenso werden auf Wunsch Abkürzungen ausgeschrieben, sofern sie mit einem title-Attribut erklärt sind. Noch ein Tipp: die Accessibility Toolbar ist nicht nur ein Prüftool, sondern auch für Nutzer z.B. mit motorischer Behinderung interessant. Im Menü »Keyboard« lassen sich einige zusätzliche Einstellungen zur Tastaturnavigation vornehmen, die der Firefox ab Werk nicht beherrscht, wie zum Beispiel das Anspringen von Überschriften per Tastatur. Wie in den meisten Toolbars lassen sich auch hier die zu testenden Seiten an externe Prüfwerkzeuge übergeben. Eine Besonderheit der Accessibility Extension ist der Functional Accessibility Evaluator, der nicht nur stur nach einer der üblichen Checklisten testet, sondern auch allgemein als Best Practice anerkannte Techniken zum Aufbau von Seiten abfragt. Tools speziell für den Internet Explorer Falls Sie den Internet Explorer unter Windows einsetzen empfehlen wir Ihnen dringend die Web Accessibility Toolbar, die kostenlos vom Web Accessibility Tools Consortium veröffentlicht wurde. Eine ältere eingedeutschte Version finden Sie auf den Seiten von »Web for All« aus Heidelberg; falls Sie den IE 7 einsetzen benötigen Sie jedoch die Version 2.0, die zurzeit nur in Englisch zu haben ist. Diese Toolbar ist die bei weitem Beste unter den vergleichbaren Angeboten für diesen und für andere Browser. Neben den üblichen Befehlen zur Weitergabe der Seiten an Validatoren oder zum an- und abschalten von bestimmten Inhalten gibt es einige Funktionen, die in der Form einmalig sind. Zum einen ist da die umfangreiche Dokumentation mit sehr vielen Links zu weitergehenden Erklärungen der Hintergründe für die einzelnen Tests. Zum anderen gibt es sehr viele Funktionen zur kleinteiligen Analyse von ganz spezifischen Accessibility-Problemen wie zum Beispiel beim Aufbau und der Auszeichnung von Datentabellen und allen anderen Strukturelementen. Bestimmte für manche Hilfsmittel problematische CSS-Konstruktionen wie z.B. display:none lassen sich direkt aus der Toolbar heraus auf display:inline ändern, um damit versteckte Texte und Funktionen aufzuspüren. Grundlegendes zum Thema Testen Die BITV besteht bekanntlich aus 66 einzelnen Punkten (46 der Priorität 1 und 20 der Priorität 2). Von diesen einzelnen Punkten lässt sich nur ein sehr geringer Teil wirklich verlässlich maschinell testen. Für alle anderen Punkte braucht man einen menschlichen Tester, der, eventuell unterstützt von einer Software, die potenziellen Fehlerquellen durchgeht und bewertet. Zu den maschinell prüfbaren Punkten gehören die Validität des Quelltextes, die Angabe einer natürlichen Sprache der Dokumente und die Verwendung von veralteten HTML-Elementen und -Attributen. Bei einigen Punkten kann eine Prüfsoftware lediglich erkennen, ob zum Beispiel bestimmte Konstruktionen wie Labels in Formularen überhaupt verwendet wurden – nicht aber ob sie korrekt verknüpft sind und somit für den Nutzer funktionieren. Ähnliches gilt für die gleich zu Beginn der Verordnung eingeforderten Textalternativen: eine Software kann zwar die Verwendung feststellen, nicht aber ob der Alternativtext tatsächlich auch sinnvoll ist. Leider gehen viele Prüfprogramme so weit und geben bei leeren alt-Attributen einen Fehler aus, auch wenn es beim besten Willen keinen sinnvollen Alternativtext z.B. für eine Schmuckgrafik gibt. Dies geht so weit, dass manche Prüfprogramme nach verdächtigen Mustern suchen, die man öfter in fehlerhaftem HTML findet. Das kann zum Beispiel die Angabe des Dateinamens im Alternativtext eines Bildes sein (die Software sucht dann nach Endungen wie .gif oder .jpeg). Wir hatten hier bei ›Einfach für Alle‹ aber auch schon mal den Fall, dass ein Prüftool eine Seite beanstandete, in der angeblich ein verdächtiger Linktext gefunden wurde. Des Rätsels Lösung: im Weblog war ein Link zu einem Artikel, der selbsterklärende Linktexte zum Thema hatte. Das Prüfprogramm fand im Text »Don‘t use click here« das Muster »click here« und gab einen entsprechenden Fehler aus. Fazit: Prüfprogramme können immer nur so gut sein wie die Regeln, nach denen sie testen. Aber manchmal schießen die Entwickler solcher Werkzeuge übers Ziel hinaus. Diese starke Fokussierung auf die rein technischen Barrieren führt dann in der Regel zu einem weiteren Problem: die Entwickler verstricken sich in die technischen Aspekte und vergessen dabei, dass der wirkliche Sinn eines barrierefreien Webangebot ist, auf die Bedürfnisse von Menschen einzugehen. Auch die Interaktion eines Nutzers mit einem Webangebot lässt sich mit solchen Tools natürlich nicht testen, da diese nur einzelne Aspekte gleichzeitig abprüfen können, nie aber das gesamte Zusammenspiel aller Komponenten einer Seite. Wenn bei komplexen Abläufen und Transaktionen wie zum Beispiel einem Einkauf nur eine unüberwindbare Barriere mitten im Ablauf besteht, dann ist der gesamte Prozess für Nutzer nicht zu gebrauchen, die auf ein barrierefreies Angebot angewiesen sind. So, das war die achtundzwanzigste Ausgabe unseres Podcasts zum Thema barrierefreies Webdesign. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags BITV, Testen und Werkzeuge. Bis zum nächsten Mal.http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Testwerkzeuge.m4aWed, 07 Nov 2007 08:00:00 +0100Tech Newsno00:20:27barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcagAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas Caspers Darstellung -> Schema, dort wählen Sie zum Beispiel »Windows Kontrast #1«. Im Internet Explorer müssen Sie nun noch unter »Extras -> Internetoptionen -> Eingabehilfen« die Checkbox »Farbangaben auf Webseiten ignorieren« ankreuzen und Sie sind fertig für den Test. Surfen Sie nun alle wichtigen Bereiche Ihrer Website ab (also auch zum Beispiel einen kompletten Bestellprozess) und überprüfen Sie, ob Sie wirklich noch sämtliche Informationen finden und ob die Orientierung auf dem Angebot noch möglich ist. Achten Sie dabei besonders auf grafische Texte, die bei diesen Einstellungen schwarz auf schwarz erscheinen könnten. Alles da? Dann haben Sie diesen Schritt bestanden. Skalierbarkeit der Schriftgröße über die Browserfunktionalität (BIENE-Prüfschritt 13.1) Prüfen Sie, ob mindestens Fließtext und Navigationselemente ausreichend vergrößert dargestellt werden und ob bei vergrößerter Ansicht die Lesbarkeit durch das Layout unterstützt wird. Der Hintergrund für diesen Prüfschritt: viele Menschen sind auf bestimmte (d.h. größere oder auch kleinere) Schriftgrößen angewiesen. Bestimmte Arten der Umsetzung erlauben es nicht ohne weiteres, dass der Benutzer die Schriftgröße verändern kann, wenn ihm diese zu groß oder zu klein erscheint. Dazu kommt, dass viele Layouts nicht mehr brauchbar sind, wenn der Benutzer eigene Schriftgrößen eingestellt hat, da das Angebot nur mit einer Schriftgröße getestet wurde. So kann es zu Überschneidungen von Inhalt kommen, Texte verschwinden und werden unleserlich. Der Test hierzu ist wirklich denkbar einfach: laden Sie die Website im Internet Explorer und drücken Sie 2x Strg + und von dort aus 4x auf Strg − oder drehen Sie bei gedrückter Strg-Taste am Mausrädchen. Achten Sie darauf, ob es unerwünschte Überschneidungen gibt oder Content ganz verschwindet. Wenn alles in Ordnung ist, dann können sie zum nächsten Schritt gehen. Ist dies nicht der Fall, dann können Sie den Test an dieser Stelle abbrechen und jemand muss noch mal Hand an das CSS legen. Keine Layout-Tabellen als Seitengerüst (BIENE-Prüfschritt 14.1) Prüfen Sie, ob auf den Einsatz von Layout-Tabellen verzichtet wird. Der Hintergrund für diesen Prüfschritt: Layout-Tabellen sind eine Technik aus den Anfangstagen des Webdesigns, die so falsch ist, dass wir gar nicht wissen wo wir mit der Aufzählung der Nachteile beginnen sollen. Also lassen wir es bei dieser Feststellung: Tabellen sollen ausschließlich zur Darstellung tabellarischer Daten verwendet werden, nicht jedoch zum Aufbau eines Seitengerüsts. Falls Sie Ihre geschäftliche Korrespondenz oder das Layout von Broschüren in Excel erstellen, dann können Sie diesen Prüfschritt überspringen, für alle anderen hier die Testanleitung: Ziehen Sie das folgende Lesezeichen in die Links-Leiste des Internet Explorers: Tabellen anzeigen. Laden Sie nun Ihre Website. Wenn Sie dann den Link aufrufen werden eventuell vorhandene Tabellen mit einer gestrichelten roten Linie umrandet (wie im folgenden Screenshot zu sehen ist). Falls Sie bei der inhaltlichen Kontrolle der Tabellen zu dem Schluss kommen, dass es sich nicht um eine Datentabelle (also z.B. Börsenkurse, Wetterdaten etc. handelt), dann hat Ihre Website den Test leider nicht bestanden und die Web-Entwickler müssen noch mal ran. Verwendung von LABEL bei Kontroll- und Eingabefeldern in Formularen (BIENE-Prüfschritt 15.2) Prüfen Sie, ob die Zuordnung von Beschriftungen zu den Eingabefeldern und Kontrollelementen mit LABEL umgesetzt ist. Der Hintergrund für diesen Prüfschritt: Menschen mit motorischer Behinderung benutzen unter Umständen alternative Eingabe- und Zeigegeräte. Sie sind darauf angewiesen, dass interaktive Elemente eine gewisse Größe haben, um zuverlässig bedient werden zu können. Durch die Verwendung von LABEL in HTML wird die interaktive Fläche auf die Größe der Beschriftung ausgedehnt, wie dies auch in anderen Anwendungen generell der Fall ist (vgl. Fitts' Law). Für Nutzer von anderen Hilfsmitteln wie zum Beispiel Screenreadern oder Lupenprogrammen ist die Verknüpfung von Bedienelementen mit ihren Beschriftungen (eng.: Label) eine zwingende Notwendigkeit, um diese korrekt zuordnen zu können. Auch für diesen Prüfschritt brauchen Sie keine besonderen Hilfsmittel oder andere Programme: testen Sie in Ihren Formularen, ob Sie per Maus Checkboxen oder Radiobuttons auslösen können, indem Sie auf die daneben stehende Beschriftung klicken. Gelingt dies, dann sind Ihre Bedienelemente vorschriftsmäßig verknüpft. Wenn Sie schon dabei sind können Sie hier gleich mittesten, ob sich die gesamte Website bzw. Anwendung ausschließlich per Tastatur (d.h. ohne Maus) bedienen lässt. Sichtbarkeit des Fokus (BIENE-Prüfschritt 17.3) Prüfen Sie, ob der Fokus in jeder Position deutlich sichtbar ist. Berücksichtigen Sie bei der Prüfung auch die Formulare. Der Hintergrund für diesen Prüfschritt liegt auch wieder bei der für die barrierefreie Nutzung wichtigen Tastaturbedienbarkeit. Wenn Sie sich per Tastatur durch die Seiten bewegen: sehen Sie immer, wo ihre aktuelle Position auf der Seite ist? Die Hervorhebung kann zum Beispiel durch eine farbliche Hervorhebung von Links, eine deutliche Umrandung oder ähnliches geschehen. Erscheint die Abfolge der Inhalte auch bei Tastaturbedienung logisch oder springt der Fokus wie wild geworden zwischen verschiedenen Spalten hin und her? Prüfung der Document-type-declaration (BIENE-Prüfschritt 34.1) Prüfen Sie, ob eine Document-type-declaration vorhanden ist, sofern sie nach W3C-Empfehlungen benötigt wird. Sie soll sich auf eine veröffentlichte DTD beziehen. Lassen Sie sich nicht von der Formulierung abschrecken – diese sind primär für die Tester während des Wettbewerbsverfahrens gedacht, und die wissen was es damit auf sich hat. Gemeint ist hier die grundlegende Möglichkeit, ein Dokument durch den Validator zu schicken, damit dieser die Einhaltung der Grammatikregeln von (X)HTML überprüfen kann. Natürlich kann es im Eifer des Gefechts passieren, dass Entwickler oder Redakteure Inhalte veröffentlichen, die nicht den formalen Kriterien der HTML- und CSS-Empfehlungen entsprechen – dafür gibt es Validatoren, die solche Fehler finden. Allerdings kann man keine generelle Aussage darüber machen, ob eine Seite mit hunderten Validierungsfehlern besser oder schlechter ist als eine mit nur wenigen. Solche langen Fehlerreporte können auch durch Vererbungen von Fehlern entstehen, wenn irgendwelche Tags nicht korrekt geschlossen sind. Die darauf folgenden Fehler verschwinden dann wie von Zauberhand, sobald man den ursprünglichen Fehler behebt. Allerdings gibt es ein paar »Vorfälle«, die nicht passieren sollten: so finden HTML-Validatoren z.B. fehlende alt-Attribute, mit denen Bilder oder Grafiken auch für Menschen zugänglich gemacht werden müssen, die diese Bilder nicht sehen können. Wenn Sie also bei der Validierung Fehlermeldungen wie: »Required attribute alt not found« antreffen, dann haben Sie massiven Nachbesserungsbedarf. Wie hoch dieser im Einzelfall ist lässt sich ohne Kenntnis des dahinterstehenden Systems kaum sagen, aber in der Regel sollte ein hochwertiges Redaktionssystem solche dicken Klopse nicht mehr durchlassen. So, das war die achtundzwanzigste Ausgabe unseres Podcasts zum Thema barrierefreies Webdesign. Wir hoffen, dass wir Ihnen auch diesmal wieder ein paar wertvolle Tipps mitgeben konnten. Wenn Sie selber Anmerkungen oder Ergänzungen zu unserem heutigen Thema haben dürfen Sie diese gerne in den Kommentaren zur Sendung hinterlassen. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags BIENE , Barrierefreiheit und Testen . Bis zum nächsten Mal.]]>Heute schauen wir uns an, wie man Qualität in Projekten sicherstellt und geben ein paar Tipps zum Testen von Websites.In den letzten Folgen hatten wir viel über die theoretischen Grundlagen und die Verteilung der Zuständigkeiten gesprochen und wie man die Ideen der Barrierefreiheit in die Abläufe von Projektteams integriert. Heute schauen wir uns an, wie man die Qualität in solchen Projekten sicherstellt und geben ein paar Tipps zum Testen von Websites. Am Mikrofon wie immer Manfred Heinze, die Musik im Hintergrund kommt diesmal aus der Creative Commons-Bibliothek, am Schluß gibt's noch mehr davon. Eine der häufigsten Fragen rund um das Thema Barrierefreiheit ist, wie man als Entscheider oder Kunde die Qualität dessen überprüfen kann, was der Dienstleister bzw. die Agentur abgeliefert hat. Dabei scheitert eine vernünftige Antwort oft schon daran, dass die Richtlinien zur Barrierefreiheit zwar ein gutes Mittel zur Qualitätssicherung sind, aufgrund ihrer technischen Natur aber einen ausgebildeten Tester zur Interpretation der Ergebnisse benötigen. Daher haben wir heute ein paar einfache Tests zusammengestellt, die keine besonderen Kenntnisse in Markup-Sprachen wie HTML voraussetzen. Einige Fragen, die sie sich zu Beginn des Projekts stellen sollten Falls es sich um ein bestehendes Projekt handelt sind die wichtigsten Fragen: Wie schlimm ist Ihre Website? Wie viel Ihrer Website ist zugänglich bzw. wie viel ist unzugänglich? Egal ob nun die Barrierefreiheit im Vordergrund steht, oder ob andere Gründe wie zum Beispiel inhaltliche Erweiterungen oder Design-Änderungen den Ausschlag für einen Relaunch gegeben haben – Sie sollten zunächst alle Inhalte inventarisieren, um überhaupt einen Überblick über die vorhandenen Inhalte und Funktionen zu bekommen. Dabei sind sich Usablility-Experten mittlerweile einig: die zentrale Einstiegsseite, neudeutsch Homepage, ist bei einer solchen Überarbeitung so ziemlich die unwichtigste Seite in ihrem ganzen Angebot. Bei der Suche nach Barrieren sollten Sie mehr Fokus auf die eigentlichen Inhaltsseiten oder die zentralen Funktionen des Angebots legen (die üblicherweise nicht auf der Homepage zu finden sind). Hier finden sich die Inhalte und Funktionen, die Benutzer auf Ihrem Angebot suchen. Also müssen diese, wie zum Beispiel ein Bestellprozess bei einem Shopping-Angebot oder die einzelnen Artikel bei einer Content-lastigen Seite, auch mit höherer Priorität bei der Beseitigung von Barrieren behandelt werden. Ein nützliches Werkzeug um die wichtigsten Baustellen einer Website zu identifizieren ist der W3C-Log Validator, der als Open Source veröffentlicht wurde und kostenlos zum Herunterladen erhältlich ist. Mit diesem Werkzeug können die meist-besuchten Seiten eines Angebots gefunden werden und an weitere Prüf-Tools wie Validatoren geschickt werden. Diese finden ja bekanntlich schon solche Fehler wie »vergessene« alt-Attribute und ähnliches, sodass man hier einen schnellen Überblick über den Handlungsbedarf auf der technischen Ebene erhält. Der Output lässt es auch zu, dass man die vorgefundenen Fehler auf einzelne Themenbereiche herunterbrechen kann, um diese dann einzeln anzugehen. Einige Fragen, die sie sich während des Projekts stellen sollten In den Prüfschritten der BIENE 2006 finden sich einige Punkte, die man hervorragend zu einer ersten (wenn auch groben) Qualitätskontrolle einsetzen kann. Sie sind alleine schon deswegen so empfehlenswert, weil die Durchführung der Tests keine großen Ansprüche an die technische Ausrüstung mit Soft- und Hardware stellen. Sie können auch von jemandem durchgeführt werden können, der nicht Diplom-Informatiker oder erfahrener Accessibility-Tester ist (im Volksmund auch Kunde oder Projektmanager genannt). Ein paar Prüfschritte haben wir mal für Sie aus dem Verfahren rausgesucht und geben Tipps, wie man die Tests selber durchführen kann. Diese Fragen sollte ein Kunde auch noch mal bei der Abnahme des Endprodukts stellen, selbst wenn diese in früheren Phasen schon mal beantwortet wurden. Fehler können sich durchaus später erneut einschleichen. Auf parallele seitenübergreifende Alternativ-Auftritte wird verzichtet (BIENE-Grundvoraussetzung) Prüfen Sie, ob auf einen parallelen seitenübergreifender Alternativ-Auftritt verzichtet wird. Das Vorhandensein eines seitenübergreifenden Alternativ-Auftritts führt zum Ausschluss vom Wettbewerb. Ein offenes Wort an alle, die Web-Auftritte beauftragen: wenn der Dienstleister Ihres Vertrauens die Frage nach der Barrierefreiheit mit Da machen wir einfach eine Nur-Text-Version beantwortet, sollte Sie dies nachdenklich stimmen. Wahrnehmbarkeit bei wechselndem Hintergrund (BIENE-Prüfschritt 12.2) Prüfen Sie in einem Windows-Kontrastmodus, ob alle Inhalte, vor allem informative Graphiken, unabhängig von der Farbe des Hintergrunds gut sichtbar sind. Der Hintergrund für diesen Prüfschritt: viele Menschen mit Sehbehinderung surfen mit höchst individuellen Farbeinstellungen, um negative Effekte für ihre jeweilige Form der Sehbehinderung zu kompensieren. Ein mögliches Szenario sind die sogenannten Kontrastschemata unter Windows, bei denen das Design einer Seite radikal verändert wird. In der Systemsteuerung finden Sie diese unter Anzeige -> Darstellung -> Schema, dort wählen Sie zum Beispiel »Windows Kontrast #1«. Im Internet Explorer müssen Sie nun noch unter »Extras -> Internetoptionen -> Eingabehilfen« die Checkbox »Farbangaben auf Webseiten ignorieren« ankreuzen und Sie sind fertig für den Test. Surfen Sie nun alle wichtigen Bereiche Ihrer Website ab (also auch zum Beispiel einen kompletten Bestellprozess) und überprüfen Sie, ob Sie wirklich noch sämtliche Informationen finden und ob die Orientierung auf dem Angebot noch möglich ist. Achten Sie dabei besonders auf grafische Texte, die bei diesen Einstellungen schwarz auf schwarz erscheinen könnten. Alles da? Dann haben Sie diesen Schritt bestanden. Skalierbarkeit der Schriftgröße über die Browserfunktionalität (BIENE-Prüfschritt 13.1) Prüfen Sie, ob mindestens Fließtext und Navigationselemente ausreichend vergrößert dargestellt werden und ob bei vergrößerter Ansicht die Lesbarkeit durch das Layout unterstützt wird. Der Hintergrund für diesen Prüfschritt: viele Menschen sind auf bestimmte (d.h. größere oder auch kleinere) Schriftgrößen angewiesen. Bestimmte Arten der Umsetzung erlauben es nicht ohne weiteres, dass der Benutzer die Schriftgröße verändern kann, wenn ihm diese zu groß oder zu klein erscheint. Dazu kommt, dass viele Layouts nicht mehr brauchbar sind, wenn der Benutzer eigene Schriftgrößen eingestellt hat, da das Angebot nur mit einer Schriftgröße getestet wurde. So kann es zu Überschneidungen von Inhalt kommen, Texte verschwinden und werden unleserlich. Der Test hierzu ist wirklich denkbar einfach: laden Sie die Website im Internet Explorer und drücken Sie 2x Strg + und von dort aus 4x auf Strg − oder drehen Sie bei gedrückter Strg-Taste am Mausrädchen. Achten Sie darauf, ob es unerwünschte Überschneidungen gibt oder Content ganz verschwindet. Wenn alles in Ordnung ist, dann können sie zum nächsten Schritt gehen. Ist dies nicht der Fall, dann können Sie den Test an dieser Stelle abbrechen und jemand muss noch mal Hand an das CSS legen. Keine Layout-Tabellen als Seitengerüst (BIENE-Prüfschritt 14.1) Prüfen Sie, ob auf den Einsatz von Layout-Tabellen verzichtet wird. Der Hintergrund für diesen Prüfschritt: Layout-Tabellen sind eine Technik aus den Anfangstagen des Webdesigns, die so falsch ist, dass wir gar nicht wissen wo wir mit der Aufzählung der Nachteile beginnen sollen. Also lassen wir es bei dieser Feststellung: Tabellen sollen ausschließlich zur Darstellung tabellarischer Daten verwendet werden, nicht jedoch zum Aufbau eines Seitengerüsts. Falls Sie Ihre geschäftliche Korrespondenz oder das Layout von Broschüren in Excel erstellen, dann können Sie diesen Prüfschritt überspringen, für alle anderen hier die Testanleitung: Ziehen Sie das folgende Lesezeichen in die Links-Leiste des Internet Explorers: Tabellen anzeigen. Laden Sie nun Ihre Website. Wenn Sie dann den Link aufrufen werden eventuell vorhandene Tabellen mit einer gestrichelten roten Linie umrandet (wie im folgenden Screenshot zu sehen ist). Falls Sie bei der inhaltlichen Kontrolle der Tabellen zu dem Schluss kommen, dass es sich nicht um eine Datentabelle (also z.B. Börsenkurse, Wetterdaten etc. handelt), dann hat Ihre Website den Test leider nicht bestanden und die Web-Entwickler müssen noch mal ran. Verwendung von LABEL bei Kontroll- und Eingabefeldern in Formularen (BIENE-Prüfschritt 15.2) Prüfen Sie, ob die Zuordnung von Beschriftungen zu den Eingabefeldern und Kontrollelementen mit LABEL umgesetzt ist. Der Hintergrund für diesen Prüfschritt: Menschen mit motorischer Behinderung benutzen unter Umständen alternative Eingabe- und Zeigegeräte. Sie sind darauf angewiesen, dass interaktive Elemente eine gewisse Größe haben, um zuverlässig bedient werden zu können. Durch die Verwendung von LABEL in HTML wird die interaktive Fläche auf die Größe der Beschriftung ausgedehnt, wie dies auch in anderen Anwendungen generell der Fall ist (vgl. Fitts' Law). Für Nutzer von anderen Hilfsmitteln wie zum Beispiel Screenreadern oder Lupenprogrammen ist die Verknüpfung von Bedienelementen mit ihren Beschriftungen (eng.: Label) eine zwingende Notwendigkeit, um diese korrekt zuordnen zu können. Auch für diesen Prüfschritt brauchen Sie keine besonderen Hilfsmittel oder andere Programme: testen Sie in Ihren Formularen, ob Sie per Maus Checkboxen oder Radiobuttons auslösen können, indem Sie auf die daneben stehende Beschriftung klicken. Gelingt dies, dann sind Ihre Bedienelemente vorschriftsmäßig verknüpft. Wenn Sie schon dabei sind können Sie hier gleich mittesten, ob sich die gesamte Website bzw. Anwendung ausschließlich per Tastatur (d.h. ohne Maus) bedienen lässt. Sichtbarkeit des Fokus (BIENE-Prüfschritt 17.3) Prüfen Sie, ob der Fokus in jeder Position deutlich sichtbar ist. Berücksichtigen Sie bei der Prüfung auch die Formulare. Der Hintergrund für diesen Prüfschritt liegt auch wieder bei der für die barrierefreie Nutzung wichtigen Tastaturbedienbarkeit. Wenn Sie sich per Tastatur durch die Seiten bewegen: sehen Sie immer, wo ihre aktuelle Position auf der Seite ist? Die Hervorhebung kann zum Beispiel durch eine farbliche Hervorhebung von Links, eine deutliche Umrandung oder ähnliches geschehen. Erscheint die Abfolge der Inhalte auch bei Tastaturbedienung logisch oder springt der Fokus wie wild geworden zwischen verschiedenen Spalten hin und her? Prüfung der Document-type-declaration (BIENE-Prüfschritt 34.1) Prüfen Sie, ob eine Document-type-declaration vorhanden ist, sofern sie nach W3C-Empfehlungen benötigt wird. Sie soll sich auf eine veröffentlichte DTD beziehen. Lassen Sie sich nicht von der Formulierung abschrecken – diese sind primär für die Tester während des Wettbewerbsverfahrens gedacht, und die wissen was es damit auf sich hat. Gemeint ist hier die grundlegende Möglichkeit, ein Dokument durch den Validator zu schicken, damit dieser die Einhaltung der Grammatikregeln von (X)HTML überprüfen kann. Natürlich kann es im Eifer des Gefechts passieren, dass Entwickler oder Redakteure Inhalte veröffentlichen, die nicht den formalen Kriterien der HTML- und CSS-Empfehlungen entsprechen – dafür gibt es Validatoren, die solche Fehler finden. Allerdings kann man keine generelle Aussage darüber machen, ob eine Seite mit hunderten Validierungsfehlern besser oder schlechter ist als eine mit nur wenigen. Solche langen Fehlerreporte können auch durch Vererbungen von Fehlern entstehen, wenn irgendwelche Tags nicht korrekt geschlossen sind. Die darauf folgenden Fehler verschwinden dann wie von Zauberhand, sobald man den ursprünglichen Fehler behebt. Allerdings gibt es ein paar »Vorfälle«, die nicht passieren sollten: so finden HTML-Validatoren z.B. fehlende alt-Attribute, mit denen Bilder oder Grafiken auch für Menschen zugänglich gemacht werden müssen, die diese Bilder nicht sehen können. Wenn Sie also bei der Validierung Fehlermeldungen wie: »Required attribute alt not found« antreffen, dann haben Sie massiven Nachbesserungsbedarf. Wie hoch dieser im Einzelfall ist lässt sich ohne Kenntnis des dahinterstehenden Systems kaum sagen, aber in der Regel sollte ein hochwertiges Redaktionssystem solche dicken Klopse nicht mehr durchlassen. So, das war die achtundzwanzigste Ausgabe unseres Podcasts zum Thema barrierefreies Webdesign. Wir hoffen, dass wir Ihnen auch diesmal wieder ein paar wertvolle Tipps mitgeben konnten. Wenn Sie selber Anmerkungen oder Ergänzungen zu unserem heutigen Thema haben dürfen Sie diese gerne in den Kommentaren zur Sendung hinterlassen. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags BIENE , Barrierefreiheit und Testen . Bis zum nächsten Mal.http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Testen.m4aFri, 12 Oct 2007 08:01:00 +0200Tech Newsno00:21:16barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcagAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersWie kann man die Accessibility grundsätzlich in einem Web-Projekt verankern?In der letzten Folge hatten wir uns ein paar Gedanken dazu gemacht, wer für welche Teilaspekte des Barrierefreien Webdesigns zuständig ist. Heute gehen wir einen Schritt zurück und fragen uns, wie man die Accessibility grundsätzlich in einem Web-Projekt verankern kann. Dazu gehört natürlich zunächst einmal die Überzeugungsarbeit, den Handlungsbedarf in einem Projekt-Team oder im Verhältnis Dienstleister — Kunde aufzuzeigen. Und genau da fängt das Problem meistens schon an: mit der Erkenntnis, oder besser gesagt der mangelnden Erkenntnis, dass bei der betreffenden Website tatsächlicher Handlungsbedarf besteht. Bei vorhandenen Web-Auftritten, die zur Überarbeitung anstehen, lässt sich das Problembewusstsein generell in die folgenden vier Kategorien einteilen: 1. Ignorieren und hoffen dass sich das Problem von selber löst. 2. Barrierefreiheit quasi als Plug-In im Nachhinein dem Web-Auftritt überstülpen, nachdem der Job erledigt ist. 3. Während der Entwicklung immer ein bisschen hier und da an den Stellschrauben drehen, wie es gerade passt oder nötig erscheint. 4. Das Thema Accessibility bereits in der Konzeptionsphase einplanen und im gesamten laufenden Prozess als Ziel beibehalten. Das erste Szenario können wir getrost überspringen, da hier die grundlegenden Voraussetzungen zur Erstellung eines barrierefreien Web-Auftritts fehlen. Es sei denn, die betreffende Organisation ist gesetzlich zur Einhaltung bestimmter Mindestanforderungen verpflichtet. Gerade bei der öffentlichen Hand hat die BITV in der Tat in den letzten Jahren schon einiges bewirkt, sodass diese »Management-Methode« nicht mehr anzutreffen sein dürfte. Für alle anderen gilt: ohne Problembewusstsein wird's nicht barriereärmer. Das zweite Szenario ist, wie schon das erste, leider noch viel zu oft anzutreffen: Barrierefreiheit wird als ein technisches Ding angesehen, das man irgendwie auf dem Server installiert. Bei solchen Websites werden oftmals nach dem Launch noch irgendwelche Features nachgerüstet, mit denen grundlegende Probleme der gesamten Architektur oder der Inhalte überdeckt werden – oder vielleicht sogar überdeckt werden sollen? Zu erkennen ist diese Art von Websites meistens daran, dass sie zwar formell bestimmte Kriterien erfüllen, in der Praxis jedoch mit Hilfsmitteln behinderter Nutzer kaum zu gebrauchen sind. Dabei wird häufig übersehen, dass Barrieren in den seltensten Fällen rein technischer Natur sind. Auch wenn man es mit diesem Ansatz vielleicht schafft, eine der ominösen Checklisten komplett abzuhaken – darum geht es bei Accessibility nicht. Es geht bei dem Thema immer um den Menschen, dem die Teilhabe am gesellschaftlichen Leben durch eine barrierefreie Nutzung erleichtert oder sogar erst ermöglicht wird. Bei Websites der dritten Kategorie ist man schon ein gutes Stück weiter: irgendwer im Projektteam hat mal gehört, dass Barrierefreiheit kein Zustand ist, sondern ein Annäherungswert, dem man sich in einem Prozess nähert. Also wird im Zuge der Erstellung oder des Relaunches an manchen Stellen das Richtige gemacht, aber ohne eine offizielle Accessibility-Strategie bleibt es meist dabei. Eventuell gab es hier schon Rückmeldungen von Menschen mit Behinderungen, dass sie bestimmte Inhalte der Website nicht nutzen können. Die Fokussierung auf das Abarbeiten von Beschwerden führt oftmals dazu, dass die Website auf ein bestimmtes Hilfsmittel wie zum Beispiel eine spezielle Version eines bestimmten Screenreaders hin optimiert wird – was auch nicht im Sinne eines barrierefreien Zugangs für sämtliche Behinderungsformen ist. Oft werden bei solchen Websites Techniken eingesetzt, die vielleicht vor Jahren mal en vogue waren, von denen man aber heute weiss, dass sie nicht wirklich sinnvoll sind. Das Problem ist, dass das Netz in dieser Hinsicht nicht vergesslich ist (»Cool URIs don‘t change«) und Tutorials zu veralteten Techniken auch heute noch für bare Münze genommen werden. Womit wir in der vierten Kategorie, der Königsklasse angelangt wären: Das Thema Accessibility wird bereits in der Konzeptionsphase mit eingeplant und im gesamten Prozess als Ziel beibehalten. Diese Variante bietet die höchste Wahrscheinlichkeit, dass man hinterher mit einem weitestgehend barrierefreien Auftritt glänzen kann. Allerdings ist dies auch, und das muss man ehrlicherweise dazu sagen, die Variante mit dem höchsten Aufwand. Aufwand, der sich in der nötigen fachlichen Kompetenz der Beteiligten ausdrückt, aber auch Aufwand, der schon mit der benötigten Überzeugungsarbeit anfängt. Wenn wir davon ausgehen, dass bei einem solchen Projekt bzw. bei den Beteiligten zumindest das Problembewusstsein schon vorhanden ist, dann entsteht hier trotzdem Aufwand in der Planungs- und Vorbereitungsphase, der sich direkt in Kosten niederschlägt. Sie können nicht davon ausgehen, dass alle am Projekt Beteiligten durch die Bank ein brauchbares Fachwissen über die speziellen Anforderungen der Barrierefreiheit in ihrem jeweiligen Fachgebiet haben. Dazu ist dieses Thema zum Beispiel in den Lehrplänen von Universitäten und Fachhochschulen oder Ausbildungsgängen noch viel zu wenig verankert. Das Gute: wenn man im Vorfeld in das Training investiert, dann sind hinterher (also während der Umsetzung des Angebots) die Kosten für die Barrierefreiheit nahezu gleich – man macht dann halt alle Sachen einfach anders als bisher – sprich: gleich richtig. Allerdings funktioniert dies nur, wenn das Thema Accessibility Rückendeckung von »ganz oben« hat, also das Management oder die Unternehmensleitung die Notwendigkeit akzeptiert und bereit ist, diese einmaligen Kosten zu tragen. Und da beginnt oftmals das Problem: wenn man auf das nächste Quartalsergebnis schielt, dann können einem diese einmaligen Kosten die Bilanz verhageln. Die Schwierigkeit liegt hier in der Argumentation, dass es sich zunächst um weiche Faktoren und nicht direkt messbare Ergebnisse handelt, sondern um eine langfristige Investition, während die unmittelbaren Kosten ziemlich genau zu beziffern sind. Dabei ist eine Ablehnung durchaus nachvollziehbar: der menschliche Instinkt sagt fast automatisch »Nein«, wenn man aktuelle Zusatzkosten mit späteren Einsparungen begründet. Weil aber barrierefreie Web-Angebote fast schon automatisch eine bessere Usability für den Nutzer, eine gesteigerte Performance auf dem Server und eine gewisse Investitionssicherheit durch Web-Standards bedeuten, dürfte diese Diskussion in den meisten Fällen pro Barrierefreiheit enden. Merke: Barrierefreiheit kostet etwas: vor allem kostet es Überwindung. Und auch wenn es erstmal teurer wird, spätestens beim nächsten Relaunch hat man nach unserer Erfahrung die zusätzlichen Kosten ganz schnell wieder drin. Denn ein wichtiges Merkmal barrierefreier Web-Angebote ist das »Mehr« an eingebauter Logik – sowohl in der gesamte Architektur als auch in der Gestaltung und der technische Umsetzung. Dieses Mehr an Logik erweist sich erfahrungsgemäß als enorm hilfreich, wenn Inhalte überarbeitet oder erweitert werden sollen oder auch schon dann, wenn der Kunde die Navigation auf einmal links statt rechts haben möchte. Zumal die Kosten für das Ent-Lernen von »das haben wir immer so gemacht« und das Neu-Lernen von moderneren Techniken geradezu lächerlich gering sind im Vergleich zu einer 4c-Seite in der ADAC-Zeitung oder einem 30-Sekünder zur Prime-Time im Fernsehen. Dabei sollten diese Kosten für die Schulung der Projektbeteiligten streng genommen beim Dienstleister verbleiben und nicht auf den Kunden abgewälzt werden. Barrierefreiheit gehört mittlerweile zum guten Handwerk und die Beherrschung der nötigen Techniken darf und muss man mittlerweile von qualifizierten Dienstleistern erwarten. Widerstände aus Sicht des Dienstleisters sind ebenso verständlich, aber sicher nicht im Sinne des Kunden und des verantwortungsvollen Umgangs mit Etat-Geldern: Standard-konforme und zugängliche Webseiten sind einfacher in Wartung und Pflege, spülen daher aber auch weniger Geld in die Kassen der Agentur. Dabei sollte es auch im ureigensten Interesse des Dienstleisters liegen, immer auf die maximal erreichbare Qualität abzuzielen. Die Zielvorgabe, den Durchschnitt zu erreichen führt ganz automatisch zu einem Absacken der allgemeinen Qualität, das ist ein ganz einfaches mathematisches Rechenmodell. Wie man denn nun die Barrierefreiheit in einem Entwicklungsprozess verankert ist Gegenstand langer Diskussionen. Ohne die Strukturen und Abläufe in einer Organisation oder die Etatgrößen zu kennen kann man kaum allgemeingültige Tipps zu diesem Thema geben – dazu sind diese zu individuell und von Faktoren abhängig, die unter Umständen einmalig sind. Trotzdem noch zwei Lesetipps zu dem Thema, leider wie so oft nur auf Englisch: Der Artikel »Implementation Plan for Web Accessibility« von der Web Accessibility Initiative des W3C gibt Tipps, wie man, wie es auf neudeutsch so schön heisst, »Awareness« schafft, wie man Baustellen identifiziert, geeignete Software aussucht und Mitarbeiter und Kollegen schult. Das ganze in Form einer ziemlich langen Liste. Viel ausführlicher ist die Artikelreihe »8-Step Implementation Model« bei WebAIM, in dem auch gleich noch verschiedene Szenarien mitgeliefert und intensiv diskutiert werden. Links wie immer am Ende der Mitschrift. So, das war die sechsundzwanzigste Ausgabe unseres Podcasts zum Thema barrierefreies Webdesign. In der nächsten Folge geben wir ein paar Tipps, wie man schon während der Erstellung oder des Umbaus eines Angebots die Qualität überprüfen kann. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags Barrierefreiheit und Best Practice . Bis zum nächsten Mal.http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Handlungsbedarf.mp3Wed, 19 Sep 2007 08:00:00 +0200Tech Newsno00:12:40barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcagAktion MenschAusfüllen, abschicken, fertig: Diskussionen in Foren und Weblogs, Jobangebote und –gesuche in Stellenbörsen, Fahrplanauskünfte bei der Bahn oder Bestellungen in Online-Shops funktionieren mit Formularen.Ausfüllen, abschicken, fertig: Diskussionen in Foren und Weblogs, Jobangebote und –gesuche in Stellenbörsen, Fahrplanauskünfte bei der Bahn oder Bestellungen und Bezahlung in Online-Shops funktionieren mit Formularen. Redaktionssysteme und Weblogs arbeiten in der Regel formularbasiert. Formulare sind oft der Kern interaktiver Angebote und Grundlage der Kommunikation zwischen Anbietern und Nutzern einer Webseite. Die Grundfunktionen eines Formulars – ausfüllen und abschicken – müssen mit allen möglichen Mitteln der Bedienung und der Ausgabe gelingen. Der Anbieter einer Webseite sollte ein Interesse daran haben allen Nutzern, auch wenn sie assistive Werkzeuge wie z. B. Screenreader, Spracherkennung oder Spezialtastaturen einsetzen, das vollständige Ausfüllen und Abschicken seiner Formulare zu ermöglichen. Gerade bei Formularen gilt das POUR-Prinzip der WCAG 2.0 in Reinform: Formulare müssen wahrnehmbar (perceivable), bedienbar (operable), verständlich (understandable) und robust (robust) sein. In den Richtlinien finden sich zwar nur wenige direkte Vorgaben zu Formularen, jedoch sind fast alle Punkte der WCAG bzw. BITV anwendbar – von HTML über CSS und Bilder bis zu JavaScript. Nur der vollständige Einsatz aller Möglichkeiten stellt sicher, dass Ihre Formulare mit allen denkbaren Zugangsformen verstanden und bedient werden können. Aber obwohl HTML seit Jahren viele Elemente für barrierefreie und damit bediener­freundliche Formulare enthält, werden diese nur sehr sparsam eingesetzt. Für öffentliche Anbieter, die den Vorgaben der BITV unterliegen, ist der Einsatz dieser Mittel klar geregelt: die Verordnung verlangt den Einsatz der korrekten HTML-Elemente und CSS für die Gestaltung; weitergehende Vorgaben zur Orientierung und geräte­unabhängigen Bedienung treffen selbstredend auch auf Formulare zu. Um die Markup-Grundlage von Formularen geht es in Teil 1 unserer Serie: »HTML-Elemente für Formulare«. In Teil 2 – »Formulardesign« – dreht sich alles um die Gestaltung und Usability und im dritten Teil der Serie geht es um Fehler und wie man mit ihnen umgeht: »Toleranz und Rücksicht« . In Zeiten des Mitmach-Webs werden Formulare noch wichtiger, sie sind sozusagen das Bindeglied zwischen Web 1.0 und 2.0. Neben den für die Struktur benötigten HTML-Elementen und CSS für die Gestaltung kommt hier in der Regel noch JavaScript für das Verhalten der Formulare zum Einsatz. In der fest in der statischen Web 1.0-Welt verhafteten BITV ist Dynamik via JavaScript effektiv verboten, besonders wenn keine Alternativen ohne clientseitiges Scripting bereitgestellt werden. Viele Web-basierte Anwendungen sind jedoch ohne JavaScript kaum oder gar nicht nutzbar. Daher geht es in Teil 4 der Serie um »Dynamik in Formularen«. In Teil 5 der Serie zeigen wir, wie Sie mit einigen einfachen Tests schon während der Entwicklung eine erste Qualitäts­sicherung vornehmen können und geben Tipps für Tests mit echten Nutzern: »Testen von Formularen und Web-basierten Anwendungen«. Zum Abschluss geht es um Dinge, die sie besser nicht oder nur nach reiflicher Überlegung in ihre Formulare einbauen sollten: »Strittige Punkte«. http://www.einfach-fuer-alle.de/artikel/barrierefreie-formulare-mit-html-css-und-javascript/http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Barrierefreie-Formulare_Klaus.mp3Thu, 13 Sep 2007 18:24:07 +0200Tech Newsno01:32:42barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcagAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersBei all den Diskussionen um das Ziel barrierefreier Webangebote fällt eine spannende Frage schon mal gerne hinten runter: wer ist denn eigentlich für die Umsetzung verantwortlich?Bei all den Diskussionen um das Ziel barrierefreier Webangebote fällt eine spannende Frage schon mal gerne hinten runter: wer ist denn eigentlich für die Umsetzung verantwortlich? Zum Start unserer BITV-Reloaded-Serie haben wir eine Tabelle veröffentlicht, in der die Arbeiten zur Erfüllung der einzelnen Bedingungen den Beteiligten wie Kunde, Konzepter, Designer, Programmierer und Redakteur zugeordnet werden. Viele Aufgaben sind eindeutig zuzuordnen, wie zum Beispiel die Gewährleistung von ausreichenden Kontrasten für sehbehinderte Nutzer – dies ist Sache des Grafikers. Oder die Verknüpfung von Formularelementen mit ihren Beschriftungen via LABEL – hier sind die Frontend-Entwickler gefragt, die das HTML umsetzen. Ein ganze Reihe von Punkten ziehen sich jedoch wie ein roter Faden durch das ganze Projekt - zum Beispiel die Textalternativen bzw. Untertitel für multimediale Inhalte: der Konzepter muss sie vorsehen, der Grafiker in der Oberfläche berücksichtigen, der Programmierer muss sie technisch ermöglichen und in der laufenden Pflege verursachen sie ebenso laufenden Aufwand. Dabei sind die Zuordnungen in dieser Tabelle immer nur der frühestmögliche Zeitpunkt, um spätere Fehler zu vermeiden. Wenn zum Beispiel in den grafischen Entwürfen das Thema der ausreichenden Kontraste nicht berücksichtigt wurde, dann kann man diesen Fehler zwar im Nachhinein an der fertigen Website noch korrigieren – nur: dann wird's teurer. Gleiches gilt für alle anderen Punkte: wenn man an der richtigen Stelle ansetzt, dann bekommt man diese Punkte noch kosten- und aufwandsneutral oder zumindest mit vertretbarem Mehraufwand in das fertige Produkt eingearbeitet. Accessibility ist kein Plug-In, das man in eine bereits fertige Website installiert - es ist eine andere Art der Haltung gegenüber dem Nutzer. Der wichtige erste Schritt Sämtliche Beteiligten sollten sich bereits in der Planungsphase ein grundlegendes Verständnis davon aneignen, was Barrierefreiheit für ihr Projekt bedeutet, warum dieses Thema wichtig ist und wie man die richtigen Menschen und Werkzeuge für diesen Job auswählt. Die Literatur zu diesem Thema ist wie üblich vorzugsweise auf Englisch, aber ein guter Einstieg in das Thema bietet die britische Spezifikation PAS 78 mit dem Titel »Guide to good practice in commissioning accessible websites«. Links gibt's wie immer in der Mitschrift. Das W3C hat ebenfalls eine ganze Reihe Anleitungen veröffentlicht, wie man das Thema Barrierefreiheit in Projektplänen berücksichtigen sollte. Auf den Seiten der Web Accessibility Initiative finden sie diese in der Navigation unter dem Punkt »Managing Accessibility«. Auch diese Dokumente sind generell in englischer Sprache verfasst. Ausnahmen wie die übersetzte Checkliste der wichtigsten Barrieren und ein deutschsprachiges Mapping der WCAG 1.0-Checkpunkte auf die verschiedenen Formen von Behinderung bestätigen diese Regel. Einige im Netz kursierende Listen von Dienstleistern, die besonders zugängliche Webseiten liefern können, sind hingegen mit Vorsicht zu genießen. Hier wird oft lediglich anhand eines eingeschränkten Kriterienkatalogs getestet, wie sehr das Produkt ebendiesen Kriterienkatalog erfüllt. Damit kann man aber im Ernstfall nur beweisen, dass man den Kriterienkatalog gemeistert hat. Ob und wie diese Angebote auch von Menschen mit Behinderung getestet wurden und vor allem: wie diese Tests ausgefallen sind kann man aus diesen Listen nicht ableiten. Zum Verständnis der Problematik von Barrieren gehört das Wissen um die Hintergründe für die Existenz der jeweiligen Checkpunkte der WCAG bzw. Bedingungen der BITV. Bei vielen Punkten wird der Sinn erst klar, wenn man ihn aus der Sicht der Nutzer mit Behinderungen betrachtet: welche Barrieren entstehen für welche Nutzer, wenn ein Punkt nicht erfüllt ist. Die Richtlinien können hier nur einen ersten Ansatz bieten, zum besseren Verständnis muss man sich tatsächlich tiefer in das Thema einlesen. Die weit verbreitete Checklisten-Mentalität verleitet nach unserer Erfahrung sehr schnell dazu, die Barrierefreiheit auf ein rein technisches Thema zu reduzieren. Hiergegen hilft einerseits die Lektüre der zum Verständnis der Richtlinien wichtigen Techniken beim W3C und die möglichst frühe Verteilung der Verantwortlichkeiten für die einzelnen Teilbereiche in einem Projekt. Idealerweise gibt es in allen Projektteams eine Person, die für das Thema Barrierefreiheit verantwortlich ist und die, wenn es sein muss, alle anderen immer wieder damit nervt. Dabei reicht es wie gesagt nicht, wenn dieses Thema erst dann auf den Tisch kommt, wenn das Kind schon in den Brunnen gefallen ist. In der Phase der Umsetzung des Frontends kurz vor dem Start eines Webangebotes kann man zwar theoretisch noch viele Fehler ausbügeln, die sich in den vorhergehenden Projektphasen eingeschlichen haben. Allerdings riskiert man in dieser Phase, dass dann entweder die Accessibility oder der Launch-Termin gekippt werden müssen. Bei Angeboten, die Kraft Gesetzes zur Barrierefreiheit verpflichtet sind, muss die Entscheidung in einem solchen Fall für die Verschiebung des Starttermins fallen; bei kommerziellen Angeboten wird, so hat es die Erfahrung gezeigt, die Accessibility oftmals auf einen späteren Zeitpunkt verschoben und im Netz landet dann ein für viele Menschen unzugängliches Angebot. Die Aufteilung der BITV nach Verantwortlichkeiten ist natürlich eine sehr vereinfachte Darstellung, bzw. nur ein Drittel der Wahrheit. Zur barrierefreien Nutzung eines Web-Angebots gehören zusätzlich noch Dinge, auf die man als Anbieter oder als verantwortlicher Webentwickler keinen oder nur sehr begrenzten Einfluss hat. Die Werkzeuge Die Hersteller von Autorenwerkzeugen wie Dreamweaver und Frontpage, großen und kleinen Content Management Systemen, aber auch Blog-Tools wie Wordpress und Movable Type müssen ihr Drittel der Verantwortung für ein barrierefreies Netz ebenso tragen. Viele Punkte der BITV lassen sich nur umsetzen, wenn dies von den Autorenwerkzeugen überhaupt erst ermöglicht und unterstützt wird. Ein Redaktionssystem, dass bei Bilddaten automatisch den Copyright-Vermerk als Alternativtext einfügt scheitert damit schon am allerersten Checkpunkt der Richtlinien und wird wohl auch mit dem Rest seine lieben Nöte haben. Ein Tipp für Anbieter bei der Auswahl eines Redaktionssystems: falls Ihnen ein Anbieter verspricht, dass ein System selbstverständlich WCAG Level AAA bzw. BITV Priorität 2 vollautomatisch erfüllt, dann sollten Sie hellhörig werden – denn das geht gar nicht. Fragen Sie den Anbieter dann, ob er schon mal was von den »Authoring Tool Accessibility Guidelines« des W3C, den Richtlinien für Autorenwerkzeuge gehört hat und wie sein Produkt da abschneidet. Falls bei Ihnen gerade die Investition in ein neues Redaktionssystem ansteht finden Sie weitere Tipps in unserem Podcast vom 13. Dezember 2006 zum Thema » CMS und Webstandards«. Diese weithin unbekannten Richtlinien lassen sich jedoch nicht nur auf den Output eines Redaktionssystems anwenden; mit ihr lässt sich ebenso bewerten, ob das System auf der Eingabeseite von Menschen mit Behinderungen zu bedienen ist. Zudem fällt man als Anbieter ebenso unter die Ägide der ATAG, sobald man es Nutzern in seinem Webangebot ermöglicht selbst Inhalte einzustellen, und seien es nur Kommentare in einem Weblog – auch hier handelt es sich streng genommen bereits um ein Autorenwerkzeug. Diese Liste ließe sich noch beliebig erweitern – alle Programme, die über einen »Als HTML speichern…«-Knopf verfügen, müssen sich mindestens die folgenden Fragen gefallen lassen: - Fördert oder verhindert das Werkzeug die Erstellung und Pflege von barrierefreien Inhalten? Gibt es überhaupt Möglichkeiten, zum Beispiel Textalternativen für Nicht-Text-Inhalte wie Bilder und Multimedia einzupflegen? - Werden nach den Richtlinien sauber eingepflegte Inhalte 1:1 übernommen oder ›dekoriert‹ das System diese Inhalte nach seiner Vorstellung mit eigenem Code um? Besonders berüchtigt sind hier Systeme, die auch im Jahre 2007 noch hartverdrahtete Layout-Tabellen und font-Tags benutzen. - Falls vorgefertigte Templates verwendet werden: sind diese in den anwendbaren Punkten WCAG-konform? - Falls einige dieser Fragen negativ beantwortet werden müssen: gibt es als letzten Ausweg noch die Möglichkeit, die Inhalte vor der Auslieferung an den User auf dem Server zu säubern? - Bei immer wiederkehrenden Problemen mit dem Autorenwerkzeug sollten Sie ein Prozedere entwickeln, wie diesen Problemen schon im Vorfeld begegnet werden könnte, oder wie diese Probleme zumindest im Nachgang automatisch bereinigt werden. Die Ausgabeseite Womit wir beim letzten Drittel angelangt wären: alle Anstrengungen um ein barrierefreies Webangebot sind für die Katz', wenn sie von den Browsern und Hilfsmitteln gar nicht, nur unzureichend oder fehlerhaft unterstützt werden. Zwar gibt es hierfür ebenso eine passende Richtlinie beim W3C, die »User Agent Accessibility Guidelines« ( UAAG ), aber auf deren Einhaltung haben Anbieter und Ersteller von Webseiten naturgemäß den geringsten Einfluss. Hier liegt die Verantwortung bei den Nutzern, sich für ihre speziellen Bedürfnisse passende Soft- und Hardware zu beschaffen oder durch den Arbeitgeber beschaffen zu lassen. Dazu gehört die Bereitschaft des Nutzers, sich mit den zur Verfügung stehenden Hilfen und Anpassungsmöglichkeiten in seinem Browser zu beschäftigen. Dazu gehört auch die Bereitschaft, sich im Ernstfall nach Alternativen umzusehen. Für Blinde und Sehbehinderte bietet hier der Informationspool Computerhilfsmittel INCOBS einen ersten Einstieg mit Testberichten und weiteren Beratungsleistungen. Das bundesweite Kompetenz- und Referenzzentrum »barrierefrei kommunizieren!« unterhält eine Datenbank zu Behinderungskompensierenden Techniken für Computer im Allgemeinen und Internet im Speziellen. Im englischsprachigen Raum gibt es das hervorragende Angebot »My Web My Way« , das von AbilityNet zusammen mit der BBC erstellt wurde. Hier finden Sie einfach zu verstehende Anleitungen, wie die verschiedenen Betriebssysteme wie Windows, MacOS und Linux an die ganz speziellen persönlichen Bedürfnisse anzupassen sind. Ein Beispiel für die Notwendigkeit, dass alle Beteiligten an einem Strang ziehen ist die leidige Debatte um Bemaßungen in Pixel. Gemäß WCAG ist die Deklaration von Schriftgrößen in px erlaubt, da es sich um eine relative Maßeinheit handelt. Als Gegenargument hört man dann, dass der Internet Explorer so gesetzte Schrift nicht skalieren könne – was nicht ganz korrekt ist: er kann es, die Option dazu ist nur sehr gut in den Einstellungen versteckt. Der Browser ist damit UAAG-konform. Aber wie viele Layouts, die auf Pixel setzen, sind in der Realität noch wirklich brauchbar, wenn man die Schrift auf Extragroß stellt? Verwenden stark sehbehinderte Nutzer nicht ab einem gewissen Grad der Sehbehinderung eine spezielle Lupensoftware, mit der diese ganze Debatte zumindest für sie überflüssig wird? Wie sie sehen kann eine vollkommen barrierefreie Web-Nutzung nur dann möglich sein, wenn alle Beteiligten zusammenarbeiten. So, das war die vierundzwanzigste Ausgabe unseres Podcasts zum Thema barrierefreies Webdesign. In der nächsten Folge schauen wir uns mal etwas detaillierter an, wie man die Ideen des Barrierefreien Webdesigns in Arbeitsabläufe integrieren kann. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter dem Tag BITV , WCAG , ATAG und UAAG. Bis zum nächsten Mal. http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Verantwortung.m4aWed, 18 Jul 2007 08:00:01 +0200Tech Newsno00:14:48barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcag, atag, uaagAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas Caspers Konvertierungseinstellungen ändern« müssen Sie nun noch folgende Voreinstellungen prüfen: - In der Registerkarte »Einstellungen« sollten Sie sicherstellen, dass Lesezeichen, Verknüpfungen und Tags zum PDF hinzugefügt werden, - im Register »Sicherheit« muss der Zugriff für Sprachausgaben sichergestellt sein, - im Register »Word« sollten Sie die Übernahme von Querverweisen, Inhaltsverzeichnissen sowie Fuß- oder Endnoten ermöglichen und - im Register »Lesezeichen« die Übernahme der Überschriften, nicht jedoch der Word-Stile (Regelfall) prüfen. Dann kommt der PDF-Export Zur Erzeugung eines getaggten PDF muss das PDF über das Menü »Adobe PDF« erzeugt werden, auf keinen Fall über das Druckmenü. Als nächstes folgt dann die Weiterverarbeitung in Adobe Acrobat 7 Allen Dokumenten, die an diesem Punkt noch keine Tags besitzen, muss in Acrobat ein Tagbaum eingebaut werden. Die Funktion hierzu finden Sie unter »Erweitert > Ausgabehilfe > Tags zu Dokument hinzufügen«. Danach folgt die Optimierung der Dokumente, insbesondere die Darstellung und die Lesereihenfolge. Auch bei einer Vergrößerung (Menübefehl »Ansicht > Umfließen«) muss die Reihenfolge der Inhalte schlüssig sein. Korrekturen können Sie mit dem TouchUp-Leserichtungswerkzeug im Menü »Erweitert > Ausgabehilfe« oder durch Entfernen und Wiederhinzufügen von Tags vornehmen. - Alle Inhalte müssen im Kontrastmodus gelesen werden können. Diesen finden sie im Menü »Bearbeiten > Grundeinstellungen > Ausgabehilfe«. Dort können Sie Ihr Dokument in verschiedenen Vordergrund- und Hintergrundfarben anzeigen lassen. - Die Lesereihenfolge für Screenreader muss unter »Anzeige > Reihenfolge« geprüft und gegebenenfalls. korrigiert werden. - Unter »Erweitert > Ausgabehilfe > Vollständige Prüfung« muss geprüft werden, ob keine wesentlichen Inhalte außerhalb des Tagbaums stehen. - Unter »Erweitert > Ausgabehilfe > Vollständige Prüfung« muss geprüft werden, ob alle Bilder geeignete Alternativtexte besitzen. - Die Prüfung und Optimierung von Datentabellen müssen Sie unter »Werkzeuge > Erweiterte Bearbeitung > TouchUp-Leserichtungwerkzeug« vornehmen. - Die Dokumentstruktur sollte im Navigationsfenster »Tags« auf semantische Korrektheit geprüft werden. Hier müssen auch der Aufbau und die Konsistenz der Überschriftenstruktur geprüft werden, und ob Links korrekte Tags mit untergeordnetem Text und OBJR-Objekt besitzen. Durch rechten Mausklick auf einen Tag kann bei Bedarf eine Rollenzuweisung vorgenommen werden. - Im Navigationsfenster »Lesezeichen« muss geprüft werden, ob eine sinnvolle Navigationshilfe bereitgestellt ist. Zum Schluss der Feinschliff Weitere Anforderungen betreffen die Tab-Reihenfolge: Dokumente mit Links, Anmerkungen und Formularen sollten im Regelfall für die Tab-Reihenfolge »Dokumentstruktur« aufweisen. Unter »Datei > Dokumenteigenschaften > Erweitert > Leseoptionen > Sprache« muss zusätzlich noch die Hauptsprache des Dokuments, z.B. »Deutsch«, angegeben werden. Sprachwechsel können im Navigationsfenster »Tags« durch rechten Mausklick auf ein Tag (»Eigenschaften > Tag«) eingestellt werden. Unter »Erweitert > Ausgabehilfe > Vollständige Prüfung« muss geprüft werden, ob der verwendete Zeichensatz auch in Sprachausgaben nutzbar ist. Abschließend fehlt noch die Prüfung mit dem eingebauten Accessibility-Checker in Acrobat. Die vollständige Prüfung darf keine weiteren Fehler aufweisen. Das war die dreiundzwanzigste Ausgabe unseres Podcasts zum Thema barrierefreies Webdesign. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter dem Tag PDF. Bis zum nächsten Mal. ]]>Eine Anleitung zur Erstellung barrierefreier PDF hatten wir vor einiger Zeit bei EfA in Form einer Checkliste veröffentlicht. Hier gibt's die Tipps nochmals zum Nachhören, ergänzt durch ein paar weitere Infos zum Thema.Heute gibt's eine kurze Einführung in die Erstellung barrierefreier PDF-Dokumente, damit diese für eine Vielzahl von Nutzergruppen zugänglich aufbereitet werden können. Eine Anleitung zur Erstellung barrierefreier PDF hatten wir vor einiger Zeit bei EfA in Form einer Checkliste veröffentlicht. Hier gibt's die Tipps nochmals zum Nachhören, ergänzt durch ein paar weitere Infos zum Thema. Diese Checkliste ist selbstverständlich als barrierefreie PDF-Version zum Download erhältlich, Links zu diesen und allen anderen Tools und Dokumenten gibt es wie immer am Ende der Mitschrift. PDF - wie barrierefrei geht es? Im Prinzip gibt es vier Arten von PDF-Dokumenten, die alle unterschiedliche Grade von Barrierefreiheit aufweisen können: 1. Aus einem Grafik-Programm in ein PDF gedruckt – das Ergebnis wird definitiv nicht zugänglich sein. Typische Anwendungsfälle sind Broschüren und andere Druckwerke, die zum Beispiel in QuarkXPress erzeugt wurden und über den Drucken-Dialog in ein PDF geschrieben wurden. Diese Dokumente haben generell keine logische Struktur, die Texte sind nicht zugänglich, Bilder haben keine Alternativen und so weiter. Sie sind damit für Nutzer von Screenreader nicht zu gebrauchen. 2. Aus einer Textverarbeitung in ein PDF gedruckt – das Ergebnis wird wahrscheinlich nicht zugänglich sein. Der Text könnte zwar, je nach verwendetem Programm, leidlich zugänglich sein, darüber hinaus gehende Inhalte wie Tabellen, Bilder etc. werden meistens nicht korrekt ausgezeichnet und bleiben somit unzugänglich. 3. Aus einer Anwendung heraus mit automatischen Tags exportiert – könnte eventuell zugänglich sein. Voraussetzung ist die konsequente Nutzung von Formatvorlagen in der Textverarbeitung und der Export mit dem Plug-In, das mit Acrobat Professional installiert wird. Auch ohne Nachbearbeitung erhält man bei einfachen Ausgangsdokumenten schon ein leidlich zugängliches PDF; in der neuesten Version von Acrobat werden mittlerweile sogar Alternativtexte für Bilder korrekt übernommen, sofern man diese in der ursprünglichen Anwendung wie MS Word oder InDesign eingepflegt hat. Tabellen sind jedoch in der Regel nach wie vor unzugänglich und müssen manuell nachbearbeitet werden. 4. Tags manuell hinzugefügt und mit Sachverstand editiert – zugänglich. Die Königsklasse, aber leider auch die mit der meisten Handarbeit. Abgesehen vom finanziellen Aufwand für die Anschaffung von Acrobat Professional kommt hier noch die Arbeit hinzu, jedes Dokument von Hand durchzugehen und, wenn nötig, Tags hinzuzufügen oder vorhandene, falsch gesetzte, zu ändern. Was sind diese Tags? PDF-Dateien ohne Tags bestehen aus PostScript, einer Seitenbeschreibungssprache aus der Druckindustrie. PostScript wurde geschaffen, um Daten möglichst ohne Verlust und mit der nötigen Präzision in eine Druckmaschine zu bekommen. Und genau da liegt das Problem: bei Texten beschreibt PostScript nur die Form der Buchstaben, für den Druck so unwichtige Dinge wie Leerschritte zwischen Worten kennt die Sprache nicht. Sie beschreibt nur den Abstand, den ein Druckkopf bis zum Beginn des nächsten Wortes zurücklegen muss. Bei Überschriften sind die Vektoren dann einfach etwas größer – das macht die Überschrift aber noch lange nicht zur Überschrift im Sinne der Barrierefreiheit. Dieser Umstand führt bei unbearbeiteten PDF-Dokumenten häufig dazu, dass der gesamte Text als eine lose unstrukturierte Folge von Buchstaben ausgegeben wird und zum Beispiel von einem Screenreader genau so vorgelesen würde. Hier kommt nun das Konzept der »Tagged PDF« zur Hilfe: diese Tags, wie wir sie schon aus HTML kennen, stülpen dem unstrukturierten Inhalt eine XML-Struktur über, in der Überschriften, Absätze, Listen, Bilder, Tabellenzellen und vieles mehr definiert sind. Genau diese Tag-Struktur benötigen Hilfsmittel wie Screenreader, um die Inhalte in einer vernünftigen Form und in einer logischen Reihenfolge wiederzugeben. Welche Dokumente eignen sich für PDF und welche nicht? Die meisten Inhalte, die man als PDF im Netz findet, wären eigentlich besser in HTML aufgehoben. Für strukturierte Texte, die nicht ausschließlich zum Ausdrucken gedacht sind, sondern am Monitor gelesen werden sollen, ist HTML nach wie vor die bessere Wahl. Alleine aus ökonomischen Gründen kann man bei diesen Dokumententypen nur von der Konvertierung in PDF abraten. Der Aufwand zur Erstellung wirklich barrierefreier Dokumente, und das können wir aus eigener leidiger Erfahrung sagen, ist durch nichts zu rechtfertigen. Natürlich gibt es auch hier eine ganze Reihe Ausnahmen. Zulässige Anwendungszwecke für PDF sind zum Beispiel: - Dokumente, deren Aufbau sich nicht in HTML & CSS nachbilden lässt. HTML ist eine sehr eingeschränkte Sprache und kennt, trotz seines wissenschaftlichen Ursprunges, zum Beispiel keine Fußnoten. - Dokumente, die von anderen gegengelesen und mit Kommentaren versehen werden sollen. Auch hier bietet HTML keine adäquaten Mittel, Acrobat integriert jedoch mittlerweile einen kompletten Workflow für solche Anwendungszwecke. Übrigens: das Manuskript zu diesem Podcast ist auch auf diesem Weg entstanden. - Dokumente mit gesetzlichen Anforderungen an die Form, wie zum Beispiel Steuerformulare, Verträge und ähnliches. - Dokumente, die im Browser nicht oder nur mit exotischen Plug-Ins dargestellt werden können, die eh niemand installiert hat. Das können zum Beispiel CAD-Zeichnungen sein oder andere Vektorformate, aber auch mathematische Formeln. - Und zu guter Letzt: kopiergeschützte Dokumente. PDF hat hier ausgefeilte Mechanismen um zu verhindern, dass Inhalte unauthorisiert entnommen und weiterverbreitet werden. Die Vorgehensweise Für alle Dokumente gilt: bei barrierefreien PDF kommt es entscheidend darauf an, dass ein »Tagged PDF«, also ein strukturiertes PDF-Dokument produziert wird. »Tagged PDF« kann in Adobe Acrobat ab der Version 5 sowie anderen Adobe-Produkten erzeugt werden. Darüber hinaus ist OpenOffice 2 in der Lage, Tags zu erzeugen. Die Checkliste hier bei ›Einfach für Alle‹ soll kein umfangreiches Tutorial sein, sondern nur den Schnelleinstieg in die Thematik geben. Anleitungen und Lösungsstrategien für komplexere Probleme können Sie den Literaturhinweisen in der Mitschrift entnehmen. Daher gibt es einige Einschränkungen: 1. Es wird davon ausgegangen, dass PDF mit dem Adobe-Makro PDFMaker oder in einer anderen Anwendung erstellt wird, die »Tagged PDF« erzeugen kann. PDFMaker gehört ab der Version 6 zum Lieferumfang von Acrobat Professional und wird bei der Installation in diversen Anwendungen auf Windows- und Mac OS-Systemen automatisch integriert. Auf dem Mac wird allerdings bis zur Version 7 kein »tagged PDF« erzeugt. Leider steht von der neuen Version 8 noch keine Testversion für Mac OS X zur Verfügung. Daher konnten wir bisher nicht testen, ob dieser Mangel immer noch besteht. 2. Text, Formulare und diverse andere Objekte sowie interaktive Oberflächen müssen einzeln und in Abhängigkeit von der Erstellungssoftware behandelt werden. Die Checkliste beschränkt sich auf solche Dokumente, wie sie typischerweise in Microsoft Word oder OpenOffice erstellt werden. Der Einfachheit halber beschränkt sich die folgende Anleitung auf den typischen Workflow mit MS Word und Adobe Acrobat Professional. Das Wichtigste: konsequente Nutzung von Formatvorlagen Besonders zu beachten ist: Überschriften müssen über die Formatvorlage zugewiesen werden. Großer fetter Text macht noch keine Überschrift, das ist hier genau so wie in HTML. Gleiches gilt für die Funktionen für Listen, Fußnoten und Tabellen. Alternativtexte für Bilder sollten bereits in der Textverarbeitung hinterlegt werden - dort ist es weniger umständlich als diese später in Acrobat nachzuarbeiten. Hyperlinks in Dokumenten sollten gleich in der Textverarbeitung aktiviert werden, sofern sie später im PDF anklickbar sein sollen. Das Layout der Seiten ist mit Spaltenfunktion oder Textfeldern, nicht mit Tabellen oder Tabulatoren zu gestalten. Kopf- und Fußzeilen sollten keine wesentlichen Informationen enthalten. Die Konvertierung in PDF Im Menü »Adobe PDF > Konvertierungseinstellungen ändern« müssen Sie nun noch folgende Voreinstellungen prüfen: - In der Registerkarte »Einstellungen« sollten Sie sicherstellen, dass Lesezeichen, Verknüpfungen und Tags zum PDF hinzugefügt werden, - im Register »Sicherheit« muss der Zugriff für Sprachausgaben sichergestellt sein, - im Register »Word« sollten Sie die Übernahme von Querverweisen, Inhaltsverzeichnissen sowie Fuß- oder Endnoten ermöglichen und - im Register »Lesezeichen« die Übernahme der Überschriften, nicht jedoch der Word-Stile (Regelfall) prüfen. Dann kommt der PDF-Export Zur Erzeugung eines getaggten PDF muss das PDF über das Menü »Adobe PDF« erzeugt werden, auf keinen Fall über das Druckmenü. Als nächstes folgt dann die Weiterverarbeitung in Adobe Acrobat 7 Allen Dokumenten, die an diesem Punkt noch keine Tags besitzen, muss in Acrobat ein Tagbaum eingebaut werden. Die Funktion hierzu finden Sie unter »Erweitert > Ausgabehilfe > Tags zu Dokument hinzufügen«. Danach folgt die Optimierung der Dokumente, insbesondere die Darstellung und die Lesereihenfolge. Auch bei einer Vergrößerung (Menübefehl »Ansicht > Umfließen«) muss die Reihenfolge der Inhalte schlüssig sein. Korrekturen können Sie mit dem TouchUp-Leserichtungswerkzeug im Menü »Erweitert > Ausgabehilfe« oder durch Entfernen und Wiederhinzufügen von Tags vornehmen. - Alle Inhalte müssen im Kontrastmodus gelesen werden können. Diesen finden sie im Menü »Bearbeiten > Grundeinstellungen > Ausgabehilfe«. Dort können Sie Ihr Dokument in verschiedenen Vordergrund- und Hintergrundfarben anzeigen lassen. - Die Lesereihenfolge für Screenreader muss unter »Anzeige > Reihenfolge« geprüft und gegebenenfalls. korrigiert werden. - Unter »Erweitert > Ausgabehilfe > Vollständige Prüfung« muss geprüft werden, ob keine wesentlichen Inhalte außerhalb des Tagbaums stehen. - Unter »Erweitert > Ausgabehilfe > Vollständige Prüfung« muss geprüft werden, ob alle Bilder geeignete Alternativtexte besitzen. - Die Prüfung und Optimierung von Datentabellen müssen Sie unter »Werkzeuge > Erweiterte Bearbeitung > TouchUp-Leserichtungwerkzeug« vornehmen. - Die Dokumentstruktur sollte im Navigationsfenster »Tags« auf semantische Korrektheit geprüft werden. Hier müssen auch der Aufbau und die Konsistenz der Überschriftenstruktur geprüft werden, und ob Links korrekte Tags mit untergeordnetem Text und OBJR-Objekt besitzen. Durch rechten Mausklick auf einen Tag kann bei Bedarf eine Rollenzuweisung vorgenommen werden. - Im Navigationsfenster »Lesezeichen« muss geprüft werden, ob eine sinnvolle Navigationshilfe bereitgestellt ist. Zum Schluss der Feinschliff Weitere Anforderungen betreffen die Tab-Reihenfolge: Dokumente mit Links, Anmerkungen und Formularen sollten im Regelfall für die Tab-Reihenfolge »Dokumentstruktur« aufweisen. Unter »Datei > Dokumenteigenschaften > Erweitert > Leseoptionen > Sprache« muss zusätzlich noch die Hauptsprache des Dokuments, z.B. »Deutsch«, angegeben werden. Sprachwechsel können im Navigationsfenster »Tags« durch rechten Mausklick auf ein Tag (»Eigenschaften > Tag«) eingestellt werden. Unter »Erweitert > Ausgabehilfe > Vollständige Prüfung« muss geprüft werden, ob der verwendete Zeichensatz auch in Sprachausgaben nutzbar ist. Abschließend fehlt noch die Prüfung mit dem eingebauten Accessibility-Checker in Acrobat. Die vollständige Prüfung darf keine weiteren Fehler aufweisen. Das war die dreiundzwanzigste Ausgabe unseres Podcasts zum Thema barrierefreies Webdesign. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter dem Tag PDF. Bis zum nächsten Mal. http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Barrierefreie-PDF.m4aMon, 02 Jul 2007 08:00:00 +0200Tech Newsno00:15:45barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcagAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersIn der letzten Ausgabe hatten wir uns den aktuellen Stand der WCAG 2.0 angesehen, heute schauen wir uns mal nach Alternativen um.Hallo, hier ist wieder der Podcast von ›Einfach für Alle‹, der Aktion Mensch-Initiative für barrierefreies Webdesign. In der letzten Ausgabe hatten wir uns den aktuellen Stand der WCAG 2.0 angesehen, heute schauen wir uns mal nach Alternativen um. Die WCAG 1.0 und damit die bundesdeutsche BITV sind bekanntlich etwas in die Jahre gekommen, und die seit langem geplante Nachfolge-Empfehlung des W3C wird wohl auch in diesem Jahr nicht fertig werden. Wobei – die grundlegenden Prinzipien des barrierefreien Webdesigns haben sich nicht geändert. Es geht nach wie vor ausschließlich um den ungehinderten Zugang und die ungehinderte Nutzung von Webinhalten für Menschen mit Behinderungen. Was sich geändert hat sind die Mittel und Wege, um dies zu erreichen. Problematisch wird dies für Anbieter, die Kraft Gesetzes zur Einhaltung der BITV ohne Wenn und Aber verpflichtet sind. Ähnliches gilt für nicht-staatliche Anbieter, die sich freiwillig oder im Rahmen einer Zielvereinbarung zur Anwendung BITV verpflichtet fühlen. So findet man in letzter Zeit häufiger Ausschreibungen mit Texten wie »Der Bieter sichert die vollständige Einhaltung der Barrierefreien Informationstechnik-Verordnung zu.« – eigentlich ein schöner Erfolg für eine Bundesverordnung, wenn nicht das ungute Gefühl bliebe, dass dies in der Praxis nicht immer von Erfolg gekrönt sein wird. Wie wir im Rahmen unserer »BITV Reloaded«-Serie gezeigt haben bestehen die der BITV zu Grunde liegenden Richtlinien zumindest zum Teil aus Punkten, die - noch nie wirklich sinnvoll waren, - früher sinnvoll waren, aber heute obsolet sind bzw. nicht mehr der gängigen Praxis entsprechen, oder - aufgrund der historischen Entwicklung neu interpretiert werden müssen. Wenn man ein wenig in den Archiven des W3C wühlt findet man Hinweise, dass bereits kurz nach der Veröffentlichung der WCAG 1.0 ein so-genanntes Errata-Dokument erstellt werden sollte, um die gröbsten Schnitzer der Richtlinie zu korrigieren. Einige Anfänge wurden damals schon gemacht, insbesondere im Bereich der allseits beliebten »until user agents…«-Checkpunkte. Allerdings sind diese Errata bis heute nicht fertiggestellt worden, um die Arbeiten an den WCAG 2.0 nicht weiter aufzuhalten. Damals ging man noch davon aus, dass diese zeitnah erscheinen würden – bei dieser frommen Hoffnung blieb es bis heute. Dabei sind nachträgliche Fehlerkorrekturen an W3C-Empfehlungen durchaus keine Seltenheit: HTML 4.01 und CSS 2.1 korrigieren ebenfalls die jeweiligen .0-Versionen und bringen sie auf eine Linie mit der gängigen Praxis in den Webbrowsern. Dass selbst wissenschaftlich fundierte Theorien und die praktische Umsetzung von einander abweichen ist ebenfalls keine Seltenheit: der Sinn von Theorien ist, dass sie widerlegt werden, um auf dieser Basis bessere Theorien entwickeln zu können. Spulen wir vor bis ins Jahr 2007: die WCAG 2.0 sind immer noch nicht fertig, und ein offizielles Errata-Dokument, dass die veralteten Aspekte der Version 1.0 korrigiert, gibt es immer noch nicht. Eine Gruppe um den kanadischen Accessibility-Experten Joe Clark hat am 7. Juni den ersten Entwurf eines Errata-Dokumentes für die WCAG 1.0 veröffentlicht. Sie nennen sich die » WCAG Samurai«, was wohl eine Anspielung auf den japanischen Kultfilm »Die Sieben Samurai« des Regisseurs Akira Kurosawa ist; vielleicht nimmt man auch Bezug auf die »CSS Samurai« des Web Standards Project, die mit dem Acid-Test die Epoche der standard-konformen Browser einläuteten. Ob die Samurai ihre Arbeit wie im Film für nur drei Mahlzeiten am Tag verrichten war nicht in Erfahrung zu bringen, und über die Mitglieder der Gruppe schweigt sich die Seite wcagsamurai.org aus. Wobei die Besetzung auch eher was für die Klatschspalten ist, wir interessieren uns hier nur frei nach Altkanzler Kohl für das was hinten rauskommt: Die WCAG Samurai Errata Schauen wir uns doch mal an, was die Samurai gemacht haben, oder besser erstmal, was sie nicht gemacht haben: - Die Gruppe hat keine Korrekturen am gegenwärtigen Stand der WCAG 2.0 veröffentlicht, es geht alleine um eine Klarstellung und teilweise Fehlerbehebung der Version 1.0. - Man übt auch keinerlei Kritik am W3C und seinen Arbeitsgruppen. - Die jetzt veröffentlichte Version ist ein erster Entwurf, Kritiken und Verbesserungsvorschläge werden über die auf der Website genannten Kanäle entgegengenommen. Was man hingegen gemacht hat ist: - Mehrdeutige oder schwammige Formulierungen wurden präzisiert. Es gibt kein »until user agents...« mehr, Worte wie »Sie sollten…« oder »vermeiden« gibt es nicht mehr. Eine Richtlinie ist entweder anzuwenden oder nicht, wenn sie nicht anwendbar ist. - Wenn eine Website konform zu den Samurai-Errata ist, dann muss sie die Vorgaben der Priorität 1 und 2 erfüllen. - Valider Code ist ebenfalls absolutes Muss. Die einzige zulässige Ausnahme ist die Verwendung von EMBED. - Sämtliche Richtlinien zu Layout-Tabellen und Frames wurden gestrichen. Gleiches gilt für ASCII-Art - der historisch kuriose Checkpunkt 13.10 wurde ebenfalls gestrichen. - NOSCRIPT entfällt. Skripte und alle Arten von Web-basierten Anwendungen müssen direkt zugänglich sein. - Viel Wert legen die Samurai auf die Semantik. Webentwickler werden angehalten, alle Inhalte und Funktionen mit dem jeweils passenden HTML-Element auszuzeichnen, auch wenn dies oftmals nur eine ungefähre Annäherung bedeutet – der Umfang von HTML ist bewusst begrenzt und kann nicht alle Eventualitäten präzise definieren. - PDF-Dokumente werden klar geregelt: das meiste, was besser in HTML aufgehoben wäre, muss auch HTML sein. Die Errata listen einige zulässige Ausnahmen von dieser Regel, diese PDFs müssen strukturiert, getaggt und damit direkt zugänglich sein. - Auch bei multimedialen Inhalten ist man strenger als die WAI: Videos mit Tonspur müssen untertitelt sein, je nach Inhalt müssen Videos Audiodeskriptionen enthalten, Podcasts mit gesprochenem Text (wie dieser hier) müssen auch verschriftet werden, und einfache Text- oder HTML-Dateien sind kein adäquater Ersatz für synchrone Untertitel. - Sämtliche Checkpunkte von WCAG-Level 3 und damit der BITV Priorität 2 werden nicht behandelt. Die Begründung der Samurai hierfür ist, dass diese Punkte entweder veraltet sind, keine Barriere darstellen, in Tests nicht verifizierbar sind, oder eigentlich Sache der Browser und Hilfsmittel wären. Die zu vernachlässigende Checkpunkte werden einzeln aufgelistet und in einer Webentwickler-kompatiblen Art und Weise werden die Gründe für den Wegfall dargelegt. Baustellen Kognitive Behinderungen: wie die WCAG 1.0 und 2.0 bleibt in den Errata eine große Lücke in diesem Bereich. Wie alle Richtlinien leiden sie an einem Mangel an in der Praxis umsetzbaren Erkenntnissen, wie der Zugang für diese Nutzergruppen barrierefreier gestaltete werden könnte. So wurde die Vorgabe zur einfachen Sprache unangetastet gelassen, es sind aber auch keine neuen Checkpunkte in diesem Bereich hinzu gekommen. Im Gegensatz zu den WCAG berechtigt die Feststellung der Konformität zu den korrigierten Richtlinien jedoch nicht zu der Behauptung, die Seiten seien damit für alle Menschen mit Behinderung zugänglich. Konformität Wie kann man diese Erkenntnisse nun in seine Webangebote einbauen? Nicht ganz einfach: die WCAG Samurai Errata basieren auf den WCAG 1.0; sie ergänzen und korrigieren die Richtlinie und sind somit auch 1:1 auf die BITV anwendbar. Hier ergibt sich für Anbieter ein Problem: konform zu WCAG Level AA ist man nur, wenn man sämtliche Checkpunkte der Priorität 2 erfüllt. Die Samurai Errata streichen aber eine ganze Reihe von Punkten in allen Prioritäten, sodass man automatisch nicht mehr WCAG-konform ist, sobald man die Samurai Errata anwendet. Für was man sich entscheidet bleibt letztendlich dem Anbieter überlassen, beides zusammen jedoch geht nicht. Mit den Errata hat man jedoch auf jeden Fall die modernere Variante gewählt, die eher der gängigen Praxis und den Erkenntnissen aus den letzten acht Jahren entspricht. Kritikpunkte Der Entwurf durchläuft zurzeit so-genannte »Peer Reviews«, in denen weitere Experten den Text gegenlesen und ihre Anmerkungen veröffentlichen. Links zu diesen Reviews wie immer im Anhang der Mitschrift. Auch wenn das ganze bisher hinter verschlossenen Türen entwickelt wurde sollte sich niemand mit Expertise davon abhalten lassen, die Dokumente genau zu lesen und eventuelle Anmerkungen und Verbesserungsvorschläge zu machen. Das war die zweiundzwanzigste Ausgabe unseres Podcasts zum Thema barrierefreies Webdesign. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags WCAG , und BITV . Bis zum nächsten Mal.http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_WCAG-Errata.m4aSun, 24 Jun 2007 22:41:34 +0200Tech Newsno00:11:31barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcagAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersNach einer kurzen Winterpause widmen wir uns heute einem Thema, dass uns seit Jahren unter den Nägeln brennt: der überfälligen Aktualisierung der Web Content Accessibility Guidelines (WCAG) auf die Versionsnummer 2.0.Hallo, hier ist der Podcast von Einfach für Alle, der Aktion Mensch-Initiative für barrierefreies Webdesign. Nach einer kurzen Winterpause widmen wir uns heute einem Thema, dass uns seit Jahren unter den Nägeln brennt: der überfälligen Aktualisierung der Web Content Accessibility Guidelines (WCAG) auf die Versionsnummer 2.0. Vor über einem Jahr veröffentlichte die Web Accessibility Initiative des W3C einen Entwurf der WCAG in Form eines so-genannten Last Call, der für erhebliche Unruhe sorgte. Last Call bedeutet in der Hierarchie der W3C-Standard-Entwürfe, dass es sich um ein weitestgehend stabiles Dokument ohne grobe Schnitzer handelt, das auf dem besten Weg zur endgültigen Empfehlung ist. So sah es die Arbeitsgruppe - dass dies nicht so war zeigte die hohe Anzahl von Kommentaren zur Veröffentlichung des Entwurfs bis hin zu formellen Einsprüchen, die nach der Veröffentlichung eingegangen sind. Viele der Kommentare bezogen sich auf esoterische Details, einige zweifelten aber die grundlegende Struktur und Zielsetzung der Richtlinie an, in der sich zum Beispiel Menschen mit Lernbehinderungen nur unzureichend berücksichtigt sahen. Das vergangene Jahr hat die WAI-Arbeitsgruppe genutzt, um hunderte Kommentare und Verbesserungsvorschläge zu sichten und, sofern sinnvoll, in die WCAG 2.0 einzuarbeiten. Das Resultat ist der am 17. Mai veröffentlichte Entwurf, den wir uns etwas näher angesehen haben. Links zu allen besprochenen Dokumenten finden Sie wie üblich am Ende der Mitschrift von diesem Podcast. Einen Überblick über die Struktur und Inhalte des Entwurfs erhält man durch die Lektüre von: »Overview of Web Content Accessibility Guidelines 2.0 Documents« Die Version mit der Änderungsverfolgung bietet den besten Einblick in die vollzogenen Änderungen bei den zentralen Richtlinien - trotz des unmöglichen Designs und des sehr gewöhnungsbedürftigen Markup. Sie zeigt gestrichene und neu eingefügte Texte, und im Kontext wird per Link auf den dafür verantwortlichen Kommentar verwiesen. So lassen sich die Hintergründe für die Änderungen erschließen. Was ist neu? Die wohl wichtigste Änderung: dieser Entwurf der WCAG 2.0 hat nicht mehr den Status eines Last-Call-Dokumentes, sondern wurde zu einem einfachen Arbeitsentwurf (engl.: Working Draft) degradiert. Dies geschah vor dem Hintergrund der schieren Masse der notwendig gewordenen Änderungen, die bis in grundlegende Konzepte reichten. Die schlechte Nachricht dabei: der jetzige Stand dient als Grundlage für weitere Entwürfe oder auch für einen erneuten Last Call Working Draft. Zwischen diesen und einer endgültigen, fertigen und auf allgemeinem Konsens beruhenden Richtlinie liegen noch einige Schritte, um den Formalien des W3C zu genügen. Damit dürfte klar sein: mit einer Fertigstellung der WCAG 2 ist wohl auch im Jahre 2007 erneut nicht zu rechnen. Eine weitere wichtige Neuerung ist eine deutlichere Herausstellung der Grenzen der Barrierefreiheit. Die neue Version sagt bereits in der Einleitung, dass auch die vollständige Befolgung der Richtlinie nicht unbedingt dazu führt, dass ein Angebot die Nutzung für alle Formen der Behinderung oder Mehrfachbehinderung ermöglicht. Ebenfalls neu ist der deutliche Hinweis, dass die WCAG nur einen Baustein in der Erreichung eines barrierefreieren Webs darstellen. In der Einleitung wird deutlich auf die Verantwortung der Hersteller von Browsern, assistiven Hilfsmitteln, aber auch Redaktionssystemen und Entwicklungstools hingewiesen. Auch neu: das Konzept der Baseline-Assumptions wurde wieder gekippt. Diese Konstruktion wurde in einem vorhergehenden Entwurf eingeführt, um Webautoren die Möglichkeit zu geben, technische Mindestanforderungen für die sinnvolle Nutzung an die verwendeten Browser und Hilfsmittel zu stellen. Das ganze wird nun »accessibility support« genannt und beschreibt die Zugänglichkeits-Features der verwendeten Techniken wie HTML, CSS, JavaScript, Flash oder PDF. Die Bedingungen haben sich trotz der Umbenennung nicht wirklich geändert: die Technik muss öffentlich dokumentiert sein und von den gängigen Browsern und Hilfsmitteln unterstützt werden. Damit wird eine große Verantwortung von den Webentwicklern genommen und auf die Hersteller von Browsern, Hilfsmitteln und Nicht-W3C-Formaten übertragen. Dem durchschnittlichen Webentwickler ist es kaum zuzumuten, seine Werke mit dem riesigen Spektrum von Hilfsmitteln zu testen. Statt dessen werden deren Hersteller in die Pflicht genommen für die Unterstützung anerkannter und verbreiteter Techniken in ihren Produkten zu sorgen. Zum besseren Verständnis der Richtlinien gibt es nun unmittelbar erreichbare Links auf das Dokument »Understanding WCAG 2.0«. Dort wird die Intention der jeweiligen Richtlinie beschrieben, eventuell verwendete Fachbegriffe werden erklärt und es werden zusätzliche Techniken zur Erfüllung aber auch gängige Fehler aufgelistet. Ein häufiger Kritikpunkt an der Last-Call-Version waren die vielen Neuschöpfungen, mit denen die Arbeitsgruppe bestimmte Sachverhalte klar definieren wollte, die aber kaum jemand verstanden hat, oder die sogar erheblich von anderen, gebräuchlicheren Definitionen abwichen. Nun wird die Bedeutung von Wortungetümern wie »Programmatically Determined« bereits in der Richtlinie erklärt, für andere unverständliche Phrasen wie »Delivery Unit« wurden bessere Ersetzungen gefunden. Begründungen für diese und alle anderen Änderungen sind in dem Text »Summary of Changes Since the 2006 WCAG 2.0 Last Call Working Draft« auf den Seiten der WAI zu finden. Was ist nicht neu? Gleich geblieben ist die Struktur der Richtlinien. Die vier Prinzipien sind nach wie vor: Wahrnehmbar, Bedienbar, Verständlich und Robust. Unterhalb dieser 4 Prinzipien gibt es insgesamt 12 Richtlinien, die aus einer Anzahl von Erfolgskriterien bestehen, mit denen die Richtlinien und Prinzipien erfüllt werden können. Diese Erfolgskriterien sind der für Webentwickler eigentlich interessante Kern des Ganzen. Hier wird beschrieben, welche Eigenschaften ein Angebot haben muss, um die jeweilige Richtlinie zu erfüllen. Wie dies inhaltlich, gestalterisch oder technisch zu erreichen ist, wird dann in weiteren Dokumenten, den so-genannten Techniques beschrieben. Aus der Summe der erreichten Erfolgskriterien ergibt sich dann am Schluss die bereits bekannte Abstufung in WCAG Level A, AA und AAA. Dabei fehlt auch hier nicht der deutliche Hinweis, dass ein Erreichen von Level AAA nicht automatisch die absolute Barrierefreiheit bedeutet und dass eine Nicht-Erfüllung bei sämtlichen Erfolgskriterien Barrieren für manche Nutzergruppen darstellen kann, unabhängig davon, ob das Kriterium nun bei A, AA oder AAA angesiedelt ist. Offene Baustellen Wie eingangs erwähnt bestehen gerade bei Menschen mit kognitiven Behinderungen erhebliche Vorbehalte gegen die Richtlinien in ihrer jetzigen Form. Die WAI-Arbeitsgruppe erkennt ihre Defizite in diesem Bereich und kündigt weitere Nachforschungen an, um diese Lücken zu schließen: »Although some of the accessibility issues of people with cognitive, language, and learning disabilities are addressed by WCAG 2.0, either directly or through assistive technologies, the WCAG 2.0 guidelines do not address many areas of need for people with these disabilities. There is a need for more research and development in this important area.« Übersetzt heisst dies: »Obwohl einige der Barrieren angesprochen werden, die Menschen mit kognitiven, Sprach- und Lernbehinderungen betreffen, sei es direkt oder durch assistive Techniken, so gehen die WCAG 2.0 doch nicht auf viele Bedürfnisse von Menschen mit diesen Behinderungen ein. Es gibt Bedarf an mehr Forschung und Entwicklung in diesem wichtigen Bereich.« Die WAI-Arbeitsgruppe steht vor einem Problem: viele Barrieren in der Web-Nutzung sind zwar für die Betroffenen deutlich und gravierend, aber individuelle Barrieren lassen sich oft nicht einfach in eine Richtlinie integrieren. Eine ganze Reihe von Erfolgskriterien der WCAG 2.0 stehen ebenfalls noch in der Diskussion. Diese sind in den Richtlinien an der nachgestellten »Editorial Note« zu erkennen. Bei einigen sind bereits mögliche Lösungen beschrieben. Diese sind noch nicht endgültig, einige der Anforderungen könnten also durchaus noch rausgestrichen werden. Die nächsten Schritte Die WAI-Arbeitsgruppe bittet interessierte Fachleute, die Dokumente zu lesen und eventuelle Anmerkungen bis zum 29. Juni einzureichen. Eine Liste der Dokumente, die zur Diskussion stehen finden Sie auf den Seiten der Web Accessibility Initiative beim W3C. Besonders interessant sind die Fragen: - Sind die Richtlinien und die Erfolgskriterien klar und verständlich? Falls nicht, wie könnte man es besser formulieren? - Gibt es Erfolgskriterien, die nicht umsetzbar oder nicht testbar sind? Wenn ja, wie könnten sie verbessert werden? - Gibt es Erfolgskriterien, mit denen die Zugänglichkeit eines Angebotes nicht verbessert wird, oder die sogar neue Barrieren errichten? Auch hier wieder die Bitte der Arbeitsgruppe um Verbesserungsvorschläge. Der einfacheren Verarbeitung halber sollten Kommentare über die bereitgestellten Formulare gemacht werden. Das war die einundzwanzigste Ausgabe unseres Podcasts zum Thema barrierefreies Webdesign. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von Einfach für Alle unter den Tags WCAG, und BITV. Bis zum nächsten Mal.http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_WCAG2-Entwurf.mp3Sun, 03 Jun 2007 12:59:56 +0200Tech Newsno00:11:22barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcagAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersHeute geht es um Barrierefreiheit 2.0 – heute die Altlasten von morgen vermeidenHeute geht es um Barrierefreiheit 2.0. Der Text ist als Artikel im Adventskalender der Webkrauts erschienen, wo bis zum 24. Dezember jeden Tag ein neues Türchen zu Themen wie Webstandards, Content Management, Barrierefreiheit, Web 2.0 usw. aufgemacht wird. Einige Artikel werden wir hier in loser Folge auch als Podcast veröffentlichen – heute gibt es einen Artikel von Tomas Caspers zum Thema: Barrierefreiheit 2.0 – heute die Altlasten von morgen vermeiden Ein gemeinsamer Nenner aller Dinge, die als Web 2.0 durchs Netz geistern ist ein Mehr an Dynamik, ein Mehr an Interaktion des Nutzers mit dem Angebot und darüber hinaus mit anderen Nutzern: das Lesen-Schreiben-Ausführen-Web. Will man die Barrierefreiheit von dynamischen, Web-basierten Anwendungen sicherstellen, dann stößt man schnell an die Grenzen der Richtlinien. Die geltenden Richtlinien für barrierefreie Webinhalte, die WCAG 1.0 des W3C bestehen nun schon seit beinahe sieben Jahren in unveränderter Form. Ein Nachfolger ist zwar in der Entwicklung, der Zeitpunkt der Fertigstellung steht jedoch in den Sternen . Da wundert es nicht, dass die Web Content Accessibility Guidelines in der Version 1.0 für viele Dinge im Web 2.0 nicht anwendbar sind oder modernere Techniken wie sauberes DOM-Scripting sogar effektiv unmöglich machen, auch wenn diese für die Erstellung Web-basierter Anwendungen zwingend nötig sind. Dieses Manko kann man den Richtlinien nicht zum Vorwurf machen; stammen sie doch aus einer Zeit, als das Web größtenteils aus, wie es im W3C-Sprech so schön heißt, »strukturierten Dokumentensammlungen« bestand. Für Websites, die lediglich aus statischen Inhalten ohne Interaktionsmöglichkeiten für den Nutzer bestehen sind die Richtlinien, wenn auch mit gewissen Abstrichen, nach wie vor anwendbar. Rückwärtsgang oder Vorwärtsgang? Das Web und die verwendeten Techniken haben sich jedoch seit Inkrafttreten der Richtlinien massiv weiterentwickelt. Das vom W3C auch schon mal als worst invention ever bezeichnete JavaScript hat in den letzten zwei Jahren eine phänomenale Wandlung vom Pfuiwort zu einer allgemein anerkannten Technik für die Erstellung von Web-basierten Applikationen hingelegt. Wer hätte gedacht, dass man mittlerweile Flash zusammen in einem Satz mit Barrierefreiheit erwähnen darf? Das Programm hat sich von einer verpönten Spielwiese zu einem ernstzunehmenden Werkzeug für die Erstellung zugänglicher Rich-Media-Inhalte gemausert. Der englische Accessibility-Experte Mike Davies meint dazu : Its time to admit, Flash is part of the web accessibility toolbox. Auch die von Menschen mit Behinderung vielfach eingesetzten Hilfsmittel sind längst dem unzureichenden Stand der Technik entwachsen, denen die »Until User Agents…«-Klauseln der WCAG 1.0 begegnen sollten. Moderne Screenreader kommen mit zeitgemäßen Scripting-Techniken und auch mit barrierefrei aufbereiteten Flash-Inhalten sowie gut strukturierten PDF-Dokumenten sehr gut zurecht. Wenn man dynamische Webinhalte mit echten Screenreader-Nutzern testet (und das ist dringend zu empfehlen – Barrierefreiheit ist keine Fingerübung im Abhaken von Checklisten ), stellt man oft fest, dass die meisten Hürden gar nicht technischer Natur sind. Vielfach liegt es an einer Mischung aus konzeptionellen Mängeln im Angebot selbst und dem ungewohnten Umgang der Nutzer mit dynamischen Web-Applikationen, resultierend aus der Erwartungshaltung, dass das Web ein weitestgehend statisches Medium sei. Der theoretische Part Nach wie vor fordern die Richtlinien von den Anbietern dynamischer Inhalte, zusätzlichen Aufwand in parallele statische Versionen zu stecken, da die WCAG von Hilfsmitteln ausgehen, für die diese Techniken in der Tat ausgesprochen problematisch waren. Man beachte die Betonung auf »waren«. Staatliche Anbieter brauchen gar nicht erst versuchen, dieses Paradoxon aufzulösen – sie sind per Verordnung zur Einhaltung der Richtlinien verpflichtet: BITV 6.2 - Es muss sichergestellt sein, dass Äquivalente für dynamischen Inhalt aktualisiert werden, wenn sich der dynamische Inhalt ändert. BITV 6.3 - Es muss sichergestellt sein, dass mittels Markup–Sprachen geschaffene Dokumente verwendbar sind, wenn Scripts, Applets oder andere programmierte Objekte deaktiviert sind. Privatwirtschaftlich organisierte Anbieter können sich jedoch der eigentlich spannenden Frage zuwenden: wie stellt man die direkte Zugänglichkeit von dynamischen Webinhalten sicher? Aus Sicht der Anbieter wie auch aus Sicht der Nutzer scheint der Einsatz lange verpönter Techniken wie AJAX sinnvoller als die von den Richtlinien eingeforderten statischen Alternativen. Die verlangten statischen Alternativen sind zudem in Zeiten von Google Office , Excel 2007 , Basecamp und .Mac Webmail keine wirkliche Alternative mehr, sondern fördern eher noch die digitale Spaltung, wenn sie nicht sogar konzeptionsbedingt unmöglich sind. Der Praxisteil Nehmen wir ein erdachtes, aber durchaus realistisches Szenario: bei einem bekannten Internet-Auktionshaus laufen gleichzeitig tausende Auktionen ab; gleichzeitig wollen zehntausende Bieter wissen, wie das aktuelle Höchstgebot ist. Die Seiten, die kurz vor Ablauf der Auktionen immer wieder neu geladen werden, sind, wie für dieses Auktionshaus typisch, eher etwas zu groß geraten. Das Auktionshaus hat also ein permanentes Problem mit der Serverlast, die Nutzer haben ein permanentes Problem mit den Antwortzeiten des Servers. Und das alles nur, um zu erfahren, ob sich eine vielleicht vierstellige Zahlenfolge geändert hat und man nicht mehr der Höchstbietende ist. Alleine aus einer simplen Abwägung von Kosten und Nutzen heraus ist es sowohl für das Auktionshaus wie auch für dessen Nutzer ist hier der Einsatz von AJAX oder ähnlichen Techniken sinnvoll. Das jeweils aktuelle Höchstgebot wird in Echtzeit per Skript ausgetauscht, ohne das jedes Mal die kompletten Seiten neu geladen werden. Die von den WCAG eingeforderte statische Alternative gibt es weiterhin (weil ja schon vorhanden) und die Richtlinien zu Barrierefreiheit sind damit (zumindest auf dem Papier) erfüllt. Dumm nur: mit der statischen Alternative gewinnt man keine Auktion mehr, da diese zwar WCAG-konform ist, aber damit auch langsamer. Das Fazit Tests der WaSP Accessibility Task Force haben ergeben, dass Screenreader nahezu die gleichen Probleme mit Änderungen in Seiten oder Anwendungen haben, egal ob sie dynamisch erfolgt sind oder durch einen kompletten Neuaufbau der Seite. Die Ursache der Probleme scheinen also nicht dynamische Änderungen per Skript zu sein, sondern Änderungen generell. Es kann eigentlich nur im ureigensten Interesse der Nutzer assistiver Hilfsmittel wie Screenreader, Lupenprogrammen etc. sein, dass Ihre Schnittstellen ins Web 2.0 dessen Möglichkeiten auch vollständig ausnutzen, sie korrekt umsetzen und so eine gleichberechtigte Teilnahme von Menschen mit Behinderungen ermöglichen. Um dies zu erreichen muss sich die Erkenntnis durchsetzen, dass die Web Content Accessibility Guidelines des W3C lediglich ein Drittel der Richtlinien zur Barrierefreiheit ausmachen. Auch die User Agent Accessibility Guidelines ( UAAG ) und insbesondere die Authoring Tools Accessibility Guidelines ( ATAG ) sind ebenso wichtig, um das umfassende Ziel eines barrierefreieren Web 2.0 zu erreichen. Wenn jedoch weiterhin die gesamte Verantwortung auf die Webentwickler abgewälzt wird, die mit Interimslösungen ihren Redaktionssystemen, Autorenwerkzeugen, aber auch den Browsern und Hilfsmitteln auf die Sprünge helfen müssen, die sich ihrerseits nicht im mindesten an die Standards halten, dann werden damit die Altlasten von morgen geschaffen. Und Interimslösungen können, wie wir alle wissen, ziemlich langlebig sein… So, das war mal wieder eine Ausgabe unseres accessCast. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von Einfach für Alle unter den Tags Barrierefreiheit , JavaScript , Hilfsmittel und Web 2.0 .http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Barrierefreiheit20.m4aWed, 20 Dec 2006 08:00:00 +0100Tech Newsno00:10:58barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcag, Web 2.0Aktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersHeute geht es um Content-Management-Systeme und ob und wie sie die Erstellung von sauberen Inhalten unterstützen.Heute geht es um Content-Management-Systeme und ob und wie sie die Erstellung von sauberen Inhalten unterstützen. Der Text ist als Artikel im Adventskalender der Webkrauts erschienen, wo bis zum 24. Dezember jeden Tag ein neues Türchen zu Themen wie Webstandards, Content Management, Barrierefreiheit, Web 2.0 usw. aufgemacht wird. Einige Artikel werden wir hier in loser Folge auch als Podcast veröffentlichen – heute gibt es einen Artikel von Ansgar Hein vom Barrierekompass zum Thema: Content-Management und Webstandards Die Kosten für die Pflege von Websites durch professionelle Webdesigner wären auf Dauer für die meisten Website-Betreiber kaum bezahlbar. Kein Wunder also, dass sich in den vergangenen Jahren Content-Management-Systeme für die Verwaltung von kleinen, mittleren und großen Websites durchgesetzt haben. Von eher statischenen Lösungen zur Verwaltung von Inhalten, bis hin zu datenbankbasierten Web-Content-Management-Systemen ( WCMS) reicht die Bandbreite an Editiermöglichkeiten, wobei die meisten Anwendungen im WCM-Bereich modernen Textverarbeitungen in vielen Aspekten sehr ähnlich sind und deren Funktionalitäten zum Teil sogar übersteigen. Moderne Content-Management-Systeme sind entweder wahre Multi-Talente oder Spezialisten: Für jedes Problem findet sich eine geeignete Lösung, was angesichts von mehr als 1.400 Programmen allein im deutschsprachigen Raum, die bei Contentmanager gelistet sind, nicht weiter verwunderlich ist. Häufig werden Content-Management-Systeme auch als Redaktionssysteme bezeichnet, was den Verwendungszweck besser beschreibt. In der Tat werden vor allem WCMS zunehmend von Redakteuren für die regelmäßige und wiederkehrende Erstellung und Pflege von Website-Inhalten genutzt. Arbeitserleichterung durch Redaktionssysteme Neben der gemeinschaftlichen Erstellung und Bearbeitung des Inhalts ermöglicht ein CMS auch dessen Organisation. Durch die Trennung von Inhalt, Struktur und Design tragen Content-Management-Systeme dazu bei, dass eine Ausgabe der Inhalte in verschiedenen Formaten ( HTML, PDF, usw.) möglich ist und dabei die Einhaltung eines vorgegebenen Gestaltungsrasters (Corporate Design) gewährleistet bleibt. Je nach Komplexität und Leistungsfähigkeit kommen Benutzer- und Rechteverwaltung sowie die Steuerung ganzer Arbeitsprozesse (Workflows) ebenso hinzu, wie die Erweiterbarkeit durch Module und Funktionen. Insgesamt sind Content-Management-Systeme dazu prädestiniert, Prozesse zu vereinfachen und Qualität zu verbessern. Leider arbeiten viele Redaktionssysteme jedoch noch immer nicht im Sinne der Webstandards. Anders lässt es sich kaum erklären, dass mehr als 90% aller Internetseiten nicht den aktuellen W3C-Standards für HTML entsprechen, obwohl die entsprechenden HTML-Vorlagen den Anforderungen genügen. In der noch jungen Vergangenheit von Content-Management-Systemen liegt einer der Hauptgründe für die mangelhafte Unterstützung von Webstandards: Die Entwcklung vieler Systeme fällt genau in die Zeit der Browserkriege und ist eng verbunden mit verschachtelten Layout-Tabellen, JavaScript-Lösungen und Frame-Technologie in Front- und Backend. Angetrieben durch die rasante Entwicklung bei Weblogsystemen haben nun zahlreiche Hersteller begonnen Webstandards in ihre Content-Management-Systeme zu integrieren und Funktionen zur Qualitätssicherung bereitzustellen. Leistungsfähigkeit Generell gilt: Nahezu jedes Content-Management-System, zumal im Open Source-Bereich, kann standardkonforme und zum Teil sogar barrierefreie Websites ausgeben. Dazu benötigt man Vorwissen, Zeit, sowie geeignete Templates und gute Programmierer, die entsprechende Lösungen direkt im Kern des CMS integrieren, ohne dabei die Update-Fähigkeit des gesamten Systems zu gefährden. Letzteres ist vor allem aus Sicherheits-Aspekten wichtig, denn fast regelmäßig tauchen Sicherheitslücken auf, die von den Herstellern kurzfristig mit Bugfixes und Updates beseitigt werden. Schlecht wäre es da, wenn die Updates nicht installiert werden könnten, um die Standardkonformität oder die Barrierefreiheit nicht zu gefährden. Inzwischen werden immer häufiger standardkonforme Weblog-Systeme mit viel Aufwand zu Content-Management-Systemen aufgerüstet , so dass Standardkonformität und Barrierefreiheit im Mittelpunkt stehen und die Erweiterbarkeit sowie die Bedienbarkeit für den Redakteur ins Hintertreffen geraten. Es droht ein schwieriger Spagat zwischen Funktionalität und Webstandards, daher hier ein paar Tipps, wie man als Webstandardista ein geeignetes Content-Management-System findet und damit auch glücklich wird. Anforderungen: Worauf man achten sollte In Anbetracht der Tatsache, dass Open Source-Systeme einen großen Verbreitungsgrad erlangt haben und von kleinen bis hin zu großen Websites nahezu jedes Einsatzgebiet abdecken und überdies in den meisten Fällen kostenlos zu haben sind, fokussieren wir uns bei den Betrachtungen auf Systeme aus diesem Bereich. Häufig kommen Content-Management-Systeme ohne Workflow-Verwaltung aus, da die meisten Redaktionen nur aus wenigen Mitarbeitern bestehen und die notwendigen Informationen schneller und effizienter ausgetauscht werden können, zum Beispiel via E-Mail. Schauen wir also zuerst auf die Ausgabe der Inhalte in Form einer gestalteten Website, im Folgenden mit Frontend bezeichnet, denn die detailgetreue und mediengerechte Umsetzung spielt für Kunden und Gestalter gleichermaßen eine wichtige Rolle. Doch auch die Qualität des ausgegebenen Quelltextes ist von Bedeutung: 1. Valider Quellcode Produziert das Content-Management-System validen Quellcode entsprechend den Richtlinien des W3C und gilt diese Aussage auch für Module? Und neben der Validität: Ist der Quelltext frei von Layout-Tabellen und Frames bzw. ist dies mit dem CMS möglich? 2. Saubere URLs Gibt es eine Möglichkeit, saubere URLs statt eines Kauderwelschs aus Zahlen, IDs, Ampersands (Und-Zeichen [&]) oder dergleichen auszugeben, ggf. auch als Erweiterung? 3. Navigation Können Menüs beliebig abgebildet werden und sind aktivierte Menüpunkte als Nicht-Links darstellbar? Sind mehrere Menüs unabhängig voneinander möglich? 4. Bilder Sind alle Bilder mit sinnvollen Alternativtexten hinterlegt (zum Beispiel nicht alt="bild 29 01 2006.jpg")? 5. Suchfunktion Gibt es eine Suchfunktion ggf. auch als Erweiterung) und wenn ja, sind die Suchergebnisse sinnvoll strukturiert? Nicht immer sind alle diese Funktionen und Features anhand einer Demo-Seite oder anhand der Beschreibung des Content-Management-Systems ersichtlich. In den meisten Fällen kommt man daher um eine genauere Betrachtung des Backends (Administration) nicht herum, um herauszufinden, was ein System leisten kann und was nicht. Wem die eigenhändige Installation auf einem Testserver zu mühsam ist, der kann sich mit einem Besuch bei OpenSourceCMS.com weiterhelfen lassen: Dort findet man eine Auswahl von mehr als 140 Content-Management-Systemen aus dem Open Source-Bereich, inklusive einer lebhaften Community und deren Bewertungen sowie der Möglichkeit, die Systeme im Front- und Backend zu testen. Natürlich kann man auch selbst eine Installation anlegen, um herauszufinden, ob ein bestimmtes Redaktionssystem den Anforderungen entspricht. Oftmals kann es auch hilfreich sein, in den entsprechenden Foren, Wikis, Hilfeseiten und Handbüchern nachzulesen, welche Funktionen ein CMS zur Verfügung stellt und wie man diese zur Sicherstellung von Webstandards beziehungsweise Barrierefreiheit nutzen kann. Qualitätssicherung über alles Letzten Endes geht es darum, geeignete Verfahren zur Qualitätssicherung zur Hand zu haben und zwar möglichst auf allen Stufen eines Prozesses. Idealerweise sollte ein Redakteur, der mit der Erstellung und Pflege von Inhalten betraut ist und meist kein spezielles HTML-Wissen vorweisen kann, gar nicht erst etwas davon mitbekommt, was im Hintergrund passiert. Mit anderen Worten: Der Quelltext sollte möglichst tabu sein. Glücklicherweise gibt es eine Reihe von Werkzeugen im Open Source-Bereich, die Hilfe versprechen. Allen voran Tidy , das man zur Säuberung, Formatierung und Verbesserung von produziertem Quellcode nutzen kann. Weitere Möglichkeiten eröffnen Validatoren , die eine Seite bereits in der Vorschau auf mögliche Fehler überprüfen können – danach ist der Redakteur jedoch meist auf sich alleine gestellt und weiß womöglich nur, das ein Fehler vorliegt, nicht aber, wie dieser behoben werden kann. Weitere Maßnahmen zur Qualitätssicherung können aussagefähige Hilfefunktionen für den Nutzer sein, die möglichst im engeren Kontext zur aktuellen Aufgabe angeboten werden sollten. Auch hier offenbaren viele Content-Management-Systeme eklatante Schwächen, obwohl gerade der Aspekt kontextsensitiver Hilfen in den Authoring Tools Accessibility Guidelines ( ATAG) eine wichtige Rolle spielt. Kaum verwunderlich also, dass bisher kein Redaktionssystem diese Richtlinien erfüllen kann. Worauf man im Einzelnen im Backend-Bereich, also der Administrations-Oberfläche des Systems, achten sollte: 1. Konfigurierbare Editoren Von WYSIWYG bis Textile und Markdown sollte ein Redakteur entscheiden können, wie Inhalte gepflegt werden. Ein gutes System passt sich an den Redakteur an, nicht umgekehrt. 2. Content is King Inhalte sollten möglichst zentral, sprich unter einem zentralen Punkt einzugeben sein und mit Hilfe einer einheitlichen Eingabemaske erfasst werden. 3. WYSIWYG plus X Redakteure sollten das bekommen, was sie sehen und noch etwas mehr: Auswahlmasken für interne Links, Verknüpfungen zur Bilddatenbank, Zugriff auf den Download-Bereich und vieles mehr, ohne HTML-Kenntnisse, ohne Umwege und ohne Wenn und Aber sollten im WYSIWYG-Modus selbstverständlich sein. 4. XHTML oder HTML? Für die einen Philosophie, für die anderen Notwendigkeit: Ein gutes CMS überlässt dem Template-Gestalter beziehungsweise dem Administrator die Frage ob mit oder ohne X im HTML gearbeitet wird. 5. Trennung von Inhalt, Struktur & Logik Gute Systeme trennen Inhalte von der Struktur, noch bessere trennen sogar die Logik (Programmierung / Funktionalität) von Inhalt & Struktur. So bleibt in der Datenbank am Ende nur (semantisch aufbereiteter) Inhalt zurück, zumindest im Idealfall. Jede Erweiterung, die ein Mehr an Funktionalität im Frontend bedeutet, muss ebenfalls allen zuvor genannten Kriterien gerecht werden. Ältere Systeme offenbaren hier nicht selten Problembereiche, da allzu oft Tabellen-Layouts in den Modulen hart verdrahtet sind. Moderne Content-Management-Systeme bieten pro Modul eigenständige Templates an und ermöglichen so in der Regel eine individuellere Anpassung. Skalierbarkeit und Flexibilität Der Appetit kommt häufig mit dem Essen und nicht wenige Websites werden im Laufe der Zeit im Hinblick auf Funktionsumfang und Leistungsfähigkeit deutlich erweiteret. Jetzt schlägt die Stunde jener Content-Management-Systeme, die eine schnelle und einfache Integration zusätzlicher Bestandteile erlauben – seien es bereits bestehende Module aus der Community oder aber eigens erstellte Erweiterungen. Die Abwesenheit einer gut dokumentierten Schnittstelle für Module, die eine möglichst einfache Erstellung von neuen Funktionen ermöglicht, ist ein häufig anzutreffendes Manko. Hier profitieren die Platzhirsche unter den Content-Management-Systemen von ihrer Erfahrung und offerieren meist stabilere Schnittstellen, die jedoch hinsichtlich der Variabilität oftmals zahlreiche Wünsche offen lassen. Nur wenige Webdesigner entwickeln eigenständige Module. Rudimentäre Kenntnisse in PHP oder anderen Scripting-Sprachen sind oftmals vorhanden und sollten bei einem guten CMS auch ausreichen, um den gewünschten HTML-Code zu erzeugen. Zahlreiche Content-Management-Systeme bieten eigene Scripting-Sprachen an, wieder andere nutzen bestehende Templating-Syteme und allzu viele Systeme bieten keine dieser Lösungen an. Häufig besteht die einzige Möglichkeit, auf den Quelltext einzuwirken, dann darin, dass man am offenen Herzen operiert und den Code des Content-Management-Systems im Hinblick auf die entsprechende Funktionalität modifiziert. Doch nicht nur im Bereich programmierter Lösungen ist Flexibilität ein entscheidender Vorteil, sondern in der generellen Handhabung von Inhalten und Strukturen. Sowohl im Hinblick auf das Format ( HTML, XML, RSS, usw.) als auch hinsichtlich der Templates (Menü-Anordnung, Spalten-Anzahl, usw.) sollte ein Webdesigner alle Freiheiten genießen – ohne viel Konfigurationsaufwand. Gleichzeitig sollte ein Redakteur diese Möglichkeiten nur durch das Bestätigen einer Auswahl nutzen können, ohne sich weitere Gedanken machen zu müssen. Kurzum: Flexibilität darf nicht auf Kosten von Gebrauchstauglichkeit und Webstandards gehen. Fazit Jede Technik, egal wie gut sie auch sein mag, kann den Menschen bei der Produktion bestenfalls unterstützen. Fehlerquellen sollten nach Möglichkeit im Vorfeld durch das System reduziert werden, Tätigkeiten des Redakteurs hingegen reglementiert und auftretende Fehler im besten Falle korrigiert. Content-Management-Systeme, die all das leisten können, gibt es nicht fertig von der Stange. Je komplexer die Anwendungsfälle, je mehr Module benötigt werden und je vielschichtiger der Aufbau der Redaktion ist, desto mehr muss ein Redaktionssystem leisten. Die Fragen nach Aufwand, Leistungsfähigkeit und Alltagstauglichkeit bestimmen den Auswahlprozess maßgeblich, wirken jedoch in unterschiedliche Richtungen. Kompromisse sind somit unausweichlich und die Suche nach dem Mittelweg ist gleichermaßen die Suche nach dem geeigneten Content-Management-System.http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_CMS.m4aWed, 13 Dec 2006 08:00:00 +0100Tech Newsno00:18:17barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcag, atag, cms, content managementAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersHeute geht's um Dinge im Web, die ihre besten Zeiten schon lange hinter sich haben, die aber scheinbar nicht auszurotten sind...Heute geht's um Dinge im Web, die ihre besten Zeiten schon lange hinter sich haben, die aber scheinbar nicht auszurotten sind. Der Text ist als Artikel im Adventskalender der Webkrauts erschienen, wo bis zum 24. Dezember jeden Tag ein neues Türchen zu Themen wie Webstandards, Content Management, Barrierefreiheit, Web 2.0 usw. aufgemacht wird. Einige Artikel werden wir hier in loser Folge auch als Podcast veröffentlichen – den Anfang macht heute Nicolai Schwarz , Webdesigner aus Dortmund mit dem Thema: Veraltete Praktiken im Webdesign Kein anderes Medium verändert sich so schnell wie das Internet. Jedes Jahr kommen neue Techniken und Standards hinzu, die den User das Netz besser erleben lassen und dem Webdesigner die Arbeit erleichtern. Nun muss nicht jede Website den Stand der Dinge widerspiegeln. Andererseits ist es bedauerlich, wenn neue Webseiten online gehen, die sich immer noch an den Trends des letzten Jahrtausends orientieren. Hier finden Sie eine Liste von alten Gepflogenheiten, die zwar seit einigen Jahren überholt, aber immer noch nicht ausgemerzt sind. Optimiert für … In der zweiten Hälfte der Neunziger Jahre kämpften der Netscape Navigator und Microsofts Internet Explorer um die Vorherrschaft unter den Browsern. Große Firmen konnten es sich damals leisten, ihre Webseiten in zwei Versionen anzulegen, um beiden Browsern gerecht zu werden. Kleine Firmen begnügten sich oft mit einer Version für eines der beiden Programme. Aus dieser Zeit stammen Vermerke auf der Website wie "Diese Website ist optimiert für den Internet Explorer ab Version 5.5". Heutzutage unterstützen alle gängigen Browser Webstandards gut genug, um sich bei der Entwicklung nicht mehr auf einzelne Exemplare beschränken zu müssen. Dennoch gehen auch heute noch Websites online, die nur auf einen einzelnen Browser angelegt sind. Warum? Lassen Sie sich gerne vorschreiben, welchen Browser Sie benutzen sollen? Websichere Farben Vielleicht haben Sie auch davon gehört, dass es im Netz nur 216 wirklich websichere Farben gäbe. Das sind Farben, die an allen Monitoren immer gleich angezeigt werden. Das Konzept der 216 Farben stammt etwa aus dem Jahr 1995, als Grafikkarten und Monitore mit einer Farbtiefe von 8-Bit Standard waren. Heutzutage liegt die Farbtiefe bei 24 Bit und darüber. Die 216 websicheren Farben sind mittlerweile gar nicht mehr websicher und technisch überholt. Nutzen Sie ruhig das Farbspektrum des RGB-Modells aus. Testen Sie das Ergebnis auf verschiedenen Monitoren und gewöhnen Sie sich daran, dass die Farben nicht auf allen Geräten gleich aussehen werden. Die 100kb-Grenze Eine übliche, einzelne Webseite besteht aus vielen Elementen: der grundlegenden HTML-Datei, einer CSS-Datei für das Design, Bildern, unter Umständen kommen noch Datein für JavaScript oder Flash-Animationen hinzu. Vor ein paar Jahren galt die Devise, mit allen Elementen unter einer Gesamtgröße von 100 Kilobyte pro Seite zu bleiben, besser noch um die 60-70 Kilobyte zu liegen. Mittlerweile haben sich die Geschwindigkeiten im Internet um ein Vielfaches gesteigert. Zwar surfen immer noch einige Leute mit langsameren Modems, dennoch dürfen Sie in Anbetracht der großen Verbreitung von DSL die 100kb-Grenze getrost ignorieren. Wenn Sie Ihren Besuchern für die zusätzlichen Kilobyte auch wirklich einen Mehrwert bieten können! Splash Pages Unter einer Splash Page versteht man eine Begrüßungsseite. Sie enthält meist nur eine Grafik oder eine Flash-Animation und in seltenen Fällen auch ein wenig Text. Über einen Link (z.B. "Skip Intro") gelangen Sie zur eigentlichen Site. Im Regelfall enthält die Splash Page nichts, was der Leser nicht auch auf der richtigen Seite findet. Sie kostet ihn nur einen unnötigen Klick. Also: Weg damit! In Ausnahmefällen jedoch kann eine Splash Page Sinn machen. Wenn sie nämlich nur zeitweise vorgeschaltet ist, um etwa auf ein Gewinnspiel, ein neues Produkt oder auch einen Trauerfall in der Firma hinzuweisen. Flash-Intro (mit Musik) Um die Jahrtausendwende war es noch schick, seine Website mit einem Flash-Intro zu eröffnen. Das war eine Zeitlang neu und hip, erfüllte in dem meisten Fällen aber gar keinen Zweck. Das Logo wurde aufgeblendet, ein paar Zeilen Text huschten von links nach rechts, fertig. Heutzutage gilt ein selbstgefälliges Flash Intro als vollkommen überflüssig. Eine richtige Plage sind Flash-Animationen, die den Besucher mit überraschender lauter Musik oder Sprache vom Stuhl hochschrecken lassen. Wie etwa bei dieser Seite des Mecklenburgischen Staatstheaters Schwerin . Eine unnötige Splash Page mit nervendem Ton, auch noch in einer Endlosschleife. Wehe dem, der seine Lautsprecher eingeschaltet hat. Wenn schon unbedingt Musik eingebaut werden muss, sollten Sie ein Stück auswählen, das langsam und behutsam anfängt. Und es sollte einen schnell zu findenden Button geben, mit dem ein Besucher den Sound stumm schalten kann. Als Lesezeichen/Startseite anbiedern Auch dies ist eine Unsitte aus alten Tagen: Buttons oder Links, die anbieten, diese Seite zu den Favoriten bzw. den Lesezeichen hinzuzufügen - oder schlimmer noch: diese Seite zur Startseite zu machen. Oft genug ist dies bei Seiten zu finden, die schlichtweg uninteressant sind. Mittlerweile können Sie davon ausgehen, dass ein User seine Lesezeichen und Startseiten selbst einstellen kann. Was er bei informativen und nützlichen Seiten auch tun wird. Laufschriften Das Element, das seit etwa 1996 weit oben auf meiner persönlichen Liste dummer Spielereien steht: Laufschriften bzw. Nachrichtenticker. Früher gab es dafür ein eigenes Tag namens marquee, mittlerweile wird der Effekt durch JavaScript erzeugt. Das Lästige ist, dass man jeweils nur einen Teil der Meldung sieht. Außerdem liest jeder User unterschiedlich schnell. Einige Betrachter kommen mit dem Lesen nicht nach, andere werden hibbelig, weil der Ticker zu langsam läuft. Es spricht nichts dagegen, die Meldung als Ganzes auf die Seite zu setzen. Wenn sie so wichtig ist, finden Sie in ihrem Design auch einen Platz dafür. Und statt die Aufmerksamkeit durch die Bewegung auf sich zu ziehen, können Sie mit Farben, Pfeilen oder Schriftgrößen arbeiten. Das aktuelle Datum Manchmal ist auf kleinen Seiten gut sichtbar das aktuelle Datum eingebaut. Das soll dem User Aktualität vorgaukeln. In vielen Fällen wirkt es eher lächerlich, wenn der erste Text z.B. darauf hindeutet, dass er bereits einige Monate alt ist. Von den meisten Websites erwartet niemand, dass sie täglich gepflegt werden. Anstatt die ganze Seite mit einem Datum zu versehen, können Sie besser die einzelnen Meldungen mit Datum versehen. Je nachdem, was Ihre Firma macht, kann es ausreichen alle ein bis zwei Monate eine neue Meldung online zu stellen. Besucherzahlen Auch dieses Thema sollte längst den Weg alles Irdischen gegangen sein. Könnte man meinen. Wenn mich nicht ab und zu noch Kunden danach fragen würden. Deshalb deutlich: Counter, die die Besucher zählen und dann für alle sichtbar auf einer Webseite vermerken, sind mittlerweile nicht nur überholt, sondern schon unseriös. Ohnehin: Niedrige Zahlen möchte niemand zeigen, hohe Zahlen wirken geschummelt. Was mehr Sinn macht, ist beispielsweise auf die Anzahl von Downloads eines Programms oder einer Broschüre zu verweisen. Oder die Anzahl der Mitglieder einen Community zu nennen. Zumindest dann, wenn Sie dabei eine Menge erreicht haben, mit der Sie zufrieden sein können. Baustellengrafiken Ein Relikt aus Zeiten, in denen eine Website ohne ein halbes Dutzend zappelnder animierter gif-Grafiken keine richtige Website war. Aus jener Zeit stammen unzählige Baustellengrafiken, die alle sagen: Hier gibt es (noch) nichts zu sehen. Heutzutage löst ein professioneller Webdesigner das Dilemma, indem er eine neue Site zunächst einmal mit einem Platzhalter – bestehend aus Logo, den Kontaktdaten und einem kurzen Text – versieht, um die Inhalte dann nach und nach hinzuzufügen. Die Navigation enthält zu Beginn noch nicht alle Menüpunkte und wächst mit den Inhalten. Mehr Nervendes Zu all diesen kleinen Unsinnigkeiten gesellen sich neue aus den letzten Jahren: Zum Beispiel Popups mit unerwünschten Werbeeinlagen, Disclaimer, die keinen Nutzen haben oder Captcha-Abfragen, die niemand entziffern kann. So, das war mal wieder eine Ausgabe unseres accessCast. Wir haben hier natürlich nur einen kleinen Ausschnitt der möglichen Nervensägen bringen können. Wenn Sie noch weitere Kandidaten für das nervigste Feature des Jahres haben haben können Sie diese gerne als Kommentar hier zu diesem Podcast oder drüben bei den Webkrauts posten.http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Veraltet.m4aWed, 06 Dec 2006 16:46:56 +0100Tech Newsno00:11:34barrierefrei, webdesign, accessibility, webkrautsAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersIn der heutigen Folge geht es um die Weiterentwicklung von HTML und um die Frage, in welche Richtung es weitergeht und wie sich Webentwickler daran beteiligen können...In der heutigen Folge geht es um die Weiterentwicklung von HTML und um die Frage, in welche Richtung es weitergeht und wie Webentwickler sich daran beteiligen können. Der folgende Text wurde im Auftrag der Web Hypertext Application Technology Working Group ( WHATWG ) geschrieben und ist in gleicher Form beim Web Standards Project , in den Weblogs von Molly Holzschlag , Roger Johansson und Lachlan Hunt veröffentlicht worden. Um möglichst viele Interessierte zu erreichen und dem deutschsprachigen Fachpublikum die Teilnahme zu ermöglichen veröffentlichen wir diesen Text hier in einer deutschen Übersetzung der Webkrauts . Wenn Sie Kommentare und Anregungen zur Weiterentwicklung von HTML haben können Sie diese in Englisch bei den oben genannten Sites machen. Wenn sie lieber in Deutsch kommentieren können Sie dies gerne hier oder unter www.webkrauts.de tun – die Webkrauts werden sich um die Übersetzung und Weiterleitung kümmern. Beteiligen Sie sich an der Zukunft von HTML Im Web wurde in letzter Zeit viel über die Entscheidung des W3C diskutiert, HTML weiterzuentwickeln . Blogposts und Nachrichten in Mailinglisten und Foren haben eine ganze Reihe Fragen über die Zukunft von HTML (einschließlich HTML 5 und XHTML 2) aufgeworfen und Mißverständnisse über die WHATWG und die neue HTML-Arbeitsgruppe des W3C aufgedeckt. Einige Leute baten um neue Features ; andere haben sich gefragt, ob nun veraltete Elemente wieder zurückkehren; einige veröffentlichten Kommentare und kritische Anmerkungen zu der Entscheidung als solche , der WHATWG oder den Abläufen im W3C; einige erhoben Bedenken, dass die WHATWG und das W3C die Bedürfnisse spezieller Gruppen ignoriertens . Die WHATWG, die sich mitten in der Entwicklung der nächsten Version von HTML (genannt HTML 5) befindet ist der Meinung, dass es wichtig sei, diesen Rückmeldungen nicht nur zuzuhören, sondern sie auch aktiv zu suchen und zu beantworten, so dass wir eine Sprache entwickeln können, die Ihre Bedürfnisse trifft. Es gibt viele Wege, wie Sie sich beteiligen können. Der direkte Ansatz, um sich Gehör zu verschaffen ist, die Mailingliste zu abonnieren. Allerdings hat nicht jeder die Zeit, aktiv teilzunehmen und diese hochfrequentierte Liste zu verfolgen. Einige fühlen sich vom Umfang der aktuellen Entwürfe ( Web Applications und Web Forms ) abgeschreckt. Andere meinen, dass man sowieso nicht auf sie hört, weil sie sich die hohen Mitgliedsbeiträge des W3C nicht leisten können. Wenn Sie, egal aus welchem Grund, der Meinung sind, dass sie an der Entwicklung nicht teilhaben können, oder sich bei dem Gedanken daran nicht wohlfühlen heisst das nicht, dass sie nicht gehört werden sollten. Die WHATWG will von Ihnen wissen, was Sie über HTML denken. * Gibt es Einschränkungen in HTML, die sie gerne aufgehoben sähen? * Haben Sie Ideen für neue Features? * Gibt es etwas, dass man zwar jetzt schon in HTML machen kann, das aber verbessert werden sollte? * Haben Sie Bedenken hinsichtlich des Entwicklungsprozesses? * Haben Sie Kommentare zu den neuen Features in den aktuellen Entwürfen? * Haben Sie irgendwelche Fragen zu HTML 5? Alle Fragen, Kommentare, Kritiken, Beschwerden oder Wünsche zu Features sind gerne gesehen. Jetzt ist die Zeit, sich Gehör zu verschaffen. Kein Kommentar ist zu dämlich, keine Frage zu schwierig oder zu einfach, keine Kritik ist zu hart. Wenn Sie irgendetwas zu sagen haben – die WHATWG hört Ihnen zu. Bitte hinterlassen Sie einen Kommentar oder posten Sie einen Link zu einem Artikel, den Sie geschrieben haben. Sie werden gehört und die Arbeitsgruppe wird versuchen zu antworten. So, das war mal wieder eine Ausgabe unseres accessCast. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags Webstandards und HTML .http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_HTML5.m4aFri, 17 Nov 2006 23:36:40 +0100Tech Newsno00:05:44barrierefrei, webdesign, accessibility, barrierefreies webdesign, HTML5, WHATWG, WebstandardsAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersHeute geht's um die für viele unserer Hörer spannende Frage, ob und wie der IE7 mit assistiven Werkzeugen zusammenarbeitet...In der letzen Folge hatten wir uns die beiden neuen Browser IE7 und Firefox 2.0 angesehen. Heute geht's um die für viele unserer Hörer spannende Frage, ob und wie der IE mit assistiven Werkzeugen zusammenarbeitet. Auch wenn die Open-Source-Alternativen in letzter Zeit mächtig aufgeholt haben, so laufen die meisten Hilfsmittel bei den Nutzern nach wie vor unter Windows. Beim Rumsurfen im Web bedeutet das im überwiegenden Fall: Internet Explorer. Windows Vista ist ja bekanntlich auch schon auf dem Weg ins Brennwerk und unbestätigten Gerüchten zufolge wird es keine, wir wiederholen, keine Version des IE6 für Vista geben. Da der Nachfolger IE7 über die automatischen Systemupdates verteilt wird, werden in nächster Zeit auch viele Nutzer von Hilfsmitteln wie Screenreadern und Lupenprogrammen mit dem neuen Browser in Berührung kommen. Im Web gab es schon einige Diskussionen darüber, ob und wie die diversen Hilfsmittel mit dem IE7 reibungslos funktionieren. Deswegen haben wir bei den Hilfsmittelherstellern und auch bei Microsoft nachgelesen und nachgefragt und hier das wichtigste zusammengestellt. Vielfach wurden auch Bedenken zum automatischen Update auf die neueste Version des Browsers laut. Wir können sie beruhigen: ohne ausdrückliche Zustimmung des Nutzers wird erstmal gar nichts installiert. Der IE7 ist zwar ein empfohlenes Update, aber die regelmäßigen Sicherheitsupdates bekommen Sie auch weiterhin, ohne auf den IE7 umzusteigen. Vor dem Update sollten Sie auf jeden Fall die Webseiten der jeweiligen Hilfsmittelhersteller konsultieren. Bei den meisten Herstellern erhalten Sie jetzt schon detaillierte Informationen, ob ihre Software kompatibel ist, oder wann mit einem Update zu rechnen ist. Wenn Sie die jeweils aktuellste Version oder sogar schon eine der vielfach bereits erhältlichen öffentlichen Beta-Versionen benutzen, dann steht einem Update auf die neueste Browsergeneration eigentlich nichts mehr im Wege. Und damit zu den Screenreadern. Den Anfang macht JAWS In den USA ist bereits die Version 8 des verbreiteten Screenreaders im Beta-Test. Eine Veröffentlichung der finalen Version ist noch für den November geplant, mit der üblichen Zeitverzögerung für die nötige Lokalisierung wird das Programm dann spätestens Anfang 2007 auch in Deutschland erhältlich sein. In der zurzeit aktuellen Version JAWS 7.1 ist der IE7 schon weitestgehend nutzbar. Eine Einschränkung muss man bei Web-basierten Formularen machen: hier gibt es noch einen Bug beim Vorlesen des fokussierten Elementes in HTML-Auswahllisten vom Typ select. Der Hersteller Freedom Scientific hat jedoch schon einen kostenlosen Patch angekündigt, der diesen Fehler beheben wird. Nutzer von JAWS sollten also noch ein paar Tage mit dem Update auf IE7 warten. JAWS hatte in früheren Versionen das Problem, dass tatsächlich vorhandene Inhalte einer Webseite nicht vorgelesen wurden, oder dass beim Eintippen in Textboxen einzelne Buchstaben »verschluckt« wurden – diese (und eine ganze Reihe anderer) Fehler sind in der aktuellen Version behoben. Die kommende Version 8 von JAWS wird eine ganze Reihe weiterer Verbesserungen bringen: so werden die im IE7 erstmals unterstützten RSS-Feeds benutzbar, und im Bereich dynamisches HTML oder AJAX wird sich noch mal eine Menge tun. Virgo, Blindows & Webformator Die zum Baum-Konzern gehörende Firma Audiodata hat eine Beta-Version des Webformators veröffentlicht, mit der finalen Version ist nach telefonischer Auskunft des Herstellers zeitnah zu rechnen. Genauer wollte sich Produktmanager Günter Hanke nicht festlegen: Er ist fertig, wenn er fertig ist – das finden wir gut, weil gerade im Web2.0 fast jede Software im ewigen Beta-Stadium festgefroren ist. Der Webformator setzt sich zwischen das Betriebssystem bzw. den Webbrowser und den Screenreader und bereitet die Inhalte einer Webseite in linearisierter Form auf. Der Webformator, aktuell in der Version 2.2, kann schon seit geraumer Zeit Flash verarbeiten, erleichtert den Umgang mit Datentabellen und vieles mehr. Laut Hanke sollte man die Beta einfach über eine bereits vorhandene Version drüberinstallieren. Diese Version ermöglicht nun die Nutzung des Internet Explorers in vollem Umfang, die hauseigenen Screenreader wie Virgo sind damit also für den IE7 gerüstet. Window-Eyes GW Micro hat ebenfalls ein Pferd in Form einer Beta im Rennen: Window Eyes 6.0 Beta 2 . Auch hier ist es die nächste Version, die erstmalig den IE7 offiziell unterstützen wird. Der grosse Unterschied zu den Vorgängern ist, dass die neue Version die eingebauten Sicherheitsmaßnahmen des IE7 unterstützen wird. Auch die Geschwindigkeit des Programms im Browse-Modus soll laut Hersteller verbessert werden. Laut Microsoft gibt es noch einige Fehler in den älteren Versionen, insbesondere im Bereich von HTML-Formularen. Anwender sollten also entweder auf die Beta-Version von Window Eyes 6.0 umsteigen, oder auf die finale Version warten wenn sie den IE7 nutzen wollen. Hal & SuperNova Der Hersteller Dolphin hat zeitgleich zur Veröffentlichung des IE7 sogenannte map files veröffentlicht, mit denen Anwender ihre Screenreader aktualisieren können. In Ausnahmefällen kann es zu Abstürzen auf Grund einer veralteten DLL kommen, die Lösung für dieses Problem ist in einem Artikel im Support-Bereich von Dolphin beschrieben. So, damit wären wir schon fast am Schluss, fehlt noch das Vergrößerungsprogramm ZoomText Die Lupensoftware ZoomText 9.04 des amerikanischen Herstellers AI Squared ist die erste Version, die den IE7 offiziell unterstützt. Nutzer aller ZoomText 9.x-Versionen erhalten ein kostenloses Update auf die neueste Version über die eingebaute Update-Funktion des Programms. Nutzer von ZoomText 9.03 sollten unbedingt die Schriftglättung abschalten oder das dringend empfohlene Update wahrnehmen, wenn sie den IE7 nutzen wollen. Im IE7 ist diese Maßnahme zur Schriftverbesserung namens ClearType erstmals in der Werkseinstellung aktiviert. Sie finden diese im Dialog »Internet-Optionen« im Reiter »Erweitert« unter dem Punkt »Multimedia« – dort die Checkbox namens »Immer ClearType für HTML verwenden« deaktivieren. So, das war mal wieder eine Ausgabe unseres accessCast. Wir haben hier natürlich nur einen kleinen Ausschnitt aus den möglichen Hilfsmitteln bringen können. Wenn Sie bereits Erfahrungen im Einsatz anderer Hilfsmittel mit dem IE7 haben können Sie diese gerne als Kommentar zu diesem Podcast posten. Auch eventuell auftretende Probleme, aber natürlich auch positive Berichte zu den behandelten Programmen können sie gerne dort abgeben. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags Browser, Sehbehinderung und Hilfsmittel.http://www.einfach-fuer-alle.de/podcast/2006/kw45/http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Browser-Hilfsmittel.m4aFri, 10 Nov 2006 19:01:07 +0100Tech Newsno00:13:01barrierefrei, webdesign, accessibility, barrierefreies webdesign, screenreader, IE7, BrowserAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersHeute werfen wir einen Blick in die aktuelle Browserlandschaft, die ja wieder mächtig in Bewegung gekommen ist.Heute werfen wir einen Blick in die aktuelle Browserlandschaft, die ja wieder mächtig in Bewegung gekommen ist. IE7 – der neue Platzhirsch? Den Anfang machte der langerwartete Internet Explorer. Das letzte Update von 5.5 auf 6.0 stammt tatsächlich schon vom August 2001. Seitdem wurden einmal im Monat die neuesten Sicherheitslücken gestopft, an dem für Webentwickler interessanten Kern des Browsers, der sogenannten Rendering Engine gab es keine Verbesserungen. Wer trotzdem dem IE das Verständnis für moderne Techniken wie CSS 2 einimpfen wollte, musste dazu auf JavaScript-Bibliotheken wie die witzigerweise auch IE7 genannte von Dean Edwards zurückgreifen. Die Älteren unter unseren Zuhörern werden sich eventuell noch erinnern: 2001 – das war die Zeit, als der Netscape 4 so langsam ausstarb und Mozilla bei 0.9.irgendwas angekommen war. Bleibt zu hoffen, dass es mit dem nächsten Update etwas schneller geht. Bisher ist der IE7 nur im englischen Original und auch nur als Download erhältlich. Diese Version ist laut Chris Wilson von Microsoft alleine in den ersten vier Tagen seit dem Erscheinen über drei Millionen mal heruntergeladen worden. Spätestens zum 1. November soll dann die eingedeutschte Version folgen und auch über die Software-Aktualisierung als empfohlenes Update verteilt werden. Schauen wir uns doch mal an, was der Browser Neues mit sich bringt: - Die offensichtlichste ist sicher, dass der IE jetzt das aus anderen Browsern bereits bekannte ›Tabbed Browsing‹ beherrscht. Und im verbreiteten Screenreader JAWS 7.1 werden diese schon erkannt und sind auch voll nutzbar, wie wir bei einem Test hocherfreut feststellen konnten. - Noch eine wichtige Neuerung: die Optionen zur Schriftskalierung sind endlich direkt erreichbar, ohne dass man sich durch fünf Dialoge klicken muss. Vielen Nutzern wird dadurch zum ersten Mal klar, dass man Schriften auf Webseiten vergrößern kann. Das ist eine gute Entwicklung und erfüllt eine wichtige Forderung aus den User Agent Accessibility Guidelines des W3C. Daneben gibt es eine neue Option, die Seiten komplett zoomt, wie dies bisher nur mit Opera möglich war. Mehr dazu im Verlauf der Sendung. - Im IE7 und damit wohl auch im kommenden Windows Vista ist die Schriftglättung werksseitig aktiviert. Gerade auf den wohl mittlerweile mehrheitlich vorhandenen LC-Displays bringt diese bei Microsoft ClearType genannte Technik enorme Vorteile in Bezug auf die Lesbarkeit. Auch für Webentwickler gibt es neue Sachen zu entdecken. Microsoft hatte bei der Überarbeitung des Browsers eine bis dato für diese Firma ungekannte Offenheit an den Tag gelegt. So wurden schon in einer sehr frühen Phase öffentliche Umfragen über das IE Blog gemacht. Die Programmierer von Microsoft wollten zum Beispiel wissen, welche Fehler in der Umsetzung von CSS die höchste Priorität haben sollten. Herausgekommen ist eine wesentlich verbesserte Unterstützung dieses wichtigen Standards. Aber: kein Licht ohne Schatten – erweiterte Selektoren, CSS-Tables und einiges mehr werden nach wie vor nicht unterstützt. Bei einigen dieser Probleme helfen aber die eingangs erwähnten Skripte von Dean Edwards. Beim Testen der ›Einfach für Alle‹-Website hat uns die IE Developer-Toolbar sehr weitergeholfen. Ähnlich dem aus den Geckos bekannten DOM Inspector wird hier der Dokumentenbaum in einem separaten Fensterbereich angezeigt und durch Klick auf die einzelnen Knoten oder Elemente kann man auf einen Blick sehen, welche Styles auf das ausgewählte Element angewendet werden und was sich wie wohin vererbt. Eine gute Sache, die bei keinem professionellen Webentwickler fehlen sollte. Die Installation des Script Debugger im IE kann allerdings in einen Albtraum ausarten. Die Jungs von 37Signals haben es versucht und die Ergebnisse in einem Video dokumentiert und gleich auch noch mit dem entsprechenden Tool für Apples Safari verglichen, der mit vier Klicks lief. Die Links zum Download finden Sie wie immer am unteren Ende der Mitschrift zu diesem Podcast. Welche Baustellen es für Browserhersteller sonst noch gibt, lässt sich gut in einem Dokument des W3C aus dem Jahr 2003 nachlesen: »Common User Agent Problems – Once Upon A Time, A User Agent…«. Auch warten wir immer noch auf einen Browser, der die User Agent Accessibilty Guidelines des W3C (UAAG, gesprochen Juh-äck) vollständig berücksichtigt. Firefox 2.0 – die Wachablösung? Der neue Firefox 2.0 erfüllt diese W3C-Richtlinie nach unserem Kenntnisstand nur teilweise, aber immerhin gibt es bei der Mozilla Foundation ein »Voluntary Product Accessibility Template« genanntes Dokument, in dem die Konformität der Vorgänger-Software Firefox 1.5 zu den amerikanischen arbeitsrechtlichen Bestimmungen beschrieben ist. Schlechter geworden ist die neue Version nicht, und sie arbeitet neuerdings hervorragend mit aktuellen Versionen von Screenreadern wie Window Eyes und JAWS und deren Open Source-Pendants zusammen. Die Konkurrenz hat sich sehr über die Veröffentlichung von Firefox 2.0 gefreut. Microsofts Produktmanager Tony Chor hat zur Feier des Tages sogar eine Torte beigesteuert und an das Firefox-Team geschickt. Die Aufschrift: “Congratulations on shipping! Love, the IE team” Ganz ohne Bugs ist der Browser auch nicht, wie schon Deutschlands meister Tester Dirk Jesse rausgefunden hat. Streng genommen kein Bug, aber nervend ist das geänderte Verhalten bei Accesskeys. Wo bisher Alt + Accesskey gereicht haben, muss man nun im Firefox 2.0 Alt + Shift + Accesskey drücken. Als Webseitenbetreiber vernünftige Hilfetexte zum Umgang mit Accesskeys zu schreiben war schon immer schwierig, jetzt muss man die Hilfen auch noch um Versionshinweise ergänzen – nach dem Motto »wenn sie Firefox kleiner gleich 1.5 benutzen drücken Sie bitte das, wenn Sie Firefox größer gleich 2.0 benutzen, dann drücken Sie bitte auch noch das.« Wie bei Firefox üblich kann man das Verhalten über das berühmt-berüchtigte about:config ändern - dazu muss man nur den Schlüssel ui.key.generalAccessKey finden und den Wert des Integers auf 18 ändern – wenig intuitiv, wie leider so vieles an diesem Browser. Weitere Tipps und Tricks rund um die vielen Konfigurationsmöglichkeiten finden sich im Wiki von firefox-browser.de und bei livehacker.com. Für Mac-User gibt es wieder eine Reihe inoffizieller Versionen des Browsers. Neil Lee hat diese jeweils auf die G4, G5 und Intel-Prozessoren optimiert, so dass sie sich eine ganze Ecke schneller anfühlen. Ausserdem sehen darin Formularelemente aus wie Formularelemente. Ganz nett sind die neu eingeführten Microsummaries. Trotz der Namensähnlichkeit sind das aber keine neuen Microformats, sondern eine Art dynamischer Lesezeichen mit einer kurzen Zusammenfassung der jeweiligen Seite. Was man damit alles anstellen kann, erklärt der Artikel »Creating a Microsummary« im Mozilla Developer Center. Für das Weblog-System Wordpress gibt es bereits eine erste Erweiterung zur Erstellung von Microsummaries. Mittlerweile sind auch sämtliche wichtigen Erweiterungen aktualisiert worden, so dass sie im Firefox 2.0 das Leben erleichtern können. Eine Liste findet man bei addons.mozilla.org. Bei uns im Dauereinsatz sind nach wie vor die für Webentwickler unverzichtbaren Erweiterungen Web Developer Toolbar, X-Ray und der nach wie vor stark verbesserungswürdige DOM Inspector. Das Fazit: Vista was besseres? Das Herunterladen und die Installation des Internet Explorers dauert eine halbe Ewigkeit. Dass sich der Browser nur auf legitimen und nicht auf »ausgeliehenen« Versionen von Windows installieren lässt, ist nachvollziehbar. Leider muss man während der Installation eventuell vorhandene Antivirensoftware und Firewalls abschalten, so dass der Rechner bis zum anstehenden Neustart des Systems offen wie ein Scheunentor ist. Der Download von Firefox geht hingegen rasend schnell, je nach Betriebssystem läuft der Browser spätestens nach vier Klicks, und die einzige Bedingung ist, das während der Installation eventuell vorhandene Vorgängerversionen beendet werden. Die erste Runde geht somit klar an den Firefox. In der Abteilung Oberfläche können wir uns nicht entscheiden. Firefox 2.0 ist seiner Vorgängerversion zum Verwechseln ähnlich, sieht man von einigen Verbesserungen im Detail ab. Der IE ist hingegen radikal anders als die Vorgänger, aber sicher nicht schlechter. Er verlangt seinen Nutzern einiges an Umdenken ab, aber die neuen Features will man nach der ersten Sitzung nicht mehr missen. Auch bei den zusätzlichen Features können wir uns für keinen klaren Sieger entscheiden. Das ›Tabbed Browsing‹ ist im IE fast schon ein bisschen intuitiver, klar vorn liegt dafür der Firefox in der Verwaltung von RSS-Feeds, die der IE nun auch beherrscht. In der Erweiterbarkeit liegt das Angebot der Mozilla Foundation klar vor der Konkurrenz aus Redmond. Nur – die wenigsten Erweiterungen für den Firefox sind auch für den Massenmarkt, wie ihn der IE bedient, wirklich sinnvoll. Die Konfiguration und Anpassung des Browsers scheint auf den ersten Blick im IE etwas komplizierter zu sein, da man sich unter Umständen durch viele Dialoge klicken muss. Allerdings ist dies intuitiver als die Konfiguration per about:config im Firefox, wo der Nutzer sich mit Integern, Strings und Booleschen Operatoren beschäftigten muss. Was ändert sich für Webentwickler? Nicht wirklich viel, wenn Sie bisher schon sauberen Code ausgeliefert haben. Der IE 7 ist gegenüber dem IE 6 wieder Standard-konformer geworden. So wie der IE 6 besser war als der IE 5.5, der IE 5.5 besser als der 5.0 etc. Und so wird der Microsoft-intern als »IE.Next« gehandelte Nachfolger sicher nochmals ein Stück besser werden. Inkrementelle Verbesserungen sind eine Grundlage des Webs, einen Browser, der alle relevanten Standards vollständig und korrekt umsetzt kennen wir bisher nicht. Wenn Ihre Style Sheets aber hauptsächlich aus Workarounds, Hacks und Browser-Filtern bestehen, dann haben Sie jetzt ein echtes Problem: viele dieser Filter funktionieren im IE 7 nicht mehr und die eigentlich den Vorgängern zugedachten Hacks zerlegen jedes Layout. Ein Weg aus diesem Dilemma ist, sämtliche Hacks nach Browserversionen getrennt in zusätzliche Style Sheets auszulagern und diese per Conditional Comment für die jeweils betroffenen Browser-Versionen nachzuladen. Was Web-Programmierern und -Designern aber viele Kopfschmerzen bereiten wird, ist das neue Zoom-Feature im IE 7. Die neue Funktion entspricht dem Verhalten in einer Textverarbeitung: wenn Text zu klein oder zu groß ist, dann kann man entweder die Schriftgröße ändern, oder das ganze Dokument skalieren. Und genau da liegt der riesige Unterschied zwischen der Art der Skalierung, wie sie in Firefox, Safari und IE 5 / Mac funktioniert und der Skalierung in IE 7 und Opera: bei der reinen Textskalierung wird nur die Textgröße geändert, Bilder, Grafiken und Spalten bleiben gleich. Bei sauberer Umsetzung passt der Inhalt immer noch ins Browserfenster und ein horizontaler Scrollbalken wird vermieden. Beim Seiten-Zoom wird, wie der Name vermuten lässt, die gesamte Seite skaliert, sodass höchstwahrscheinlich schon in der ersten Zoomstufe ein horizontaler Scrollbalken erscheint. Ganz schwierig wird es, wenn sowohl Seiten-Zoom als auch Textskalierung miteinander angewendet werden. Sobald der IE eine kritische Masse bei den Zugriffen erreicht, werden daher viele auf flexiblen Bemaßungen basierende Konzepte neu überdacht werden müssen. So, das war mal wieder eine Ausgabe unseres accessCast. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags Browser, Mac, Windows, Linux und Hilfsmittel. Wenn es Ihnen gefallen hat hören wir uns nächste Woche wieder.http://www.einfach-fuer-alle.de/podcast/2006/kw44/http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Neue-Browser.m4aTue, 31 Oct 2006 19:49:54 +0100Tech Newsno00:14:54barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcagAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersHeute gibt es den zweiten Teil des Rückblicks auf die Veranstaltung »Warum barrierefreies Internet?« des Vereins »accessible media« in Wien. Für alle, die nicht dabei sein konnten hier eine Nachlese von Martin Ladstätter von Bizeps.Heute gibt es den zweiten Teil des Rückblicks auf die Veranstaltung »Warum barrierefreies Internet?« des Vereins »accessible media« in Wien. Die Veranstaltung fand am 12. Oktober im TechGate Vienna statt. 170 Teilnehmerinnen und Teilnehmer nutzten die Gelegenheit, um sich über Barrierefreiheit in der Praxis zu informieren. Für alle, die nicht dabei sein konnten und jene, die gerne nachschlagen möchten: hier eine Nachlese von Martin Ladstätter von Bizeps. Herzlichen Dank! »Unser Ziel war viele Benutzer zu erreichen« Der Internetauftritt des Österreichischen Jüdischen Museums hat bei weitem nicht die Größe von wien.at oder Kurier. Johannes Reiss legte seine Erfahrungen im Veranstaltungsblock: "Barrierefreier Relaunch in der Praxis" dar. "Das Budget war schnell ermittelt, weil nicht vorhanden", scherzte Reiss und sprach eine Situation an, die viele Internetbeauftragte von kleineren Angeboten sehr gut kennen. "Die Entscheidung ojm.at zu relaunchen war dringend notwendig geworden. Wir hatten viele Abrufe und die Website war schlicht und einfach in die Jahre gekommen, blinkende, laufende und hüpfende Elemente waren für manche zugegeben noch immer lustig, für die meisten anderen jedoch eine Zumutung", erklärte er die Motivation den Internetauftritt gründlich zu überarbeiten. Besonders klar und einleuchtend war die Erklärung, mit der Reiss die Motivation zur Erstellung eines verbesserten Internetauftrittes gab: "Das hatte auch damit zu tun, dass wir aufgrund unserer Erfahrungen vor allem bestrebt waren, Schwellenängste und Unsicherheiten im Umgang mit dem jüdischen Museum abzubauen und diesen entgegenzutreten. Etwas grob formuliert: Eine Website mit vielen Barrieren würde unterschwellig die Ängste und Unsicherheiten schüren, zumal die Website für viele Besucher, aber auch Käufer unserer Publikationen die allererste Anlaufstelle ist. Ziel war also ein möglichst hübscher, sympathischer, verständlicher, gut und leicht benutzbarer Webauftritt.« "Das Design sollte in erster Linie von Klarheit geprägt sein, optimale Lesbarkeit sowie Verständlichkeit des Gelesenen hatten absolute Priorität", resümierte er. Die weiträumig und großzügig wirkenden und nie überladenen Seiten nehmen den Eindruck eines Ganges durch die realen Ausstellungsräume des Museums vorweg, führte er weiter aus. Wenn ein Ziel als vorrangig genannt werden soll, dann die textliche Gestaltung - so der Leiter des Museums im Rückblick. "Alle Texte der Website wurden für dieses Projekt neu verfasst (mit Ausnahme vorhandener wissenschaftlicher Artikel). Der Text sollte exakt dem des Museumsalltags entsprechen und so dem sehr inhomogenen Zielpublikum möglichst gerecht werden. Verständlichkeit hatte immer oberste Priorität. Daraus folgt: Die Einrichtung der Website ojm.at in Leichter Sprache versteht sich als ergänzendes Serviceangebot des Österreichischen Jüdischen Museums. Dem Benutzer stehen sämtliche Seiten der Website mit Ausnahme des Abschnitts Artikel in leichter Sprache zur Verfügung. "Auf die Übertragung der Artikel wurde bewusst verzichtet um den vom jeweiligen Autor bezweckten wissenschaftlichen bzw. ästhetischen Duktus der einzelnen Texte zu bewahren", lautete die Erklärung. Von nahezu allen Bildern werden Großansichten zur Verfügung gestellt. "Mit Großansichten der Bilder wolle man aber insbesondere auch schlecht sehenden Benutzern die Möglichkeit geben, die zum Teil sehr schönen und seltenen Bilder besser zu sehen bzw. nachzuvollziehen." Als Accessibility-Schwerpunkt neben der Leichten Sprachversion kann das Angebot in Gebärdensprache gesehen werden, hält Reiss fest und erwähnt, dass drei Videos in Österreichsicher Gebärdensprache in einer Gesamtlänge von ca. 36 Minuten zur Verfügung gestellt werden. "Die Besucherzahl von ojm.at stieg binnen weniger Monate auf das 3-5fache", berichtet er nicht ohne sichtbare Freude. "Und das obwohl die englische Version derzeit noch immer nicht online ist", wie er festhält. Doch daran werde intensiv gearbeitet, kündigt er an. Aber auch über andere positive Erlebnisse berichtet er: "Wir haben - und das war eine erfreuliche neue Erfahrung - konkretes und aktives positives Feedback von Besuchern und Besucherinnen, persönlich oder per Mail erhalten. Wenn ich Feedback aus der Accessibility-Branche außen vor lasse, waren es Menschen aus aller Welt, die von einer barrierearmen Website noch nie etwas gehört haben, sondern ganz normale Surfer sind und ojm.at als angenehm und benutzbar empfunden haben und dies auch äusserten." Auch wenn er es im Vortrag nicht erwähnte, wussten viele der Teilnehmerinnen und Teilnehmer, dass das Österreichische Jüdischem Museum noch eine weitere Auszeichnung erhielt. Im Dezember 2005 wurde dem Team des OJM eine BIENE im deutschsprachigen Wettbewerb der besten barrierefreien Webseiten verliehen. »User: Das unbekannte Wesen« "Wer sind die User?" fragte Jo Spelbrink die Teilnehmerinnen und Teilnehmer. "Überlicherweise" - so beantwortet der Vortragende seine Frage gleich selbst - "werden Menschen in Zielgruppen definiert". Doch daraus ergibt sich das Problem, das sich diese Einteilungen hauptsächlich auf Inhalte und Ästhetik bezieht, "doch das Userverhalten bleibt unberücksichtigt, weil vermeintlich selbstverständlich". Er legt dar, dass es "unterschiedliche Prioritäten in der Wahrnehmung von Websites" gibt, auf die unterschiedlich eingegangen werden soll. Der Webdesigner muss daher häufig ein "Allrounder" sein. "Der 'ideale' Webdesigner versucht im Prinzip nur eines: Eine Balance zu finden, um den User zu erreichen", hält Spelbrink fest. Der Designprozess ist ein Userorientierter Prozess. Wichtig sei dabei insbesonders: - Hineinversetzen in verschiedene Wahrnehmungswelten (z. B. blind, gehörlos, motorisch eingeschränkt, farbenblind, ...) - Designmatrix für Farben/Kontraste, Navigation, Semantik und Struktur - Überprüfung der Funktionalität der Website - Seitentest Er hält fest, dass "User Research durch Seitentesten!" wichtig ist und "mehr Aufschluss über die Wirksamkeit einer Website gibt" als in den WAI-Richtlinien empfohlen. »Behinderung ist die mangelnde Fähigkeit, mit schlechtem Design umgehen zu können.« Tomas Caspers brachte in seinem Referat "Design barrierefrei" humorvolle Betrachtungen und pointierte Statements. Was sind die Folgen von schlechtem Design? Caspers nennt technische Barrieren und eine Klage wegen Diskriminierung, wie es jüngst dem US-Einzelhändler "target" widerfahren ist. Auch in Österreich kann seit dem 1. Januar 2006 eine Schadenersatzklage wegen einer nicht barrierefreien Internetseite eingereicht werden. In aller Munde ist derzeit das Wort "Web 2.0". War das Web in seiner Grundkonzeption als Informationsweitergabe gedacht sei nun vom "Lesen-Schreiben-Ausführen Web" die Rede. Caspers erläutert - etwas weniger sperrig - anhand von Beispielen: "Web 2.0 ist … - ... wenn Du Dich statt in der Karaoke-Bar bei Youtube gleich weltweit zum Affen machst. - ... wenn Du sogar für Deine Lieblings-Dönerbuden eine Google-Map anlegst." Doch was muss passieren, "damit Menschen mit Behinderungen von den neuen Möglichkeiten des Netzes profitieren können?", fragt er das Publikum bei der Veranstaltung von accessible media. Aus dem statischen Medium wird ein dynamisches Echtzeit-Medium. Daraus ergibt sich mehr Kompfort für den Nutzer; wenn er diesen nutzen kann. Aus dem passiven Einbahnstraßen-Medium wird ein Werkzeug, so Caspers weiter. "Typisch für alle genannten Beispiele ist ein Mehr an Dynamik. Dynamik, die in den Richtlinien und Verordnungen zur Barrierefreiheit so nicht vorgesehen war oder sogar ausgeschlossen ist", umreißt er das Problem. Er zeigt anhand von Beispielen, wie neue Techniken ("Progessive Enhancement") versuchen das Problem zu lösen. "Die wirklich spannende Aufgabe ist also, die direkte Zugänglichkeit dieser Applikationen für die Hilfsmittel von Menschen mit Behinderung herzustellen", hält Caspers fest. Es sei nicht die Frage "ob" man neue Technologien des Web 2.0 barrierefrei umsetzen soll, sondern "wie". Barrierefreiheit bezeichnet "bestimmte Qualitäten gestalteter Lebensbereiche, wodurch diese für Menschen mit Behinderung nutzbar sind." Caspers kommt dann aber mit einer - zugegebenermaßen - mehrdeutigen Definition: "Behinderung ist die mangelnde Fähigkeit, mit schlechtem Design umgehen zu können." Ein Satz, über den man ruhig länger nachdenken sollte. Viel wurde bei der Veranstaltung schon zum Thema barrierefreies Internet gesagt. Plakativ - aber durchaus erwähnenswert - zeigt er pointiert und mit einem Schuss Humor auf "Was Barrierefreiheit nicht ist": "Ich will das aber so und das habe ich immer so gemacht." "Das tut‘s aber nicht in Netscape 4.“ "Handbücher? Lese ich grundsätzlich nicht!" "Mein Rechner ist noch auf dem Stand von 1999" Wenn man einerseits die Fülle der neuen Möglichkeiten und andererseits die Herausforderungen seitens der Barrierefreiheit gegenüberstellt wird eines klar: Es ist eine der wesentlichsten Voraussetzungen Angebote umfangreich zu testen, hält Caspers abschließend fest. »Muss nun jedes Internetangebot barrierefrei sein?« Einen Streifzug durch das österreichische Bundesrecht führte Martin Ladstätter in seinem Referat "Gleichstellung in der digitalen Welt". "Barrierefreies Internet bietet für Anbieter eine Reihe von Vorteilen", nahm der Vortragende auf vorangegangene Referate Bezug. Doch - "und das ist noch den wenigsten bewusst" - in einigen Bereichen ist barrierefreies Internet auch schon gesetzlich vorgeschrieben. Das seit 1. Jänner 2006 geltende Behindertengleichstellungsgesetz "stellt nicht den Anfang, sondern eine wichtige Weiterentwicklung im Kampf auf das Recht auf Information dar", so Ladstätter. Er berichtete von einer Menschenrechtstagung in Großbritannien, die er vor knapp 10 Jahren besucht hatte. Eine blinde Menschenrechtlerin wies dabei mehrfach auf die steigende Bedeutung des Internets und den notwendigen gleichberechtigten Zugang für behinderte Menschen hin. Sie bat damals die Anwesenden mit Nachdruck für das Recht auf Information zu kämpfen. Der Kampf um Zugänglichkeit von Bauten ist gesellschaftlich anerkannt, doch beim Internet stecke dies noch in den Kinderschuhen. Man werde aufpassen müssen, hier nicht den Anschluss zu verpassen. Weltweit hat sich in den letzten Jahren viel im Bereich "Recht auf Information" getan. Auch die österreichische Rechtsordnung wurde Schritt für Schritt verbessert. "Trotzdem bleibt noch viel zu tun", so Ladstätter. Er brachte bei seinem Streifzug eine Reihe von Beispielen aus österreichischen Bundesgesetzen. Als einen wichtigen Punkt nannte er die Verfassungsbestimmung in Artikel 7, die festhält, dass "die Gleichbehandlung von behinderten und nichtbehinderten Menschen in allen Bereichen des täglichen Lebens zu gewährleisten" sei. So wurde im "Allgemeinem Verwaltungsverfahrensgesetz" eine Bestimmung aufgenommen, dass "Blinden oder hochgradig sehbehinderten Beteiligten ... den Inhalt von Akten …nach Maßgabe der vorhandenen technischen Möglichkeiten in sonst geeigneter Weise zur Kenntnis zu bringen" sei. Eine Weiterentwicklung stellte die Novelle des "Urheberrechtsgesetzes" dar, weil dort statt von einer Gruppe behinderter Menschen, gleich alle umfasst wurden. Konkret heißt es dort: "... an behinderte Personen in einer für sie geeigneten Form". Noch einen Schritt weiter - so Ladstätter im Referat - ging das "E-Government-Gesetz". Es schreibt vor, "dass behördliche Internetauftritte ... so zu gestalten sind, dass internationale Standards über die Web-Zugänglichkeit auch hinsichtlich des barrierefreien Zugangs für behinderte Menschen eingehalten werden". Damit wurden erstmals die Standards für barrierefreies Internet in einem österreichischen Gesetz als Messlatte vorgeschrieben. Das "Zustellgesetz" definiert noch weitergehend, dass diese Standards "nach dem jeweiligen Stand der Technik des barrierefreien Zugangs" zu gewährleisten sind. Angesichts der Diskussion um die in Erarbeitung befindlichen WCAG 2.0 kein unerhebliches Detail. Die aber mit Abstand wichtigste gesetzliche Bestimmung stellt das Bundes-Behindertengleichstellungsgesetz dar. In diesem Gesetz werden ausdrücklich "Systeme der Informationsverarbeitung" erwähnt und die Erläuterungen nennen wieder die Internationalen Standards für barrierefreies Internet. Wichtig ist dieses Gesetz besonders deswegen, weil es - im Gegensatz zum "E-Government-Gesetz" - auch Unternehmen betrifft, die Dienstleistungen verkaufen, weist er auf den größeren Adressatenkreis des Gesetzes hin. Doch das Bundes-Behindertengleichstellungsgesetz enthält noch eine weitere wesentliche Bestimmung. Förderungen des Bundes müssen so eingesetzt werden, dass Gleichstellung hergestellt wird. "Muss nun jedes Internetangebot barrierefrei sein?", könnte man sich fragen. Zur Verdeutlichung fasste er nochmals zusammen, wer nun barrierefreies Internet anbieten muss. "Es sind schon mehr Anbieter, als vielen bewusst ist", hebt Ladstätter hervor. - Behörden - Zusteller laut e-Government-Gesetz - Verwaltung des Bundes - Unternehmen die Güter verkaufen "die der Öffentlichkeit zur Verfügung stehen" und - Förderungsnehmer von Bundesförderungen (BGStG) Abschließend wies Ladstätter darauf hin, dass diese Rechte auch durchsetzbar sind. Konkret gebe es derzeit ein von einer blinden Person gegen ein großes österreichisches Unternehmen angestrengtes Schlichtungsverfahren nach dem Behindertengleichstellungsgesetz, weil deren neues Internetangebot nicht barrierefrei sei. "Wenn diese Schlichtung nicht mit einer positiven Einigung ende, also das Unternehmen das Internetangebot innerhalb einer angemessenen Zeit barrierefrei gestaltet, stünde der betroffenen Person das Recht auf eine Schadenersatzklage gegen das Unternehmen zu", verdeutlicht Ladstätter. "Doch", so führt er weiter aus, "sehe es ganz danach aus, dass das Unternehmen seiner gesetzlichen Pflicht nachkommen werde". »Mediennutzung ohne Barrieren« Beate Firlinger berichtete in ihrem Referat "Medienzugang für alle: Gewinn für alle?" über die Ergebnisse einer Studie. Der Verein MAIN_Medienarbeit Integrativ führt ein Sensibilisierungs- und Vernetzungsprojekt mit den Namen "GEGEN UNFAIR. Für barrierefreie Kommunikation" durch. Bei diesem Sensibilisierungs- und Vernetzungsprojekt geht es darum, "Medien, Unternehmen und Kultureinrichtungen anzuregen, ihre Informations- und Kommunikationsangebote zugänglicher und inklusiv zu gestalten", erläutert Firlinger. MAIN wollte wissen, wie Menschen mit Behinderungen und wie Fachleute in Medien und Unternehmen die Möglichkeiten und Grenzen barrierefreier Information und Kommunikation sehen. Um dies zu erfahren, haben sie das "Institut Karmasin.Motivforschung" mit der Durchführung einer qualitativen Untersuchung beauftragt. Die Studie "Mediennutzung ohne Barrieren" dient ihnen dabei als Bestandsaufnahme und Argumentationsgrundlage, berichtet die Vortragende. "Die Befragung erfolgte in ganz Österreich und es gab zwei Befragungsrunden", hält Firlinger fest "Die erste Befragungsrunde widmete sich der Zielgruppe Menschen mit Behinderungen. Die Antworten aus dieser ersten Runde dienten dann als Basis für den zweiten Untersuchungsschritt, bei dem um die Sichtweisen von Fachleuten in Medien und Unternehmenskommunikation ging." Aus der Sicht von Menschen mit Behinderungen wurde festgehalten: Das tägliche Informationsverhalten von Menschen mit Behinderungen wird eindeutig durch das Internet dominiert. Für 69 % der Befragten ist das Internet sehr wichtig. Information über politisches und alltägliches Geschehen erfolgt primär via TV, gefolgt von Online Medien und Online Diensten. Internet und Online-Medien zählen somit zu den primären Informationsquellen und Kommunikationsinstrumenten der befragten Personen. "Daran zeigt sich auch, wie wichtig Veranstaltungen wie die heutige zum Thema barrierefreies Internet sind", meint Firlinger. Aus der Sicht von Unternehmen wurde festgehalten: Das Thema Barrierefreiheit ist durchaus präsent in den Unternehmen. Dabei können die Befragten grundsätzlich auch auf ausreichend Information zurückgreifen, um Maßnahmen der barrierefreien Gestaltung von Kommunikations- und Informationsangeboten zu setzen. Bei unzureichender Information sollte vor allem die Kommunikation mit den Betroffenen bzw. deren Organisationen stattfinden, um gezielt auf ihre Bedürfnisse eingehen zu können. Rund ein Fünftel wünscht auch Informationen über rechtliche Grundlagen, Leitfäden und Ähnliches. "Die rechtlichen Bestimmungen des am 1. Januar 2006 in Kraft getretenen Bundes-Behindertengleichstellungsgesetzes sind wenig präsent", resümiert Firlinger. Die Studie hält zu diesem Punkt fest: Nur 12 % kennen die rechtlichen Bestimmungen im Detail. 46 % haben davon gehört, kennen aber keine näheren Details. 42 % sind diesbezüglich völlig unbedarft, haben noch nichts davon gehört. "Das Wissen der befragten Fachleute in den Medien und Unternehmen zur Gesetzeslage im Bereich Barrierefreiheit und barrierefreie Kommunikation ist generell sehr niedrig", hebt sie hervor und schlägt vor: "Eine detaillierte Aufklärung über die neuen rechtlichen Grundlagen wäre daher ein wichtiger Ansatzpunkt." Die Vorbehalte, eine Website nicht barrierefrei zu gestalten, liegen laut Studie eher auf einer emotionalen als auf einer faktischen Ebene. Das Klima für Veränderungen in Richtung Ausbau alternativer und ergänzender Informations- und Kommunikationsangebote für Menschen mit Behinderungen "ist grundsätzlich positiv", so Firlinger, die abschließend festhält: "Der Zug fährt in Richtung barrierefreie Informationsgesellschaft, der Weg ist aber noch ein weiter." So, das war der zweite Teil unseres Berichts aus Wien. Der Dank der Woche geht diesmal an Martin Ladstätter, der uns die Texte zur Verfügung gestellt hat. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von Einfach für Alle unter den Tags Veranstaltungen, Barrierefreiheit und Österreich, die Links gibt‘s wie üblich in der Mitschrift. http://www.einfach-fuer-alle.de/podcast/2006/kw43/http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Wien-Teil2.m4aWed, 25 Oct 2006 18:48:12 +0200Tech Newsno00:25:59barrierefrei, webdesign, accessibility, barrierefreies webdesign, Leichte Sprache, ÖsterreichAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersWeil es wirklich eine tolles Ereignis war gibt es heute einen zweiteiligen Rückblick auf die Veranstaltung »Warum barrierefreies Internet?« des Vereins »accessible media« im schönen Wien.Weil es wirklich eine tolles Ereignis war gibt es heute einen zweiteiligen Rückblick auf die Veranstaltung »Warum barrierefreies Internet?« des Vereins »accessible media« im schönen Wien. Die Veranstaltung fand am 12. Oktober im TechGate Vienna gleich neben der UNO statt. 170 Teilnehmerinnen und Teilnehmer nutzten die Gelegenheit, um sich über Barrierefreiheit in der Praxis zu informieren. Die Vortragenden aus dem In- und Ausland zeigten auf, dass Barrierefreiheit eine umfassende und herausfordende Aufgabe darstellt. Für alle, die nicht dabei sein konnten und jene, die gerne nachschlagen möchten: hier eine Nachlese von Martin Ladstätter von Bizeps. Herzlichen Dank! »Einfach aber nicht Simpel!« »Wie schreibe ich einfach?« So nannte sich ein bemerkenswerter Vortrag von Elke Mayer, Christopher Meiller und Johannes Reiss. »Willkommen bei der Deutschen Post, der Leistungsmarke für Briefkommunikation, Dialogmarketing und effiziente Outsourcing- und Systemlösungen für das Briefgeschäft.« Mit diesem Beispiel zeigte Elke Mayer welches Satzungetüm - bestehend nahezu ausschließlich aus Fremdwörtern, zusammengesetzten Substantiven und Anglizismen - die Deutsche Post ihrem durchschnittlichen Kunden zumutet. Die Teilnehmer der Veranstaltung wurden mit diesem Praxisbeispiel direkt und ohne viel Theorie mit dem Thema »Leichte Sprache« konfrontiert. »Für verschiedenste in ihrer Lesekompetenz eingeschränkte Benutzergruppen stellt die sprachliche Erfassung durchschnittlicher Internetauftritte eine Schwierigkeit, ja Unmöglichkeit dar«, ergänzte Christopher Meiller und erläuterte: »Lange und umständlich formulierte Texte, unübersichtliche Seitengestaltung, komplexe Schachtelsätze und der Einsatz entbehrlicher Fremdwörter erschweren das Verständnis und schließen so potentielle Zielgruppen von bereitgestellten Inhalten aus.« Internet-Kommunikation ist überwiegend textbasierte Kommunikation, stellte Johannes Reiss fest und erinnerte daran, dass »geschätzte 20.000 Jugendliche jährlich die Schule verlassen, ohne hinreichend sinnerfassend lesen zu können«. Doch es gibt noch eine Reihe von weiteren Gruppen, die von leichter Sprache profitieren: Menschen mit nicht-deutscher Muttersprache, Kinder im Volksschulalter sowie Menschen mit Lernschwierigkeiten Das Bereitstellen von Angeboten in Leichter Sprache ist somit einerseits Teil der fortschreitenden Demokratisierung des Internet, erläutert Meiller. »Man kann gewiss nicht alles simpel sagen, aber man kann es einfach sagen«, zitieren die Vortragenden Kurt Tucholsky. Daher kann als kürzestes Grundsatzprogramm der Leichten Sprache gelten: »Einfach, aber nicht simpel!« Sprache muss umfassend und nicht nur vage verstanden und begriffen werden, will man Webangebote nicht am Benutzer vorbei formulieren. Mehrdeutigkeiten müssen daher vermieden werden. Mit den Beispielen »Fritz singt eine Arie oder Fritz singt vor der Polizei oder Hans kauft die Zeitung um 2 Euro oder Hans kauft die Zeitung um 21 Millionen Euro« wurde dargelegt, wie im Alltag Schwierigkeiten auftreten können. Im nächsten Praxisbeispiel berichtete Reiss über die Erfahrungen mit einem Formular. »Anlässlich einer größeren Veranstaltung nächste Woche hatte ich die Aufgabe, ein interaktives Anmeldeformular mit allen üblichen Leistungen wie Feedbackmail, Fehlerroutine etc. bereitzustellen. Jetzt mal abgesehen von den Kundenwünschen war es mir natürlich wichtig, das Formular möglichst barrierearm und benutzerfreundlich zu gestalten. Der Adressat war im konkreten Fall ziemlich eindeutig: deutschsprachig, zu 99 % Akademiker und imstande, mehrere Zeilen Text sinnverstehend zu lesen«, umriss er die Anforderungen und die Ausgangslage. Interessant war, dass aus verschiedenen Gründen trotzdem rund 50 % »schlicht und einfach am korrekten Ausfüllen des Formulars« scheiterten. Nicht erkannte Barrieren können so auch schnell zum Kostenfaktor werden. Diese Erkenntnis war damit greifbar gemacht worden und so dem Publikum leicht nachvollziehbar. Shadi Abou-Zahra: »Wir produzieren Standards« Abou-Zahra ist für die Organisation World Wide Web Consortium ( W3C) als Experte im Bereich barrierefreies Internet tätig- ein internationales Konsortium, in dem Mitgliedsorganisationen, ein fest angestelltes Team, und die Öffentlichkeit gemeinsam daran arbeiten, Web-Standards zu entwickeln. »Wir produzieren Standards«, erläutert er und verweist auf die seit dem Jahr 1999 geltenden W3C Richtlinien für barrierefreies Internet. Diese »W3C Web Content Accessibility Guidelines 1.0 ( WCAG 1.0)« sind in vielen Ländern - so auch in Österreich - Beurteilungsstandards der Gesetzgebung, wenn es um barrierefreies Internet geht. Die Richtlinien WCAG 1.0 wurden im Jahr 1999 veröffentlicht. Nun wird intensiv und seit Jahren an einer Nachfolge gearbeitet. Diese WCAG 2.0 sollen in absehbarer Zeit erscheinen. »Wann dies genau ist, kann ich nicht beantworten", so Abou-Zahra auf Nachfrage aus dem Publikum. Obwohl der Entwurf der WCAG 2.0 nicht unumstritten ist, rät er den Teilnehmerinnen und Teilnehmer sich trotzdem schon jetzt damit vertraut zu machen. Derzeit werden über 400 Anregungen bearbeitet und danach könnten die Richtlinien veröffentlicht werden. Die neuen Richtlinien für barrierefreies Internet sollen technologieunabhängiger sein und die "Kriterien müssen leichter testbar werden", kündigt er die wesentlichsten Verbesserungen an. Wichtig sei auch, dass "eine Vielzahl von begleitender Information" zu den neuen Richtlinien erstellt werde. Daran werde im W3C gerade gearbeitet. Kurier: »Relaunch für die User« Der Veranstaltungsblock: "Barrierefreier Relaunch in der Praxis" wurde mit einem Vortrag von Thomas Jöchler von der Tageszeitung Kurier eröffnet. Der Kurier ist seit dem Jahr 1996 online und der drittgrößte Internetauftritt einer österreichischen Tageszeitung. Zum 10-Jahres-Jubiläum hat sich der Kurier kein großes Fest geleistet, sondern einen "Relaunch für die User" durchgeführt, berichtet der Vortragende. Der Kurier ging im Frühjahr 2003 als erste große österreichische Seite mit einem tabellenfreien Layout online. "Der letzte Relaunch im Jahr 2003 war bereits ein Schritt in die Richtung webstandardnahes Design. Wir haben schon damals die Trennung von Design und Struktur großteils umgesetzt", erläutert Jöchler. Der konsequente Einsatz von CSS war daher nahe liegend und hat beim Relaunch 2006 "sehr viel Zeit gespart". "Für die Wahrnehmung durch die User bietet uns die klar strukturierte Seite weitere Vorteile", analysiert der Leiter der Kurier Projektentwicklung. "Wir tauschen die (sklavische) Browserkompatibilität nach unten gegen die prinzipielle Zugänglichkeit der Seiten Browserkompatibilität. Beim Relaunch 2003 haben wir bewusst Netscape 4 nicht mehr unterstützt, diesmal haben wir die Latte beim IE 5.5 eingezogen." Der Zugang zum Inhalt soll mit prinzipiell allen Endgeräten möglich sein, "die designliche Auszeichnung setzt bestimmte einigermaßen an Webstandards orientierte Browser voraus", stellt er klar. "Jeder Artikel besteht aus Überschrift, Anreisser, Bild und Bildtext und Fließtext", erklärt Jöchler. Da der Kurier versucht die Nachrichten über möglichst viele Ausgabekanäle zu verbreiten (Webseite, RSS-Feed, Newsletter, Kurier Mobil) ist der Grundsatz "Die Artikel müssen Titel haben, die für sich allein stehen können" besonders wichtig. Um diese verschiedenen Ausgabekanäle möglichst optimal zu organisieren, war die Trennung von Inhalt und Layout schon seit dem Jahr 2003 für den Kurier ein wichtiges Kriterium bei der Planung eines neuen Internetauftrittes. Der Fokus auf multiplen Ausgabekanälen bewirkt: Inhalt losgelöst von Form denken. "Für uns war die Nutzung von CSS wichtig", berichtet Jöchler von einer geglückten Personalentscheidung: "Unser Glücksgriff war, dass dieser Grafiker nicht nur das Layout sondern auch Webstandards-konformen HTML-Code lieferte." Von Anfang an war beim Relaunch "Accessibility und Webstandardskonformität mitgedacht". Es hat sich auch gezeigt, dass "strukturierter Aufbau Accessibility bringt", teil er seine Erfahrungen mit. Der Code sei möglichst übersichtlich strukturiert und die Abfolge im Code entspricht der journalistischen Gewichtung der Seite (weiter oben = wichtiger). Sprungmarken zur Navigation und Inhalt werden angeboten. "Zugänglichkeit muss man umfassend denken: Design, laufende Entwicklung, tägliche redaktionelle Arbeit werden berücksichtigt", so sein Credo. Wichtig war auch die "Projektbegleitung durch den Verein accessible media ". Doch der Relaunch 2006 "stellt nicht den Endpunkt dar", erläutert Jöchler durchaus selbstkritisch. Noch seinen einige Punkte zu verbessern. So werde derzeit "das ALT-Attribut für Quellenangaben von Bildern genutzt", was nicht ideal sei. Auch kämpfe sein Team "mit einigen Tücken des Redaktionssystems" und daher werde nicht immer fehlerfreier Programmiercode geliefert. Ihm ist daher "Kritik, Feedback und Input auch in Zukunft sehr willkommen". »Barrierefreiheit kostet ... und zahlt sich aus! Beim Veranstaltungsblock: "Barrierefreier Relaunch in der Praxis" berichtete Michael Rederer von der wien.at-Koordination über die Bemühungen eines barrierefreien Internetauftritts der Stadt Wien. "Seit dem Jahr 1995 ist wien.at für alle Wienerinnen und Wiener sowie für all jene, die mehr über die Bundeshauptstadt erfahren möchten, online", erinnert er und nennt die Battlinie: "Öffentliche Inhalte müssen für alle zugänglich sein." Seit dem Jahr 2000 bemüht sich wien.at um Barrierefreiheit. Die damaligen Gegebenheiten waren schwierig. Es gab kein Redaktionssystem, die "Seiten wurden mit einem Tabellen-Layout erstellt" und es gab keine Vorgaben für Formulare, erläutert Rederer in seinem Vortrag im Rahmen der Veranstaltung von accessible media . Doch es gab auch einige Pluspunkte. Dazu zählten u. a. der "relativ einfacher, sauberer HTML-Code" sowie die Bereitschaft des Internet-Teams die 40.000 bestehenden Seiten zu verbessern. Doch diese Aufgabe musste exakt geplant sein, da "über 150 Autorinnen und Autoren aus über 70 Fachabteilungen" beteiligt sind. Auch sind die "einschlägigen Kenntnisse und Vorwissen sehr unterschiedlich", da die einzelnen Autorinnen und Autoren ihre Internet-Tätigkeit nebenbei zu ihren regulären Arbeiten durchführen. Eine wichtige Funktion kommt daher der Redaktion und Koordination bei wien.at zu. Dazu gehört das "Institutionalisieren der Barrierefreiheit, damit alle Bescheid wissen; auch oder gerade Entscheidungsträger". Von "absoluter Unzugänglichkeit" zu "zumindest nutzbar" ist es manchmal nur ein kleiner Schritt, hält Rederer fest und zeigt Beispiele, wie wien.at damals sein Angebot Schritt für Schritt verbessert hat. Hilfreich waren auch Informationsveranstaltungen mit Live-Demo. So konnte Mitarbeiterinnen und Mitarbeitern von wien.at die Arbeitsweise von behinderten Menschen näher gebracht werden. "Barrierefreiheit kostet ... und zahlt sich aus!", hält er fest und benennt die "Zusatzaufwände" auch konkret. Es handelt sich beispielsweise um Kosten der Tests, Qualitätssicherung, Arbeitszeit und Kosten für externe Dienstleister, die bei Bedarf beigezogen werden. Doch muss man auch den Nutzen von barrierefreien Internet klar benennen, fordert er. Hier ist beispielsweise die leichtere Wartung gut strukturierter Angebote erwähnenswert. Auch nutzt Barrierefreiheit, weil solche Seiten grundsätzlich die Benützbarkeit für alle erleichtern. Mit Freude konnte das wien.at-Team im Jahr 2005 den lang vorbereiteten Relaunch durchführen. Damit wurde eine grundlegende Verbesserung des Angebotes erreicht. Die Seiten erfüllen nun - auf das Layout bezogen - "Level AA" der Richtlinien für barrierefreies Internet und auch die Wartung hat sich vereinfacht und der Seitenaufbau deutlich beschleunigt. Doch "Barrierefreiheit ist ein Prozess", so Rederer, der klar darauf hinweist, dass "der nächste Relaunch bestimmt kommt". "Wir betrachten deshalb unsere Bemühungen in Sachen Barrierefreiheit mit dem Relaunch 2005 nicht als abgeschlossen, sondern sehen ihn als kontinuierlichen Prozess, unser Portal weiter zu verbessern", gibt wien.at bekannt. So, das war die dreizehnte Ausgabe unseres wöchentlichen Podcasts zum Thema barrierefreies Webdesign. Der Dank der Woche geht diesmal an Martin Ladstätter, der uns die Texte zur Verfügung gestellt hat. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von Einfach für Alle unter den Tags Veranstaltungen, Barrierefreiheit und Österreich, die Links gibt‘s wie üblich in der Mitschrift.http://www.einfach-fuer-alle.de/podcast/2006/kw42/http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Wien-Teil1.m4aFri, 20 Oct 2006 17:35:45 +0200Tech Newsno00:16:17barrierefrei, webdesign, accessibility, barrierefreies webdesign, WCAG, ÖGS, Leichte Sprache, ÖsterreichAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersWie in der letzten Woche sehen wir uns einige Aspekte barrierefreien Webdesigns an, die oft falsch eingesetzt werden. Mangelnde Skalierbarkeit und unmögliche Tastaturbedienung, die den Anbietern bei genauerem Hinsehen hätten auffallen müssen...In unserer Mini-Serie geht es diesmal wieder um Hilfen, die bei unüberlegtem Einsatz selbst zur Barriere werden können. Wie schon in der letzten Woche sehen wir uns heute einige Aspekte barrierefreien Webdesigns an, die oft falsch eingesetzt werden. Ebenfalls mit dabei sind einige Barrieren wie mangelnde Skalierbarkeit und unmögliche Tastaturbedienung, die den Anbietern bei genauerem Hinsehen schon längst hätten auffallen müssen. Fehler № 8: Ungewollte Navigation Im Netz fällt uns immer wieder auf, dass viele Angebote offensichtlich nur unzureichend getestet werden. Zu einem vollständigen Test gehört nicht nur die Simulation verschiedener Ausgabeformen und variabler Bedingungen; eine brauchbare Prüfung schliesst die Bedienbarkeit des Angebotes ein. Der einfachste Test lässt sich in einem kurzen Satz beschreiben: legen Sie die Maus beiseite. Einfach den Stecker rausziehen und versuchen, ob Sie das gesamte Angebot noch erreichen und bedienen können. In den Kriterien der BIENE 2006 steht zu diesem Thema: 17. Jegliche Funktion der Seite ist auch über die alleinige Verwendung der Tastatur in einer schlüssigen Reihenfolge zu erreichen, wobei die jeweils ausgewählte Funktion in der Standardansicht gut sichtbar ist. 17.1 Erreichbarkeit über Tastatur Prüfen Sie, ob alle aktivierbaren Positionen (Links, Navigationselemente, Buttons, Bilder) mit den Standardbelegungen der Tastatur zu erreichen (Tab-Taste, Pfeil-Tasten) und auszulösen sind (Enter-Taste). Anmerkung: Zur Abwertung führt, wenn durch Navigationsbewegungen Aktionen wie z. B. ein Download ausgeführt werden. Das Kriterium der schlüssigen Reihenfolge bei Tastaturbedienung ist fast schon von alleine erfüllt, wenn die Entwickler eine saubere Struktur mit den entsprechenden Strukturelementen aufgebaut haben. Dass man diese auch sehr schnell wieder mit dem unbedachten Einsatz von tabindex und accesskey zerstören kann hatten wir ja schon in der zehnten Folge unseres Podcasts besprochen. Neulich ist uns wieder mal eine Site über den Bildschirm geflimmert, bei der zum Zeitpunkt der Erstellung tabindex eingebaut wurden. Mittlerweile hatte sich die Seite aber geändert und Inhalte sind innerhalb der Seite verschoben worden. Leider wurde vergessen, die Werte der tabindex-Attribute anzupassen – die Navigation per Tab-Taste fühlte sich dann an wie Hüpfekästchen früher auf dem Schulhof. Unbedienbar werden Angebote, die die Anmerkung am Schluss des BIENE-Prüfschrittes betrifft: ein simples Durch-Tabben der Seite löst Aktionen aus, die der Nutzer nicht beabsichtigt. Gemeint sind Links, die beim Antabben per JavaScript Downloads auslösen, Popups öffnen oder sogar Druck-Dialoge auslösen. Erreicht wird dies per JavaScript mit onfocus; eine verwandte Technik findet man oft in formularbasierten Navigationen oder Auswahllisten, in denen schon durch den Wechsel der Auswahl mit onchange oder onblur das Formular abgesendet wird. Ein einfacher Test nach der oben beschriebenen Art enthüllt, dass dieses Formular per Tastatur nicht bedienbar ist. Fehler № 9: Mangelnde Skalierbarkeit Viele Webangebote sind schon bei geringfügig geänderten Einstellungen nicht mehr zu benutzen. Der Klassiker sind Layouts, die schon bei geringfügiger Änderung durcheinander geraten, oder in denen sich einzelne Inhalte oder sogar ganze Bereiche überlagern, sobald die Einstellungen des Nutzers von der Standardinstallation abweichen. Häufige Fehlerquellen hierfür sind: - Die Schriftgrößen sind zwar in relativen Einheiten wie em oder % definiert, die Spalten jedoch in starren Pixeln. Auch das Gerüst der Seiten und damit die Positionierung der Elemente geht von bestimmten Annahmen aus. Surft man nun eine Seite mit größerer Schrift an als der Webdesigner vorgesehen hat kommt es zu Überlagerungen ganzer Inhaltsblöcke und Texte verschwinden hinter anderen Texten. - Das Layout berücksichtigt nicht, dass per CMS überlange Worte eingepflegt werden, die jedes flexible CSS-Layout zerstören. Webbrowser beherrschen keine Silbentrennung, also umbrechen diese Worte auch nicht und drücken so ihre Container auseinander. Tipp: nehmen sie keine Blindtexte wie den bekannten Lorem Ipsum… – die Wortlängen entsprechen einfach nicht der deutschen Sprache. Nehmen Sie deutsche Beispieltexte, um ihre Templates zu testen, nur dann erhalten Sie ein echtes Bild. So, das war die zwölfte Ausgabe unseres wöchentlichen Podcasts zum Thema barrierefreies Webdesign. Der Dank der Woche geht an Jan Hellbusch, der uns beim Brainstorming geholfen hat. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags HTML , CSS und Navigation ; die Links gibt's wie üblich in der Mitschrift. Wenn es Ihnen gefallen hat hören wir uns nächste Woche wieder.http://www.einfach-fuer-alle.de/podcast/2006/kw38/http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Navigation.m4aThu, 21 Sep 2006 16:48:57 +0200Tech Newsno00:06:49barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcagAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersDiesmal schauen wir uns ein Thema an, dass wegen seiner Ergiebigkeit für eine eigene Sendung reicht: Metadaten in HTML-DokumentenHeute gibt es den zweiten Teil unserer kleinen Serie zum Thema »Gut gemeint ist das Gegenteil von Gut«. Nach dem erfolgreichen ersten Teil schauen wir uns diesmal ein Thema an, dass wegen seiner Ergiebigkeit ebenfalls für eine eigene Sendung reicht: Metadaten in HTML-Dokumenten. Das erste, woran Techniker beim Stichwort Metadaten denken, sind meist die bekannten Meta-Tags. Diese findet man im (unsichtbaren) Kopfbereich von HTML-Dokumenten und sie sollen dort weitergehende Informationen zu Inhalten und Funktionen der jeweiligen Seite oder Anwendung transportieren. Aber werfen wir erst mal einen Blick in die Richtlinien : BITV 13.2: Es sind Metadaten bereitzustellen, um semantische Informationen zu Internetangeboten hinzuzufügen. Im Glossar der BITV wird der Begriff Metadaten wie folgt definiert : Metadaten - Informationen über die verwendeten Daten oder Inhalte. Die Web Content Accessibility Guidelines 1.0 formulieren diesen Punkt so : WCAG 13.2: Stellen Sie Metadaten bereit, um semantische Information zu Seiten und Sites hinzuzufügen. [...] Z. B.: Verwenden Sie RDF [...], um den Autor, den Typ des Inhalts usw. anzuzeigen. Anmerkung: Manche HTML-Benutzeragenten können Navigations-Tools aus den Beziehungen des Dokuments erstellen, die mit dem LINK-Element von HTML und den Attributen "rel" und "rev" beschrieben sind. (z. B. rel="next", rel="previous", rel="index" usw.). Das ist bereits das Problem: befolgt man die Beispiele aus den WCAG wortgetreu, hat man hinterher unsichtbare Informationen, die kaum einem Besucher etwas nützen. Die gelisteten Beispiele haben keine definierte Schnittstelle zum Nutzer und die Handhabung dieser Metadaten ist von Browser zu Browser sehr unterschiedlich. Die Unterstützung geht von »gar nicht« bis »optional« - manche Browser zeigen die Informationen in einer optional einblendbaren Toolbar an, manche auch gar nicht. Somit kann man sich als Anbieter nicht darauf verlassen, dass diese Informationen auch wahrgenommen werden. Denn selbst wenn sie angezeigt werden, dann meistens ausserhalbaußerhalb des so genannten Viewports und damit nicht in der Blickrichtung des Nutzers. Die Informationen müssen also zusätzlich zum head des Dokumentes nochmals im body, also im sichtbaren Teil von HTML hinterlegt werden. Nur – dann braucht man die unsichtbaren Metadaten auch nicht. Denn es steht nirgendwo, dass man diese Daten ausschließlich unsichtbar hinterlegen darf. Die Richtlinien sind grundsätzlich gut, sie müssen nur richtig interpretiert werden. Die Techniken, die WCAG zur Verfügung stellen, sind weniger geeignet. Irgendwie sind auch die »Dublin Core«-Metatags auf einer Menge Checklisten gelandet - anders lässt sich deren verstärkter Einsatz kaum erklären. Suchmaschinen, die diesen Typ Metadaten auswerten sind uns, zumindest ausserhalb des akademischen Sektors, bisher nicht begegnet. Tipp: weglassen. Generell gibt es in HTML viele Dinge, die unsichtbare Daten bereitstellen und somit nur für Maschinen zugänglich sind oder für die seltenen User Agents, die diese auswerten und dem Nutzer anzeigen. Dazu gehören: * title-Attribute – diese braucht man eigentlich nur, wenn man keine braucht, oder wenn man damit vom eigentlichen Problem ablenken will. Unverständliche Linktexte sind hier das klassische Beispiel. Statt diese mit einem zusätzlichen title zu erklären sollte man besser den Linktext selbst verbessern. * title, wenn der Linktext bereits selbst ok ist. Eng verwandt mit dem ersten Beispiel, aber vollständig überflüssig. * summary und caption in Tabellen und ähnliche HTML-Elemente und Attribute, die Inhalte doppeln oder wegen unzuverlässiger Ausgabe eine Dopplung erzwingen. Was sind vernünftige Metadaten? Gute Metadaten sind in erster Linie für Menschen wahrnehmbar, Maschinen sollen die Metadaten ebenfalls auswerten können. Ein einfaches Beispiel zur Verdeutlichung: statt die Abfolge einer Artikelserie im head der Datei mit: link href="vor.html" rel="next" title="Nächste Seite" bzw. link href="zurueck.html" rel="previous" title="Vorherige Seite" zu definieren kann man dies genauso gut im body des Dokumentes machen: a href="vor.html" rel="next" Nächste Seite /a bzw. a href="zurueck.html" rel="previous" Vorherige Seite /a erfüllt den gleichen Zweck und transportiert zudem noch die identischen Meta-Informationen über den Platz des Dokumentes in einer Struktur. Damit muss die Information nicht doppelt hinterlegt werden. Ähnliches gilt für fast alle Meta-Informationen im HTML-head: mit etwas Nachdenken kommt man sehr schnell auf Lösungen, um diese gleichwertig im wichtigsten Teil des Dokumentes darzustellen: dem Teil, den der Benutzer zu Gesicht bekommt. Auch die immer beliebter werdenden Microformats sind Metadaten. Sie haben den Vorteil, dass es eine ganze Reihe Implementierungen gibt, die auch tatsächlich etwas mit den Daten anfangen können. Die Wahrnehmung durch den Benutzer ist hier viel verlässlicher - es ist ein Satz an Konventionen in »normalem« HTML, das man per CSS in das gewünschte Aussehen bringen kann. Das durch die starke Verbreitung von Weblogs immer bekannter werdende Konzept des Tagging ist ebenso eine Möglichkeit, einem Objekt beschreibende Metadaten mitzugeben. So, das war die elfte Ausgabe unseres wöchentlichen Podcasts zum Thema barrierefreies Webdesign. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags BITV , WCAG , HTML und Webstandards ; die Links gibt's wie üblich in der Mitschrift. Wenn es Ihnen gefallen hat hören wir uns nächste Woche wieder.http://www.einfach-fuer-alle.de/podcast/2006/kw37/http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Metadaten.m4aFri, 15 Sep 2006 08:59:12 +0200Tech Newsno00:07:39barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcag, metadata, html, microformatsAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersNicht nur aus purer Neugier schauen wir uns beinahe täglich jede Menge Webseiten an. Dabei fallen uns immer wieder Angebote auf, die alle möglichen Verrenkungen in Richtung Barrierefreiheit unternehmen und dabei weit über das Ziel hinausschießen.Nach den Tipps der letzten Wochen was man alles einbauen sollte geht es heute um das genaue Gegenteil: vermeintliche Hilfen, die bei unüberlegtem Einsatz selbst zur Barriere werden können. Nicht nur aus purer Neugier schauen wir uns beinahe täglich jede Menge Webseiten an. Dabei fallen uns immer wieder Angebote auf, die alle möglichen Verrenkungen in Richtung Barrierefreiheit unternehmen und dabei weit über das Ziel hinausschießen. In der Hoffnung allen Nutzungsszenarien gerecht zu werden stopfen die Anbieter alles in ihre Website, was das HTML-Vokabular hergibt. Heraus kommen Seiten, bei denen man vor lauter »Hilfen« den eigentlichen Inhalt kaum noch wahrnehmen und erst recht nicht bedienen kann. Deswegen schauen wir uns heute ein paar Dinge an, auf die man getrost verzichten kann. Fehler № 1: Bitte entscheiden Sie sich jetzt, wohin Sie springen möchten Gelegentlich finden wir auf Seiten bis zu einem dutzend (!) Skip-Links am Anfang der Dokumente, die die Orientierung erleichtern sollen. In diesen Fällen scheinen die Entwickler die Vorgaben aus den WCAG bzw. der BITV wörtlich zu nehmen, ohne den tieferen Sinn der Richtlinien zu berücksichtigen. Beide Richtlinien verlangen, inhaltlich verwandte Links zu gruppieren. Sie sollen mit einem Mechanismus versehen werden, der ein Überspringen ermöglicht (sogenannte Skip-Links). Die WCAG 2 sind da präziser: dort wird empfohlen, am Anfang eine Sprungmarke zum wesentlichen Inhalt einer Seite zu setzen. Und genau da liegt der eigentliche Sinn der Skip-Links: sie sollen punktgenaues Anspringen ermöglichen, ohne dass man erst die ganze Navigation durchtabben muss. Wenn man nun aber Batterien von Links nach dem Muster: Zur Hauptnavigation, Zur Metanavigation, Zur Infonavigation, Zur Unternavigation, Zur Bereichsnavigation, Zur Servicenavigation, Zum Seiteninhalt, … in einer Seite hinterlegt tut man seinen Besuchern keinen Gefallen – wobei in einem solchen Fall möglicherweise auch die gesamte Informationsarchitektur und die Gestaltung des Angebotes überdacht werden sollte. Eine Navigation, die sich über viele Unterebenen erstreckt und so beliebig über die Seite verteilt ist, dass man entsprechend viele Sprungmarken braucht, ist aller Wahrscheinlichkeit nach nicht nur unbedienbar, sie wird auch nicht verstanden. Streng genommen reichen einzelne, geschickt platzierte Sprungmarken, um den wesentlichen Inhalt zu erschliessen. Wenn diese Inhalte mit einer vernünftigen Überschriftenstruktur ausgestattet sind, Listen als Listen ausgezeichnet sind usw., dann erübrigen sich alle weiteren Hilfen von alleine. Fehler № 2: Bitte konfigurieren sie unsere Seiten, bevor Sie bei uns einkaufen Bei einigen Angeboten fällt auf, dass diese nahezu endlose Konfigurationsmöglichkeiten anbieten. Bevor man überhaupt etwas dem eigentlichen Sinn und Zweck der Seiten erfährt muss man erstmal mehrere Bildschirmseiten mit Bedienhinweisen und Anpassungsmöglichkeiten durchackern. Auch wir benutzen bei Einfach für Alle seit Jahren ein Skript, mit dem Nutzer die Schriftgröße dynamisch verändern können und einen Style Switcher zum Umschalten zwischen verschiedenen Layouts. Manche Anbieter gehen allerdings soweit und bieten Funktionen an, die besser dem Betriebssystem überlassen werden sollten. So macht eine alternative Gestaltung mit invertierten Farben keinen Sinn, auch wenn man damit vermeintlich sehbehinderten Nutzern entgegenkommen will. Wer wirklich sehbehindert ist und aufgrund der oftmals damit verbundenen Blendempfindlichkeit eigene Farben eingestellt hat ( z. B. Gelb auf Schwarz), dem nützt ein solcher Umschalter nichts. Im besten Fall werden, je nach verwendetem Betriebssystem die Farben einfach ignoriert, oder man erhält im schlimmsten Fall wieder die positive Darstellung mit dunklem Text auf hellem Hintergrund. Merke: nicht alles, was technisch machbar ist nützt auch dem Nutzer. Fehler № 3: Bitte drücken Sie Alt-Cmd-Ctrl-Shift-Esc-F8-Enter Ähnliches gilt für die immer noch häufig anzutreffenden Accesskeys. Diese werden häufig, oft auch in Verbindung mit Skip-Links, eingesetzt, um Bereiche einer Seite unmittelbar anspringen zu können. Bei häufig genutzten webbasierten Anwendungen, bei denen man einen gewissen Lernaufwand seitens des Benutzers voraussetzen kann, mögen diese noch sinnvoll sein. Auf reinen Content-Seiten sind sie dies in der Regel nicht. Problematisch ist hier der Lernaufwand, der den Nutzen übersteigt; fehlende, weil unmögliche Konventionen zur Belegung der Accesskeys; und die stark abweichende Umsetzung in den verschiedenen Browser-/Betriebssystem-Kombinationen. Fehler № 4: Bitte drücken Sie nicht hier Bei unseren Streifzügen sind wir auch schon über Seiten gestolpert, die tatsächlich für jeden einzelnen Link ein tabindex-Attribut vergeben hatten. Und zwar genau in der Reihenfolge, in der sie im Quelltext standen! Besonders fatale Wirkung entfaltet tabindex zusammen mit den oben angesprochenen Skip-Links und Accesskeys. Hat man einmal eine solche vermeintliche Hilfe innerhalb einer Seite benutzt und drückt dann zum weiterkommen auf die Tab-Taste, fängt man automatisch wieder bei Null an, d. h. in der Regel ganz oben im Dokument. Fehler № 5: Fehler № 5: Fehler № 5: Fehler № 5: geschwätzige Alternativen Im Bestreben, den allerersten Punkt aller Richtlinien zur Barrierefreiheit besonders gut zu erfüllen schießen viele Web-Autoren weit über das Ziel hinaus. Gemeint sind alternative Texte für Bilder und Grafiken, die doppelt und dreifach in einer Seite hinterlegt werden. Was gerade in der Sprachausgabe sehr anstrengend sein kann sind nicht nur überaus geschwätzige Alternativtexte, sondern auch Doppler von identischen alt- und title-Attributen bei Bildern, die zudem im umgebenden Link und im daneben stehenden Text nochmals wiederholt werden. Ähnliches gilt für title-Attribute von Links, in denen nichts anderes als der verlinkte Text wiederholt wird, »Absenden«-Buttons mit zusätzlichem »Absenden«-title und so weiter: Viel hilft nicht immer viel. Gerade wenn der Texter besonders freundlich sein wollte und den Link zum Katalog mit dem tollen title-Attribut »Klicken Sie hier, um zu unserem hervorragenden Katalog zu kommen« dekoriert hat wird die Navigation im Screenreader zu einem Geduldsspiel. Der grösste anzunehmende Unfall tritt ein, wenn der Nutzer so genervt ist, dass er zum Beispiel in seinem Screenreader die Ansage von title-Attributen ganz unterdrückt und dann wichtige Hinweise nicht mehr mitbekommt, die sich in folgenden title-Attributen verstecken. Fehler № 6: Barrieren, an die keiner denkt Nahezu unmöglich wird die Bedienung solcher wohlmeinenden Hilfen, wenn man zur Steuerung eine Spracheingabe benutzt. Ein sehender Nutzer sieht den Text »Bestellen« des grafisch realisierten Absenden-Buttons in einem Formular und spricht diesen ins Mikrofon. Die Sprachsteuerung kann aber das Bild nicht lesen und ist stattdessen auf den Text im Alternativ-Attribut angewiesen. Wenn dort nun nicht der exakt gleiche Text hinterlegt ist, sondern »Klicken Sie hier, um zur Kasse zu gehen« steht, dann scheitert an dieser Stelle der gesamte Bestellvorgang. Fazit: Anbieter von Webseiten sind häufig immer noch der Auffassung, dass Barrierefreiheit mehr kostet. Verschiedene Berechnungen haben aber gezeigt, dass die Gesamtkosten barrierefreier Internet-Angebote nicht höher liegen als die anderer Webseiten. Die Beispiele, die wir heute angesprochen haben, zeigen jedoch, dass Barrierefreiheit tatsächlich höhere Kosten verursachen kann, aber nur wenn man sie falsch begreift. Unsere Empfehlung: Web-Designer sollten die Richtlinien nicht als abzuhakende Checklisten nutzen, sondern ihren Ursprung, ihre Wirkung und ihre möglichen Nutzungsszenarien bedenken. Dann kann man mit weniger oft mehr erreichen – und damit ist wirklich allen geholfen. Denn die eingesparten Ressourcen können in die Verbesserung der Inhalte fliessen, und daran sind die Nutzer ja eigentlich interessiert. So, das war die zehnte Ausgabe unseres wöchentlichen Podcasts zum Thema barrierefreies Webdesign. Der Dank der Woche geht diesmal an Niko Krupinski vom Niedersächsischen Blinden- und Sehbehindertenverband, der uns beim Brainstorming zu diesem Thema geholfen hat. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von Einfach für Alle unter den Tags BIENE , HTML und Webstandards ; die Links gibt's wie üblich in der Mitschrift. Wenn es Ihnen gefallen hat hören wir uns nächste Woche wieder.http://www.einfach-fuer-alle.de/podcast/2006/kw35/http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_viel-hilft-viel.m4aThu, 31 Aug 2006 13:53:56 +0200Tech Newsno00:12:02barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcagAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersHeute geht es um eine der wichtigsten Grundlagen von barrierefreien Webangeboten: sauberer Code.Heute geht es um eine der wichtigsten Grundlagen von barrierefreien Webangeboten: sauberer Code. Auch bei der BIENE 2006 spielt sauberer Code eine Rolle Der Dreh- und Angelpunkt zu diesem Thema im Prüfverfahren der BIENE 2006 ist: 34. Eine Validierung von Dokumenten, die durch Markup-Sprachen erstellt wurden, ist gegen veröffentlichte formale W3C-Grammatiken möglich. 34.1 Prüfung der DTD 34.2 HTML Prüfung auf Einhaltung der W3C-Spezifikation 34.3 CSS Prüfung auf Einhaltung der W3C-Spezifikation Ähnliche Vorgaben an die Standard-Konformität der eingereichten Angebote ziehen sich wie ein roter Faden durch das weitere Prüfverfahren. Beispiele sind die Punkte: 14. Layout-Tabellen werden vermieden. und 30. Inhalt und Layout sind getrennt. Wie das in der vorigen Folge behandelte label-Element sind diese Punkte hervorragend geeignet, um sich einen schnellen Überblick über die Barrierefreiheit zu verschaffen. So kann man schnell feststellen, ob mehrfach verschachtelte Layout-Tabellen, font-Tags und ähnliches aus der Steinzeit der Webentwicklung verwendet werden. Das schöne daran ist, dass diese Punkte nahezu automatisch abgeprüft werden können. Ordentliches Fundament oder esoterischer Firlefanz? Die spannende Frage ist die nach der Gewichtung der gefundenen Fehler. Aus Sicht der Nutzer gibt es ganz bestimmt schwerwiegendere Barrieren als den nicht-validen Quelltext einer Seite oder einer Anwendung. Die Validatoren geben ja schon bei einem einzigen uncodierten Ampersand einen Fehler aus – das sind die kaufmännischen »unds« (&), die man häufig in den URLs dynamisch generierter Seiten findet. Streng genommen ist dies auch ein Fehler, da diese Ampersands zum Codieren von Sonderzeichen benötigt werden und somit selbst codiert werden müssen (&). Tipp: falls Ihr Redaktionssystem uncodierte Ampersands in URLs ausgibt kann man diese auch serverseitig noch bereinigen – fragen Sie den Sysadmin Ihres Vertrauens. Wichtig wird valider Quelltext jedoch, sobald die Zugangssoftware ins Spiel kommt. Die Hersteller und Programmierer von Browsern und Hilfsmitteln wie Screenreadern, Sprachsteuerungen etc. müssen enorme Anstrengungen machen, damit ihre Software auch bei groben Schnitzern noch ein verwertbares Ergebnis zurückliefert. Dazu müssen die Programme eine gewisse Fehlertoleranz besitzen und, grob vereinfacht ausgedrückt, auch Mechanismen besitzen, um sich von Fehlern zu »erholen« und mit der Verarbeitung des Quelltextes fortzufahren. Nichts anderes ist mit der etwas holprigen Formulierung in den WCAG 2.0 gemeint, die fordert, dass der Code »eindeutig gelesen« werden kann (parsed unambiguously). Quelltext, in denen vorgeschriebene Schlusstags fehlen, Elemente in der falschen Reihenfolge verschachtelt sind oder simple Tippfehler die eindeutige Verarbeitung erschweren, macht den Zugangsprogrammen (den sog. »User Agents«) das Leben unnötig schwer. Auch aus Sicht der Webentwickler wird es immer wichtiger, valides HTML zu schreiben. Wer schon mal das Vergnügen hatte, die Ursachen von Darstellungsfehlern in Seiten zu suchen, bei denen weder das HTML noch das CSS validierte weiss wovon wir reden: es ist nahezu unmöglich. Wenn beides zumindest ansatzweise validiert hat man eine ganze Reihe möglicher Fehlerquellen bereits ausgeschlossen. In den Urzeiten der Webentwicklung waren vergessene Schlußtags nicht so tragisch – spätestens am Ende der jeweiligen Zelle in der Layouttabelle war Ende und weitervererbt wurde dort gar nichts. Mit dem Einzug von CSS ins Webdesign gilt dies aber nicht mehr. Hier können sich Style-Angaben schon bei einem vergessenen oder falsch gesetzten Schlusstag quer durch das ganze Dokument vererben. Eine Behebung des Darstellungsfehlers wird erst durch die Reparatur des Quellcodes möglich. Neben der syntaktisch richtigen Umsetzung ist auch die Semantik von Bedeutung. Validierung bedeutet zunächst einmal nur eine Grammatik-Prüfung, ob die formalen Regeln von HTML und CSS eingehalten wurden. Natürlich ist es möglich, ein valides Dokument zu schreiben, das inhaltlich kompletter Unfug ist. Daher bei der BIENE 2006 unter anderem auch untersucht, ob Elemente entsprechend ihrer Bedeutung eingesetzt wurden. Ebenso wie der umgekehrte Fall, also ob Inhalte einer Seite mit den dafür vorgesehenen Elementen ausgezeichnet wurden, geprüft wird. Layouttabellen sind passé Bei diesem Punkt sticht die BIENE fester zu als die ihr zu Grunde liegenden Richtlinien. Die mittlerweile über sieben Jahre alten Zugänglichkeitsrichtlinien für Web-Inhalte 1.0 (_ WCAG 1.0) sagen zu dem Thema: »Tabellen sollten verwendet werden, um tatsächlich tabellarische Daten (›Datentabellen‹) zu kennzeichnen. Entwickler von Inhalten sollten es vermeiden, sie für das Seitenlayout zu verwenden (›Layout-Tabellen‹).« (Anm.: Hervorhebung hinzugefügt) Man beachte das »sollten« und setze es in den historischen Kontext. Zur damaligen Zeit war es tatsächlich kaum möglich, halbwegs ansprechende Designs ohne Layouttabellen hinzubekommen. Es war die Zeit der 3er- und 4er-Browser, die zwar erste Gehversuche in Richtung CSS machten, aber eigentlich alles falsch umsetzten. Diese Zeiten sind nun glücklicherweise vorbei und heutzutage gibt es keinen vernünftigen Grund mehr, neu gestaltete Seiten immer noch mit Layouttabellen und deren ständigem Begleiter, den Leer-GIFs, aufzubauen. Somit ist es nur folgerichtig, dass in den Prüfschritten der BIENE 2006 nun steht: 14.1 Keine Layout-Tabellen als Seitengerüst So, das war die achte Ausgabe unseres wöchentlichen Podcasts zum Thema barrierefreies Webdesign. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags BIENE, HTML und Webstandards; die Links gibt‘s wie üblich in der Mitschrift. Wenn es Ihnen gefallen hat, hören wir uns nächste Woche wieder.http://www.einfach-fuer-alle.de/podcast/2006/kw34/http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Sauberer-Code.m4aFri, 25 Aug 2006 20:37:49 +0200Tech Newsno00:08:00barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcag, HTML, CSSAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersNeben dem alt-Attribut ist das label-Element in Formularen eine wirklich simple Sache: mit seinem Einsatz kann man vielen Nutzern ohne großen Aufwand sehr viel gutes tun. Auch für die Tester bei der BIENE eignen sich diese Elemente hervorragend.In den kommenden Wochen wollen wir uns mal einige ausgewählte Prüfschritte aus dem BIENE-Testverfahren etwas genauer ansehen; den Anfang macht diese Woche das Label-Element aus HTML. Schnelltest auf Barrieren: das Label-Element Neben dem Alternativ-Attribut für Bilder ist das Label-Element in Formularen eine wirklich simple Sache: mit seinem Einsatz kann man vielen Nutzern ohne großen Aufwand sehr viel gutes tun. Auch für die Tester bei der BIENE eignen sich diese Elemente hervorragend, um sich einen ersten Blick über die Ernsthaftigkeit der Anstrengungen einer Einreichung zu verschaffen. Ob alt-Attribute überhaupt verwendet werden oder nicht lässt sich maschinell mit Hilfe eines Validators feststellen - seit HTML 4 ist dies Pflichtprogramm (die Sinnhaftigkeit der Alternativtexte ist natürlich ein anderes Thema). Um alternative Texte für nicht-textliche Inhalte kümmern wir uns in einer späteren Folge, heute schauen wir uns mal das label-Attribut etwas näher an. Im Prüfverfahren der BIENE 2006 steht: 15. Es gibt eine eindeutige Zuordnungsmöglichkeit von Beschriftungen zu den Kontrollelementen (z.B. Radio-Buttons) und zu Formulareingabefeldern. 15.1 Vergrößerte Ansicht: Zuordnung von Beschriftungen zu den Kontrollelementen und Eingabefeldern in Formularen Prüfen Sie in vergrößerter Ansicht, ob eine eindeutige Zuordnung von Beschriftungen zu den Kontrollelementen und Eingabefeldern möglich ist. 15.2 Verwendung von LABEL bei Kontroll- und Eingabefeldern in Formularen Prüfen Sie, ob die Zuordnung von Beschriftungen zu den Eingabefeldern und Kontrollelementen mit LABEL umgesetzt ist. Label – was ist das? Das englische Wort Label steht für Etikett und bezeichnet ein (Text-)Element, mit dem man Kontrollelementen in Formularen eine Beschriftung verpassen kann. Kontroll- oder Bedienelemente wiederum sind die Dinge in Formularen, mit denen der Benutzer interagiert, Auswahlen trifft oder Eingaben macht – also Textfelder, sogenannte radio buttons und checkboxes, Select-Boxen und einiges mehr. Diese Etiketten lassen sich nun auf zwei verschiedene Arten mit ihren Bedienelementen verknüpfen: Zum einen gibt es die implizite Methode, bei der das Bedienelement von einem label-Tag sozusagen eingewickelt wird. Der Webbrowser weiß nun, dass der im label-Tag enthaltene Text die Beschriftung des ebenfalls enthaltenen Bedienelementes ist - dessen Etikett. Diese automatische Verknüpfung ergibt sich also aus der Verschachtelung. Zum anderen gibt es die Methode der expliziten, der ausdrücklichen Verknüpfung. Hier wird dem label-Tag ein ID-Attribut mitgegeben, das wie alle IDs in HTML einen einmaligen Wert hat, also nicht mehrfach auf einer Seite vorkommen darf. Die Verknüpfung mit dem Bedienelement geschieht nun dadurch, dass dieses label ein zusätzliches for="..."-Attribut mit dem Wert der ID des dazugehörigen Bedienelements erhält. Diese müssen nun nicht mehr ineinander verschachtelt sein (können es aber). Warum sollte man Labels definieren? Der einfachste Grund ist: Benutzer sind dieses Verhalten gewohnt. Labels im HTML verursachen nämlich nichts anderes als ihre Vorbilder im Rest des Betriebssystems – der Labeltext wird anklickbar und steuert damit das verknüpfte Bedienelement. Besonders wichtig ist dies für Menschen, die Schwierigkeiten im präzisen Umgang mit der Computermaus haben. Durch die Verwendung von Labels wird die anklickbare Fläche nämlich um ein Vielfaches vergrößert und der Nutzer muss nicht unbedingt die 12 Pixel große Checkbox treffen, um ein Häkchen zu setzen. In der Wissenschaft ist dies als Fitts' Law bekannt – vereinfacht gesagt: je größer das Scheunentor, desto einfacher ist es mit der Schrotflinte zu treffen...http://www.einfach-fuer-alle.de/podcast/2006/kw33/http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Label.m4aThu, 17 Aug 2006 08:00:00 +0200Tech Newsno00:08:47barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcag, htmlAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersIm Februar dieses Jahres hatten die National Federation of the Blind und der blinde Kalifornier Bruce Sexton eine Sammelklage gegen Target.com eingereicht. Der Vorwurf lautet: Die Website ist für blinde Nutzer nicht bedienbar.Die Klage gegen Target In unserem Weblog hatten wir schon mehrfach über die Klage gegen den amerikanischen Einzelhändler Target, das heißt, gegen seine Website target.com berichtet. Im Februar dieses Jahres hatten die amerikanische National Federation of the Blind (NFB) und der blinde Kalifornier Bruce Sexton, ein Student aus Berkley, eine Sammelklage gegen Target eingereicht. Der Vorwurf lautet: Die Website ist für blinde Nutzer nicht bedienbar. Dieser Klage wird viel Bedeutung beigemessen, denn Target ist einer der Marktführer der Branche. Das Unternehmen unterhält circa 1.300 Läden und hat einen jährlichen Umsatz von über 46 Milliarden US$. Von Bedeutung ist die Klage auch deshalb, weil bisher in keinem einzigen Fall abschließend geklärt wurde, ob das US-Gesetz »Americans with Disabilities Act« auch für die Webseiten privater Anbieter gilt. Weitere Hintergründe zur Klage findet man auf den Seiten der Disability Rights Advocates, einer gemeinnützigen Organisation, die den blinden Berkley-Studenten Sexton vor Gericht vertritt. Als die Klage im Frühjahr eingereicht wurde, haben wir uns die Website target.com angesehen. Die Zugänglichkeit lässt in der Tat stark zu wünschen übrig. Der Bestellvorgang funktioniert nur per Maus, mit der Tastatur scheitert man an der Kasse und die Bilder und grafischen Bedienelemente haben größtenteils keine Alternativtexte. Am 23. Juli fand nun vor einem kalifornischen Gericht die erste Anhörung statt in der Gutachten und Gegengutachten eingebracht wurden. Dabei haben beide Seiten namhafte Experten der Accessibility-Szene hinzugezogen: - auf Seiten der Kläger steht der bekannte Autor und Berater Jim Thatcher. Thatcher ist freier Berater und hat den ersten Screenreader für IBM entworfen. Er ist außerdem Autor eines der Standardwerke über das Design barrierefreier Websites (»Constructing Accessible Websites«) - auf Seiten des verklagten Unternehmens arbeitet Chuck Letourneau. Letourneau ist der ehemalige Co-Chair der Arbeitsgruppe für Web Content Acessibility Guidelines 1.0 (WCAG 1.0). Diese Gruppe gehört zum World Wide Web Consortium (W3C). Beim Erstellen der Gutachten sind allerdings einige Fehler unterlaufen: So fokussiert Thatcher seine Befunde ausschließlich auf Barrieren für blinde Nutzer von Screenreadern. Dies liegt zunächst nahe, da der Kläger selbst blind ist und eine individuelle Diskriminierung nachzuweisen versucht. Die Art der Formulierungen erweckt jedoch den Eindruck, dass es beim barrierefreien Webdesign ausschließlich um die Bereitstellung des technischen Zugangs für nur eine Gruppe von Hilfsmitteln geht. Damit konzentriert sich die Klage im vorliegenden Fall ausschließlich auf eine veraltete JAWS-Version für Windows. Die Aussage etwa, dass Alternativtexte für Bilder beim Drübermausen als Tooltip erscheinen, können Experten kaum überzeugen. Einige der im Gutachten aufgelisteten Hürden sind mittlerweile vom Anbieter beseitigt. Dies hat der Autor selbst angemerkt. Einige der höchsten Barrieren sind im Gutachten für Sexton nicht angeführt: So werden die wöchentlichen Sonderangebote oder andere Rabatte (“An easy 10% off”) ausschließlich als Grafiken ohne Alternativtext dargestellt. Dies führt dazu, dass jemand, der diese Grafiken nicht sehen kann, 10% mehr bezahlt. Das ist eine klare Diskriminierung. Da dies vom Gutachten nicht erwähnt wird, hat der Gegengutachter leichtes Spiel: die Strategie der Verteidigung zielt offensichtlich darauf ab, für die Unzugänglichkeit der Website den Anwender und seine Software verantwortlich zu machen: »In my experience, a blind person’s ability to access any given website depends on more than just the website’s design. It will depend on [...] how much time the user is willing to spend exploring the cite [sic]« Frei übersetzt heißt das: »Der Zugang klappt schon irgendwie, egal wie ungünstig das Design ist. Der Benutzer muss einfach nur etwas mehr Ausdauer beim Erkunden der Site aufbringen.« http://www.einfach-fuer-alle.de/podcast/2006/kw32/http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Target.m4aThu, 10 Aug 2006 22:00:53 +0200Tech Newsno00:10:27accessibility, barrierefreies webdesign, bitv, wcag, Lawsuit, NFB, Target, Apple, VoiceOver, ScreenreaderAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas Caspers durch die zusätzliche Klasse vcard:

im HTML eine komplette Adresse, die sich in ein Adressbuch übernehmen lässt. Mit weiteren Klassen lassen sich Namen, Orte, Telefonnummern etc. beschreiben, bis hin zu Geodaten zur Verknüpfung mit Stadtplänen. Ähnlich funktioniert das bei Kalenderdaten: die Auszeichnung eines Datums mit der Klasse vevent macht aus dem Inhalt automatisch ein hCalendar-Microformat. Weitere Klassen wie description, location, url, dtstart und dtend können für zusätzliche Daten vergeben werden, die z. B. einen Termin oder eine Veranstaltung beschreiben. Wie so etwas im praktischen Einsatz funktioniert, können Sie auf unserer Seite mit den Veranstaltungstipps, im Impressum von ›Einfach für Alle‹ oder im Programm des Webkongress Erlangen sehen. Eine Übersicht der gängigen Regeln finden Sie im Spickzettel Microformats Cheat Sheet. Und das schönste: im Gegensatz zu RDF kann man die Daten per CSS formatieren – es ist und bleibt ja einfaches, aber semantisches HTML ohne Umwege. So lassen sich im Style Sheet Regeln aufstellen, die den Kalenderdaten gleich auch noch ein kalendermäßiges Aussehen verpassen. Die benötigten Klassen für die entsprechenden CSS-Selektoren haben wir ja soeben eingebaut. Was hat der Nutzer davon? Die alles entscheidende Frage bei jeder Technik: was bringt es dem Nutzer? Ein wichtiges Designprinzip bei Microformats ist: erst der Mensch, dann die Maschine. Dass es, ähnlich wie bei RDF noch keine Killer-Applikation gibt ist nicht weiter schlimm. Wichtiger ist der Netzwerkeffekt, der durch die rasche Verbreitung von Microformats über Weblogs entsteht. Das ist wie bei dem bekannten Beispiel mit den Faxgeräten: ein Faxgerät alleine nützt gar nichts, aber je mehr Faxgeräte es gibt, desto wertvoller wird jedes einzelne Gerät. Mittlerweile gibt es eine ganze Reihe von Anwendungen, die sich Microformats zu Nutze machen. Zentrale Anlaufstelle ist die Microformats-Suche bei Technorati. Dort können Nutzer zum Beispiel nach Webinhalten suchen, die mit ganz bestimmten Schlagworten getaggt sind. Der Suchroboter wertet dafür Links aus, die das rel-tag Microformat benutzen und findet so zum Beispiel Blogposts, die mit den Tags »BITV« oder »Web Accessibility« versehen sind. Auch Yahoo! ist auf den Zug aufgesprungen: so sind die Benutzerprofile bei der Foto-Community flickr mit dem hCard-Microformat hinterlegt, Yahoo! Tech benutzt das hReview-Microformat für Produktbesprechungen und upcoming.org listet Veranstaltungen im hCalendar-Microformat. So richtig spannend wird es, wenn sich diese Formate direkt in lokale Anwendungen des Nutzers übernehmen lassen. Wer schon einmal Termine aus PDFs abgetippt hat oder per Copy 'n' Paste aus HTML-Seiten in den Kalender übertragen hat wird sich sicher darüber freuen: geeignete Programme vorausgesetzt kann man entsprechend aufbereitete Daten per Mausklick zum Beispiel in Outlook oder iCal übertragen. Und wer unbedingt darauf besteht, kann das ja immer noch in RDF umwandeln :-) Ein Vorteil von Microformats ist, dass dafür kein Browser umgeschrieben werden muss. Da es ja nur Konventionen innerhalb der etablierten HTML-Standards sind, werden sie von allen Browsern prinzipiell gelesen. Ein Problem gibt es zur Zeit noch bei der Anzeige und damit der Auffindbarkeit solcher Daten: wie so oft bei Metadaten sind sie erst mal unsichtbar. Alternative Browser wie der auf Firefox basierende Flock schaffen da Abhilfe, und für Firefox selbst gibt es eine Anzahl passender Erweiterungen. Auch für andere Browser gibt es Bestrebungen oder zumindest Vorschläge, die Anzeige von Mikroformaten im Browser zu ermöglichen (»A Proposal for a Safari Microformats plugin« oder »Microformats in Web Browsers«). Daher sollte man als Anbieter auf jeden Fall kenntlich machen, dass Microformats hinterlegt sind und diese mit Tools wie X2V in Formate konvertieren, die der Besucher herunterladen und weiterverarbeiten kann. Oder man zapft die online verfügbaren Tools bei Technorati an und lässt die Konvertierung automatisch per Mausklick geschehen. Brian Suda bietet auf seiner Seite zwei Bookmarklets an, mit denen man vCard- und iCal-Daten aus Webseiten extrahieren kann. So, das war die sechste Ausgabe unseres wöchentlichen Podcasts zum Thema barrierefreies Webdesign. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter dem Tag »Microformats«; die Links gibt‘s wie üblich in der Mitschrift. Wenn es Ihnen gefallen hat hören wir uns nächste Woche wieder.]]>Heute geht es um ein neues Schlagwort, mit dem man nicht nur Kunden oder Kollegen beeindrucken kann, sondern das auch brauchbare Anwendungszwecke hat: Microformats...Heute geht es um ein neues Schlagwort, mit dem man nicht nur Kunden oder Kollegen beeindrucken kann, sondern das auch brauchbare Anwendungszwecke hat. Das nächste große Ding ist etwas ganz Kleines: Microformats Ein weiterer Schritt in Richtung des semantischen Webs sind die sogenannten Microformats. Das Schlagwort vom Semantischen Web macht ja nun schon etwas länger die Runde – allerdings auch immer versehen mit der Einschränkung in der Zukunft werden Maschinen damit dies und jenes machen können. Der Begriff Semantik kommt eigentlich aus der Sprachwissenschaft und bezeichnet die Lehre von der Bedeutung der Dinge. Wenn es nach dem W3C ginge, dann würde man für mehr Semantik im Netz Sprachen wie die Web Ontology Language (kurz OWL) oder Resource Description Framework (RDF) benutzen und damit Metadaten über die vorhandenen Webinhalte hinterlegen. Damit wären Computer in der Lage, den Sinn und Zweck der Inhalte besser zu verstehen. Nun haben Webentwickler damit aber gleich zwei Probleme. Zum einen: warum sollen nur Maschinen den ganzen Spaß haben? Und zum anderen: in Zukunft? Wir brauchen Lösungen, und zwar bitteschön jetzt. Erschwerend kommt hinzu, dass beim Einsatz solcher Metadaten die Informationen mehrfach hinterlegt sein müssen – einmal für die maschinenlesbare Auswertung und zusätzlich im Klartext für den Fall, dass auch mal menschliche Besucher vorbeikommen. Doppelte Arbeit, die unnötig ist. Wie praktisch, dass sich neben der akademischen Diskussion gerade ein »lowercase semantic web« entwickelt, sozusagen das semantische Web auf dem kleinen Dienstweg. Statt das Web immer wieder neu zu erfinden haben sich schon vor zwei Jahren ein paar schlaue Köpfe (Tantek Çelik und Kevin Marks, um genau zu sein) die bestehenden Standards, besonders (X)HTML noch mal genau angesehen und festgestellt, dass sich auch mit den vorhandenen Möglichkeiten weitergehende Logik in Webseiten einbauen lässt. Die bekanntesten Ergebnisse sind Microformats – kleine Codeschnipsel nach bestimmten Regeln, die man in seine Webseiten einbauen kann, ohne dass man dafür eine neue Sprache erlernen muss – sie sind nämlich bloß einfaches HTML. Die Regeln selbst bestehen aus einem einfachen Satz an Konventionen von Klassennamen und Attributwerten, die man an fast jedes HTML-Element dranhängen kann. Also eigentlich nichts anderes als das, was man beim Aufbau einer Seite mit sauberem HTML & CSS eh‘ schon macht. In den HTML-Empfehlungen des W3C ist die Bedeutung der jeweiligen Elemente festgelegt, wenn auch wegen des begrenzten Vokabulars oft nur Annäherungen möglich sind. Bei der Definition von Mikroformaten hingegen einigt man sich darauf, welche Bedeutung die einzelnen Werte der HTML-Attribute haben sollen – und da wären wir wieder bei der Semantik, also der Bedeutung der Dinge, nur diesmal in kleinbuchstaben. Bekannte Beispiele sind das hCard-Microformat, um Adressdaten auszuzeichnen, oder das hCalendar-Microformat für Kalenderdaten. So wird beispielsweise aus einem: <address class="kontaktdaten"> durch die zusätzliche Klasse vcard: <address class="kontaktdaten vcard"> im HTML eine komplette Adresse, die sich in ein Adressbuch übernehmen lässt. Mit weiteren Klassen lassen sich Namen, Orte, Telefonnummern etc. beschreiben, bis hin zu Geodaten zur Verknüpfung mit Stadtplänen. Ähnlich funktioniert das bei Kalenderdaten: die Auszeichnung eines Datums mit der Klasse vevent macht aus dem Inhalt automatisch ein hCalendar-Microformat. Weitere Klassen wie description, location, url, dtstart und dtend können für zusätzliche Daten vergeben werden, die z.&thinsp;B. einen Termin oder eine Veranstaltung beschreiben. Wie so etwas im praktischen Einsatz funktioniert, können Sie auf unserer Seite mit den Veranstaltungstipps, im Impressum von ›Einfach für Alle‹ oder im Programm des Webkongress Erlangen sehen. Eine Übersicht der gängigen Regeln finden Sie im Spickzettel Microformats Cheat Sheet. Und das schönste: im Gegensatz zu RDF kann man die Daten per CSS formatieren – es ist und bleibt ja einfaches, aber semantisches HTML ohne Umwege. So lassen sich im Style Sheet Regeln aufstellen, die den Kalenderdaten gleich auch noch ein kalendermäßiges Aussehen verpassen. Die benötigten Klassen für die entsprechenden CSS-Selektoren haben wir ja soeben eingebaut. Was hat der Nutzer davon? Die alles entscheidende Frage bei jeder Technik: was bringt es dem Nutzer? Ein wichtiges Designprinzip bei Microformats ist: erst der Mensch, dann die Maschine. Dass es, ähnlich wie bei RDF noch keine Killer-Applikation gibt ist nicht weiter schlimm. Wichtiger ist der Netzwerkeffekt, der durch die rasche Verbreitung von Microformats über Weblogs entsteht. Das ist wie bei dem bekannten Beispiel mit den Faxgeräten: ein Faxgerät alleine nützt gar nichts, aber je mehr Faxgeräte es gibt, desto wertvoller wird jedes einzelne Gerät. Mittlerweile gibt es eine ganze Reihe von Anwendungen, die sich Microformats zu Nutze machen. Zentrale Anlaufstelle ist die Microformats-Suche bei Technorati. Dort können Nutzer zum Beispiel nach Webinhalten suchen, die mit ganz bestimmten Schlagworten getaggt sind. Der Suchroboter wertet dafür Links aus, die das rel-tag Microformat benutzen und findet so zum Beispiel Blogposts, die mit den Tags »BITV« oder »Web Accessibility« versehen sind. Auch Yahoo! ist auf den Zug aufgesprungen: so sind die Benutzerprofile bei der Foto-Community flickr mit dem hCard-Microformat hinterlegt, Yahoo! Tech benutzt das hReview-Microformat für Produktbesprechungen und upcoming.org listet Veranstaltungen im hCalendar-Microformat. So richtig spannend wird es, wenn sich diese Formate direkt in lokale Anwendungen des Nutzers übernehmen lassen. Wer schon einmal Termine aus PDFs abgetippt hat oder per Copy 'n' Paste aus HTML-Seiten in den Kalender übertragen hat wird sich sicher darüber freuen: geeignete Programme vorausgesetzt kann man entsprechend aufbereitete Daten per Mausklick zum Beispiel in Outlook oder iCal übertragen. Und wer unbedingt darauf besteht, kann das ja immer noch in RDF umwandeln :-) Ein Vorteil von Microformats ist, dass dafür kein Browser umgeschrieben werden muss. Da es ja nur Konventionen innerhalb der etablierten HTML-Standards sind, werden sie von allen Browsern prinzipiell gelesen. Ein Problem gibt es zur Zeit noch bei der Anzeige und damit der Auffindbarkeit solcher Daten: wie so oft bei Metadaten sind sie erst mal unsichtbar. Alternative Browser wie der auf Firefox basierende Flock schaffen da Abhilfe, und für Firefox selbst gibt es eine Anzahl passender Erweiterungen. Auch für andere Browser gibt es Bestrebungen oder zumindest Vorschläge, die Anzeige von Mikroformaten im Browser zu ermöglichen (»A Proposal for a Safari Microformats plugin« oder »Microformats in Web Browsers«). Daher sollte man als Anbieter auf jeden Fall kenntlich machen, dass Microformats hinterlegt sind und diese mit Tools wie X2V in Formate konvertieren, die der Besucher herunterladen und weiterverarbeiten kann. Oder man zapft die online verfügbaren Tools bei Technorati an und lässt die Konvertierung automatisch per Mausklick geschehen. Brian Suda bietet auf seiner Seite zwei Bookmarklets an, mit denen man vCard- und iCal-Daten aus Webseiten extrahieren kann. So, das war die sechste Ausgabe unseres wöchentlichen Podcasts zum Thema barrierefreies Webdesign. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter dem Tag »Microformats«; die Links gibt‘s wie üblich in der Mitschrift. Wenn es Ihnen gefallen hat hören wir uns nächste Woche wieder.http://www.einfach-fuer-alle.de/podcast/http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_microformats.m4aThu, 03 Aug 2006 17:07:32 +0200Tech Newsno00:09:13barrierefrei, webdesign, accessibility, barrierefreies webdesign, bitv, wcagAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersAm 22. Juni endete die Frist zur Abgabe von Kommentaren zum aktuellen Entwurf der Web Content Accessibility Guidelines 2. Wir hatten mehrfach im Blog darüber berichtet und der Sache auch einen eigenen Podcast gewidmet: das Echo ist eher durchwachsen…Da hier in NRW die Schulferien mit der Fussball-WM um Aufmerksamkeit kämpfen, zeigen bei unserem Angebot die Zugriffszahlen folgerichtig nach Süden. Deswegen gibt's diese Woche kein besonderes Thema, sondern den Wochenrückblick zu allem, was in Accessibility-Land wichtig war. Letzte Runde für WCAG 2 abgelaufen Am 22. Juni endete die Frist zur Abgabe von Kommentaren zum aktuellen Entwurf der Web Content Accessibility Guidelines 2. Wir hatten mehrfach im Blog darüber berichtet und der Sache auch einen eigenen Podcast gewidmet: das Echo ist eher durchwachsen. Nachdem die Web Accessibility Initiative die Frist um drei Wochen verlängert hat sind nun insgesamt über 400 Kommentare eingegangen. Um es vorweg zu sagen: alle Kommentare haben wir nicht gelesen. Dazu waren es einfach zu viele, und zudem ist das Archiv der Kommentare schlichtweg unbenutzbar. Die Übersicht der über das Webformular eingegangenen Kommentare listet hunderte gleich benannter Links auf; wer was wozu gesagt hat erfährt man erst, wenn man sich durch die Links durchklickt. Als Alternative zu dem Formular gab es auch weitere Möglichkeiten zur Einreichung von Kommentaren – entweder in Form einer Excel-Datei oder in unformatiertem Endlos-ASCII-Text. Alles nicht barrierefrei zu nutzen, und eine Recherche, ob Punkte bereits ausreichend behandelt wurden, oder ob der eigene Kommentar vielleicht schon mehrfach von anderen eingereicht wurde ist damit unmöglich. Aber auch wenn man nicht sämtliche Kommentare gelesen hat, kann man erkennen, dass der Entwurf tendenziell abgelehnt wird. Einen Kommentar, der die Richtlinien für gut befindet haben wir nicht finden können. Oft beziehen sich diese nur auf Details, aber in sehr vielen Kommentaren wurden grundlegende Zweifel an wichtigen Eckpunkten der Richtlinien geäußert und diese Zweifel auch begründet. Erschreckend finden wir es geradezu, dass einige dieser Kommentare aus der Ecke der schwergewichtigen Mitglieder der WCAG-Arbeitsgruppe selbst kommen. So zum Beispiel von Vertretern von IBM, AOL und Opera, um nur einige zu nennen, sowie Universitäten, Regierungs- und Nicht-Regierungs-Einrichtungen. Dies ging hin bis zu einem formellen Einspruch gegen die WCAG 2 selbst. Dieser Einspruch namhafter Experten aus der Szene fordert, dass Lernbehinderungen aus der Liste der Behinderungen gestrichen werden, die von WCAG 2 abgedeckt sind. Sie sind der Meinung, dass die Bedürfnisse von Menschen mit Lernbehinderung in den Richtlinien nicht mehr berücksichtigt werden. Die meisten Vorgaben für diese Gruppe befinden sich in der dritten Stufe der Richtlinien. Von dieser Stufe braucht man ja bekanntlich nur 50% zu erfüllen um sich ein Triple-A auf die Website zu heften. Wenn man es einigermaßen geschickt anstellt braucht man sich also nur die Level-3-Punkte herauszusuchen, die nicht anwendbar sind oder einfach zu erreichen sind. Schon sind alle Zielgruppen ausgeschlossen, für die Barrieren nicht nur technischer, sondern inhaltlicher Natur sind - wie bereits in den WCAG 1.0. Auch aus Webentwickler-Kreisen war das Echo fast einheitlich ablehnend. Dass die Richtlinien schwer verständlich sind wird schon länger diskutiert - auch wir haben eine ganze Zeit gebraucht, um den Vorläufer – die WCAG 1.0 – zu verstehen und richtig anzuwenden. Das ist für sich genommen also noch nicht außergewöhnlich. Wie viele Menschen aber der Meinung sind, dass die WCAG 2 nicht nur schwer verständlich, sondern unverständlich sind hat uns dann doch erstaunt und sollte der Arbeitsgruppe zu Denken geben. Eine ganze Reihe von Eingaben zeigen die Tendenz, dass man besser die von den WCAG 1 eingeschlagene Richtung nicht verlassen hätte… http://www.einfach-fuer-alle.de/podcast/2006/kw26/http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_WCAG2.m4aThu, 29 Jun 2006 08:00:00 +0200Tech Newsno00:09:28WCAG, WCAG2, BITV, WAI, W3C, web accessibility, barrierefreiAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersIn dieser Woche dreht sich alles um Veranstaltungen zum Thema Webstandards und Barrierefreiheit. Wir schauen uns einmal etwas genauer an, was an solchen Veranstaltungen gut und was verbesserungswürdig ist…In dieser Woche dreht sich alles um Veranstaltungen zum Thema Webstandards und Barrierefreiheit. Neben der alljährlichen South by Southwest Interactive (SxSWi) im März ist die letzte Woche über die Bühne gegangene Londoner @media-Konferenz quasi die Jahreshauptversammlung der internationalen Webstandards- und Accessibility-Szene. Grund genug, sich einmal etwas genauer anzusehen was an solchen Veranstaltungen gut und was verbesserungswürdig ist. Konferenzen Die großen Konferenzen leben davon, dass möglichst viele Leute in möglichst kurzer Zeit möglichst viele Vorträge von möglichst berühmten Rednern hören. So war es auch in der vergangenen Woche wieder in London: 2 Tage vollgepackt mit hervorragenden Beiträgen aus der Champions League der Vortragsreisenden, garniert mit einem ausgedehnten Rahmenprogramm. Anders als im Vorjahr war in diesem Jahr eine große Delegation aus Deutschland angereist. Die Verdoppelung des Publikums im Vergleich zum Vorjahr ging leider einher mit der Verdoppelung der Vorträge, so dass die Veranstaltung in zwei parallele Tracks aufgeteilt wurde. Was wiederum zur Folge hatte, dass man ganz zwangsläufig mindestens die Hälfte der Vorträge verpassen musste. Wie bei guten Konferenzen üblich sollen in Bälde sämtliche Vorträge und Diskussionen als Podcast und teilweise sogar als Videocast veröffentlicht werden, sodass man alles nachhören kann. Neben diesen perfekt durchorganisierten Kongressen schießen im Augenblick aber auch eine ganze Reihe neuer Veranstaltungen aus dem Boden, die einen radikal anderen Ansatz haben: Un-Konferenzen Entstanden ist das ganze, als der Verleger Tim O‘Reilly eine Veranstaltung namens Foocamp mit ein paar handverlesenen Gästen gab. Einige der Nichteingeladenen veranstalteten kurzerhand ein alternatives Ding namens Barcamp (Programmierer werden das in den Namen versteckte Osterei sicher finden) und eine Idee war geboren. Ausgehend von der Erkenntnis, dass die wirklich interessanten Dinge bei Konferenzen jenseits der Panels auf dem Flur stattfinden lässt man bei diesem Typ Veranstaltung die Panels gleich ganz weg und legt die Veranstaltung auf den Flur. Anders als bei großen Konferenzen ist die Teilnahme grundsätzlich kostenlos, dafür wird die rege Beteiligung aller Anwesenden erwartet. Mittlerweile schwappt diese Idee auch über den großen Teich – so hat Tim Bonnemann die Idee des Web Montags aus dem Silicon Valley importiert und erfolgreich etabliert. Bis jetzt haben in 15 deutschen Städten Web Montage stattgefunden oder sie sind in Planung. Die Planung wiederum läuft un-konferenz-typisch nicht über ein Organisationskomitee, sondern webbasiert und offen für alle per Wiki. Dort kann man sich einfach in die Liste der Teilnehmer eintragen. Wenn man ein interessantes Thema vorstellen möchte, dann meldet man sich für einen Kurzvortrag. Die Vorträge sind üblicherweise auf 10 Minuten begrenzt. Wenn der Vortrag gut war schließt sich eine Diskussion mit dem Publikum an, wenn nicht, dann ist der nächste dran. Wann und wo die nächsten Web Montage stattfinden kann man unter www.webmontag.de nachlesen. Und wenn in Ihrer Nähe keiner stattfindet, dann organisieren sie doch einfach selber einen Web Montag. Noch radikaler und gänzlich ohne Frontalunterricht sind die Barcamps, in Deutschland erstmalig im Spätsommer in Berlin. Das Motto hier: »Keine Zuschauer, nur Teilnehmer« - man trifft sich zwei Tage lang, diskutiert in losen Gruppen und arbeitet an Lösungen für Probleme, die die Teilnehmer aus ihrer täglichen Arbeit als Web-Schaffende mitgebracht haben. Die Voraussetzungen sind denkbar einfach: alles was benötigt wird ist ein Dach über dem Kopf, ausreichend Bandbreite für den Internetzugang aller Teilnehmer und einen Sponsor für‘s Catering. Also im übertragenen Sinne ein Wiki für‘s richtige Leben…http://www.einfach-fuer-alle.de/podcast/2006/kw25/http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Veranstaltungen.m4aThu, 22 Jun 2006 08:00:00 +0200Tech Newsno00:09:28Barrierefreiheit, Veranstaltungen, WebstandardsAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersIn dieser Woche dreht sich alles um aktuelle Trends in der Webentwicklung und wie man diese mit den Prinzipen der Barrierefreiheit vereinbaren kann…In dieser Woche dreht sich alles um aktuelle Trends in der Webentwicklung und wie man diese mit den Prinzipen der Barrierefreiheit vereinbaren kann. Der Versuch einer Positionsbestimmung Zurzeit machen eine ganze Reihe neuer Schlagwörter die Runde, mit denen umschrieben wird, wie wir alle in Zukunft das Web wahrnehmen und nutzen sollen. Web two point oh oder Web Zwei Punkt Null, das Schreib-/Lese-Web, Software als Service oder auch technische Details wie Ajax sind ein paar Beispiele, mit denen wir uns heute mal etwas intensiver beschäftigen wollen. Was dieses Web zwei punkt null-Dings denn nun genau ist, darüber besteht weitestgehende Uneinigkeit. Der gemeinsame Nenner und gleichzeitig die Abgrenzung zur Versionsnummer Eins Punkt Null scheint aber zu sein, dass das Web nicht mehr nur als passives Einbahnstraßenmedium gesehen wird. Nutzer können und sollen sich aktiv an der Gestaltung der Inhalte beteiligen und erobern so das Netz zurück. Oder, wie ein Systemadministrator ausdrücken würde: chmod 777 Web. Webseiten bieten Funktionen an, die bisher den klassischen Desktop-Anwendungen vorenthalten waren, oder für die man aufwändige Redaktionssysteme brauchte. Das geht bis zu ganzen Anwendungen aus dem Office-Bereich, die vollständig im Browser laufen. Gleichzeitig verschwimmt die Grenze zwischen Desktop und Web immer weiter. Der Anwender merkt bei vielen Angeboten und Diensten schon gar nicht mehr, ob er noch auf dem eigenen Rechner arbeitet oder auf einem entfernten Server. Der Berliner Webdesigner Markus Angermeier hat vor einiger Zeit versucht, die vielen Schlagworte in einer absolut Web2.0-tauglichen Tagcloud darzustellen, den Link dazu finden Sie wie immer in der Mitschrift zu diesem Podcast. Darin sind die Gewichtungen und Zusammenhänge von Standardisierung und Einfachheit, von offenen Daten, Protokollen und Schnittstellen, und ganz wichtig, die Partizipation der Nutzer schön zu erkennen. Genau diese Teilnahmemöglichkeit steht auf der Kippe oder ist für einige Nutzergruppen kaum vorhanden. Während die Urversion des Webs eine Ansammlung weitestgehend statischer Texte war und auch die Regeln zur Barrierefreiheit größtenteils auf diesen Typus von Webinhalten abzielen, prägt das neue Web sehr viel Dynamik. Genau diese Dynamik ist es, die Anbietern und Webentwicklern Kopfschmerzen bereitet, wenn sie ihre Websites für möglichst viele Nutzer zugänglich gestalten wollen. Typische Anwendungsfälle Schauen wir uns doch zunächst mal ein paar typische Anwendungsfälle für Techniken wie Ajax an: Einfache Beispiele, an denen sich sehr schnell der Nutzen von dynamischen Inhalten erklären lassen sind Google Suggest und Yahoo! Livesearch. Bei diesen Webanwendungen werden Eingaben in die Suchbox per JavaScript abgefangen und automatisch an die Server zurückgeschickt bevor der Nutzer das Formular absendet. Die Server wiederum schicken fast in Echtzeit passende Treffer zurück, die sofort angezeigt werden. Nutzer bekommen also ein unmittelbares Feedback über die Erfolgsaussichten der eingegebenen Suchbegriffe, ähnlich lautende Treffer oder sogar Rechtschreibvorschläge bei Tippfehlern. Der Nutzen aus Sicht der Anwender ist so offensichtlich, dass wir eine ähnliche Technik beim letzten Relaunch auch auf unseren Seiten eingebaut haben. Nutzer, die ausgefeilte Suchstrategien oder womöglich sogar die Verknüpfung von Suchbegriffe mit Operatoren nicht beherrschen bekommen direktes Feedback über mögliche bessere Suchbegriffe, Menschen mit Lese-/Rechtschreibschwäche dürfen sich schonmal vertippen, und das Beste: das ganze ist in modernen Screenreadern vollständig nutzbar…http://www.einfach-fuer-alle.de/podcast/2006/kw24/http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_Ajax.m4aWed, 14 Jun 2006 08:00:00 +0200Tech Newsno00:16:43AJAX, JavaScript, Web 2.0, accessibility, screenreaderAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersDie BIENE 2006, der Wettbewerb Barrierefreies Internet, geht in diesem Jahr in die vierte Runde. Der Wettbewerb soll die besten barrierefreien Angebote im Internet prämieren und als Vorbild bekannt machen…In dieser Woche dreht sich alles um die BIENE 2006, den Wettbewerb Barrierefreies Internet, der in diesem Jahr in die vierte Runde geht. Die BIENE wird von der Aktion Mensch und der Stiftung Digitale Chancen veranstaltet; der Wettbewerb soll die besten barrierefreien Angebote im Internet prämieren und als Vorbild bekannt machen. Dabei ist die BIENE der einzige Internet-Wettbewerb in Deutschland, der die Barrierefreiheit von Webseiten in den Mittelpunkt stellt. BIENE? Was ist das? Die BIENE wurde von den Veranstaltern im Jahr 2003 ins Leben gerufen; gemeinsam mit einem fachlichen Beirat wurde ein Prüfverfahren auf Basis der Barrierefreie Informationstechnik-Verordnung (BITV) entwickelt und am Schluss waren es über 170 Websites, die sich um einen der Preise bewarben. In den folgenden Jahren steigerte sich die Zahl der eingereichten Angebote immer weiter; im letzten Jahr mussten immerhin 320 Angebote das strikte Auswahlverfahren überstehen. Erfreulich auch, dass die ausgezeichneten Angebote tendenziell immer besser wurden: wo in den ersten Jahren in einigen Kategorien noch kein Gold vergeben werden konnte, hat sich die Qualität gerade im letzten Jahr deutlich gesteigert – was sich auch in einer ganzen Reihe goldener Bienen widerspiegelte. So wurden in den vergangenen drei Jahren eine ganze Reihe großer und kleiner Webangebote mit den begehrten Bienen in Gold, Silber oder Bronze ausgezeichnet: • In der Kategorie »E-Commerce« waren dies zum Beispiel Angebote wie das Online-Banking der Postbank bis zur Hebammenpraxis am Bodensee; • in der Kategorie »E-Government« die Webseiten von Bundesministerien oder der Polizei Nordrhein- Westfalen bis hin zu kleinen Angeboten von Ortsvereinen politischer Parteien und dem Integrationsfachdienst Hamburg; • in der Kategorie »Kultur und Gesellschaft« gab es Silber oder Bronze zum Beispiel für Greenpeace Berlin, das Österreichische Jüdische Museum in Eisenstadt und die Initiative neue Soziale Marktwirtschaft. • Auch in der Kategorie »Bildung, Wissenschaft und Forschung« gab es ein breites Spektrum: die prämierten Websites reichten von Universitäten über Fachhochschulen und Berufsbildungswerke bis hin zum vorbildlichen Angebot einer Grundschule. • Traditionell eher unterbesetzt ist die Kategorie Medien – hier konnten in den vergangenen Jahren nur zwei Bienen in Bronze vergeben werden. Neben diesen klassischen Kategorien wurden auch immer wieder Sonder- und Förderpreise an Webseiten vergeben, die vielleicht nicht immer absolut barrierefrei im Sinne des Testverfahrens waren, die aber hervorragende Lösungsansätze für Teilaspekte des Barrierefreien Webdesigns zeigten. Aus allen diesen Gewinnern lässt sich ein gemeinsames Fazit ziehen: Barrierefreiheit geht, man muss es nur anpacken. Und auch einen anderen Mythos konnte die BIENE widerlegen: dass Ästhetik und Barrierefreiheit unvereinbar sind. Oder, um Guido Karl, Projektleiter der Polizei NRW zu zitieren: “Wie man sieht, dass eine Website barrierefrei ist? Gar nicht. Das ist ja das Schöne!” Was ist neu bei der BIENE 2006? Der Name Die offensichtlichste Änderung vorneweg: Award wird gestrichen – der Wettbewerb heißt ab sofort nicht mehr »BIENE-Award«, sondern einfach nur noch »BIENE«. Damit reagieren die Veranstalter auf die Hinweise von Menschen mit Lernbehinderung, für die solche Anglizismen unnötige Barrieren aufbauen. Neue Kategorien Eine zweite wichtige Änderung ist die Sortierung der Einreichungen nach ihrem Nutzen und ihrer Komplexität. Dazu wurden die Kategorien unterteilt in: • Informations- und Kommunikationsangebote (beispielsweise Themenportale, tagesaktuelle Medien und Foren), • Recherche- und Serviceangebote (das können Fahrplanauskünfte ohne Buchung, Kataloge, Datenbanken, Modellrechner sein) und • Einkaufs- und Transaktionsangebote (wie zum Beispiel Buchungen, Reservierungen und Zahlungen) Diese Kategorien sollen die Perspektive der Nutzer viel besser widerspiegeln…http://www.einfach-fuer-alle.de/podcast/2006/kw23/http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_BIENE.m4aThu, 08 Jun 2006 08:00:00 +0200Tech Newsno00:10:46BIENE, accessibility, barrierefreies webdesign, wettbewerb, awardAktion Mensch, Sprecher: Manfred Heinze, Text: Tomas CaspersDaß der am 27. April als sogenannter »Last Call« vorgestellte Entwurf der WCAG 2.0 für kontroverse Diskussionen in der Szene sorgen würde war zu erwarten. Daß die Kontroversen aber so heftig würden, haben selbst Insider nicht vorhersehen können…Dass der am 27. April als sogenannter »Last Call« vorgestellte Entwurf der WCAG 2.0 für kontroverse Diskussionen in der Szene sorgen würde war eigentlich zu erwarten. Dass die Kontroversen aber so heftig würden, das haben selbst Insider nicht vorhersehen können. Vielleicht war auch einfach nur die Erwartungshaltung zu groß, dass nun nach sechs Jahren Entwicklungszeit endlich eine brauchbare Fassung vorgelegt würde. Eine Richtlinie, die das Thema für die nächsten Jahre wetterfest macht und Webdesignern hilft, moderne Webinhalte zugänglich zu gestalten. So zumindest waren die Hoffnungen. Nichts von dem scheint der Fall zu sein, wenn man den Äusserungen verschiedener Experten glauben mag, die sich teilweise sehr vehement in ihren Weblogs geäussert haben. Aber schauen wir uns doch erst einmal an, welche Ziele sich die Web Accessibility Initiative des W3C für die Überarbeitung der Richtlinien selbst gesetzt hatte: 1. Anwendbar über alle Techniken hinweg 2. Klare Bedingungen zur Konformität 3. Die Richtlinien sollten einfach zu benutzen sein 4. Sie sollten für ein breiteres Publikum geschrieben sein 5. Sie sollten klar herausstellen, wer von zugänglichen Inhalten profitiert 6. Die überarbeitete Richtlinie sollte auf- und abwärtskompatibel sein So steht es zumindest auf der Website des W3C in einem Dokument namens »Requirements for WCAG 2«. Wer die Latte so hoch legt, der wird dann auch daran gemessen. Da wundert es nicht, dass in der aktuell laufenden Kommentarphase namens Last Call mit Stand von heute schon über 170 Kommentare eingegangen sind. Und viele Fachleute haben sich über die in ihren Augen viel zu kurze Einspruchsfrist von fünf Wochen geärgert - so viele, dass die Frist nun bis zum 22. Juni verlängert wird. Die heftigste Kritik hat die WCAG-Arbeitsgruppe aber ausgerechnet von denen geerntet, die zu den wichtigsten Verfechtern der Barrierefreiheit im World Wide Web gehören: so hat der kanadische Accessibility-Berater und Journalist Joe Clark bei A List Apart einen Artikel unter dem Titel »To hell with WCAG« veröffentlicht und gleichzeitig die Bildung der »WCAG Samurai« angekündigt, einer Gruppe die eine verbesserte Version der bestehenden Richtlinien WCAG 1.0 entwickeln wollen. Und auch die Accessibility Task Force des Web Standards Project arbeitet, so war hinter den Kulissen zu vernehmen, an einer Stellungnahme zum Entwurf. Fassen wir die wichtigsten Kritikpunkte zusammen: Testbarkeit Um die Vorgabe der Testbarkeit aller Kriterien zu erfüllen hat die WCAG-Arbeitsgruppe eine Richtlinie geschaffen, die fast nur noch die technischen Zugangsprobleme berücksichtigt. Punkte zu inhaltlichen Barrieren, wie sie für Menschen mit Lernbehinderungen bestehen, findet man kaum noch im Entwurf. Das geht so weit, dass nun sogar ein Mitglied der Arbeitsgruppe, Lisa Seeman aus Israel, die selbst eine Lese- / Rechtschreibschwäche hat, beantragt hat, Lernbehinderungen aus dem Katalog der Behinderungsformen zu streichen, die von einer verbesserten Richtlinie profitieren würden. Links zu diesem und den andern eingegangenen Kommentaren, und zu einem Artikel von Gez Lemon, der weiter ins Detail geht, gibt's auf unserer Website. Baselines Das gesamte Konzept der Baselines, mit denen ein Anbieter einer Website Mindestvoraussetzungen an die technische Ausstattung seiner Nutzer stellen kann, trifft auf weitestgehendes Unverständnis. Die dahinter stehende Idee ist, dass alle Anstrengungen in Richtung barrierefreier Inhalte nichts nützen, wenn die vom Nutzer eingesetzte Software diese nicht unterstützt oder nicht korrekt wiedergibt. Damit Anbieter weiterhin die Barrierefreiheit ihrer Seiten deklarieren können wurden die so genannten »Baseline Assumptions« erdacht, grob übersetzt: »Annahmen von Mindesttechniken«. Darin kann ein Anbieter festlegen, dass die zur Nutzung des Angebots eingesetzte Software zum Beispiel mindestens HTML 4 und CSS 2  verstehen und korrekt umsetzen muss…http://www.einfach-fuer-alle.de/podcast/2006/kw22/http://www.einfach-fuer-alle.de/podcast/enhanced/accessCast_WCAG_2.0.m4aThu, 01 Jun 2006 08:00:00 +0200Tech Newsno00:11:02WCAG, WCAG2, BITV, WAI, W3C, web accessibility, barrierefrei