WCAG 2 - Die Richtlinien für barrierefreie Webinhalte 2.0

WCAG 2.0 Die Richtlinien für barrierefreie Webinhalte 2.0 Web Content Accessibility Guidlines 2.0 Access-for-all.ch 22.10.2009 «Zugang für alle» Schweizerische Stiftung zur behindertengerechten Technologienutzung Sven Jenzer, Interaction Designer MAS, Stiftung «Zugang für alle» Kontakt: sven.jenzer@access-for-all.ch

Inhalt

Einleitung

Der Aufbau der WCAG 2

Konformitätsbedingungen

Konformität mit P028

WCAG 2 als Evaluationsinstrument

WCAG 1 und 2 Einige Unterschiede

WAI ARIA

Schlussbemerkung

Die Autoren der WCAG

Die Seite der WAI (Web Accessibility Initative)

http://www.w3.org/WAI/

Die aktuelle (noch inoffizielle) deutsche Übersetzung bei:

http://wcag2.0-blog.de/2009-09-16/

How to meet WCAG 2.0

http://www.w3.org/WAI/WCAG20/quickref/Overview.php?introopt=N

Techniques for WCAG 2.0:

http://www.w3.org/TR/WCAG20-TECHS/

Richtlinien für barrierefreie Webinhalte (WCAG) 2.0

(Web Content Accessibility Guidelines (WCAG) 2.0)

Der Aufbau der WCAG 2 – der Standard

Die Ebenen des W3C-Standards WCAG 2

Prinzipien (normativ)

Richtlinien (normativ)

Erfolgskriterien (normativ)

Ausreichende und empfohlene Techniken (informativ)

Wichtige Begriffe (normativ)

Konformität

Webinhalts-Techniken (Baseline Assumption)

Barrierefreiheit unterstützend

Glossar

Die WCAG 2 wurden am 11. Dezember 2008 offizielle Empfehlung des W3C

Damit sind die WCAG 2 ein W3C-Standard mit international anerkannter Weisungskraft

(Kein internationaler DIN-Standard)

4 Prinzipien

Richtlinien

Erfolgskriterien

Konformität

WCAG 2.0

Richtlinien

Erfolgskriterien

Techniken

WCAG erfüllen

HTML, CSS, JS, ...

Anwendungs-Beispiele - Code-Beispiele - Testvorgehen

Techniken

Absicht

Vorteile f. Menschen m. Behinderung

Szenarien

Verstehen Normativer W3C-Standard Anpassbare Referenz Informativ, erweiterbar Informativ, erweiterbar

Die WCAG 2.0 Prinzipien

Wahrnehmbar (Perceivable) zum Beispiel durch Textalternativen für Bilder, Untertitel für Audio, Anpassbarkeit der Darstellung und Farbkontraste

Bedienbar (Operable) Maus- und Tastaturbedienung, Farbkontraste, Zeitbegrenzungen bei Eingaben, Navigierbarkeit

Verständlich (Understandable) Lesbarkeit, Vorhersagbarkeit, Hilfen bei Fehlern und bei der Eingabe

Robust (Robust) durch Kompatibilität mit Browsern und mit assistierenden Technologien

Prinzip 1: Wahrnehmbar

Informationen und Bestandteile der Benutzerschnittstelle müssen den Benutzern so präsentiert werden, dass diese sie wahrnehmen können.

Das Prinzip "wahrnehmbar" umfasst folgende einzelne Richtlinien:

1.1. Stellen Sie Textalternativen für alle Nicht-Text-Inhalte zur Verfügung, so dass diese in andere vom Benutzer benötigte Formen geändert werden können, wie zum Beispiel Großschrift, Braille, Symbole oder einfachere Sprache.

1.2. Zeitbasierte Medien: Stellen Sie Alternativen für zeitbasierte Medien zur Verfügung.

