TFH Berlin

4.5. Barrierefreie GUI-Gestaltung     

TFH Berlin

Prinzipen Barrierefreie Webseiten Barrierefreie Webapplikationen Barrierefreie Software-GUIs Prüfprogramme

© Ilse Schmiedecke 2008

Motivationsvideo des Schweizer Fernsehens: TFH Berlin

 http://youtu.be/b2o_hIdudJc © schmiedecke 13

HCI

2

Barrierefreie Gestaltung TFH Berlin

 Barrierefreie Gestaltung – Zugangsmöglichkeiten mit Hilfsmitteln oder unterstützenden Geräte-Einstellungen – Englisch: Accessability – Umfangreiches Regelwerk: WCAG2.0 des W3C "Web Content Accessability Guide" – Weitestgehend übernommen in ISO 9241-171 "Leitlinien für die Zugänglichkeit von Software"

– 3 Konformitätsstufen A - grundsätzliche Bedienbarkeit AA - erweiterte Bedienbarkeit AAA – universelle Bedienbarkeit © schmiedecke 13

HCI

3

Konformitätsbedingungen des WCAG20 TFH Berlin

 Bedingung 1 – Konformitätsstufe angeben  Bedingung 2 – Konformität stets für ganze Seiten  Bedingung 3 – Konformität für Vollständigen Prozess  Bedingung 4 – Verzicht auf nicht barrierefreie Elemente  Bedingung 5 – Störungsfreier Zugang mit Hilfsmitteln (Steuerbarkeit aller zeitgebundenen Vorgänge und aller Audio-Wiedergaben) © schmiedecke 13

HCI

4

Barrierefreiheit – technisch und inhaltlich TFH Berlin

 Technisch: – Hilfsmittelgerechte Gestaltung – Hilfsmittelkompatible Techniken für Webseiten und Anwendungssoftware

 Inhaltlich: – Verstehbarkeit auch mit Hilfsmitteln – Anpassung an Benutzer mit besonderen Einschränungen und Bedürfnissen

© schmiedecke 13

HCI

5

TFH Berlin

WCAG-PRINZIPIEN

© schmiedecke 13

HCI

6

Prinzipien des WCAG TFH Berlin

Zunächst die inhaltlichen Kriterien – die WCAG-Prinzpien

   

Prinzip 1 – Wahrnehmbarkeit Prinzip 2 – Bedienbarkeit Prinzip 3 – Verständlichkeit Prinzip 4 – Robustheit so in der ISO 9241-171

© schmiedecke 13

HCI

7

Prinzipien des WCAG20 TFH Berlin

Prinzip 1 – Wahrnehmbarkeit

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

 Textalternativen zu Audio- und Bildinformation  Medienalternativen und Steuerbarkeit zeitbasierter Medien  Anpassbarkeit der Darstellung  Unterscheidbare Inhalte

© schmiedecke 13

HCI

8

Prinzipien des WCAG20 TFH Berlin

Prinzip 2 – Bedienbarkeit

Bestandteile der Benutzerschnittstelle und Navigation müssen bedienbar sein.

 Bedienbarkeit per Tastatur  Steuerung des Zeitverhaltens – Tempo, Pausen, …

 Keine anfallsauslösenden Elemente – hektische Animationen, Lichtblitze,…

 Freie Navigierbarkeit auch mit Hilfsmitteln – Semantische Auszeichnung, – Tastaturnavigation, überspringbare Blöcke © schmiedecke 13

HCI

9

Prinzipien des WCAG20 TFH Berlin

Prinzip 3 - Verständlichkeit

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

 Lesbarkeit – Sprache, Sprachniveau, Abkürzungen, Aussprache

 Linearisierbarkeit – Inhaltiche Linearisierungsreihenfolge

 Vorhersehbarkeit – erwartungskonforme Fokuswahl und Navigation, – aussagekräftige Link-Beschriftungen und Alternativtexte

 Hilfestellung bei Eingabe – Beschriftungen und Hilfe, z.B. durch Tooltips) – Fehlererkennung u. –vermeidung

© schmiedecke 13

HCI

10

Prinzipien des WCAG20 TFH Berlin

Prinzip 4 – Robustheit

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.

 Valide Auszeichnung  Plattform-Kompatibilität (wichtig vor allem für - Javascript-basierte Bedienelemente)

© schmiedecke 13

HCI

11

TFH Berlin

