News mit tag »WCAG«

21 Sep 2011

Wie misst man Barrierefreiheit?

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.

Weiterlesen …

Online-Symposium zu Meßverfahren

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?«

w3.org/WAI/RD/2011/metrics/cfp.html#objectives

Weitere Infos dazu: Call for Papers: Online Symposium on Website Accessibility Metrics.

23 Aug 2011

»Barrierefreiheit im Web – den Kunden im Blick« – ein Leitfaden für Unternehmen

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«

04 Mai 2011

WCAG-Techniken: Flash

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:

Weiterlesen …

Allgemeine Techniken

• FLASH19: Bereitstellung eines Skriptes, das den Benutzer warnt, dass eine zeitliche Begrenzung bald abläuft und das eine Möglichkeit bietet, diese zu verlängern
• FLASH24: Es dem Benutzer ermöglichen, die Standardeinstellung der zeitlichen Begrenzung zu erweitern
• FLASH33: Benutzung von relativen Werten für Abmessungen eines Flash-Objektes
• FLASH35: Benutzung von Skript zum Scrollen von Flash-Inhalten und Bereitstellung eines Mechanismus, um ihn zu pausieren
• FLASH36: Benutzung von Skripten, um Blinken zu steuern und es in fünf Sekunden oder weniger anzuhalten

Flash & Medienalternativen

• FLASH1: Festlegung der Eigenschaft "Name" für ein Nicht-Text-Objekt
• FLASH2: Festlegung der Eigenschaft „Beschreibung“ für ein Nicht-Text-Objekt in Flash
• FLASH3: Markierung von Objekten in Flash, so dass sie von assistierenden Techniken ignoriert werden können.
• FLASH9: Anwendung von Untertiteln auf aufgezeichnete, synchronisiere Medien
• FLASH11: Bereitstellung einer längeren Textbeschreibung eines Objektes
• FLASH13: Benutzung der HTML language-Attribute, um die Sprache in Flash-Inhalten zu kennzeichnen
• FLASH18: Bereitstellung eines Steuerelementes, um Töne, die in Flash automatisch abgespielt werden, abzustellen
• FLASH26: Anwendung von Audiodeskriptionen bei Flash-Videos
• FLASH28: Bereitstellung von Textalternativen für ASCII Art, Emoticons und Leetspeak (Ersetzung von Buchstaben durch Ziffern oder Sonderzeichen) in Flash
• FLASH34: Benutzung der Screenreader-Erkennung, um Ton, der automatisch abgespielt wird, abzustellen

Navigation und Bedienung in Flash

• FLASH5: Kombination nebeneinander liegender Bild- und Textschaltflächen für die gleiche Ressource
• FLASH6: Erstellung barrierefreier Hotspots durch die Benutzung unsichtbarer Schaltflächen
• FLASH7: Benutzung von Scripting, um Beschriftungen (Label) von Steuerelementen zu ändern
• FLASH14: Benutzung von redundanten Tastatur- und Maus-Event-Handlern in Flash
• FLASH15: Benutzung der Eigenschaft „tabIndex“, um eine logische Lesereihenfolge und eine logische Tab-Reihenfolge in Flash festzulegen
• FLASH16: Aktionen per Tastatur zugänglich machen durch die Verwendung des Klick-Ereignisses bei Standardkomponenten
• FLASH17: Bereitstellung eines Zugangs per Tastatur auf ein Flash-Objekt und Vermeidung einer Tastatur-Falle
• FLASH20: Reskinning von Flash-Komponenten, um eine sehr gut sichtbare Fokus-Indikation zu bieten
• FLASH21: Benutzung der DataGrid-Komponente, um Spalten-Überschriften mit Zellen zu verknüpfen
• FLASH22: Hinzufügen von per Tastatur zugänglichen Aktionen zu statischen Elementen
• FLASH23: Hinzufügen von zusammengefassten Informationen (summary information) zu einem DataGrid
• FLASH27: Bereitstellung von Beschriftungen (Labels) für Schaltflächen, die den Zweck einer Schaltfläche beschreiben
• FLASH30: Festlegung von barrierefreien Namen für Bild-Schaltflächen
• FLASH31: Festlegung von Untertiteln für ein DataGrid

