News mit dem Tag »WCAG«
Alles was beim Vorlesen nur stören würde, weil es wirklich rein dekorativ ist und keine Informationen transportiert, sollte auch in PDFs so versteckt werden, dass es von Screenreadern ignoriert werden kann: PDF4: Ausblenden dekorativer Bilder mit dem Artifact-Tag in PDF-Dokumenten.
Wie in CSS-Layouts kann man auch in PDFs die Reihenfolge innerhalb eines Dokuments frei bestimmen. Wichtig dabei ist, dass die Abfolge des Inhalts sinnvoll ist und dem Textfluß entspricht. Wie das geht zeigt die Technik PDF3: Sicherstellen der korrekten Tab- und Lesereihenfolge in PDF-Dokumenten.
Lesezeichen sind wichtig für den besseren Überblick in PDFs, besonders in längeren Dokumenten. Wie sie diese anlegen zeigt die WCAG-Technik PDF2: Erstellung von Lesezeichen in PDF-Dokumenten.
Wie im letzten Blogpost angekündigt veröffentlichen wir die frisch ins Deutsche übersetzten PDF-Techniken zur Umsetzung der Vorgaben aus den WCAG 2.0. Den Anfang macht die Technik №1 mit dem Thema Alternativ-Texte für Bilder: PDF1: Textalternativen auf Bilder anwenden mit dem Alt-Eintrag in PDF-Dokumenten.
Glaubt man unseren Statistiken, so ist das Thema »Barrierefreie PDF« einer der Suchbegriffe, der mit den meisten Traffic auf dieses Angebot und die bereitgestellten Anleitungen bringt. Was nicht weiter verwunderlich ist, angesichts der schieren Masse an PDFs, die täglich im Web veröffentlicht werden. Hinzu kommt, dass die Produktion barrierefreier PDF nicht gerade einfach ist, wenn man die falschen Werkzeuge benutzt oder keinen geeigneten Workflow beachtet. Und selbst mit den geeigneten Werkzeugen ist die Bearbeitung oftmals wenig intuitiv und die Programme sind nicht unbedingt frei von Bugs (so kann Acrobat Professional auch in der neuesten Version immer noch kein Undo für viele Operationen).
Grund genug, sich mal die PDF-Techniken anzusehen, die Adobe als Ergänzung zu den Web Content Accessibility Guidelines 2.0 (WCAG2) beigesteuert hat und die Autoren helfen sollen ihre Inhalte auch jenseits von HTML & CSS barrierefreier zu machen. Anfang diesen Jahres wurden diese auf den Seiten der Web Accessibility Initiative des W3C veröffentlicht und wir haben diese nun ins Deutsche übersetzt.
Den Anfang macht heute die Einleitung zu den PDF-Techniken; die eigentlichen Techniken (insgesamt 23 an der Zahl) folgen dann in loser Folge. Die Aktualisierung und Erweiterung dieser unterstützenden WCAG-Dokumente ist ein laufender Prozess und wir freuen uns über Ihre Beiträge und Verbesserungsvorschläge in den Kommentaren.
Anders als die BITV 2 fälschlicherweise verordnet sind ausschließlich die Erfolgskriterien aus den WCAG 2.0 die Grundlage für die Feststellung der Konformität zu diesem Standard – nicht die Techniken. Das Techniken-Dokument stellt eine Handlungsempfehlung zur Verfügung, die »informativ« ist – Sie müssen diese Techniken nicht benutzen, um die WCAG zu erfüllen! Web-Inhalte können andere Methoden benutzen, um die WCAG-Erfolgskriterien zu erfüllen. Web-Inhalte könnten sogar bei einem bestimmten Techniken-Test durchfallen und trotzdem noch die WCAG 2 auf eine andere Art erfüllen. Außerdem erfüllen Inhalte, die die veröffentlichten Techniken benutzen, nicht notwendigerweise alle WCAG-Erfolgskriterien.
| Erfolgskriterien | Stufe | Techniken |
|---|---|---|
| 1.1.1 Nicht-Text-Inhalte (non-text content) | A | |
| 1.2.1 Reine Audio- und Videoinhalte (aufgezeichnet) | A | |
| 1.2.2 Untertitel (aufgezeichnet) | A | |
| 1.2.3 Audiodeskription oder Medienalternative (aufgezeichnet) | A | |
| 1.2.4 Untertitel (Live) | AA | |
| 1.2.5 Audiodeskription (aufgezeichnet) | AA | |
| 1.3.1 Info und Beziehungen | A | |
| 1.3.2 Bedeutungstragende Reihenfolge | A | |
| 1.3.3 Sensorische Eigenschaften | A | |
| 1.4.1 Benutzung von Farbe | A | |
| 1.4.2 Audio-Steuerelement | A | |
| 1.4.3 Kontrast (Minimum) | AA | |
| 1.4.4 Textgröße ändern | AA | |
| 1.4.5 Bilder eines Textes | AA | |
| 2.1.1 Tastatur | A | |
| 2.1.2 Keine Tastaturfalle | A | |
| 2.2.1 Zeiteinteilung anpassbar | A | |
| 2.2.2 Pausieren, beenden, ausblenden | A | |
| 2.3.1 Grenzwert von dreimaligem Blinken oder weniger | A | |
| 2.4.1 Blöcke umgehen | A | |
| 2.4.2 Seite mit Titel versehen | A | |
| 2.4.3 Fokus-Reihenfolge | A | |
| 2.4.4 Linkzweck (im Kontext) | A | |
| 2.4.5 Verschiedene Methoden | AA | |
| 2.4.6 Überschriften und Labels | AA | |
| 2.4.7 Fokus sichtbar | AA | |
| 3.1.1 Sprache der Seite | A | |
| 3.1.2 Sprache von Teilen | AA | |
| 3.2.1 Bei Fokus | A | |
| 3.2.2 Bei Eingabe | A | |
| 3.2.3 Konsistente Navigation | AA | |
| 3.2.4 Konsistente Erkennung | AA | |
| 3.3.1 Fehlererkennung | A | |
| 3.3.2 Beschriftungen (Labels) oder Anweisungen | A | |
| 3.3.3 Fehlerempfehlung | AA | |
| 3.3.4 Fehlervermeidung (rechtliche, finanzielle, Daten) | AA | |
| 4.1.1 Syntaxanalyse | A |
|
| 4.1.2 Name, Rolle, Wert | A |
Den Grad der Barrierefreiheit eines Angebots zu messen und auf dieser Basis Verbesserungen zu entwickeln ist keine einfache Aufgabe. Mit den WCAG 2.0 haben wir zwar messbare Kriterien mit insgesamt 4 Ebenen der Konformität (A, AA, AAA und garnix), aber diese Ebenen sind zu stark voneinander abgegrenzt, um kleinteiligere Vergleiche und Messungen vorzunehmen oder um Fortschritte in der Verbesserung der Zugänglichkeit eines Angebots festzustellen. Wenn eine Website sämtliche Kriterien der Ebene A erfüllt und darüber hinaus viele, aber nicht alle AA- und AAA-Kriterien, dann ist sie trotzdem nur konform zu Ebene A. Die zusätzlichen Kriterien würden zwar den Nutzern zu Gute kommen, würden aber nicht in eine abschließende Bewertung der Barrierefreiheit einfließen.
Die in einigen Testverfahren benutzte Vergabe von Punkten oder Prozenten erlaubt die Bewertung auf einer Skala und damit auch vergleichende Statistiken. Allerdings bleibt die Frage, wie aussagekräftig verlässlich und letzendlich nachvollziehbar und überprüfbar solche Statistiken sind. Ein Beispiel: wenn auf einer HTML-Seite zwei von zehn Bildern fehlerhaften Alternativtext aufweisen – ist diese Seite zugänglicher als eine Seite, bei der eins von fünf Bildern oder vier von 20 Bildern fehlerhaft gecodet sind?
Eine solche Berechnung ist zwar recht einfach anzustellen, aber ohne weitere Informationen zum Kontext, in dem die Fehler auftreten, lassen sich keine verlässlichen und nachprüfbaren Aussagen zur tatsächlichen Barrierefreiheit für die Nutzer machen. Die Bewertung des Kontextes wiederum erhöht die Komplexität der Tests, weil der Test dann nicht mehr rein maschinell durchführbar ist, sondern ein menschlicher Tester die Bewertung vornehmen muss. Das wiederum eröffnet andere Probleme durch unterschiedliche Interpretationen.
Die Research and Development Working Group (RDWG) der Web Accessibility Initiative des W3C plant ein Online-Symposium, wo genau diese Fragen erörtert werden. Ziel ist, Anwender der Richtlinien aus Forschung und Praxis zusammenzubringen um gemeinsam den Stand der Meßverfahren zu betrachten und Pläne für die Zukunft zu entwickeln, wohin sich die Forschung in diesem Bereich entwickeln soll. Das Symposium wird am 5. Dezember 2011 in Form einer Telekonferenz stattfinden.
Die Research and Development Working Group sucht Beiträge und praktische Erfahrungen zur Messung der Barrierefreiheit, die über die einfache Konformität zu den Standards wie WCAG 2.0, Section 508 oder BITV hinausgehen. Die Frist zur Einreichungen von Beiträgen endet am 1. November 2011, die Ergebnisse werden im Nachgang veröffentlicht. Besonders gefragt sind Beiträge die sich mit den unterschiedlichen Verfahren zur Bewertung der Barierefreiheit beschäftigen und wie man diese eventuell kombinieren kann:
»We particularly welcome discussion of the relationship of these two approaches and how to potentially combine them, as well as a discussion of any of the following types of questions:
- What sort of techniques can we explore to combine metrics that are computed automatically, semi-automatically (with input from humans), and manually (where the judgement is made by humans, even if with input from software)?
- How can we build an infrastructure (such as IBM Social Accessibility) that allows experts to store accessibility information (metadata) for use with metrics that are computed during subsequent audits?
- What metrics, or combination of metrics, can be used as predictors of accessibility?
- How shall we characterize the quality of such predictors in terms of properties such as reliability, validity, sensitivity, adequacy and adaptability?
- Which approaches can be embraced for validating, benchmarking, and comparing web accessibility metrics?
- How should we tackle metrics in web applications with dynamic content?«
Weitere Infos dazu: Call for Papers: Online Symposium on Website Accessibility Metrics.
Unter dem Titel »Barrierefreiheit im Web – den Kunden im Blick« kann beim Beratungs- und Informationszentrum elektronischer Geschäftsverkehr Hessen (BIEG) ein Leitfaden zur Barrierefreiheit heruntergeladen werden, der sich speziell an kleine und mittelständische Unternehmen richtet. Der Leitfaden erläutert Grundlagen und Vorteile barrierefreier Websites und Shops und entstand in Kooperation von BIEG Hessen mit der Autorin Kerstin Probiesch. Thematisiert werden unter anderem der Zusammenhang von Suchmaschinenoptimierung und Barrierefreiheit, spezielle Aspekte wie Tastaturbedienbarkeit und einige Richtlinien der WCAG 2.0. Der Leitfaden steht als barrierefreies PDF und als HTML zur Verfügung.
Zum Leitfaden »Barrierefreiheit im Web – den Kunden im Blick«
Eine der wichtigsten Neuerungen der WCAG 2.0 gegenüber der Vorgängerversion ist, dass auch Formate als barrierefrei angesehen werden, die ausserhalb der Kontrolle des W3C liegen. Das gilt natürlich nur unter dem Vorbehalt, dass diese Inhalte auch in Hinblick auf die Barrierefreiheit entwickelt wurden, aber die gleiche Einschränkung lässt sich ja auch auf Formate wie HTML & CSS anwenden. Daher ist es ausgesprochen erfreulich, dass der Hersteller Adobe die Techniken dokumentiert hat, mit denen man Flash-basierte Inhalte so umsetzen kann, dass sie auch für Menschen mit Behinderung zugänglich sind (wichtige Einschränkungen sind in den Flash-Technik-Anmerkungen dokumentiert). Was es bei der Erstellung von barrierefreiem Flash zu beachten gilt wird in den folgenden WCAG-Techniken erklärt:
Die folgenden WCAG-Techniken beziehen sich ausschließlich auf Inhalte, die nicht mit Markup-Sprachen wie HTML ausgezeichnet wurden, sondern roher, unformatierter Text sind (z.B. in .txt-Dateien, die Techniken sind aber auch auf E-Mail-Newsletter anwendbar). Weitere Informationen dazu finden Sie in den folgenden WCAG-Techniken:
Im Idealfall sollten natürlich alle Objekte einer Webseite WCAG-konform und damit barrierefrei nutzbar sein; es gibt aber durchaus Umstände, unter denen dies eventuell nicht möglich ist. So kann es Situationen geben, in denen ein Objekt oder ein Abschnitt des Inhalts zwar Menschen mit bestimmten Behinderungen als Zielgruppe hat, während genau diese Attribute das Objekt für andere Nutzer unzugänglich machen. In solchen Fällen lassen die WCAG Ausnahmen von der Regel »Eine Seite für alle« zu, indem eine konforme Alternativversion verlinkt wird, die die gleichen Informationen wie die nicht-konforme Version vermittelt. Weitere Informationen hierzu finden Sie in den folgenden WCAG-Techniken:
Gerade für die Sprachausgabe ist es von enormer Wichtigkeit, dass die menschliche Sprache eines Dokuments und darüber hinaus auch Wechsel in der Sprache innerhalb eines Dokuments im Code hinterlegt sind. Das erleichtert nicht nur die Sprachsynthese und die korrekte Aussprache z.B. im Screenreader, sondern kann auch Verwechselungen durch Mehrdeutigkeiten vorbeugen (Tag wie Wochentag oder wie HTML-Tag?). Wie Sie diese Sprachen auszeichnen wird in den folgenden WCAG-Techniken erklärt:
Die folgenden WCAG-Techniken sind für den eher unwahrscheinlichen Fall, dass Ihre Seiten auch fremdsprachigen Content beinhalten, der bestimmte Vorkehrungen im Code benötigt. Die Technik G163 bezieht sich zum Beispiel auf Sprachen wie Hawaiianisch, die hierzulande doch eher selten anzutreffen sind. Da die WCAG-Richtlinien aber auch weltweite Geltung haben, sind diese Techniken hier der Vollständigkeit halber aufgelistet:
Tabellen haben auch im barrierefreien Webdesign nach wie vor eine Daseinsberechtigung – aber bitte wirklich nur für die Darstellung tabellarischer Daten und nicht als Layout-Ersatz. Wie Sie Datentabellen für alle Nutzer zugänglich machen und welche Fehler Sie vermeiden sollten wird in den folgenden WCAG-Techniken erklärt:
Eine ganze Reihe veralteter Techniken stellen zwar keine absoluten Barrieren dar, sollten aber in der modernen Webentwicklung eigentich keine Rolle mehr spielen, weil Sie die Wartung der Seiten unnötig verkomplizieren. Welche das sind sehen Sie in den folgenden WCAG-Techniken:
Barrierefreie Seiten zeichnen sich dadurch aus, dass sie auch unter den widrigsten Umständen noch Leistung abliefern. Das geht natürlich nur mit einem grundsoliden technischen Fundament, bei dem Browser nicht erst mal zahllose Fehler korrigieren müssen, bevor die Seite dargestellt werden kann. Das vereinfacht nicht nur die Verarbeitung, sondern hilft auch den Nutzern bei der eindeutigen Wahrnehmung und Bedienung, wie in den folgenden WCAG-Techniken erklärt wird:
Zappelnde, blinkende oder gar blitzende Inhalte sind nicht nur verwirrend und halten von der Aufnahme der eigentlichen Inhalte einer Seite ab, sie können für bestimmte Benutzergruppen auch zu einem echten medizinischen Problem werden, wenn durch flackernde Inhalte epileptische Anfälle ausgelöst werden. Wie Sie dies verhindern wird in den folgenden WCAG-Techniken erklärt:
Ebenso wie Weiterleitungen können periodische Aktualisierungen und dynamische Änderungen am Seiteninhalt in vielen assistiven Hilfsmitteln dazu führen, dass die Nutzbarkeit eines Angebots stark eingeschränkt oder sogar unmöglich gemacht wird. Tipps zur Vermeidung, aber auch immer wieder gern gemachte Fehler finden Sie in den folgenden WCAG-Techniken:
Bestimmte Techniken, um Seiten auf andere URLs weiterzuleiten führen in vielen Hilfsmitteln behinderter Menschen zu Problemen, können aber auch ohne Hilfsmittel ganz schön verwirrend sein. Wie man es als Anbieter besser macht zeigen die folgenden WCAG-Techniken:
Sie sind einfach nicht auszurotten, obwohl es sich mittlerweile rumgesprochen haben sollte, dass sie für Spambots meist eine wesentlich geringere Hürde darstellen als für echte menschliche Nutzer: CAPTCHAs. Welche Alternativen es zu unleserlichen Sicherheits-Grafiken gibt lesen Sie in den folgenden WCAG-Techniken:
Barrierefreiheit geht insbesondere in Formular-Anwendungen weit über technische und gestalterische Details hinaus und schließt im Grunde genommen den gesamten Prozess bis zum erfolgreichen Abschluss einer Transaktion mit ein – ein Umstand der in den letzten Jahren auch verstärkt im Prüfverfahren des BIENE-Wettbewerbs berücksichtigt wurde. Wie Sie Ihre Nutzer bei der Bewältigung möglicher Hürden unterstützen steht in den folgenden WCAG-Techniken: