Barrierefreie Webseiten
Eine Einführung

Es geht nicht um “Behinderte”! (Grafik: Microsoft)

Es geht um Webseiten für uns alle!
Websites müssen trotz möglicher dauerhafter
oder vorübergehender Einschränkungen des
Besuchers verständlich und benutzbar sein!
Grafik: Microsoft

Anforderungen an barrierefreie Webseiten
Web Content Accessibility Guidelines (WCAG)
der Web Accessibility Initiative (WAI)
des World Wide Web Consortiums (W3C)
https://www.w3.org/WAI/standards-guidelines/
wcag/glance/

Anforderungen an barrierefreie Webseiten
Prinzip 1: Wahrnehmbarkeit
Informationen und Bestandteile der Benutzerschnittstelle müssen den Benutzern so
präsentiert werden, dass diese sie wahrnehmen können.
Prinzip 2: Bedienbarkeit
Bestandteile der Benutzerschnittstelle und Navigation müssen bedienbar sein.
Prinzip 3: Verständlichkeit
Informationen und Bedienung der Benutzerschnittstelle müssen verständlich sein.
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.

Was können wir dafür tun?
● Barrierefreies Design
● Barrierefreie Inhalte
● Semantisches HTML
● Accessible Rich Internet Applications (ARIA)

Barrierefreies Design

Barrierefreies Design: Farben
● Unterscheidbarkeit durch Kontraste
○ gegenüber benachbarten Farben
○ gegenüber dem Hintergrund
○ nicht schätzen, messen!
○ WCAG-Empfehlung für Text:
4.5 : 1, oder 3 : 1 bei großen / fetten
Schriften!
● Farbe darf nie alleinstehendes Merkmal sein!
○ Beispiel: farbige Links zusätzlich fett machen oder unterstreichen
○ Ampel-Darstellungen oder Diagramme mit Texthinweisen versehen
Kontrast 8.4 : 1 Kontrast 2.5 : 1

Barrierefreies Design: Typografie
● Lesbare / vertraute Schriftarten verwenden
● Schriftgröße, z.B. >= 16px
● Zeilenabstand, z.B. 1.5 (abhängig von Schriftgröße)
● Absatzabstände
● Zeilenlänge begrenzen, z.B. 45 - 75 Zeichen
● Schriften skalierbar machen, z.B. bis 200 %, ohne sonstige Inhalte
-> relative Maßeinheiten, z.B. rem
-> aber nicht für Alles!

Beispiel: Typografie
Hallo. Ich bin ein kleiner Blindtext. Und zwar schon so lange ich denken kann. Es war nicht leicht zu verstehen, was es bedeutet, ein blinder Text zu sein: Man ergibt keinen Sinn. Wirklich
keinen Sinn. Man wird zusammenhangslos eingeschoben und rumgedreht – und oftmals gar nicht erst gelesen. Aber bin ich allein deshalb ein schlechterer Text als andere? Na gut, ich
werde nie in den Bestsellerlisten stehen. Aber andere Texte schaffen das auch nicht. Und darum stört es mich nicht besonders, blind zu sein. Und sollten Sie diese Zeilen noch immer
lesen, so habe ich als kleiner Blindtext etwas geschafft, wovon all die richtigen und wichtigen Texte meist nur träumen.
Hallo. Ich bin ein kleiner Blindtext. Und zwar schon so lange ich denken
kann. Es war nicht leicht zu verstehen, was es bedeutet, ein blinder Text zu
sein: Man ergibt keinen Sinn. Wirklich keinen Sinn. Man wird
zusammenhangslos eingeschoben und rumgedreht – und oftmals gar nicht
erst gelesen. Aber bin ich allein deshalb ein schlechterer Text als andere?
Na gut, ich werde nie in den Bestsellerlisten stehen. Aber andere Texte
schaffen das auch nicht. Und darum stört es mich nicht besonders, blind zu
sein. Und sollten Sie diese Zeilen noch immer lesen, so habe ich als kleiner
Blindtext etwas geschafft, wovon all die richtigen und wichtigen Texte meist
nur träumen.