1.3. Anpassbar: Erstellen Sie Inhalte, die auf verschiedene Arten dargestellt werden können (z.B. einfacheres Layout), ohne dass Informationen oder Struktur verloren gehen.

1.4. Unterscheidbar: Machen Sie es Benutzern leichter, Inhalt zu sehen und zu hören einschließlich der Trennung von Vorder- und Hintergrund.

Prinzip 2: Bedienbar

Bestandteile der Benutzerschnittstelle und Navigation müssen bedienbar sein.

Das Prinzip "bedienbar" umfasst folgende einzelne Richtlinien:

2.1. Per Tastatur zugänglich: Sorgen Sie dafür, dass alle Funktionalitäten per Tastatur zugänglich sind.

2.2. Ausreichend Zeit: Geben Sie den Benutzern ausreichend Zeit, Inhalte zu lesen und zu benutzen.

2.3. Anfälle: Gestalten Sie Inhalte nicht auf Arten, von denen bekannt ist, dass sie zu Anfällen führen.

2.4. Navigierbar: Stellen Sie Mittel zur Verfügung, um Benutzer dabei zu unterstützen zu navigieren, Inhalte zu finden und zu bestimmen, wo sie sich befinden.

Prinzip 3: Verständlich

Informationen und die Bedienung der Benutzerschnittstelle müssen verständlich sein.

Das Prinzip "verständlich" umfasst folgende einzelne Richtlinien:

3.1. Lesbar: Machen Sie Inhalt lesbar und verständlich.

3.2. Vorhersehbar: Sorgen Sie dafür, dass Webseiten vorhersehbar aussehen und funktionieren.

3.3. Hilfestellung bei der Eingabe: Helfen Sie den Benutzern dabei, Fehler zu vermeiden und zu korrigieren.

Prinzip 4: Robust

Inhalte müssen robust genug sein, damit sie zuverlässig von einer großen Auswahl an Benutzeragenten einschließlich assistierender Techniken interpretiert werden können.

Das Prinzip "robust" umfasst folgende Richtlinie:

4.1. Kompatibel: Maximieren Sie die Kompatibilität mit aktuellen und zukünftigen Benutzeragenten, einschließlich assistierender Techniken

Beispiel einer Richtlinie und ihren Erfolgskriterien Alternativ-Text:“Blindenführhund Leo“ Beispiel-Beurteilung Alternativtext von Bildern:

Beispiel einer Richtlinie und ihren Erfolgskriterien

Beispiel Richtlinie 1.1 und Erfolgskriterium 1.1.1

Erfolgskriterium 1.1.1 verstehen

Erfolgskriterium 1.1.1 erfüllen

Sufficient Techniques

Advisory Techniques

Failures

Beispiel einer Technik für EK 1.1.1

Jede Technik:

Beschrieb

Beispiele

Ressourcen

G = Generelle Techniken H = HTML Techniken S = Scripting Techniken T = Text Techniken A = ARIA Techniken F = Failures

Demonstration

WCAG 2.0 deutsch:

http://wcag2.0-blog.de/2009-09-16/index.html

How to meet WCAG 2.0:

http://www.w3.org/WAI/WCAG20/quickref/Overview.php?introopt=N

Konformitätsstufen

Ganze Seiten

Vollständiger Prozess

Barrierefreiheit unterstützend

Nicht störend

1. Konformitätsstufen

Eine der folgenden Stufen der Konformität ist vollständig erfüllt.

Stufe A: Für eine Konformität auf Stufe A (die minimale Konformitätsstufe) muss die Webseite alle Erfolgskriterien der Stufe A erfüllen oder es wird eine konforme Alternativversion zur Verfügung gestellt.

Stufe AA: Für eine Konformität auf Stufe AA muss die Webseite alle Erfolgskriterien der Stufen A und AA erfüllen oder es wird eine Stufe AA-konforme Alternativversion zur Verfügung gestellt.