Flash & Formulare

• FLASH4: Bereitstellung von Schaltflächen zum Abschicken in Flash
• FLASH8: Hinzufügen eines Gruppen-Namens zu dem barrierefreien Namen eines Formular-Steuerelements
• FLASH10: Kennzeichnung erforderlicher Formularsteuerelemente in Flash
• FLASH12: Bereitstellung einer client-seitigen Gültigkeitsprüfung und Hinzufügen von Fehlertext über die barrierefreie Beschreibung (Beschreibung im Panel Eingabehilfen)
• FLASH25: Beschriftung eines Formular-Steuerelementes durch Festlegung seines barrierefreien Namens
• FLASH29: Festlegung der Eigenschaft „Beschriftung“ (label) für Formular-Komponenten
• FLASH32: Benutzung der automatischen Beschriftung (auto labeling), um Text-Label mit Formular-Steuerelementen zu verknüpfen

WCAG-Techniken: Reiner Text

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:

Weiterlesen …

Text-Techniken

• T1: Benutzung von Standard-Konventionen zur Textformatierung für Absätze
• T2: Benutzung von Standard-Konventionen zur Textformatierung für Listen
• T3: Benutzung von Standard-Konventionen zur Textformatierung von Überschriften

Typische Fehler

• F33: Fehler bei Erfolgskriterium 1.3.1 und 1.3.2, weil Leerzeichen benutzt werden, um mehrere Spalten bei reinem Textinhalt zu erstellen
• F34: Fehler bei Erfolgskriterium 1.3.1 und 1.3.2, weil Leerzeichen benutzt werden, um Tabellen bei reinem Textinhalt zu formatieren

03 Mai 2011

WCAG-Techniken: Komplette Alternativversionen

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:

Weiterlesen …

Allgemeine Techniken

• G136: Bereitstellung eines Links am Beginn einer nicht-konformen Webseite, der auf eine konforme Alternativversion hinweist
• G190: Bereitstellung eines Links neben einem oder verbunden mit einem nicht-konformen Objekt, der zu einer konformen Alternativversion verlinkt

CSS-Techniken

• C29: Benutzung eines Style-Switchers, um eine konforme Alternativversion zur Verfügung zu stellen

Server-seitige Scripting-Techniken

• SVR2: Benutzung von .htaccess, um sicherzustellen, dass der einzige Weg, um auf nicht-konformen Inhalt zuzugreifen, von konformem Inhalt aus ist
• SVR3: Benutzung eines HTTP Referer, um sicherzustellen, dass der einzige Weg, um auf nicht-konformen Inhalt zuzugreifen, von konformem Inhalt aus ist
• SVR4: Es dem Benutzer ermöglichen, Präferenzen zur Darstellung von konformen Alternativversionen zu bestimmen

Typische Fehler

• F19: Fehler bei Konformitätsbedingung 1, weil dem Benutzer keine Methode zur Verfügung gestellt wird, um die alternative, konforme Version einer nicht-konformen Webseite zu finden

WCAG-Techniken: Sprache festlegen

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:

Weiterlesen …

HTML-Techniken

• H57: Benutzung der language-Attribute lang-Attribute beim html-Element
• H58: Benutzung der language-Attribute lang-Attribute, um Änderungen der menschlichen Sprache zu kennzeichnen

Server-seitige Scripting-Techniken

• SVR5: Angabe der voreingestellten Sprache im HTTP header

02 Mai 2011

WCAG-Techniken: Internationalisierung

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:

Weiterlesen …

Allgemeine Techniken

• G163: Benutzung von normierten Aussprachezeichen, die abgeschaltet werden können

HTML-Techniken

• H34: Benutzung eines Unicode right-to-left mark (RLM) oder left-to-right mark (LRM), um die Textrichtung inline zu kombinieren
• H56: Benutzung des dir-Attributes an einem inline-Element, um Probleme mit verschachtelten Laufrichtungen (nested directional runs) zu lösen
• H62: Benutzung des ruby-Elementes