TECHNISCHE KRITERIEN

© schmiedecke 13

HCI

12

Kriterien technischer Barrierefreiheit Hilfsmittelgerechte Gestaltung

TFH Berlin

Für sehbehinderte Nutzer – Skalierbarkeit: • Schriftvergrößerung / Auflösungsveränderung • Bildschirmlupe

– Grafische Reduzierbarkeit • Ausblenden von Farbflächen, Hintergrund- und Dekorationsbildern

Für blinde Nutzer – Linearisierbarkeit: • Screenreader und Braillezeile

– Naviagationunterstützung • Tastaturnavigation innerhalb der Seite • Semantische Navigationsreihenfolge

– Objektlesbarkeit

•

Objektart, Wert, Zustand

– Änderungs-Erkennung

© schmiedecke 13

HCI

13

Technische Anforderungen der Barrierefreiheit TFH Berlin

 Webseiten:    

Valides HTML Semantische Auszeichnung Layout und Dekor nur durch CSS relative Größenangaben

 Rich Internet Applications  Zusätzlich ARIA-Auszeichnung

 Software:  Hilfsmittel erwarten Accessibility-APIs  müssen von der GUI-Technologie implementiert werden © schmiedecke 13

HCI

14

Webseiten: Valides HTML / XHTML TFH Berlin

 Validität (Gültigkeit) bedeutet Einhaltung der Syntaxregeln  Überprüfbar duch frei verfügbare Validatoren z.B. Unicorn: http://validator.w3.org/unicorn/  Bedeutung für die Barrierefreiheit:

Grundvoraussetzung: notwendig, aber nicht hinreichend!

© schmiedecke 13

HCI

15

Webseiten: Textalternativen TFH Berlin

Textalternativen: informativ, aber nicht "geschwätzig"

Quelle: http://www.bitv-lotse.de/ © schmiedecke 13

HCI

16

Webseiten: Textalternativen TFH Berlin

Mit longdesc-Attribut auf externe Textquelle verweisen

Datei beschreibung_wahlbeteiligung.txt: Die Entwicklung der Wahlbeteiligung in Deutschland bei Bundestagswahlen von 1949 bis 2009. 1949 lag die Wahlbeteiligung nur bei 78,5 %. Bis 1969 lag die Beteiligung immer im Bereich von 86 bis 88 %, 1972 gab es einen Sprung auf 91,1 %. In den Folgejahren sank die Beteiligung, bis sie 1990 einen Tiefststand von 77,8 % erreichte. Nach einem kurzen Anstieg ende der 90er, sank die Beteiligung wieder ... © schmiedecke 13

HCI

Quelle: http://www.bitv-lotse.de/

17

Webseiten: Linearisierbarkeit TFH Berlin

Linearisierbarkeit für blinde Nutzer: 1. Inhalt des Dokuments verstehbar gliedern 2. Gliederungsblöcke und – ebenen mit Elementen markieren 3. Mithilfe von CSS Blöcke optisch anordnen 4. Blöcke mit CSS weiter

…. … … … … …

gestalten

© schmiedecke 13

HCI

18

Webseiten: Navigationsunterstützung TFH Berlin

 Attribut tabindex – – – – –

Seit HTML 4 für alle Bedienelemente Seit ARIA für alle sichtbaren Elemente (auch div-s) Positive Zahlen (bis 32000) für die Navigationsreihenfolge 0 ist Default und bedeutet Reihenfolge des HTML-Dokuments Negative Zahlen werden nicht durch Tabulatoren angesteuert (Fokus wird programmatisch gesteuert)

... ... // Fokus durch Javascript var progdiv = document.getElementById(‘progaccess‘); Progdiv.focus(); Quelle: dev.opera.com/articles/view/introduction-to-wai-aria/ © schmiedecke 13

HCI

19

Webseiten: Überspringbare Blöcke TFH Berlin

 Der Screeenreader linearisiert erbarmungslos! D.h. er beginnt immer wieder von oben.  Was am Anfang steht, wird immer wieder vorgelesen, z.B. eine lange Navigationsliste.  Abhilfe lt. WCAG:

Gruppierung und Überspringbarkeit verwandter Links:

© schmiedecke 13

HCI

20

Webseiten: Überspringbare Blöcke Unsichtbare Sprungmarken

TFH Berlin

Navigation überspringen Navigation … © schmiedecke 13