Stufe AAA: Für eine Konformität auf Stufe AAA muss die Webseite alle Erfolgskriterien der Stufen A, AA und AAA erfüllen oder es wird eine Stufe AAA-konforme Alternativversion zur Verfügung gestellt.

2. Ganze Seiten

Konformität (und Konformitätsstufen) gelten nur für (eine) ganze Webseite(n) und kann nicht erreicht werden, wenn ein Teil einer Webseite ausgeschlossen ist.

Anmerkungen:

Anmerkung 1: Zum Zweck der Bestimmung der Konformität gelten Alternativen zu einem Teil der Inhalte einer Seite als Teil der Seite, wenn die Alternativen direkt von der Seite aus erreicht werden können, z.B. eine lange Beschreibung oder eine alternative Darstellung eines Videos.

Anmerkung 2: Autoren von Webseiten, die aufgrund von Inhalten, die außerhalb der Kontrolle des Autors liegen, nicht konform sein können, können eine Erklärung partieller Konformität in Betracht ziehen.

2.b. Partielle Konformität – Inhalte von Dritten

Wenn eine Seite dieses Typs überwacht und innerhalb von 2 Arbeitstagen repariert wird (nicht-konformer Inhalt wird entfernt oder konform gemacht), kann eine Konformitäts-Erklärung gemacht werden. Eine Konformitätserklärung kann nicht gemacht werden, wenn es nicht möglich ist, nicht-konforme Inhalte zu überwachen oder zu korrigieren; ODER

Man kann eine „Erklärung partieller Konformität“ abgeben, dass die Seite nicht konform ist, aber konform sein könnte, wenn bestimmte Teile entfernt würden. Die Form dieser Erklärung wäre: „Diese Seite ist nicht konform, wäre aber konform zu WCAG 2.0 auf Stufe X, wenn die folgenden Teile aus unkontrollierten Quellen entfernt würden. In der Erklärung partieller Konformität wird beschrieben:

Es handelt sich nicht um Inhalt, welcher der Kontrolle des Autors unterliegt .

Es wird auf eine Art und Weise beschrieben, welche die Benutzer erkennen können (z.B. kann es nicht beschrieben werden als „alle Teile über die wir keine Kontrolle haben“ außer, diese sind deutlich als solche markiert.)

3. Vollständiger Prozess

Wenn eine Webseite Teil einer Folge von Webseiten ist, die einen Prozess darstellen, dann müssen alle Webseiten in dem Prozess zu der bestimmten Stufe oder höher konform sein

Beispiel: Ein Online-Shop hat eine Reihe von Seiten, die benutzt werden, um Produkte auszuwählen und zu kaufen. Alle Seiten in der Abfolge vom Anfang bis zum Ende (Kasse) sind konform, damit alle Seiten, die Teil des Prozesses sind, konform sind.

4. Die Barrierefreiheit unterstützend

Nur bei der Benutzung von Techniken auf eine die Barrierefreiheit unterstützende Art kann man sich darauf verlassen, dass die Erfolgskriterien erfüllt werden.

Jegliche Information oder Funktionalität, die auf eine nicht die Barrierefreiheit unterstützende Art zur Verfügung gestellt wird, ist auch auf eine die Barrierefreiheit unterstützende Art und Weise verfügbar.

Definition von «Accessibility Support» berücksichtigt:

Umgebung (z.B. Intranet mit alten Browsern)

Sprache/Dialekt (z.B. sind in manchen Sprachregionen freie assistive Tools verfügbar, sind diese zu berücksichtigen)

Neue Technologien werden nicht von älteren assisitiven Geräten unterstützt

Unterstützung von nur 1 assisitiver Technik ist normalerweise nicht ausreichend

Unterstützung von verbreiteten assistiven Techniken

5. Nicht störend