WCAG-Techniken: Tabellen

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:

Weiterlesen …

HTML-Techniken

• H39: Benutzung von Caption-Elementen, um Untertitel von Datentabellen mit Datentabellen zu verbinden
• H43: Benutzung von id- und Überschriften-Attributen, um Datenzellen und Überschriftenzellen in Datentabellen zu verbinden
• H51: Benutzung von Tabellen-Markup, um tabellarische Informationen zu präsentieren
• H63: Benutzung des scope-Attributes, um Überschriftenzellen und Datenzellen in Tabellen zu verbinden
• H73: Benutzung des Summary-Attributs des table-Elements, um einen Überblick über Datentabellen zu geben

Typische Fehler

• F46: Fehler bei Erfolgskriterium 1.3.1, weil th-Elemente, Caption-Elemente oder nicht-leere Summary-Attribute in Layout-Tabellen benutzt werden
• F48: Fehler bei Erfolgskriterium 1.3.1, weil das pre-Element benutzt wird, um tabellarische Informationen auszuzeichnen

29 Apr 2011

WCAG-Techniken: Veraltete Techniken

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:

Weiterlesen …

HTML-Techniken

• H70: Benutzung von frame-Elementen, um Blöcke mit sich wiederholendem Material zu gruppieren

CSS-Techniken

• C18: Benutzung von CSS margin- und padding-Regeln zum Layout-Design anstelle von Spacer-Images

Typische Fehler

• F49: Fehler bei Erfolgskriterium 1.3.2, weil eine HTML-Layout-Tabelle benutzt wird, die keinen Sinn ergibt, wenn sie linearisiert wird

WCAG-Techniken: Robustheit

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:

Weiterlesen …

Allgemeine Techniken

• G134: Validierung von Webseiten
• G192: Vollständig konform zu den Spezifikationen sein

HTML-Techniken

• H74: Sicherstellen, dass Start- und End-Tags gemäß der Spezifikation benutzt werden
• H75: Sicherstellen, dass Webseiten wohlgeformt sind
• H88: Benutzung von HTML entsprechend der Spezifikation
• H93: Sicherstellen, dass id-Attribute auf einer Webseite einmalig sind
• H94: Sicherstellen, dass Elemente keine doppelten Attribute enthalten

Client-seitige Scripting-Techniken

• SCR21: Benutzung von Funktionen des Document Object Model (DOM), um einer Seite Inhalte hinzuzufügen
• SCR27: Neugliederung von Seitenbereichen mit Hilfe des Document Object Model

Typische Fehler

• F17: Fehler bei Erfolgskriterium 1.3.1 und 4.1.1 durch nicht ausreichende Informationen im DOM, um Eins-zu-Eins-Beziehungen (z.B. zwischen Labels mit der gleichen ID) in HTML zu bestimmen
• F62: Fehler bei Erfolgskriterium 1.3.1 und 4.1.1 wegen nicht ausreichender Informationen im DOM, um bestimmte Beziehungen in XML zu bestimmen
• F70: Fehler bei Erfolgskriterium 4.1.1, weil die Start- und End-Tags oder die Attribut-Auszeichnung inkorrekt benutzt werden
• F77: Fehler bei Erfolgskriterium 4.1.1 aufgrund von doppelten Werten von type ID

28 Apr 2011

WCAG-Techniken: Epileptische Anfälle

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:

Weiterlesen …

Allgemeine Techniken

