TFH Berlin
4.5. Barrierefreie GUI-Gestaltung
ü Prinzipenü Barrierefreie Webseitenü Barrierefreie Webapplikationenü Barrierefreie Software-GUIsü Prüfprogramme
© Ilse Schmiedecke 2019TFH Berlin
TFH Berlin
Bewertungskriterien Abschlusspräsentation
§ Präsentation§ Gesamteindruck der Lösung, vorher/nachher§ Usability-Ziele / direkt erkenbare Zielerreichung§ Prototypen und Evaluation / Entwurfsprozess§ HCI-Gestaltungskriterien (einzeln!)§ HCI-Benutzerorientierung
§ Ggf. Barrierefreiheit
© schmiedecke 19 HCI 2
TFH Berlin
© schmiedecke 08 HCI 3
Barrieren der Computernutzung
Nutzungsbarrieren erfahren:
§ blinde Nutzer§ sehbehinderte Nutzer§ motorikgestörte Nutzer (auch temporär)§ gehörlose Nutzer§ lernbehinderte Nutzer§ alte Nutzer
Fotoquelle: www.webforall.info
TFH Berlin
WAS IST BARRIEREFREIHEIT?
© schmiedecke 19 HCI 4
TFH Berlin
Motivationsvideo des Schweizer Fernsehens:
§ http://youtu.be/b2o_hIdudJc 0:24-2:32
© schmiedecke 19 HCI 5
youtube.com/watch?v=92pM6hJG6Wo als Alternative (englisch, aber sehr gut erklärt!)
TFH Berlin
© schmiedecke 19 HCI 6
TFH Berlin
Barrierefreiheit – technisch und inhaltlich
§ Technisch:
– Les- und Bedienbarkeit– Hilfsfunktions- und Hilfsmittelgerechte Gestaltung– Hilfsmittelkompatible Techniken für Webseiten und Anwendungssoftware
§ Inhaltlich:
– Verstehbarkeit auch mit Hilfsmitteln– Anpassung an Benutzer mit besonderen Einschränkungen und
Bedürfnissen
© schmiedecke 19 HCI 7
Bildquelle: https://www.turlock.k12.ca.us
TFH Berlin
Barrierefreiheit – WIE?
WCAG 2.1 –Web Content Accessibility Guide
§ Herausgeber:– WAI – Web Accessibility Initiative des W3C– Weltweiter Standard, aber keine verbindliche Norm (ISO)
§ Aufbau: – 4 Prinzipien
Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit, Robustheit– Richtlinien zu den Prinzipien
und Empfehlungen zur technischen Umsetzungz.B. Alternativtext zu Bildern, Alternativlinks zu "klickbaren" Bildern
– 3 KonformitätsstufenA, AA, AAA
© schmiedecke 19 HCI 8
Bildquelle: www.turlock.k12.ca.us
TFH Berlin
WCAG-Richtlinien am Beispiel
Richtlinie 1.1 Textalternativen: 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.1.1 Nicht-Text-Inhalt:Alle Nicht-Text-Inhalte, die dem Benutzer präsentiert werden, haben eine Textalternative, die einem äquivalenten Zweck dient, mit Ausnahme der unten aufgelisteten Situationen. (Stufe A)– Steuerlemente/Eingabe: ....– Zeitbasierte Medien: ....– Test: ....– Sensorisch: ....– CAPTCHA: ....– Dekoration, Formatierung, unsichtbar: ....
© schmiedecke 19 HCI 9
TFH Berlin
Rechtliche Lage
§ BITV– fordert Barrierefreiheit für Webauftritte der öffentlichen Hand– BITV 2.0 (überarb.) setzt auf WACG 2.0 auf
§ Europäischer Rechtsakt zur Barrierefreiheit– Seit April 2019 in Kraft – Umsetzung in nationales Recht folgt– Barrierefreiheit für
alle Angebote von Waren oder Dienstleistungen(nicht nur im Internet)
– Ausnahmen z.B. für Kleinstunternehmen– Erarbeitung seit 2011 auf UN-Anforderung– 2.12.2015 Ausarbeitung veröffentlicht
© schmiedecke 19 HCI 10
TFH Berlin
Rechtsakt 12/15 der EU-Legislative vorgelegt
© schmiedecke 19 HCI 11
TFH Berlin
© schmiedecke 19 HCI 12
TFH Berlin
Rechtliche Entwicklung in Deutschland
§ 20 Jahre zwischen WCAG 1.0 und EAA§ Weitere 2 Jahre bis zu nationalem Recht
© schmiedecke 19 HCI 13Bildquelle: Franziska Tornow, Abschlussarbeit
TFH Berlin
PROBLEMBEISPIELE
© schmiedecke 19 HCI 14
TFH Berlin
Bedienbarkeit: Beispiel weZoom App
© schmiedecke 19 HCI 15
SUPER: Einhandbedienung, stufenloser Zoom, Standbild, Farbinversionen ...PROBLEM: Einstellungen in sehr kleiner Schrift, nicht zoombar
TFH Berlin
Eingebettete Medien: Video
© schmiedecke 19 HCI 16
TFH Berlin
Medien: Barrierefreiheit bei Inhalt und Bedienung
Bedienung§ Bedienelemente
– vorlesbar – vergrößerbar– tastaturbedienbar
§ Inhalt– Audiobeschreibung– Textbeschreibung
Stopp, Langsamer, Zurück...
Inhalt§ Audiobeschreibung
– Primärinhalt– Visuelle Effekte
§ Textbeschreibung– Primärinhalt– Audioeffekte
© schmiedecke 19 HCI 17
TFH Berlin
Wahrnehmbarkeit mit Hilfsmitteln
§ Schriftvergrößerung§ Zoom§ Farbanpassung§ Screenreader© schmiedecke 19 HCI 18
TFH Berlin
Tastaturbedienbarkeit
§ Die klassischen Bedienelemente sind tastaturbedienbar§ Moderne dynamische Elemente oft nicht (aber: ARIA macht es doch möglich)
© schmiedecke 19 HCI 19
TFH Berlin
WCAG-PRINZIPIEN
© schmiedecke 19 HCI 20
TFH Berlin
Prinzipien des WCAG
§ Prinzip 1 – Wahrnehmbarkeit§ Prinzip 2 – Bedienbarkeit§ Prinzip 3 – Verständlichkeit§ Prinzip 4 – Robustheit
© schmiedecke 19 HCI 21
so in der ISO 9241-171
Zunächst die inhaltlichen Kriterien – die WCAG-Prinzpien
TFH Berlin
Prinzipien des WCAG20
Prinzip 1 – WahrnehmbarkeitInformationen 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 19 HCI 22
TFH Berlin
Prinzipien des WCAG20
Prinzip 2 – BedienbarkeitBestandteile 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 19 HCI 23
TFH Berlin
Prinzipien des WCAG20
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 19 HCI 24
TFH Berlin
Prinzipien des WCAG20
Prinzip 4 – RobustheitInhalte 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 <Widgets> - Javascript-basierte Bedienelemente)
© schmiedecke 19 HCI 25
TFH Berlin
BARRIEREFREIHEIT PRKATISCH
© schmiedecke 19 HCI 26
TFH Berlin
Die wichtigsten Anforderungen
Für sehbehinderte Nutzer– Skalierbarkeit– Kontraste und Graustufenerkennbarkeit– Tastaturbedienbarkeit
Für blinde Nutzer– Linearisierbarkeit– Tastaturbedienbarkeit und -navigation– Objektlesbarkeit– Änderungs-Erkennung
© schmiedecke 19 HCI 27
TFH Berlin
Die 7 Säulen der Barrierefreiheit(nach Hellbusch)
1. Alternativen für Grafiken und Multimedia
2. Kontrast und Graustufenerkennbarkeit
3. Skalierbarkeit
4. Linearisierbarkeit
5. Tastaturbedienbarkeit (auch für dynamische Inhalte)
6. Verständlichkeit der Sprache und Verfahren
7. Semantische Strukturierung
© schmiedecke 19 HCI 28
TFH Berlin
Webseiten: Textalternativen
Textalternativen: informativ, aber nicht "geschwätzig"
© schmiedecke 19 HCI 29
Quelle: http://www.bitv-lotse.de/
TFH Berlin
Kontrast und Graustufenerkennbarkeit
© schmiedecke 19 HCI 30
TFH Berlin
Keine Inhalte als CSS-Hintergrundbilder!
© schmiedecke 19 HCI 31
Quelle: Hellbusch, www.barrierefreies-webdesign
Icons als Hintergrundbilder verschwinden im Kontrastmodus
TFH Berlin
Skalierbarkeit: Verhalten bei Zoom
© schmiedecke 19 HCI 32
webOPAC:Vergrößerte Schriftenüberlagern sich
BelegsystemHorizontales Scrollen bei Schriftvergößerung
Beuth-SeiteResponsive – quasi-mobile Ansicht bei starkem Zoom
TFH Berlin
Skalierbarkeit
§ Skalierbarkeit für Nutzer mit Sehbehinderung:Kein Informationsverlust und kein horizontales Scrollen durch– Schriftvergrößerung– Veränderung der Bildschirmauflösung
§ Maßnahmen:– Responsive Design– Vermeidung absoluter Größenangaben
Relative Größe: 55 % - Relativ zur aktuellen Größe/Breite/Höhe0.5em - Relativ zur aktuellen Breite des "M"
Tabellen: Breite den <td>-Elementen in Prozent zuordnen, auf keinen Fall scrolling=NO oder Noresize setzen
Texte: min-width und max-width angeben, scrolling=NO
© schmiedecke 19 HCI 33
TFH Berlin
Linearisierbarkeit
§ Blinde "lesen" nur das HTML-Dokument, von oben nach untenà Reihenfolge im Dokument muss sinnvoll und logisch sein.
§ Regeln:§ Regionen planen, benennen § je als ein benanntes HTML-Element codieren§ Logische Lesereihenfolge der Regionen bestimmen§ HTML-Elemente in dieser Reihenfolge ins Dokument übernehmen.
© schmiedecke 19 HCI 34
TFH Berlin
Webseiten: Überspringbare Blöcke
§ 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 19 HCI 35
TFH Berlin
Webseiten: Überspringbare BlöckeUnsichtbare Sprungmarken
<nav><a href="#navende"
class="unsichtbar">Navigation überspringen</a>
<h4 class="unsichtbar">Navigation
</h4><ul>…</ul><a name="navende"></a></nav>
CSS:.unsichtbar: {
position:absolute;left: -1000px;top: -1000px;width: 0;
height:0;}
© schmiedecke 19 HCI 36
TFH Berlin
Die verborgene Sprungmarke
Im Screenreader:
Navigation überspringenNavigationlink1link2link3….
Im Browser:
link1link2link3…
© schmiedecke 19 HCI 37
TFH Berlin
Tastaturbedienbarkeit (Fokussteuerung)
§ Mit TAB kommt man grundsätzlich von Objekt zu Objekt§ Reihenfolge ist die im HTML-Dokument (à sinnvoll)§ Bedienbarkeit bei HTML-Elementen gegeben.
§ Probleme:§ Dynamische (JS-erzeugte)
Inhalte und Bedienelemente§ Bedienung eingebetteter
Medien(-player)
© schmiedecke 19 HCI 38
TFH Berlin
Semantische Strukturierung
§ Gliederung mit HTML-Strukturelementen– header, footer, nav, aside, main, article, section
– außerdem div (benannt), ARIA-Rollen– h1, h2, .... (keine Ebenen auslassen)
– Begründung: Screenreader liest die Elemente vorund kann sie gezielt anspringen.
§ Formatierung nur mit CSS
© schmiedecke 19 HCI 39
TFH Berlin
WAI-ARIA-AUSZEICHNUNG
© schmiedecke 19 HCI 40
TFH Berlin
Rich Internet Applications
Screenreader wird ausgebremst durch
§ Javascript-erzeugte Elemente– Bedeutung, Bedienung, Zustand bleiben verborgen
§ Die Verwendung von Ajax– Aktualisierungen werden nicht bemerkt
§ Textbasierte Markierungen (* für "erforderlich")– und auch das text- und farbbasierte Feedback
© schmiedecke 19 HCI 41
TFH Berlin
Rich Internet Applications: ARIA
WAI-ARIAWeb Accessibiliy Initiative –
Accessible Rich Internet Applications specificationseit ca. 2014 Version 1.0 W3C-Standard
Zusätzliche Auszeichnungsmöglichkeiten für beliebige sichtbare Elemente– Fokusbehandlung, Rollen, Zustände und Eigenschaften– von Hilfsmitteln interpretiert– von Browsern ignoriertà problemlos einsetzbar
© schmiedecke 19 HCI 42
TFH Berlin
ARIA - Rollen
Rollen bezeichnen die Bedeutung sichtbarer ElementeRollen-Ontologie mit 30+ Rollen 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 19 HCI 43
<div role=“banner“> ... </div><div role=“navigation“ tabindex=“1“> ... </div>
TFH Berlin
ARIA-Zustände und -Eigenschaften
§ 9 Zustände machen visualisierteEigenschaften für Hilfsmittel zugänglich
aria-valuenowaria-valuemaxaria-valueminaria-valuetextaria-labelledbyaria-describedby
...§ 20+ Eigenschaften stellen Beziehungen zwischen
Elementen her© schmiedecke 19 HCI 44
TFH Berlin
ARIA-Beispiel Slider
§ HTML-Tag ist input§ Screenreader erkennt
slider§ leffective ist ein id, von
dem der Text übernommen wird.
§ Berechnung von valuenow kann durch javascript erfolgen
© schmiedecke 19 HCI 45Quelle: dev.opera.com/articles/introduction-to-wai-aria
TFH Berlin
Tabindex für die Tastennavigation
§ ARIA: Tabindex für alle HTML-Elemente möglich
§ Tabindex=0Tabulatornaviagtion in natürlicher Reihenfolge
§ Tabindex -1Wird nicht mit dem Tabulator angesprungen , sondern nur programmatisch – z.B. Fehlermeldungen, Alerts
§ Tabndex > 0Schlechte Idee, manipulierte Reihnefolge, Rücksprung unlogisch!
© schmiedecke 19 HCI 46
TFH Berlin
Beispiel:Selbst gebautes HTML-Bedienelement
<span onclick="doThis();">Push</span>
im Screenreader nicht als Bedienelement erkennbar!
<span onclick="doThis();" role="button">Push</span>
als Button erkennbar
<span onclick="doThis();" role="button" tabindex="0">Push</span>
Fokus hinzugefügt, mit dem Tabulator erreichbar
© schmiedecke 19 HCI 47
TFH Berlin
ARIA-Aktive Regionen
§ 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 - Werte off, polite, assertive– aria-atomic - Bereich, der bei Updaten bekannt zu geben ist– aria-busy - Update noch nicht abgeschlossen?– aria-relevant - welche DOM-Veränderungen werden bekannt
gegeben?© schmiedecke 19 HCI 48
TFH Berlin
ARIA-Beispiel List-update
– relevant=additions:Update wird bekanntgegeben, wenn DOM-Element hinzugefügt wirdandere Werte: removals, text, all
– atomic=true:gesamte Liste wird bei Update angezeigt/wiedergegeben
– live=polite:Benutzeraktion wird nicht unterbrochenandere Werte: off, assertive
© schmiedecke 19 HCI 49
TFH Berlin
Gute Einführung auf Youtube
www.youtube.com/watch?v=GgserrcH6nQ© schmiedecke 19 HCI 50
TFH Berlin
Vortrag zu WAI-ARIA Marco Zehe auf dem MMT 2011
§ https://www.youtube.com/watch?v=QBcV00ZLYDA
© schmiedecke 19 HCI 51
TFH Berlin
Marco Zehe über WAI-ARIA auf dem MMT 2011
© schmiedecke 19 HCI 52
TFH Berlin
ACESSABILITY-PRÜFUNG
© schmiedecke 19 HCI 53
TFH Berlin
Firefox-Erweiterungen
§ WAVEhttps://wave.webaim.org/
§ aXehttps://www.deque.com/axe/
© schmiedecke 19 HCI 54
TFH Berlin
Chrome-Erweiterungen
© schmiedecke 19 HCI 55
TFH Berlin
Accessibility-Prüfprogramme
§ Vollständige Liste des W3C unterhttp://www.w3.org/WAI/RC/tools/complete
© schmiedecke 19 HCI 56…
TFH Berlin
Barrierefreie GUIs
© schmiedecke 19 HCI 57
TFH Berlin
Barrierefreie GUIs:Objekte-Modell à Hilfmittelunterstüzung
• HTML- historisch:
rein visuelle Gestaltung à kein Modell /unstrukturiertes Modell- heute, insbesondere in HTML 5:
semantische AuszeichnungTrennung 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 19 HCI 58
TFH Berlin
Technische Grundlagen: Software Accessibility
§ 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 19 HCI 59
TFH Berlin
Java Accessibility
§ 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 19 HCI 60
TFH BerlinIBM Software Acessibility Checklist
§ Tastaturalternativen– Tastaturbedienbarkeit für alle Aktionen– Keine Konflikte mit Tastatur-Accessibility des BS
§ Objekt-Informationen– Fokus Visuell und Hilfsmittel-lesbar anzeigen– Semantische Objektinformation– Labels für alle UI-Elemente– Hilfsmittelzugang für Formulare
§ Töne und Multimedia– Textalternativen zu Audio und Video– Lautstärkeregulierung
§ Darstellung– 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 19 HCI 61
www-03.ibm.com/able/guidelines/software/accesssoftware.html
TFH Berlin
Das war noch lange nicht alles –aber genug für diesen Einstieg
JFreuen Sie sich auf den Workshop mit
einem blinden Benutzer!
© schmiedecke 19 HCI 62