Wenn Techniken auf nicht die Barrierefreiheit unterstützende Art benutzt werden, oder wenn sie auf nicht -konforme Art benutzt werden, dann blockieren sie nicht die Fähigkeit des Benutzers, auf den Rest der Seite zuzugreifen. Darüber hinaus erfüllt die Webseite als Ganzes weiterhin die Konformitätsbedingungen unter jeder der folgenden Bedingungen:

wenn irgendeine Technik, auf die man sich nicht verlassen kann, in einem Benutzeragenten angeschaltet wird,

wenn irgendeine Technik, auf die man sich nicht verlassen kann, in einem Benutzeragenten ausgeschaltet wird und

wenn irgendeine Technik, auf die man sich nicht verlassen kann, nicht von dem Benutzeragenten unterstützt wird

Darüber hinaus gelten die folgenden Erfolgskriterien für sämtlichen Inhalt einer Seite einschließlich Inhalt, auf dessen Konformität man sich sonst nicht verlassen würde, da das Scheitern bei der Erfüllung dieser die Nutzung der Seite beeinträchtigen könnte:

1.4.2 - Audio-Steuerelement,

2.1.2 - Keine Tastatur-Falle,

2.3.1 - Grenzwert von dreimaligem Blinken oder weniger, und

2.2.2 - Anhalten, beenden, ausblenden.

Anmerkung: Wenn eine Seite nicht konform sein kann (zum Beispiel eine Konformitäts-Testseite oder eine Beispielseite), dann darf diese nicht in dem Geltungsbereich der Konformität oder in der Konformitätserklärung inbegriffen sein.

Konformitätserklärung

Konformitätserklärungen werden nicht verlangt. Autoren können WCAG 2.0-konform sein, ohne eine Erklärung abzugeben.

Wenn jedoch eine Konformitätserklärung abgegeben wird, dann muss diese die folgenden Informationen beinhalten:

Konformitätserklärung

Datum der Erklärung

Titel der Richtlinien, Version und URI der „Richtlinien für barrierefreie Webinhalte 2.0 unter http://www.w3.org/TR/2008/REC-WCAG20-20081211/ “

Erfüllte Konformitätsstufe: (Stufe A, AA oder AAA)

Eine präzise Beschreibung der Webseiten, wie zum Beispiel eine Liste von URIs, für welche die Erklärung abgegeben wird einschließlich der Information, ob Subdomains in der Erklärung beinhaltet sind.

Eine Liste mit Webinhalts-Techniken, auf die man sich verlässt.

Anmerkung: Wenn ein Konformitätslogo benutzt wird, dann würde dies eine Erklärung darstellen und muss von den oben aufgeführten erforderlichen Komponenten einer Konformitätserklärung begleitet sein.

Beispiel einer Konformitätserklärung

Zertifikat barrierefreie Website «access-for-all»

Für die Tests werden auch die optionalen Konformitätsbedingungen transparent bestimmt:

http://www.access-for-all.ch/ch/zertifizierung/rahmenbedingungen.html

Die Qualitäts-Stufen korrespondieren mit den WCAG 2-Leveln:

Konformität mit P028 P028: Richtlinien des Schweizer Bundes für die Gestaltung von barrierefreien Internetangeboten

Konformität WCAG 2 und P028

Mit den Verwaltungsrichtlinien P028 hat der Bund die Umsetzung der Barrierefreiheit in der zentralen Bundesverwaltung detailliert geregelt.

Bereits in der Bundesverfassung wird festgehalten, dass niemand diskriminiert werden darf aufgrund einer Behinderung.

Das im Jahr 2004 in Kraft getretene Behinderten-gleichstellungsgesetz regelt weitergehend auch die Dienstleistungen des Gemeinweisens. Diese müssen auch zugänglich für Menschen mit Behinderungen angeboten werden. Darunter fallen die Internetangebote von Bund, Kantonen und Gemeinden und bundesnahen Betrieben.

