Warum ist eine Anpassung notwendig?

• Rechtsverordnung
  • Gesetz zur Gleichstellung behinderter Menschen 2002
  • Barrierefreie-Informationstechnik-Verordnung - BITV 2.0 2011
    • regelt praktische Umsetzung in Deutschland
    • nach WCAG 2.0 gestaltet
• Behinderungen
  • visuelle Behinderung
    • Blindheit, Sehbehinderung, Farbenblindheit
  • auditive Behinderung
    • Gehörlosigkeit, Schwerhörigkeit
  • motorische Behinderung
    • Beeinträchtigung der Hände, eingeschränkte Feinmotorik
  • kognitive Behinderung
    • Einschränkungen beim Inhaltsverständnis
• geräteunabhängige Benutzung

WCAG 2.0

• Erstellung durch Web Accessibilty Initiative (WAI)
  • weltweit als Vorlage zur Umsetzung der Barrierefreiheit
• 4 Prinzipien, 12 Richtlinien, 61 Erfolgskriterien und unzählige Techniken
• Konformitätsstufen (A, AA, AAA)
  • fängt bei A an
  • alle Erfolgskriterien der Stufe müssen erfüllt werden
• Konformität nur für ganze Webseiten
  • essentiell, dass auch Unterseiten konform sind

Prinzipien mit einer Auswahl an Richtlinien

• Wahrnehmbarkeit – Benutzer müssen alle Informationen und das Interface erfassen können.
  • Stellen Sie Textalternativen für alle Nicht-Text-Inhalte zur Verfügung.
  • Machen Sie es für den Benutzer leichter, Inhalte zu sehen und zu hören.
• Bedienbarkeit – Jeder Nutzer muss sich durch den Inhalt und die Navigation bewegen können.
  • Sorgen Sie dafür, dass alle Funktionalitäten von der Tastatur aus verfügbar sind.
  • Stellen Sie Mittel zur Verfügung, um Benutzer dabei zu unterstützen zu navigieren, Inhalte zu finden und zu bestimmen, wo sie sich befinden.
• Verständlichkeit – Informationen und Interface müssen verständlich vermittelt werden.
  • Machen Sie Textinhalte lesbar und verständlich.
  • Sorgen Sie dafür, dass Webseiten vorhersehbar aussehen und funktionieren.
  • Helfen Sie den Benutzern dabei, Fehler zu vermeiden und zu korrigieren.
• Robustheit – Umsetzung muss robust genug sein, um von einer großen Anzahl von Nutzern und Technologien interpretiert werden zu können.
  • Maximieren Sie die Kompatibilität mit aktuellen und zukünftigen Benutzeragenten, einschließlich assistierender Techniken.
• vollständig unter w3.org/Translations/WCAG20-de

Baustellen und Vorlagen

• potenzielle Baustellen:
  • Bilder mit geeignetem Alternativtext
  • HTML-Stukturelemente verwenden
  • Verwendung von Überschriften in passender Reihenfolge
  • auf Kontraste achten
• Auswahl konformitätsgeprüfter TU-Seiten, u. a.
  • Startseite der TUC, Terminkalender, WTC-Seite
  • Liste der Studiengänge, Suche im Vorlesungsverzeichnis
  • FAQ-Studentenservice
  • Fakultätsseite der Naturwissenschaften mit Professurenliste
  • Kontaktseite des Universitätsrechenzentrums

Anpassungen am Framework

• Überschriftenreihenfolge
  • Abschnitte mit Überschriften strukturiert
    • Navigation, Pressebereich, Footer
  • Inhalt der Seite muss auch mit <h1> beginnen, um sich in die Struktur zu integrieren
• Visitenkarten als <figure>
• Pop-up-Fenster (modale Dialogfenster)
  • Bilder in <figure>
  • Alternativtexte für Bilder können mit angegeben werden

    • hs_image(string $bild_klein, string $bild_groß, string $text , array('img_alt' => 'Alternativtext'));

    • hs_slideshow(array(array('bild.jpg', 'Beschreibung 1', 'Alternativtext'), array(...)));

    • Hinweis: Copyright-Angaben gleich als Bildbeschreibung mit hinzufügen
• Optimierung der Tastaturbedienung
  • alle Hover-Effekte werden auch durch Fokus ausgelöst
  • Hover- und Fokus-Effekte nur auf <a>...</a>-Elementen angewendet
    • zu beachten, welche HTML-Elemente fokussierbar sind
• Hinweis: Mit class="sr-only" werden Elemente visuell versteckt und dienen als Erläuterungen für Screenreader.