• G11: Erstellung von Inhalten, die weniger als 5 Sekunden blinken
• G15: Benutzung eines Werkzeugs um sicherzustellen, dass Inhalte nicht die allgemeinen Grenzwerte zu Blitzen und roten Blitzen verletzen
• G19: Sicherstellen, dass kein Bestandteil des Inhalts mehr als dreimal in einem beliebigen, eine Sekunde dauernden Zeitraum blitzt
• G152: Animierte gif-Bilder so einstellen, dass sie nach n Zyklen (innerhalb von 5 Sekunden) aufhören zu blinken
• G176: Den blitzenden Bereich klein genug halten
• G186: Benutzung eines Steuerelementes auf der Webseite, mit dem man sich bewegende, blinkende oder sich automatisch aktualisierende Inhalte anhalten kann
• G187: Benutzung einer Technik, um blinkende Inhalte einzuschließen, die über den Benutzeragenten ausgeschaltet werden kann
• G191: Bereitstellung eines Links, einer Schaltfläche oder eines anderen Mechanismus, der die Seite erneut ohne blinkende Inhalte lädt

Client-seitige Scripting-Techniken

• SCR22: Benutzung von Scripts, um das Blinken zu steuern und in 5 Sekunden oder weniger zu beenden

Typische Fehler

• F4: Fehler bei Erfolgskriterium 2.2.2, weil text-decoration:blink benutzt wird ohne Mechanismus, um es in weniger als 5 Sekunden zu beenden
• F7: Fehler bei Erfolgskriterium 2.2.2, wegen eines object oder applet wir Java oder Flash, welches blinkende Inhalte enthält ohne Mechanismus, um die blinkenden Inhalte für mehr als 5 Sekunden zu pausieren
• F47: Fehler bei Erfolgskriterium 2.2.2, weil das blink-Element benutzt wird
• F50: Fehler bei Erfolgskriterium 2.2.2, wegen eines Scripts, welches einen blink-Effeft auslöst ohne Mechanismus, um das Blinken in 5 Sekunden oder weniger zu beenden

WCAG-Techniken: Änderungen / Aktualisierungen

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:

Weiterlesen …

Allgemeine Techniken

• G10: Durch die Benutzung einer Technik, welche die API-Barrierefreiheitsfunktion der Plattform, auf dem der Benutzeragent laufen wird, unterstützt, werden Bestandteilen erstellt, um Namen und Rollen offenzulegen, um eine direkte Festlegung der vom Benutzer festzulegenden Eigenschaften zu ermöglichen und eine Benachrichtigung über Änderungen zur Verfügung zu stellen
• G75: Bereitstellung eines Mechanismus, um jegliche Aktualisierung des Inhalts aufzuschieben
• G76: Bereitstellung eines Mechanismus, um die Aktualisierung von Inhalten anzufordern statt einer automatischen Aktualisierung
• G108: Benutzung von Auszeichnungsfunktionen, um Name und Rolle offenzulegen, um es zu ermöglichen, vom Benutzer einzustellende Properties direkt festzulegen und um Benachrichtigungen über Änderungen zur Verfügung zu stellen
• G135: Benutzung der API Barrierefreiheitsfunktionen einer Technik, um Namen und Rollen offenzulegen, um eine direkte Festlegung der vom Benutzer festzulegenden Eigenschaften zu ermöglichen und eine Benachrichtigung über Änderungen zur Verfügung zu stellen

Client-seitige Scripting-Techniken

• SCR33: Benutzung eines Scripts, um Inhalte zu scrollen und Bereitstellung eines Mechanismus, dies anzuhalten
• SCR36: Bereitstellung eines Mechanismus, um es Benutzern zu ermöglichen, Text, der sich bewegt, der gescrollt wird oder der sich automatisch aktualisiert in einem statischen Fenster oder Bereich anzuzeigen
• SCR37: Erstellung anpassbarer Dialoge auf geräteunabhängige Art und Weise

Typische Fehler