P028 Empfehlungen verglichen mit WCAG 2 Empfehlungen P028 (ergänzend zu WCAG 1, Level AA) Richtlinien aus den WCAG 1 Level AAA Korrespondierende Richtllinie/n WCAG 2.0 4.2 Spezifizieren Sie die Ausschreibung jeder Abkürzung und jedes Akronyms an der Stelle des ersten Auftretens. 3.1.4. AAA 4.3 Machen Sie die vorherrschende natürliche Sprache des Dokuments kenntlich. 3.1.1 A 9.4 Definieren Sie eine logische Tab-Reihenfolge für Links, Formular-Kontrollelemente und Objekte. 2.1.2 A 9.5 Stellen Sie Tastatur-Kurzbefehle (Shortcuts) für wichtige Links (einschließlich solcher in Client-seitigen Imagemaps), Formular-Kontrollelemente und Gruppen von Formular-Kontrollelementen bereit. 2.4.5 AA 11.3 Stellen Sie Informationen bereit, so dass Benutzer Dokumente entsprechend ihren Vorgaben (Sprache, Typ usw.) erhalten können. - 13.6 Gruppieren Sie verwandte Links, identifizieren Sie die Gruppe (für Benutzeragenten), und ermöglichen Sie das Überspringen der Gruppe, bis Benutzeragenten dies gestatten. 1.3.1 2.4.1 2.4.6 A A AA 13.8 Platzieren Sie unterscheidungskräftige Information an den Anfang von Überschriften, Absätzen, Listen usw. 1.3.2 A 13.9 Stellen Sie Informationen über Zusammenstellungen von Dokumenten bereit (z.B. Dokumente, die aus mehreren Seiten bestehen usw.) 2.4.5 AA 14.3 Verwenden Sie einen Präsentationsstil, der über Seiten hinweg konsistent ist. 3.2.3 3.2.4 AA AA 5.5 Stellen Sie Zusammenfassungen für Tabellen bereit. 1.3.1 A

Konformität WCAG 2 und P028

Fazit:

Von den 10 zusätzlichen WCAG 1 AAA-Kriterien der P028 wurden 9 bei der Neuformulierung der WCAG 2

Höher gewichtet und zu AA-Kriterien (Ausnahme: Abkürzungen)

Und werden damit in der WCAG 2-AA-Evaluation berücksichtigt

http://www.access-for-all.ch/ch/richtlinien/gesetz-schweiz.html

WCAG 2 im Requirements Engineering

«Erfüllen»-Katalog eignet sich gut für Pflichtenheft (z.B. Angabe des Levels WCAG 2 AA)

Eignung für Webseiten als Informationssysteme

Eignung für Webseiten als Applikationen

Web als technikunabhängiges Konzept («one web»)

Bisher noch wenig beachtet:

WCAG 2 Richtlinien decken auch eine Vielzahl der Usability-Anforderungen und liefern in wichtigen Punkten sehr präzise Ausformulierung der Anforderungen.

WCAG 2 Richtlinien sind gut geeignet für Web 2.0 Anwendungen (Webservices mit grosser Interaktion) und webbasierte Anwendungen, auch mit eigen entwickelten User Interfaces.

Die WCAG 2 sind selber keine Testanleitung, können und sollen aber für die Evaluation der Konformität angewendet werden.

Für die Evaluation sind bei vielen Erfolgskriterien Testanleitungen definiert.

Ein standardisiertes und nachvollziehbares Testvorgehen ist gut möglich.

Accessibility-Tests können in Eigenregie oder durch externe Experten in einer definierten Testumgebung durchgeführt werden.

WCAG 2 als Evaluationsinstrument http://www.w3.org/WAI/WCAG20/quickref/Overview.php

WCAG 1 (2) als Evaluationsinstrument

Accessibility-Checkliste (wichtigste 30-Punkte der WCAG 1)

Erklärungen-Dokument, mit: - Weshalb ist das nötig? - Beispielen für Designer und Entwickler - Wie wird evaluiert, mit welchen Test-Tools?