Developer Tools

• Chrome
  • Accessibility Developer Toolbar
    • Kontrastprüfer
    • Barrierefreiheitstests (Audits)
  • HeadingsMap
    • Überschriftenreihenfolge
• Firefox
  • Juicy Studio Accessibility Toolbar
    • Kontrastprüfer
• Web-File-Manager mit HTML-Editor
  • Beispielseite, die Nutzung von Barrierefreiheitsprüfwerkzeug zeigt
• NVDA

ScreenReader NVDA

• alles soll mit grundlegender Bedienung erreichbar sein
  • Sehbehinderung ≠ guter Umgang mit dem Screenreader
• Tastaturbedienung
  • ↑ bzw. ↓ – zur nächsten Zeile (+ Strg – abschnittsweise)
  • H – zur nächsten Überschrift
  • 1 bis 6 – zur nächsten Überschrift dieser Ebene
  • D – nächster Bereich
  • I – nächstes Listenelement
  • Umschalt + … – vorheriges Element
  • Strg – Sprachausgabe unterbrechen
  • weitere Tastaturbefehle unter webaim.org/resources/shortcuts/nvda

Grundlegendes

• Jede Seite benötigt einen Titel.
  • im TUCAL automatisch aus Navigationsangaben $nav[] und Name in $menu[] in der config.inc
  • bei langen Titeln überschreibbar

  • seite(__FILE__,'Barrierefreiheit | URZ');

• Schreiben Sie kurze, klare Sätze.
• Vermeiden oder erklären Sie komplexe Begriffe.
• Zeichnen Sie Sprachwechsel ggf. aus (z. B. <span lang="en">MERGE<span>) → Screenreader kennen bereits viele Begriffe, die anderen Sprachen entlehnt sind (Anhaltspunkt Duden)
• Abkürzungen bei der ersten Verwendung erläutern: im Fließtext oder mit
  <abbr title="Universitätsrechenzentrum">URZ</abbr>, ebenfalls Sprachwechsel berücksichtigen
• Inhalt ggf. durch Grafiken oder Symbole ergänzen, z. B. Kennzeichnung von YouTube-Links

Valider HTML-Code

• aktuelle Version: HTML 5
• typische Fehler im HTML-Code:
  • veraltete Tags und Attribute (siehe Liste des W3C)
  • Tags an der falschen Stelle (z. B. <p><ul><li></li></ul></p>)
  • nicht geschlossene Tags (z. B., weil der Backslash vergessen wurde)
  • überzählige Tags
• Fehler im Browser nicht immer erkennbar
• unterschiedliche Autokorrektur in unterschiedlichen Browsern
• valides HTML = Grundvoraussetzung für korrektes Arbeiten von Zugangs-Hilfsmitteln
  • → W3C Markup Validation Service: https://validator.w3.org/
  • → alternativ Addon „HTML-Validator“ für Firefox (offline)
  • → Accessibility Checker im HTML-Editor CKEditor („Für Autoren”)
• Semantik der Elemente berücksichtigen, nicht falsch verwenden → wichtig für die Aufbereitung, Hinweise finden sich z. B. in der Tag-Liste des W3C unter „Definition and Usage“ in der Elementbeschreibung

Überschriften – korrekte Hierarchie

• <h1> bis <h6> sind möglich
• dient der sinnvollen Strukturierung, nicht nur optisch
• Überschriften sollen nachfolgenden Inhalt wiedergeben
• vgl. wissenschaftliches Dokument (Titel → Kapitel → Abschnitt → Unterabschnitt → …)
• keine <h3> auf eine <h1> folgend
• falls optische Darstellung nicht gefällt → TUCAL gestattet Tricks:

  • <h2 class="h4">Text</h2>

  • <h5 class="h2">Text</h5>

h1 sollte für die Hauptüberschrift verwendet werden. Auch wenn manche Accessibility-Tools mehrere h1-Elemente als Fehler markieren, ist der Einsatz nicht verboten und bei bestimmten Seiten sinnvoll.

Screenreaderlesbare Strukturen

• Eine sinnvolle Strukturierung erhöht die Zugänglichkeit
• <div></div> sind für Screenreader keine strukturierenden Elemente und werden ignoriert
• Fließtexte in <p>…</p> einschließen → So kann von Absatz zu Absatz gesprungen werden.
• optische Anpassungen ggf. per CSS umsetzen (z. B. margin-top)
• Leerzeilen und Zeilenumbrüche werden vorgelesen → Absätze nicht durch <br /> trennen
• <br /> kann bei Adressen oder Gedichten sinnvoll sein
• keine Tabellen zu Formatierungszwecken verwenden (Trennung von Inhalt und Layout)