CSS: .unsichtbar: { position:absolute; left: -1000px; top: -1000px; width: 0; height:0; }

HCI

21

Die verborgene Sprungmarke TFH Berlin

Im Screenreader:

Im Browser:

Navigation überspringen Navigation link1 link2 link3 ….

link1 link2 link3 …

© schmiedecke 13

HCI

22

Anwendung: Skalierbarkeit TFH Berlin

 Skalierbarkeit für Nutzer mit Sehbehinderung: Kein Informationsverlust und kein horizontales Scrollen durch - Schriftvergrößerung - Veränderung der Bildschirmauflösung

 Maßnahmen: Keine absoluten Größenangaben! Möglichkeiten: 55 % - Relativ zur aktuellen Größe/Breite/Höhe 0.5em - Relativ zur aktuellen Breite des "M" Tabellen: Breite den -Elementen in Prozent zuordnen, auf keinen Fall scrolling=NO oder Noresize angeben! Texte: min-width und max-width angeben, scrolling=NO © schmiedecke 13

HCI

23

TFH Berlin

WAI-ARIA-AUSZEICHNUNG

© schmiedecke 13

HCI

24

Rich Internet Applications TFH Berlin

Screenreader wird ausgebremst durch  Eingebettete Programme wie Flash – Flash wird immer "barrierefreier"

 Die Verwendung von Javascript-Widgets – Bedeutung, Bedienung, Zustand bleiben verborgen

 Die Verwendung von Ajax – Updates werden nicht erkannt

 Textbasierte Markierungen (* für "erforderlich") – und auch das text- und farbbasierte Feedback

© schmiedecke 13

HCI

25

Rich Internet Applications: ARIA TFH Berlin

WAI-ARIA Web Accessibiliy Initiative – Accessible Rich Internet Applications specification seit ca. 2007 – aktueller Status: W3C-Candidate Zusätzliche Auszeichnungsmöglichkeiten für beliebige sichtbare Elemente – Fokusbehandlung, Rollen, Zustände und Eigenschaften – von Hilfsmitteln interpretiert – von Brownsern ignoriert  problemlos einsetzbar © schmiedecke 13

HCI

26

ARIA - Rollen TFH Berlin

Rollen bezeichnen die Bedeutung sichtbarer Elemente Rollen-Ontologie in 4 Kategorien  Wigets – alert, alertdiaolg, button, checkbox, gridcell, link, menuitem, ...

 Composite Widgets – Combobox, grid, listbox, menu, radiogroup, tablist, tree, ...

 Document Structure – Article, columnheader, definition, directory, heading, list, ...



Document Landmarks – application, banner, complementary, contentinfo, main, navigation, search, math,...

... ... © schmiedecke 13

HCI

27

ARIA-Zustände und -Eigenschaften TFH Berlin

 Zustände und Eigenschaften machen visualisierte Eigenschaften für Hilfsmittel zugänglich aria-valuenow aria-valuemax aria-valuemin aria-valuetext aria-labelledby aria-describedby ...

© schmiedecke 13

HCI

28

ARIA-Beispiel Slider TFH Berlin

 HTML-Tag ist input  Screenreader erkennt

slider  leffective ist ein id, von dem der Text übernommen wird.  Berechnung von valuenow kann durch javascript erfolgen

Quelle: dev.opera.com/articles/introduction-to-wai-aria © schmiedecke 13

HCI

29

ARIA-Aktive Regionen TFH Berlin

 Aktive Regionen verändern sich, ohne dass die Seite neu geladen werden ( Ajax)  Hilfsmittel müssen wissen – – – –

welches aktive Regionen sind wann sie eine Veränderung bekannt geben sollen wieviel sie bei einem Update bekannt geben sollen wann ein Updaten abgeschlossen ist

 ARIA bietet die folgenden Attribute – – – –

aria-live aria-atomic aria-busy aria-relevant

© schmiedecke 13

-

Werte off, polite, assertive Bereich, der bei Updaten bekannt zu geben ist Update noch nicht abgeschlossen? welche DOM-Veränderungen werden bekannt gegeben?HCI 30

ARIA-Beispiel List-update TFH Berlin

– relevant=additions: Update wird bekanntgegeben, wenn DOM-Element hinzugefügt wird andere Werte: removals, text, all – atomic=true: gesamte Liste wird bei Update angezeigt/wiedergegeben – live=polite: Benutzeraktion wird nicht unterbrochen andere Werte: off, assertive