WCAG 2 Checkliste derzeit in Arbeit (bis ca. Mai 2010 erwartet) In Deutsch und Französisch Link: www.ch.ch/accessibility/

Zertifikat barrierefreie Website «access-for-all»

Test nach Richtlinien WCAG 2.0 (A, AA, AA+)

Test durch behinderte und nicht-behinderte Experten der Stiftung «Zugang für alle»

Ausführlicher Bericht mit Verbesserungsvorschlägen Re-Test der getroffenen Verbesserungsmassnahmen

Zertifizierte barrierefreie Website «access for all» www.access-for-all.ch/zertifikat/ Die drei Qualitäts-Stufen:

WCAG 2 als Evaluationsinstrument Accessibility im Entwicklungsprozess Anforderungen- Analyse/ Entwurf Design & Konstruktion Übergabe Sensibilisierung Beteiligte Möglichkeiten der Accessibility Detail Tests Zertifizierung

WCAG 1 und 2

Einige Unterschiede

WCAG 1 und 2 – Unterschiede

Die wichtigsten Änderungen:

Neue, verbesserte Anforderungen an Farbkontraste

Neue, präzisierte Anforderungen an Formulare

Scripting: Neu können Websites auch ohne Fall-back-Lösung auskommen. JavaScipt muss aber selber auch barrierfrei sein.

Neue, präzisere Anforderungen an Multimedia (Untertitel, Synchronisation, Steuerung usw.)

Neue, präzisere Anforderungen an Tastaturbedienung

Neue, präzisere Anforderungen bei dynamischer Aktualisierung von Inhalten

Vergleich der WAI:

http://www.w3.org/WAI/WCAG20/from10/comparison/

Neuer Farbkontrast-Messalgorythmus WCAG 1.0 WCAG 2.0

Präzisere Anforderungen an Formulare

Richtlinie 3.3 Hilfestellung bei der Eingabe: Helfen Sie den Benutzern dabei, Fehler zu vermeiden und zu korrigieren.

3.3.1 Fehlererkennung (Eingabefehler automatisch bearbeiten, Stufe A)

3.3.2 Beschriftungen (Labels oder Anweisungen, Stufe A)

3.3.3 Fehlerempfehlung (Eingabefehler Korrekturempfehlungen, Stufe AA)

3.3.4 Fehlervermeidung (Reversibel/bestätigt rechtliche, finanzielle Daten, Stufe AA)

3.3.5 Hilfe (kontextsensitive Hilfe, Stufe AAA)

3.3.6 Fehlervermeidung (Reversibel/bestätigt alle rechtlichen, finanziellen Daten, Stufe AAA)

Scripting zugelassen und zu evaluieren

JavaScript als client-side Scripting-Technik gewinnt an Bedeutung.

Zur Bedienbarkeit

Zur Fehlervermeidung

Zur Steuerung

Diverse Scripting-Techniken werden mit html- und JavaScript-Code erläutert

Beispiel (clientside validation of forminput): http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/SCR18.html

Scripting zugelassen und zu evaluieren

Präzisere Anforderungen an Multimedia

Richtlinie 1.2 Zeitbasierte Medien: Stellen Sie Alternativen für zeitbasierte Medien zur Verfügung.

Mit 9 Unterpunkten für alle denkbaren aufgezeichneten und Live-Medien.

Untertitel, Text-Transkription, Text-Alternative, Synchrone Wiedergabe von z.B. Untertitel und gesprochenem Text.

(problematischer Aufwand für AA-Konformität:

Live-Streaming mit Untertiteln versehen)

Präzisere Anforderungen an Tastaturbedienung

Richtlinie 2.1 Per Tastatur zugänglich: Sorgen Sie dafür, dass alle Funktionalitäten per Tastatur zugänglich sind.

Aller Inhalt ist mit der Tastatur erreichbar (Stufe A)