• F16: Fehler bei Erfolgskriterium 2.2.2, weil scrollende Inhalte enthalten sind, bei denen die Bewegung für die Handlung nicht unentbehrlich ist, ohne zusätzlich einen Mechanismus aufzunehmen, um Inhalte anzuhalten und wieder zu starten
• F59: Fehler bei Erfolgskriterium 4.1.2, weil Script benutzt wird, um div oder span zu einem Steuerelement der Benutzerschnittstelle in HTML zu machen
• F60: Fehler bei Erfolgskriterium 3.2.5, weil ein neues Fenster geöffnet wird, wenn ein Benutzer Text in einem Eingabefeld eingibt
• F61: Fehler bei Erfolgskriterium 3.2.5, weil der Hauptinhalt durch eine automatische Aktualisierung, die der Benutzer aus dem Inhalt heraus nicht deaktivieren kann, komplett geändert wird
• F76: Fehler bei Erfolgskriterium 3.2.2, weil in einem Element der Benutzerschnittstelle an einem Ort, den Benutzer umgehen können, Material mit Anweisungen zu den Änderungen des Kontextes durch die Änderung der Einstellungen bereitgestellt wird

27 Apr 2011

WCAG-Techniken: Um- und Weiterleitungen

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:

Weiterlesen …

Allgemeine Techniken

• G110: Benutzung einer sofortigen, client-seitigen Umleitung

HTML-Techniken

• H76: Benutzung des meta refresh, um eine sofortige, client-seitige Umleitung zu erstellen

Server-seitige Scripting-Techniken

• SVR1: Server-seitige statt client-seitige Implementierung automatischer Umleitungen

WCAG-Techniken: CAPTCHAs

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:

Weiterlesen …

Allgemeine Techniken

• G143: Bereitstellung einer Textalternative, die den Zweck des CAPTCHA beschreibt
• G144: Sicherstellung, dass die Webseite ein anderes CAPTCHA enthält, das den gleichen Zweck erfüllt, bei dem aber eine anderes Verfahren benutzt wird

26 Apr 2011

WCAG-Techniken: Barrierefreie Prozesse

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:

Weiterlesen …

Allgemeine Techniken

• G98: Bereitstellung einer Möglichkeit für den Benutzer, die Antworten vor dem Absenden durchzusehen und zu korrigieren
• G99: Bereitstellung der Möglichkeit, gelöschte Informationen wiederherzustellen
• G105: Speichern der Daten, so dass diese benutzt werden können, nachdem der Benutzer sich erneut authentifiziert hat
• G133: Bereitstellung einer Checkbox auf der ersten Seite eines mehrteiligen Formulars, die es den Benutzern ermöglicht, um längere zeitliche Begrenzungen oder keine zeitliche Begrenzungen bei einer Sitzung zu bitten
• G164: Bereitstellung eines angegebenen Zeitraums nach dem Versenden des Formulars während dessen die Bestellung vom Benutzer aktualisiert oder storniert werden kann
• G168: Aufforderung zur Bestätigung, um mit der ausgewählten Handlung fortzufahren
• G181: Kodierung der Benutzerdaten als versteckte oder verschlüsselte Daten auf einer Seite zur erneuten Authentifizierung
• G184: Bereitstellung von Textanweisungen zu Beginn eines Formulars oder eines Satzes an Feldern, welche die notwendigen Eingaben beschreiben
• G193: Bereitstellung von Hilfe durch einen Assistenten auf der Webseite
• G199: Bereitstellung einer Erfolgsmeldung, wenn Daten erfolgreich verschickt wurden

WCAG-Techniken: Formulare & Fehler

Ihr Formulardesign kann noch so ausgefeilt und gut getestet sein – Nutzer machen trotzdem Fehler. Die Frage ist nur wie Sie als Anbieter mit diesen Fehlern umgehen: unterstützen Sie den Nutzer bei der Korrektur oder lassen Sie ihn im Dunklen? Was es bei Fehlermeldungen zu beachten gibt wird in den folgenden WCAG-Techniken erklärt:

Weiterlesen …

Allgemeine Techniken

• G13: Beschreiben, was passieren wird, bevor eine Änderung an einem Formular-Steuerelement vorgenommen wird, die eine Änderung des Kontextes auslösen wird
• G107: Benutzung von "activate" statt "focus" als Auslöser für Änderungen des Kontextes
• G139: Erstellung eines Mechanismus, der es Benutzern erlaubt, zu den Fehlern zu springen

Client-seitige Scripting-Techniken