Linktexte

• Linkzweck eindeutig beschreiben → am Linktext erkennbar
• mehrdeutige Texte wie „mehr“ oder „hier“ vermeiden
• Format und ggf. Größe verlinkter Dateien innerhalb von <a>…</a> angeben, z. B.

  <a href="URZ_ordnung.pdf">Benutzungsordnung des Universitätsrechenzentrums (PDF)</a>

• Ist der Linkzweck aus dem technischen Kontext erkennbar?
  • mögliche Variante für weiterführende Information:

    <h2>Eine Überschrift</h2>
    <p>Ein Anreißertext. <a style="display:block" href="artikel.html">mehr</a></p>

  • ARIA-Attribute für eindeutige Linktexte

    <h2 id="beschreibung" Eine Überschrift</h2>
    <p>Ein Anreißertext.</p> <p><a aria-describedby="beschreibung" href="artikel.html">mehr</a></p>

  • am besten:

    <h2><a href="artikel.html">Eine Überschrift</a></h2>
    <p>Ein Anreißertext.</p>
    <p><a href="artikel.html">[Thema] im Detail</a></p>

Alternativtexte für Bilder

• Alternativtext zu Inhalt bzw. Funktion jeder Grafik (Ausnahme: dekorative Grafiken)
  • möglichst objektiv formulieren
  • im Hinblick aufs Vorlesen: unter 100 Zeichen bleiben
  • unter Umständen Ergänzung eines Bildtypen, z. B. alt="Buchcover"
  • Verweis auf Kontext zulässig
  • falls notwendig, Langbeschreibung (z. B. longdesc) nutzen
• Alternativtext nicht für zusätzliche Informationen gedacht
• Freiheit in Bezug auf Verwendung von Sätzen oder Stichpunkten
• Unterscheidung zwischen funktionalen, identifizierenden, beschreibenden und leeren Alternativtexten

Funktionale Alternativtexte

• für verlinkte oder als Schaltflächen genutzte Grafiken
• Linktexte / Formularbezeichnung von Bedeutung, nicht Beschreibung der Grafik
  z. B. alt="Suchen" statt alt="Lupe"
  
• leerer Alternativtext bei beigestelltem Text, beispielsweise auf einem Button
• bei einem Link vorangestellten Icons ggf. Alternativtext bei Kontext- oder Formatwechsel (z. B. neuer Tab, neues Fenster, PDF, Video, …)
• eindeutige Alternativtexte bei mehrfach erscheinenden Icons mit variierender Bedeutung (Infozeichen mit wechselnden Inhalten)
• bei Schriftgrafiken (Veranstaltungsplakate, Banner, Buchcover, …) beinhaltenden Text im Alternativtext wiedergeben

Identifizierende Alternativtexte

• für Grafiken mit geringer inhaltlicher Bedeutung, textunterstützende Grafiken, z. B. Impressionen für einen Presseartikel zum Stadtfest
• knapper identifizierender Alternativtext, Beschreibung im Fließtext
• bei illustrativen Grafiken zusätzliche Details in Alternativtext aufnehmen
  
• Diagramme im Kontext (z. B. in Tabelle) beschreiben, knapper Alternativtext
• Sonderrolle Kunstwerke: Name und Art des Werkes, Künstlername, Epoche / Stil / Jahrhundert bzw. Art, Titel, Künstlername

Beschreibende Alternativtexte

• wenn keine Beschreibung im Kontext möglich (vorher prüfen)
• möglichst objektive Beschreibung des Inhaltes
• bei Schriftgrafiken (z. B.) Logos sichtbaren Text in alt aufnehmen
• bei manchen Logos lange Beschreibung mit longdesc sinnvoll,
  

  <img longdesc="description.html" src="if-logo.png" alt="Logo der Fakultät für Informatik" />

• Fotos tragen häufig nicht nur Information sondern lösen auch Emotionen aus → im Wirkung Alternativtext bedenken („Graffiti in der Innenstadt-Unterführung“ vs. „Schmiererei an frisch verputzter Wand“)
• bei Fotos mit Personen Namen wichtig, ggf. Situation / Handlung ergänzen

Leere Alternativtexte

• für dekorative, unsichtbare oder redundante Grafiken, beispielsweise die Seitenbilder der TU-Webseite
  
• Alternativtext trägt keinen Inhalt

  <img src="bild.png" alt="" />

• alt="" wird dann vom Screenreader ignoriert

Weitere Hinweise