Barrierefreies Design: Layout / Hierarchie
● Klare Strukturen (Header, Footer, Sidebars, …)
● Hierarchie durch z.B. Schriftgrößen, Einrückungen
● Responsives Design
● Whitespace
● Konsistenz
● Lesefluss beachten

Barrierefreies Design: Animationen
● Sparsam / subtil verwenden
● Abschaltbar machen
○ Beispiel: prefers-reduced-motion beachten!
● Vorsicht mit animierten GIFs
● Blitzen / Blinkeffekte vermeiden

Barrierefreie Inhalte

Barrierefreie Inhalte: Texte / Sprache
● Sprache muss identifizierbar sein (lang-Attribut)
● Texte müssen verständlich sein
● Alternative Fassung, z.B. Vorlesefunktion oder vereinfachte Sprache
Beispiel: die sogenannte “Leichte Sprache”
● kurze Sätze
● einfache Worte
● konsistente Begriffe
● keine Passiv-Formulierungen
siehe dazu Deutsche Gesellschaft für Leichte Sprache https://dg-ls.de/regelwerk/

Beispiel: Leichte Sprache
Ballistische Experimente mit
kristallinem H₂O auf dem
Areal der pädagogischen
Institutionen unterliegen
striktester Prohibition!
Das Werfen von
Schneebällen auf dem
Schulhof ist verboten!
Quelle: DGLS

Barrierefreie Inhalte: Bilder / Medien / Dokumente
● Beschreibungen für Bildinhalte (alt-Texte)
● Captions (Untertitel)
● Transkriptionen für Audio-/Video-Dateien
● Allgemein verfügbare Formate (jpg/png/webp, pdf, mp3/mp4)
● Barrierefreie PDF
● Keine selbststartenden Medien (Audio/Video)
● Icons: vertraute Bildsprache (z.B. Home, Menü, Download,...)
+ Text-Hinweis, z.B. title-Attribut (veraltet)

Barrierefreie Inhalte: Formulare
● Labels
● Feldbeschreibungen
● Felder gruppieren
● Bedienbarkeit per Tastatur
● Sinnvolle Feldtypen, z.B. select vs. radios
● Placeholder nie allein einsetzen!
● Keine rein grafischen Captchas!
● Aussagekräftige Validierungsmeldungen

Barrierefreie Inhalte: Navigation
● Bedienbarkeit per Tastatur (Tab, Enter, ESC)
● Navigationselemente klar erkennbar machen
● Skip Links anbieten
● Sichtbarer Focus
● Reihenfolge nicht per CSS verändern
● tabindex-Attribut nach Möglichkeit vermeiden
● Alternativen (Suchfunktion, Inhaltsverzeichnis)
● Klickbare Bereiche groß genug machen

Semantisches HTML

Semantisches HTML: Was ist das?
● Semantik = Lehre von der Bedeutung
● Semantisches HTML-Tag: gibt Auskunft zur Bedeutung seines Inhalts
● Es gibt ca. 110 HTML-Tags
● Davon ca. 25 neue Tags in HTML5
● Zwei HTML-Tags sind nicht semantisch: <div> und <span>
Neu in HTML5 sind z.B. die Sectioning Elemente:
<article>, <aside>, <footer>, <header>, <main>, <nav>, <section>

Seitenstruktur: HTML4 vs. HTML5
Quelle:
Jamon Dixon
Medium

Seitenstruktur: Elemente
● <header>
Seitenkopf, eventuell wiederholt auf allen Seiten
● <nav>
Navigation, typischerweise eine Liste mit Links
● <main>
Hauptinhalt der Seite
● <aside>
Zusätzliche Informationen zum Inhalt
● <footer>
Seitenfuß, eventuell wiederholt auf allen Seiten
● <article>
Strukturierter Content, der auch allein stehen könnte.
● <section>
Untergliederung eines längeren Content-Bereichs