• SCR14: Benutzung von Scripts, um entbehrliche Warnmeldungen optional zu machen
• SCR18: Bereitstellung einer client-seitigen Gültigkeitsprüfung und einer Warnmeldung
• SCR32: Bereitstellung einer client-seitigen Gültigkeitsprüfung und Hinzufügen von Fehlertext via DOM

25 Apr 2011

WCAG-Techniken: Formulare & Buttons

Ohne Buttons werden Nutzer kaum in der Lage sein, ein Formular abzuschicken, daher sollten Sie diesen die gleiche Aufmerksamkeit zukommen lassen wie den übrigen Formularelementen. Was es hierbei zu beachten gibt, sieht man an den folgenden WCAG-Techniken:

Weiterlesen …

Allgemeine Techniken

• G80: Bereitstellung einer submit-Schaltfläche, um eine Änderung zu Kontextes einzuleiten
• G155: Bereitstellung einer Checkbox zusätzlich zur Absenden-Schaltfläche
• G167: Benutzung einer benachbarten Schaltfläche, um den Zweck eines Feldes zu benennen

HTML-Techniken

• H32: Bereitstellung von Schaltflächen zum Abschicken
• H84: Benutzung einer Schaltfläche mit einem select-Element, um eine Handlung auszuführen

Typische Fehler

• F85: Fehler bei Erfolgskriterium 2.4.3, weil Dialoge oder Menüs benutzt werden, die in der aufeinander folgenden Navigationsreihenfolge nicht an ihre auslösenden Steuerelemente angrenzen

WCAG-Techniken: Formulare & Dynamik

Bei der Verwendung von Skripten zur dynamischen Änderung von Formularen gibt es eine ganze Reihe Aspekte der Barrierefreiheit zu beachten, wie in den folgenden WCAG-Techniken erklärt wird:

Weiterlesen …

Allgemeine Techniken

• G13: Beschreiben, was passieren wird, bevor eine Änderung an einem Formular-Steuerelement vorgenommen wird, die eine Änderung des Kontextes auslösen wird
• G107: Benutzung von "activate" statt "focus" als Auslöser für Änderungen des Kontextes

Client-seitige Scripting-Techniken

• SCR19: Benutzung eines onchange-Events auf einem ausgewählten Element, ohne eine Änderung des Kontextes auszulösen

Typische Fehler

• F9: Fehler bei Erfolgskriterium 3.2.5, weil der Kontext geändert wird, wenn der Benutzer den Fokus von einem Formularelement wegnimmt
• F15: Fehler bei Erfolgskriterium 4.1.2, weil individuelle Steuerelemente implementiert werden, die kein Barrierefreiheits-API für die Technik benutzen oder dies unvollständig tun
• F36: Fehler bei Erfolgskriterium 3.2.2, weil ein Formular automatisch abgeschickt wird und neuer Inhalt ohne vorherige Warnung angezeigt wird, sobald das letzte Feld des Formulars eines Wert erhält
• F37: Fehler bei Erfolgskriterium 3.2.2, weil ein neues Fenster ohne vorherige Warnung geöffnet wird, wenn der Status eines Radiobuttons, einer Checkbox oder einer Auswahlliste geändert wird

22 Apr 2011

WCAG-Techniken: Formulare & Eingaben

Neben dem technischen Aufbau gehören auch konzeptionelle und gestalterische Aspekte zur Umsetzung einer barrierefreien Formular-Anwendung. Welche das sind zeigen die folgenden WCAG-Techniken:

Weiterlesen …

Allgemeine Techniken

• G83: Bereitstellung von Textbeschreibungen, um nicht ausgefüllte Pflichtfelder zu identifizieren
• G84: Bereitstellung einer Textbeschreibung, wenn der Benutzer Informationen eingibt, die nicht der Liste der erlaubten Werte entsprechen
• G85: Bereitstellung einer Textbeschreibung, wenn die Eingaben des Benutzers außerhalb des verlangten Formats oder der verlangten Werte sind
• G89: Bereitstellung des erwarteten Datenformats und Beispiels
• G131: Bereitstellung beschreibender Labels
• G162: Positionierung von Labels, um die Vorhersehbarkeit von Beziehungen zu maximieren
• G177: Bereitstellung einer Empfehlung zur Korrektur des Textes
• G194: Bereitstellung einer Rechtschreibprüfung und von Vorschlägen für die Texteingabe
• G197: Konsistente Benutzung von Labeln, Namen und Textalternativen bei Inhalt, der die gleiche Funktionalität hat