• Bildunterschriften:
  

  

  <figure>
    <img src="clt2017.jpg" alt=" " aria-labelledby="bildunterschrift-ID" />
    <figcaption id="bildunterschrift-ID" aria-hidden="true"> 
    Tux, Tobias Gall, Ralph Sontag und Ariane Jacobs werben mit der neuen Webseite 
    für die Chemnitzer Linux-Tage 2017.</figcaption>
  </figure>
      

• Textäquivalente für reine Audio- und Videoinhalte anbieten
• Anweisungen klar formulieren (z. B. konkrete Beschreibung eines Eingabefehlers)
• Absicherung von Webformularen: Captchas häufig nicht barrierefrei
  Alternative: → https://www.tu-chemnitz.de/urz/www/secform.html

Formulare I

• typisches Formular enthält Eingabefelder und Knöpfe
  • standardisierte Elemente <input /> und <select /> übermitteln korrekte Semantik an Screenreader
  • interaktive Steuerelemente müssen mit ARIA-Attributen versehen werden, um eine semantische Auszeichnung zu erreichen
  • komplette Tastatur-Bedienbarkeit zu ermöglichen
• Beschriftungen müssen beschreibend sein!
  • Pflichtfelder entsprechend gekennzeichnet
  • Eingabefelder mit eingeschränktem Wertebereich textlich gekennzeichnet
• Hilfen für den Fehlerfall
  • Wenn Abschicken nicht erfolgreich und Formular erneut geladen wird, müssen fehlerhaft ausgefüllte Felder gekennzeichnet werden, ggf. sogar mit Korrekturvorschlag versehen werden.
• Besonderheit Formulare mit juristischer Relevanz
  • Abschicken muss rückgängig gemacht werden können (häufig: Datenkontrollseite)

Formulare II

• Beschriftung für alle Formularelemente, die sich nicht selbst beschreiben:

  <label for="lkz">Loginkennzeichen</label>:
  <input type="text" name="login" id="lkz" />

  Loginkennzeichen:

• Schaltflächen (Buttons) benötigen kein Label:

  <input type="reset" value="Alle Eingaben wieder löschen" />
  <input type="submit" value="Formular abschicken" />

• Besonderheit <button />:

  <button type="submit"><img src="schmuckgrafik.png" alt="" />Jetzt Abschicken!</button>

  Jetzt Abschicken!

Formulare III

• Vorbelegung von Eingabefeldern – zum Platz sparen oder zum vermeintlich Hilfe geben – nicht sinnvoll!
  value-Wert muss erst manuell gelöscht werden:

  <input type="text" name="suchwort" value="Suchen nach ..." />
  <button type="submit"><img src="lupe.png" alt="" /></button>

  
   

  Auch placeholder ist nach Eingabe weg…

  <input type="text" name="suchwort" placeholder="Suchen nach ..." />
  <button type="submit"><img src="lupe.png" alt="Suche beginnen!" /></button>

  

  Verstecktes label-Element möglich:

  <label style="position:absolute; left:-10000px; top:auto" for="s">Suchwort</label>
  <input type="text" name="suchwort" id="s" />
  <button type="submit" title="Suche beginnen!"><img src="lupe.png" alt="" /></button>

  Suchwort

  Andere Verstecken-Variante und Verwendung von ARIA möglich:

  <label style="position:absolute; clip:rect(0 0 0 0)" for="s">Suchwort</label>
  <input type="text" name="suchwort" id="s" />
  <button type="submit" aria-label="Suche beginnen!"><img src="lupe.png" alt="" />

  Suchwort

• tabindex möglich, aber eigtl. nie notwendig

Formulare IV

• fieldset nicht aus Gestaltungsgründen einsetzen! Die legend-Angabe wird vom Screenreader vor dem Feldname mit vorgelesen.

<fieldset><legend>Namensangaben</legend><label …>[…]<input …></fieldset>
<fieldset><legend>Kontaktdaten</legend><label …>[…]<input …></fieldset>
<input type="submit" value="Daten senden" />

Formulare V

• Beispielformular mit Fehlerüberprüfung
  • Formular aufrufen
  • Quelltext anschauen
• Vor der Verwendung von verwirrenden und extern gehosteten Captchas gründlich Alternativen prüfen!
  • URZ-Entwicklung: Formularschutz
  • Auch Captchas müssen die heute genannten Anforderungen erfüllen!

Danke

Danke für Ihre Aufmerksamkeit!

Bei Fragen und für Anregungen kontaktieren Sie uns bitte:
<webmaster@tu-chemnitz.de>