Seitenstruktur: Empfehlungen
● Elemente beziehen sich immer auf das übergeordnete Strukturelement (also
nicht das Parent-Element), oder den <body>
● Elemente können verschachtelt werden, z.B. können <article> Elemente
einen eigenen <header> oder <footer> bekommen.
● Das <main> Element sollte nur einmal verwendet werden!
● Kein <header> oder <footer> in <header> und <footer>!
● Ein <header> nur mit einer Überschrift ist überflüssig!
● Bei wiederholt eingesetzten Elementen empfiehlt sich eine Kennzeichnung
zur Unterscheidung, z.B. Beginn mit einer Überschrift und ARIA-Attribut

Besonderheit: Überschriften <h1> - <h6>
● Bilden die Inhaltsstruktur der Seite (Document Outline)
● Ermöglichen schnellere Navigation
Regeln:
● Hierarchie beachten!
○ Starten mit <h1>
○ Keine Lücken lassen!
● Nicht wegen visueller Darstellung wählen!
Also nicht: Schrift soll groß sein, deshalb <h2>
Durch diese Regeln erweisen sich <h4> - <h6> meistens als überflüssig.

Beispiel: Überschriften auf drupal.org
● beginnt nicht mit <h1>
● überspringt Levels

ARIA
Accessible Rich Internet Applications

Exkurs: Accessibility Object Tree
Quelle:
https://wcig.gitub.io

Auszüge aus dem Accessibility Object Tree
<ul aria-label="Obstsorten">
<li>Apfel</li>
<li>Birne</li>
<li>Pfirsich</li>
</ul>
Statt aria-label wäre ggf. auch title geeignet!

Auszüge aus dem Accessibility Object Tree

ARIA Rollen: “role” Attribut
● Ergänzung, um HTML-Tags semantisch(er) zu machen
● Inhaltlich geeignetes “role” Attribut, z.B. <div role=”complementary”>
Was ist zu beachten:
● Semantische HTML-Tags haben bereits implizite Rollen,
diese sollten nicht dupliziert werden!
Beispiel: <ul> => “list”, <nav> => ”navigation”
Also nicht: <nav role=”navigation”>
● Die implizite Rolle eines HTML-Tags sollte nur in Ausnahmefällen
überschrieben werden!
Also nicht: <nav role=”complementary”>
Ausnahme z.B. <a href=”...” role=”tab”>

ARIA Attribute: Eigenschaft oder Zustand von Elementen
<div role="dialog" aria-labelledby="dialogheader">
<h2 id="dialogheader">Wählen Sie eine Datei</h2>
.… Dialog Inhalte
<button aria-label="schließen" aria-describedby="descriptionClose" onclick="myDialog.close()">X</button>
….
<div id="descriptionClose">
Beim Schließen dieses Fensters werden eingegebene Daten verworfen.
Sie werden zur Hauptseite zurückgeleitet.
</div>
</div>

Regel: Semantisches HTML bevorzugen!
Also nicht:
<div role=”checkbox” aria-checked=”true” onclick=”…”>
⛝
</div>
sondern:
<input type=”checkbox” />
ARIA-Rollen und -Attribute einsetzen, wenn semantisches HTML nicht verfügbar ist oder
ausreicht, z.B. bei Custom Elements (Web Components) oder Formularen! Ebenso bei
Dialogen, Modals, Slidern, Tabs, Ajax-Inhalten u.ä.

Accessibility: Links
Web Content Accessibility Guidelines des W3C:
https://www.w3.org/WAI/standards-guidelines/wcag/
Web Accessibility in Mind:
https://webaim.org/
Mozilla Developer Network (MDN):
https://developer.mozilla.org/en-US/docs/Web/Accessibility
The A11Y Project:
https://www.a11yproject.com/

Accessibility: Tools
● Developer Tools des Browsers
● Browser-Erweiterungen, z.B. Web Developer, Axe, WAVE
● Screenreader, z.B. NVDA (Windows), VoiceOver (Mac), MS Edge Browser
● Online-Dienste zur Überprüfung
Sammlungen:
https://www.w3.org/WAI/ER/tools/
https://webaim.org/articles/evaluationguide/