Tastaturfokus ist sichtbar (Stufe A)

Präzisere Anforderungen bei dynamischen Inhalten

Für einige Erfolgskriterien werden auch ARIA-Techniken empfohlen und beschrieben.

(Auch eigen programmierte User Interfaces sind möglich.)

Accessible Rich Internet Applications (WAI-ARIA) 1.0

W3C Working Draft (24.02.2009)

Wird ein offizieller Bestandteil von HTML 5

Das WAI-ARIA-Framework richtet sich an:

Web User-Agenten-Entwickler (z.B. Browser, Screen-Reader)

Website-Entwickler

http://www.w3.org/TR/wai-aria/

Ein wichtiges AAA-Kriterium

3.1.5 Leseniveau: Wenn der Text nach der Entfernung von Eigennamen und Titeln Lesefähigkeiten voraussetzt, die über das Niveau der niedrigen, sekundären Schulbildung hinausgehen, dann gibt es ergänzenden Inhalt oder eine Version, die keine über die niedrige, sekundäre Schulbildung hinausgehenden Lesefähigkeiten verlangt. (Stufe AAA)

Empfohlene Technik Gebärdensprachvideos G60: http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G160

WAI ARIA

Präzisere Anforderungen bei dynamischen Inhalten ARIA1: Using ARIA describedby property to provide a descriptive, programmatically determined label ARIA2: Identifying required fields with the "required" property ARIA3: Identifying valid range information with the "valuemin" and "valuemax" properties ARIA4: Using ARIA to programmatically identify form fields as required … wird erweitert

Präzisere Anforderungen bei dynamischen Inhalten

2 Beispiele von WAI-ARIA

«Landmark-Roles» www.access-for-all.ch und http://test.cita.illinois.edu/aria/nav/nav1.html

«Slider» zur Werte-Eingabe: http://test.cita.illinois.edu/aria/slider/slider1.php

[ Demonstration mit WinXP, IE7, FF3, Screen-Reader: JAWS 9.x / 10.x ]

HTML 5 bringt zahlreiche Verbesserungen

HTML 5 Live-Test: http://www.der-auftritt.de/wissen/HTML-5-und-WAI-Aria-.html Link: "Jetzt in den HTML5 Modus wechseln“

Z.B. Neue Elemente für die Orientierung in „Regionen“:

<!DOCTYPE html>

<head>

</head>

<body>

<header>

</header>

<div id="wrapper" role=main“>

<section>

<article>

<footer>

Schlussbemerkung

Schlussbemerkung

WCAG 2 sind deutlich besser – sowohl umfangreicher als auch tiefgehender und präziser

WCAG 2 sind sowohl für einfache Websites als auch hochkomplexe Webapplikationen geeignet

Auch für eigene User Interfaces

Decken auch viele Usability-Kriterien präzise ab

JavaScript gewinnt an Bedeutung

WAI-ARIA wird wichtig (für Rich Internet Applications)

HTML 5 – wird rasch und fliessend eingeführt

Bitte planen Sie in Projekten genügend Zeit ein für gute Arbeit Ihrer Webdesigner und Webentwickler!

Fragen an das Publikum

Wie realistisch sehen Sie die Anwendung der WCAG 2 im Requirements-Engineering, die Angabe der Accessibility in Pflichtenheften?

Wo sehen Sie die Schwierigkeiten bei der Einführung und Umsetzung der WCAG 2 in Ihrem Umfeld?

Wie sind Ihre Erfahrungen bei der «Eigen-Evaluation»?

Welche Tiefe der Massnahmen-Vorschläge erwarten Sie in Testberichten von «Zugang für alle»?

Vielen Dank!

Gerne erreichbar für Fragen und Anregungen

[email_address]

WCAG 2 - Die Richtlinien für barrierefreie Webinhalte 2.0

1 comments

Notes on slide 1

1 Favorite