© schmiedecke 13

HCI

31

ARIA einsetzen? TFH Berlin

Zitat Gez Lemon, 2008: http://dev.opera.com/articles/view/introduction-to-wai-aria/

Be an early adopter As there are no negative side-effects from using ARIA, and support is already in place, there is nothing to lose by becoming an early adopter, but plenty to gain. Even if you have the simplest of websites, you could include document landmark roles to help users better navigate, and orientate themselves within the content. Besonders wichtig und wünschenswert für JS-Bibliotheken! © schmiedecke 13

HCI

32

Vortrag zu WAI-ARIA

Marco Zehe auf dem MMT 2011

TFH Berlin

 https://www.youtube.com/watch?v=QBcV00ZLYDA © schmiedecke 13

HCI

33

TFH Berlin

ACESSABILITY-PRÜFUNG

© schmiedecke 13

HCI

34

Freie Accessibility-Prüfprogramme TFH Berlin

 Firefox Accessibility Extension

https://addons.mozilla.org/en-US/firefox/addon/5809/

 WebAnywhere

http://webinsight.cs.washington.edu/wa/content.php

 Visicheck (simuliert Fehlsichtigkeiten) http://www.vischeck.com/vischeck/

 WAVE

http://wave.webaim.org/

© schmiedecke 13

HCI

35

Accessibility-Prüfprogramme TFH Berlin

 Vollständige Liste des W3C unter http://www.w3.org/WAI/RC/tools/complete

© schmiedecke 13

HCI

36

TFH Berlin

BARRIEREFREIE GUIS

© schmiedecke 13

HCI

37

Barrierefreie GUIs:

Objekte-Modell  Hilfmittelunterstüzung

TFH Berlin

• HTML  historisch: rein visuelle Gestaltung  kein Modell /unstrukturiertes Modell  heute, insbesondere in HTML 5: semantische Auszeichnung Trennung von Struktur (HTML) und visueller Gestaltung (CSS)  Struktur liefert Modell

 Programmiersprachen: – GUI-Bibliotheken realisieren (zunehmend) MVC  es gibt ein strukturiertes Modell mit abstrakten Objekteigenschaften auf das die Hilfsmittel zurückgreifen können  GUI-Bibliotheken implementieren Accessability-Schnittstellen auf der Grundlage dieses Modells © schmiedecke 13

HCI

38

Technische Grundlagen: Software Accessibility TFH Berlin



Microsoft Schnittstellen für Zugangs-Hilfsmittel – MSAA bzw MSUIA – zunehmend auch von Clienttechnologien implementiert (flash, …)



Java-Accessibitity – Schnittstellen JAAPI – Klassenbibliothek für Hilfsmittel – Java Accessibility Utilities – Schnittstelle zu MSAA – Java Access Bridge

© schmiedecke 13

HCI

39

Java Accessibility TFH Berlin

 JAAPI (Java Accessible API) – Interface javax.accessibility.Accessible wird von GUI-Frameworks standardmäßig implementiert

– AttributAccessibleContext enthält Accessible-Namen, Accessible-Beschreibung, Status, Alternativtext,… automatisch oder von Hand zu setzen:

 Tastaturbedienung und -navigation – in allen GUI-Komponenten standardmäßig enthalten © schmiedecke 13

HCI

40

IBM Software Acessibility Checklist 

Tastaturalternativen – –



Textalternativen zu Audio und Video Lautstärkeregulierung

Darstellung – – –



Fokus Visuell und Hilfsmittel-lesbar anzeigen Semantische Objektinformation Labels für alle UI-Elemente Hilfsmittelzugang für Formulare

www-03.ibm.com/ able/guidelines/ software/accesssoftware .html

Töne und Multimedia – –



Tastaturbedienbarkeit für alle Aktionen Keine Konflikte mit Tastatur-Accessibility des BS

Objekt-Informationen – – – –



TFH Berlin

Textalternativen für alle Objekte Systemeinstellungen für Kontrastverstärkung unterstützen Systemenstellungen für Schriftart, Schriftgröße, Farbe, Größe erben

Timing –

Animationen abstellbar

–

Blinkfrequenz zwischen 2 und 55 Hz

© schmiedecke 13

HCI

41

TFH Berlin

Das war noch lange nicht alles – aber genug für diesen Einstieg

 © schmiedecke 13

HCI

42