Die Stiftung »Zugang für alle« aus der Schweiz veröffentlicht heute das erste Gratis-Programm zum Testen der Barrierefreiheit von PDF-Dokumenten. PAC – PDF Accessibility Checker – führt automatisch Prüfungen durch und erstellt einen Bericht mit den gefundenen Fehlern. PAC ermöglicht zudem eine Vorschau eines PDF-Dokuments. Diese Vorschau zeigt auf, wie das Dokument von einem blinden Menschen mit Screenreader (Bildschirmleseprogramm) interpretiert und gelesen wird.
Barrierefreie PDF sind Dokumente, die von allen – auch von Menschen mit Behinderungen – gelesen werden können. So können beispielsweise Blinde auf ein barrierefreies PDF-Dokument über ein Bildschirmlese-Programm (Screenreader) zugreifen; der Screenreader liest das Dokument vor. Damit das aber funktioniert, sind – ähnlich wie in HTML – Strukturinformationen (sog. Tags) notwendig. Erst bei korrektem Einsatz dieser Tags ist es möglich, dass viele Menschen mit Behinderungen ein PDF lesen, benutzen und bedienen können.
Im Internet werden immer mehr PDF-Dokumente publiziert. Leider sind diese Dokumente ohne spezielle Bearbeitung nicht zugänglich und viele Menschen mit Behinderungen können die Informationen in diesen Dateien nicht oder nur teilweise lesen. Auch der grösste Teil der PDF-Dokumente von Behörden, welche aufgrund des Behindertengleichstellungsgesetzes zugänglich sein müssten, sind nicht barrierefrei und somit nicht lesbar für Menschen mit Behinderungen.
Weiterlesen …
Werkzeug überprüft Barrierefreiheit übersichtlich
Das kostenlose Programm PAC ist ein sehr nützliches Hilfsmittel für alle die testen möchten, ob ihre PDF-Dokumente auch für Menschen mit Behinderungen geeignet sind. PAC führt bei einem PDF-Dokument oder PDF-Formular die folgenden 12 Prüfschritte durch:
- Dokument als getaggt markiert
- Dokumenttitel vorhanden
- Dokumentsprache definiert
- Zulässige Sicherheitseinstellung
- Tab folgt Dokumentstruktur
- Dokument konsistent gegliedert
- Lesezeichen vorhanden
- Zugängliche Zeichencodierungen
- Inhalt vollständig getaggt
- Logische Lesereihenfolge
- Alternativtexte vorhanden
- Korrekte Syntax von Tags/Rollen
PAC bietet weiter die Möglichkeit, eine Vorschau des strukturierten PDF-Dokuments in einem Browser anzuzeigen. Diese Vorschau zeigt auf, welche Tags im PDF-Dokument enthalten sind. Somit kann einfach erkannt werden, welche Elemente von assistierenden Programmen (z.B. einem Screenreader) interpretiert und ausgegeben werden können. Die Vorschau ist eine Accessibility-Preview des Dokuments.
Im PAC-Prüfungsbericht wird zu den einzelnen Checkpunkten der Status mit den entsprechenden Meldungen ausgegeben. Über die Links kann innerhalb des Prüfberichts navigiert werden. Beim Aktivieren der Links mit den Fehlermeldungen wird das PDF-Dokument im Webbrowser geöffnet und die Position von möglichen Fehlern wird angezeigt.
Feedback
PAC steht kostenlos und ohne Einschränkungen als sog. Freeware zur Verfügung. Feedback, Fehlermeldungen oder Vorschläge für weitere Funktionen sind willkommen. Bitte Feedback per E-Mail an pac@access-for-all.ch.
Download und weitere Informationen
Hier geht es zum kostenlosen Download des PDF Accessibility Checker PAC.
Folgende System-Anforderungen müssen erfüllt sein:
- Windows XP, Vista oder 7
- Adobe Reader Version 8 oder neuer
- Mozilla Firefox 3 oder neuer, Interner Explorer 8 oder neuer oder Google Chrome
- Microsoft .NET Framework 2.0 SP2 oder neuer
Der Arbeitstag des gemeinen Web-Entwicklers beginnt ja üblicherweise damit, dass man mal eben schnell was im IE & Firefox kontrollieren will. Beim Start der Virtualisierungs-Software will diese erstmal aktualisiert werden. OK. Update durchgeführt, neugestartet und, oh Wunder, die nächsten Sicherheitsupdates für XP. Na gut, schnell mal installiert, Neustart und dann endlich Firefox geöffnet. Oh, ein Update! Mal schnell runterladen, Browser neustarten, Erweiterungen auf Updates überprüfen und, man glaubt es kaum, es gibt neue Versionen. Runterladen, installieren, Browser neustarten und …
… nichts geht mehr.
Und das alles nur um festzustellen, dass zumindest der letzte Teil des Prozederes für die Katz' war, weil ausgrechnet eine für Web-Entwickler so wichtige Erweiterung namens Firebug so dermaßen voller Bugs ist, dass nur noch das Downgrade auf die Vorgängerversion hilft. Pustekuchen, weil die ist dann nämlich nicht mit der neueren Browser-Version kompatibel und verweigert die Installation.
20 GOTO 10
Der einzige Trost: Die Suche bei Twitter zeigt, dass man nicht allein mit dem Problem ist. Dabei wollten wir eigentlich nur was zu den angeblichen Accessibility-Verbesserungen in Firebug 1.4.x schreiben, aber mangels Testobjekt muss dieser Blogpost halt bis zur nächsten Version warten. Und dann geht der Spaß wieder von vorne los …
Im Punkt 2.3.1 der WCAG 2.0 geht es um eine eher seltene, aber in ihren Auswirkungen drastische Form von Behinderung: die photosensitive Epilepsie. Von ihr betroffen sind Menschen, bei denen in einem bestimmten Frequenz-Bereich blinkender oder blitzender Inhalt einen epileptischen Anfall auslösen kann. Aus dem Erfolgskriterium selbst wird natürlich nicht klar, worum es genau geht und wie dies zu verhindern bzw. zu testen ist:
2.3.1 Grenzwert von dreimaligem Blitzen oder weniger: Webseiten enthalten nichts, was öfter als dreimal in einem beliebigen, eine Sekunde dauernden Zeitraum blitzt, oder der Blitz ist unterhalb der allgemeinen Grenzwerte zu Blitzen und roten Blitzen. (Stufe A)
Im Glossar der WCAG 2.0 steht nur pauschal »Es gibt Werkzeuge, welche die Analyse durch die Erfassung des Video-Bildschirms ausführen«
, aber nicht, welche diese Werkzeuge sind und wo man sie bekommt. Zum besseren Verständnis muss man da schon die »Understanding WCAG 2.0«-Dokumente heranziehen – dort wird dann im Detail erklärt, was hinter diesem Kriterium steckt und wie man es bewertet: »Understanding Success Criterion 2.3.1: Three Flashes or Below Threshold«
Genau für diese Evaluation gibt es jetzt vom Trace Research and Development Center ein Werkzeug namens Photosensitive Epilepsy Analysis Tool (PEAT), das nun in einer Beta-Version 1.5 zum Download (für Windows) veröffentlicht wurde.
Eher was für richtige Programmierer oder solche die es werden wollten: Wenn Sie schon immer mal wissen wollten wie das eigentlich funktioniert, dass ein Screenreader was mit dem Zeugs anfangen kann das da auf dem Bildschirm zu sehen ist – bei code-magazine.com ist vor einiger Zeit ein Sonderheft zum Thema ›Windows Accessibility Focus‹ erschienen, in dem das alles erklärt wird. Die Artikel gibt es entweder als (leider nicht barrierefreies) PDF zum herunterladen oder einzeln in HTML-Form. So zum Beispiel:
Einige der Artikel sind aber auch für profane Web-Entwickler sehr gut zu gebrauchen:
Zugänglichkeit für Nutzer ohne Maus zu ermöglichen ist einer der wichtigsten Schritte beim Aufbau einer barrierefreien Webseite oder Web-Applikation. Beim Testen der Zugänglichkeit per Tastatur findet man sich immer wieder nach dem Drücken der Tabtaste in der Situation: »Wo ist mein Cursor?« oder »Welches Element hat eigentlich gerade den Fokus?«. Gerade bei Elementen, die per CSS aus dem sichtbaren Bildschirm-Bereich geschoben wurden, tabt man dann gern und lang im Dunkeln.
LogFocus – hilfreiches Bookmarklet beim Testen von Keyboard-Accessibility
Beim Aufräumen unserer Lesezeichen-Sammlung haben wir ein Skript von Dirk Ginader gefunden, das Licht in diese Situationen bringt, und das er vor einiger Zeit in ein handliches Bookmarklet gekapselt hat.
LogFocus arbeitet in allen Browsern, die eine Konsole zur Verfügung stellen: Im Firefox ist hierfür Firebug notwendig; in Safari (bzw. WebKit) muss das ›Develop‹-Menü aktiviert sein; für Internet Explorer empfiehlt sich das PlugIn Companion.JS und in Opera wird die eingebaute Konsole im Debugger Dragonfly genutzt.
Um das Bookmarklet zu installieren zieht man einfach den folgenden Link in die eigenen Bookmarks:
LogFocus
Von dort aus kann das Skript dann einfach per Klick auf jeder beliebigen Seite ausgeführt werden und die aktuelle Position wird in die Konsole geschrieben.
Irgendwie haben wir wohl verpasst, dass die neueste Version 4 des freien Accessibility-Checkers WAVE Ende März dem βeta-Stadium entwachsen ist: WAVE Blog - New WAVE Version Released. Neben einer verbesserten Oberfläche und einer schnelleren Reaktionszeit werden eine ganze Reihe neuer Richtlinien und auch Techniken wie WAI-ARIA getestet. Wave ist eines der wenigen Tools, dass zum Beispiel Formularelemente ohne dazugehöriges Label findet (was auch dem besten Coder schonmal passieren kann, wenn man sich bei der ID vertippt).
Die WAVE-Reports gibt es entweder über das Web-Interface oder als Firefox-Toolbar, in beiden Fällen werden die gefundenen Fehler direkt im Browser angezeigt. Für die Zukunft ist auch die Lokalisierung in verschiedene Sprachen geplant, laut WebAIM Blog werden noch freiwillige Helfer gesucht.
Nachtrag 25.04.: Ab sofort ist auch die aktualisierte Firefox-Toolbar unter wave.webaim.org/toolbar erhältlich; weitere Infos dazu im WebAIM: Blog.
Beim britischen RNIB gibt es eine neue Erweiterung für den Internet Explorer, die Menschen mit Behinderungen das Surfen erleichtern soll: RNIB Surf Right Toolbar - beta version. Die Toolbar wurde zusammen mit dem Web Accessibility Tools Consortium entwickelt und ermöglicht es, JavaScript, Style Sheets, Flash oder Bilder abzuschalten, Schrift zu skalieren und verschiedene Benutzer-definierte Style Sheets auf Webseiten anzuwenden. (gefunden via)
(Bevor jemand fragt: ja, es ist immer besser sowas clientseitig zu haben, als dass jede einzelne Website entsprechende Knöpfchen anbietet.)
Eines der brauchbarsten Testwerkzeuge ist nun wie angekündigt als Erweiterung für Firefox erhältlich (Download, Packungsbeilage).
Das Prüfwerkzeug Bobby ist seit dem 1. Februar nicht mehr öffentlich zugänglich. Falls Ihnen dass jetzt nichts sagt: Bobby ist dieser grinsende Polizist, mit dem unbedarfte Webmaster den Nachweis auf ihre Seiten kleben konnten, dass man eine barrierefreie Seite hat das Bobby-Prüfverfahren bestanden hat.
Das Programm war zunächst am amerikanischen Center for Applied Special Technology (CAST) entwickelt und in den letzten Jahren von der Firma Watchfire weiterentwickelt und kommerziell vertrieben worden. Letztere ist im vergangenen Jahr von IBM übernommen worden und das Programm soll dem Vernehmen nach als Teil der Rational Policy Tester Accessibility Edition weiter vertrieben werden.
Unser Lieblings-Testwerkzeug liegt in einer neuen Version vor: WAVE 4.0 (beta). Das schöne an WAVE ist, dass man nicht mit einer seitenlangen Tabelle von Fehlern (oder vermeintlichen Fehlern) konfrontiert wird, sondern die problematischen Dinge im optischen Kontext der getesteten Seite sieht. Mehr dazu und zu den Änderungen und Neuerungen vom Mit-Entwickler Jared Smith im WebAIM-Blog: »Introducing WAVE 4.0«.
Eine Toolbar für Firefox ist noch in der Mache und soll in Bälde folgen. Mit dieser lassen sich dann auch Seiten im Intranet bzw. in Passwort-geschützten Bereichen testen, oder wenn sensitive Daten nicht über's Netz verschickt werden sollen.
Auf den simplen Namen Design hört ein ziemlich cooles JavaScript-Bookmarklet (bzw. Favelet oder wie auch immer das in Ihrem Browser heisst). Wie üblich einfach in die Lesezeichen-Leiste ziehen, Seite laden, draufdrücken und schon erhält man jede Menge nützliche Infos zum Aufbau der Seite. Sowas ähnliches gibt es auch als eigenständige Anwendung in Form von xScope, allerdings ist dies Bezahlware und MacOS-only.
Ganz ohne Werkzeuge gehen die Schnelltests, die Maria Putzhuber vorstellt und mit denen sich auch Nicht-Fachleute einen ersten Eindruck von der Zugänglichkeit eines Web-Angebotes verschaffen können: »Barrierefreiheit selber testen – Schnelltest ohne Werkzeuge«. Etwas komfortabler, allerdings auch mit höheren Ansprüchen an das Vorwissen geht es dann aber doch mit entsprechender Unterstützung: »Barrierefreiheit selber testen mit Werkzeugleisten«. (via)
XHTML-CSS Validator β ist kein wirklich neuer Validator, sondern ein Tool, dass Seiten gleichzeitig an die (X)HTML- und CSS-Prüfer des W3C übergibt und deren Ergebnisse aufbereitet; weitere Erklärung zur Funktionsweise bei »About the XHTML-CSS Validator«.
Barrierefreie Informationstechnik ist natürlich nicht nur auf das Geschehen im Webbrowser beschränkt. Bei IBM alphaworks gibt es neuerdings ein ganzes Framework von Accessibility-Werkzeugen, und mit dem enthaltenen aDesigner lässt sich nun auch die Barrierefreiheit von ›Open Document Format‹-Dokumenten (also OpenOffice etc.) überprüfen.
Gut daran: es werden nicht nur die gefundenen Probleme aufgelistet, sondern man erhält auch gleich noch eine Visualisierung, wie z.B. Nutzer mit verschiedenen Formen der Sehbehinderung das Dokument wahrnehmen würden. Getestet wird übrigens auf Basis der ODF v1.1 Accessibility Guidelines Version 1.0.
Microformats hatten wir auch schon lange nicht mehr:
Und gleich noch die passenden Werkzeuge dazu: »ufXtract - Microformats Parser« und »Safari Microformats plugin«.
In diversen Artikeln und Tutorials hatten wir immer wieder auf die großartige Web Accessibility Toolbar 2.0 für den Internet Explorer hingewiesen, die bisher nur als englischsprachige Version zu haben war. Benjamin Griessmann von Web For All und Martin Kliehm haben das jetzt geändert und das Werkzeug ins Deutsche übersetzt: Web Accessibility Toolbar DE - Version 2.0 (1,3 MB große .exe).
Ebenfalls empfehlenswert ist die Kombination aus Firefox Accessibility-Erweiterung zusammen mit dem Functional Web Accessibility Evaluator (FAE) der Universität von Illinois. Während die meisten Prüf-Tools nur den einmal vom Server geladenen HTML-Code überprüfen können, so kann man mit der o.g. Kombo auch dynamische Web-Applikationen testen. Mit der Accessibility-Extension kann man neuerdings auch den aktuellen Zustand des Dokumentes testen, wenn dieses von Skripten verändert wurde. Dazu wird von der Erweiterung ein jeweils aktueller Schnappschuss des Document Object Models an den FAE zur weiteren Analyse gesendet.
Queerbeet zu allem was uns in dieser Woche zum Thema Accessibility über den Bildschirm gelaufen ist:
Passend zum letzten Link eine interessante Analyse, die wir via Mel Pedley (Text Sizes and Screen Resolution) fanden: »A survey of Browser Text Size settings«. Meßergebnis: 99,7% der gemessenen Nutzer belassen es bei der im Browser Internet Explorer voreingestellten mittleren Schriftgröße; die verbleibenden 0,3% verteilen sich auf 0,2% mit größerem Schriftgrad und 0,1% mit browserseitig verkleinerter Schrift. Nutzer mit sehr geringen Bildschirm-Auflösungen (sprich: 640×480), aber auch Nutzer am anderen Extrem (sprich: 1600×1200 und höher) haben mit doppelt so hoher Häufigkeit an der Schriftgröße im Browser gedreht.
Nachtrag: »Screen Resolutions and Aspect Ratios Worldwide«.
Eine alte Weisheit des Feng GUI sagt, dass der Code von Webseiten mit der Zeit immer größer wird, obwohl (oder gerade weil) sich niemand im Team mehr daran erinnern kann, wofür der zusätzliche Code eigentlich nötig ist. Das gilt insbesondere für Style Sheets, die man schon etwas länger in Betrieb hat. Bei einigermaßen komplexen Style Sheets ist es nahezu unmöglich herauszufinden, ob wirklich alle Selektoren (das ist der Text vor den geschweiften Klammern) noch benötigt werden, oder ob man sie gefahrlos entsorgen kann.
Wenn es da nicht die Firefox-Erweiterung »Dust-Me Selectors« von James ›brothercake‹ Edwards gäbe, die nun in der stark verbesserten Version 2.0 vorliegt (Download, Packungsbeilage). Wenn man seine gesamte Website absurft, merkt sich die Erweiterung die im HTML tatsächlich verwendeten Elemente, IDs und Klassen und gleicht sie mit den Selektoren im CSS ab. Die wichtigste Neuerung: die Erweiterung merkt nun auch, wenn Seiten nach dem Laden per DOM-Scripting (im Volksmund auch AJAX genannt) verändert werden.
Diesmal geht's wieder um das Aufspüren von Barrieren in Web-Angeboten. Dazu schauen wir uns ein paar empfehlenswerte Prüfwerkzeuge an und geben Praxistipps zu deren sinnvollem Einsatz …
Zum Mithören:
Podcast vom 07. Nov.
(.mp3, 20′27″, 18,7 MB)
Zum Mitlesen:
Die Mitschrift des Podcasts
Zum Abonnieren:
Der Podcast im iTunes Music Store
Aktennotiz an uns selber: bei Gelegenheit mal ausprobieren: Simple CSS — A Free CSS Authoring Tool (für Mac, Windows und Linux, Download, Packungsbeilage).
XRAY hatten wir ja neulich schonmal, jetzt gibt's vom selben Autor ein neues Tool zur CSS-Fehlersuche namens MRI. Zur Installation einfach in die Lesezeichen-Leiste ziehen, dann eine Seite laden, MRI anklicken, beliebige Selektoren eintippen und das Skript zeigt wo diese Selektoren in der Seite verwendet werden. Nett.
Falls Sie dann noch Platz auf der Platte haben – damit bekommen Sie ihn weg: »100 great free and open source tools and applications for web developers«.
Und überhaupt: einfache Linklisten sind out. Was jetzt angesagt ist sind Listen von Listen. So wie die »Mother of All Resource Lists For Web Designers«. Spätestens wenn es drei von dieser Sorte gibt, dann lohnt es sich eine Liste von allen Listen anzulegen, die Listen verzeichnen.
Schon seit der Version 0.8 ist der W3C-Validator nicht mehr ganz so designfrei und viel benutzbarer. Seitdem sind hinter den Kulissen weitere Verbesserungen hinzugekommen und auch die neueste Version 0.8.2 hat wieder ein paar Bugs weniger. Ein Bugfix ist insbesondere für Screenreader-Nutzer von Bedeutung: ab sofort sind die versteckten Optionen (More Options) auch tatsächlich versteckt und man muss sich nicht mehr durch eine ellenlange Liste von Formularelementen durchtabben, wenn man sie nicht braucht. (via)
Nachtrag: Validator S.A.C. (Stand Alone Complex) ist eine Version des W3C-Markup-Validators in Form einer eigenständigen Applikation für Mac OS X (Download, Packungsbeilage). Alternativ kann man das ganze auch unter dem lokalen Apachen laufen lassen und im hausinternen Netz als Dienst zur Verfügung stellen. (via)
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 …
Zum Mithören:
Podcast vom 12. Okt.
(.mp3, 21′16″, 19,6 MB)
Zum Mitlesen:
Die Mitschrift des Podcasts
Zum Abonnieren:
Der Podcast im iTunes Music Store
Ein gewisser Michael Sync schreibt an einer mehrteiligen Erklärung der genialen Firefox-Erweiterung Firebug von Joe Hewitt:
(via)
Wo wir gerade beim Thema Qualitätssicherung sind: »Setting media type headers on your Web site« vom W3C Q&A Weblog.