HTML-Techniken

• H89: Benutzung des title-Attributs zur Bereitstellung kontextsensitiver Hilfe
• H90: Kennzeichnung erforderlicher Formularsteuerelemente
• H92: Hinzufügen eines Hinweises in Textform zu farbigen Labels von Formular-Steuerelementen

Typische Fehler

• F81: Fehler bei Erfolgskriterium 1.4.1, weil Pflichtfelder oder Fehlerfelder nur durch die Benutzung von Farbunterschieden identifiziert werden
• F82: Fehler bei Erfolgskriterium 3.3.2 durch die visuelle Formatierung eines Satzes an Feldern für Telefonnummern ohne ein Text-Label einzuschließen
• F86: Fehler bei Erfolgskriterium 4.1.2, weil nicht für jeden Teil eines mehrteiligen Formularfeldes, wie zum Beispiel eine US-amerikanische Telefonnummer, Namen zur Verfügung gestellt werden

ARIA-Techniken

Falls Sie bereits den kommenden WAI-ARIA-Standard einsetzen sollten Sie neben den passenden Techniken auch die WAI-ARIA Technik-Anmerkungen zu Rate ziehen.

• ARIA1: Benutzung des aria-describedby-property (Eigenschaft), um eine beschreibende Beschriftung für Eingabe-Steuerelemente zur Verfügung zu stellen
• ARIA2: Kennzeichnung von Pflichtfeldern mit dem aria-required-property (Eigenschaft)
• ARIA3: Kennzeichnung von Informationen zum Gültigkeitsbereich mit den Eigenschaften (properties) aria-valuemin und aria-valuemax

WCAG-Techniken: Formulare - technischer Aufbau

Formulare sind die hohe Schule des barrierefreien Webdesigns – wenn hier etwas nicht nutzbar ist, dann ist oftmals für den Nutzer an dieser Stelle das Ende eines Prozesses erreicht und ein geplanter Einkauf oder eine Beteiligung an einer Diskussion bleibt ihm verwehrt. Wie Sie Ihren Formularen eine barrierefreie technische Basis geben wird in den folgenden WCAG-Techniken gezeigt:

Weiterlesen …

HTML-Techniken

• H44: Benutzung von Label-Elementen, um Text-Label mit den Steuerelementen eines Formulars zu assoziieren
• H65: Benutzung des title-Attributs, um Formular-Steuerelemente zu kennzeichnen, wenn das Label-Element nicht benutzt werden kann
• H71: Bereitstellung einer Beschreibung für Gruppen von Formular-Steuerelementen, indem fieldset- und legend-Elemente benutzt werden
• H85: Benutzung von OPTGROUP, um OPTION-Elemente innerhalb eines SELECT zu gruppieren
• H91: Benutzung von HTML-Formularsteuerelementen und Links

CSS-Techniken

• C17: Skalierung von Formularelementen, die Text enthalten

Typische Fehler

• F31: Fehler bei Erfolgskriterium 3.2.4, weil zwei verschiedene Labels für die gleiche Funktion auf verschiedenen Webseiten innerhalb eines Satzes von Webseiten benutzt werden
• F68: Fehler bei den Erfolgskriterien 1.3.1 und 4.1.2, weil Verbindung zwischen Label und Steuerelementen nicht durch Software bestimmbar ist
• F80: Fehler bei Erfolgskriterium 1.4.4, wenn textbasierte Formular-Steuerelemente sich nicht in der Größe verändern, wenn visuell gerenderter Text bis zu 200 Prozent in der Größe verändert wird