Zentrale Anlaufstelle Barrierefrei

Alternativer Text

• Fehlender alternativer Bildtext
  
  Was bedeutet das?
  Bildalternativer Text ist nicht vorhanden. Das Bild wird nicht beschrieben.
  Warum es wichtig ist:
  Jedes Bild muss ein alt-Attribut haben. Ohne Alternativtext steht der Inhalt eines Bildes den Benutzer*innen von Screenreadern nicht zur Verfügung, das Bild ist nicht vorhanden.
  Wie man es beheben kann:
  Fügen Sie dem Bild ein alt-Attribut hinzu. Der Attributwert sollte den Inhalt und die Funktion des Bildes genau und prägnant darstellen. Wenn der Inhalt des Bildes im Kontext oder in der Umgebung des Bildes vermittelt wird oder wenn das Bild keinen Inhalt vermittelt oder keine Funktion hat, sollte es mit leerem/nicht vorhandenem Alternativtext (alt="") versehen werden.
  HTML-Code:
  statt: <img src="bild.jpg"></img>
  korrekt: <img src="bild.jpg" alt="Zwei Studierende an einem Schreibtisch"></img>
  
  Normen und Richtlinien
  1.1.1 Nicht-Text-Inhalt (Ebene A)
  • 1.1.1a Alternativtexte für Bedienelemente
  • 1.1.1b Alternativtexte für Grafiken und Objekte
  • 1.1.1c Leere alt-Attribute für Layoutgrafiken
  • 1.1.1d Alternativen für CAPTCHAs
     
• redundanter Alternativtext
  
  Was bedeutet das?
  Der alternative Text für ein Bild ist derselbe wie der benachbarte oder angrenzende Text.
  Warum es wichtig ist:
  Alternativer Text, der mit nahegelegenem oder benachbartem Text übereinstimmt, wird den Bildschirmlesern mehrfach präsentiert.
  Wie man es beheben kann:
  Ändern Sie entweder den Alternativtext oder den angrenzenden Text, um die Redundanz zu beseitigen. In den meisten Fällen können Sie das Bild mit leerem/nicht-alternativem Text (alt="") versehen, da der Inhalt des Bildes bereits im Kontext durch Text bereitgestellt wird. Verlinkte Bilder können oft mit dem angrenzenden Text zu einem Link kombiniert werden. In diesem Fall kann das Bild mit null/leerem Alternativtext (alt="") versehen werden.

ZAB Video-Anleitung (YouTube)

Audio / Video

• Alternativen für Audiodateien und stumme Videos
  
  Was bedeutet das?

  Audio- und Videodateien schließen Menschen aus, die diese nicht hören können.
  Warum es wichtig ist:
  Audiodateien und stumme Videodateien, die Informationen vermitteln, müssen mit gleichwertigen Medienalternativen versehen werden - es sei denn, es handelt sich bei Ihnen bereits um Medienalternativen für Text.
  Wie man es beheben kann:
  Audiodateien sind für hörbehinderte Nutzer*innen nicht oder nur eingeschränkt zugänglich, deshalb brauchen sie eine Transkription. Stumme Videodateien (etwa eine Film- oder Animationsequenz, die zeigt, wie ein Gerät zusammengesetzt wird) sind für blinde und sehbehinderte Nutzer*innen nicht verfügbar. Sie brauchen deshalb eine vollwertige Medienalternative (Text oder Audiodatei).
  Normen und Richtlinien:
  1.2.1a Alternativen für Audiodateien und stumme Videos
   

• Aufgezeichnete Videos mit Untertiteln
  
  Was bedeutet das?
  Wenn die Tonspur eines aufgezeichneten Videos Informationen enthält, müssen Untertitel als Alternative bereitgestellt werden.
  Warum es wichtig ist:
  Filme sind in der Regel ohne den Ton nicht zu verstehen.
  Wie man es beheben kann:
  Für Menschen mit Hörbehinderung muss der Inhalt der Tonspur durch Untertitel bereitgestellt werden. Untertitel können auch für andere Nutzer*innen hilfreich sein, zum Beispiel für Personen, die mit der Sprache des Films nicht vertraut sind.
  Normen und Richtlinien:
  1.2.1a Alternativen für Audiodateien und stumme Videos
   

• Audiodeskription oder Volltext-Alternative für Videos
  
  Was bedeutet das?
  Für informationstragende visuelle Videoinhalte muss eine Audiodeskription oder Volltext-Alternative bereitgestellt werden.
  Warum es wichtig ist:
  Die Handlung von Videos kann oft auch ohne Bild recht gut verfolgt werden. Den Sprecher einer Nachrichtensendung muss man zum Beispiel nicht sehen, um zu verstehen, worum es geht. Dagegen enthalten Spielfilme und Reportagen oft Passagen, in denen wenig gesprochen wird und Inhalte über das Bild vermittelt werden.
  Wie man es beheben kann
  Damit ein blinder Zuschauer den Film verfolgen kann, müssen ihm solche Passagen beschrieben werden. Hierfür wird das Verfahren der Audiodeskription eingesetzt.
  Normen und Richtlinien:
  1.2.3a Audiodeskription oder Volltext-Alternative für Videos
  1.2.4a Videos (live) mit Untertiteln
  1.2.5a Audiodeskription für Videos
   

• Ton abschaltbar
  
  Automatisch abgespielte Töne, die nicht nach drei Sekunden enden, sollen abschaltbar sein.

  Automatisch abgespielte Töne stören Nutzer*innen, die sich auf einer Seite mittels Sprachausgabe orientieren.

  Falls ein Tonelement nach dem Laden einer Seite automatisch startet, ist es deshalb wichtig, dass es sich über einen am Seitenbeginn befindlichen barrierefreien Mechanismus abschalten, anhalten oder herunter regeln lässt.
  
  1.4.2a Ton abschaltbar

Weitere Informationen unter: Videos barrierefrei gestalten

Ausklappfunktion

<details> und <summary>

Ausklappbare Bereiche ähnlich wie die Ziehharmonika-Effekte (im Roxen Groups mit Accordeon) mit jQuery sind mit den HTML5-Befehlen <details> und <summary> in den Befehlen von HTML enthalten. Es gibt einen Unterschied zum Harmonika-Accordeon-Effekt: es können mehrere Bereiche geöffnet sein.

Aber der Reihe nach. Schauen wir uns den Einsatz in HTML an. Es werden beide Befehle benötigt und die Anweisung <details> umschließt den kompletten Bereich. In diesem Bereich kommt als erstes die Anweisung <summary> - dieser ist immer sichtbar und wird automatisch mit einem Pfeil davor versehen.

Jeder weitere Text und HTML-Code wird erst sichtbar, wenn man auf den Text klickt.

Hier die html5-Alternative:

<details><summary>Überschrift</summary> Ausklappinhalte .... </details>
 

https://developer.mozilla.org/de/docs/Web/HTML/Element/summary

Funktioniert in den gängigsten Browsern auf Mac und PC und ist Touch kompatibel. Auf dem Edge ist alles automatisch ausgeklappt. Wichtig für Sehbehinderte aber auch für andere Nutzer*innen ist der erläuternde Satz. Einzig auf Firefox wird der Pfeil nicht angezeigt.

In der Vorlage eingebaut: https://www.uni-bielefeld.de/einrichtungen/zab/servicedesk/vorlagen/web/index.xml

Beispiel:

Weitere Infos: https://www.html-seminar.de/html-befehle-details-summary.htm

Bedienbar

• (die vier Prinzipien der WCAG 2.0 stellen die Basis der Richtlinien dar)
  
  Bestandteile der Benutzerschnittstelle und Navigation müssen bedienbar sein.
   
• 2.1 Sorgen Sie dafür, dass alle Funktionalitäten von der Tastatur aus verfügbar sind.
• 2.2 Geben Sie den Benutzer*innen ausreichend Zeit, Inhalte zu lesen und zu benutzen.
• 2.3 Gestalten Sie Inhalte nicht auf Arten, von denen bekannt ist, dass sie zu Anfällen führen.
• 2.4 Stellen Sie Mittel zur Verfügung, um Benutzer*innen dabei zu unterstützen zu navigieren, Inhalte zu finden und zu bestimmen, wo sie sich befinden.

Beeinträchtigungen

Wie erleben Menschen mit Beeinträchtigungen eine Webseite?

Auf dieser Seite erläutern wir auf Basis des Web Disability Simulators, wie Benutzer mit Beeinträchtigungen eine Webseite erleben können.

Themen:

• Totale Farbenblindheit
• Gelb-blaue Farbenblindheit
• Rot-Grün-Farbenblindheit
• Weitsichtigkeit
• Tunnelblick
• Sonnenschein
• Parkinson
• Legasthenie
• Kleiner Wortschatz
• Konzentration

Bewegte Inhalte

• Bewegte, blinkende oder automatisch aktualisierende Inhalte abschaltbar
  
  Was bedeutet das?
  Alles was sich bewegt, blinkt oder scrollt, sollte vermieden werden.
  Warum es wichtig ist:
  Sich bewegende Inhalte sind für Menschen oft nur schwer wahrzunehmen. Es verschleiert Inhalte und führt zu einer optischen Verschleierung und ist für viele Menschen nicht zu benutzen.
  Wie man es beheben kann:
  Die Schaltfläche oder die Anweisung, mit der man die Bewegung anhalten kann, muss eindeutig sein und deutlich sichtbar am Seitenbeginn oder im direkten Kontext des bewegten Inhalts platziert sein. Alle Inhalte müssen nach dem Anhalten der Bewegung verfügbar bleiben. Es spielt keine Rolle, ob es sich bei den blinkenden oder sich bewegenden Inhalten um Werbung oder um redaktionelle Inhalte handelt.
  Normen und Richtlinien:
  2.2.2a Bewegte Inhalte abschaltbar
  2.3.1a Verzicht auf Flackern

BITV-Test

Der BITV-Test ist ein Verfahren für die umfassende und zuverlässige Prüfung der Barrierefreiheit von Websites und  Webanwendungen.

• Grundlage für den BITV-Test ist die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) vom 21. Mai 2019. Der Test bezieht also die neuen Anforderungen der WCAG 2.1 mit ein.
• Der BITV-Test umfasst insgesamt 60 Prüfschritte. Zu jedem Prüfschritt gibt es ausführliche Erläuterungen, die sagen, was genau geprüft wird, warum das wichtig ist und wie in der Prüfung vorzugehen ist. Das Prüfverfahren ist im Detail offengelegt.

Die einzelnen Prüfschritte und Erläuterungen finden sich in dieser Übersicht immer unter den Punkten 'Normen und Richtlinien'.

Quelle: https://www.bitvtest.de/bitv_test.html

Buttons

• Leere Schaltfläche
  
  Was bedeutet das?
  Eine Schaltfläche ist leer oder hat keinen Werttext.
  Warum es wichtig ist:
  Wenn zu einer Schaltfläche navigiert wird, muss den Benutzer*innen von Screenreadern ein beschreibender Text präsentiert werden, um die Funktion der Schaltfläche anzuzeigen.
  Wie man es beheben kann:
  Platzieren Sie den Textinhalt innerhalb des <button>-Elements oder geben Sie dem <input>-Element ein Wertattribut.
  Der Algorithmus:
  Ein <button> Element ist vorhanden, das keinen Textinhalt (oder alternativen Text) enthält, oder ein <input type="submit">, <input type="button"> oder <input type="reset"> hat ein leeres oder fehlendes Wertattribut.
  Normen und Richtlinien:
  2.4.4a Aussagekräftige Linktexte

Diagramme und Infografiken

• Nicht barrierefreie Schaubilder
  
  Was bedeutet das?
  Oft illustrieren Diagramme und Infografiken Daten. Ohne adäquate Textalternativen sind diese jedoch nicht barrierefrei.
  Warum es wichtig ist:
  Screenreader können Daten und Fakten in Grafiken nicht vorlesen. Die Inhalte werden damit ausgeblendet und übergangen.
  Wie man es beheben kann:
  Einen allgemeingültigen Weg zur Handhabung komplexer Darstellungen gibt es nicht. Doch sollte die verbesserte Nutzerfreundlichkeit durch die Schaubilder nicht zugunsten der absoluten Barrierefreiheit entfernt werden. Also sollte beides gelingen und ein möglichst gleichberechtigter Zugang erreicht werden. Eine Seite, die auflistet, auf was zu achten ist, findet man hier:
  https://www.publicgarden.de/blog/grafiken-barrierefrei-ausgezeichnet
   

  Für Diagramme ist entscheidend, dass alle Bestandteile deutlich zu erkennen sind, das gilt auch für die Begleittexte, die zumeist auch als Pixelgrafik eingebunden werden. Bei Wahlergebnissen stehen z.B. die Parteinamen und Prozentangaben oft im Tortendiagramm. Das ist suboptimal, da die Tortenstücke meist in den Parteifarben gestaltet sind und oft zu geringen Kontrast bieten.
  Wenn Farbe als einziges Unterscheidungsmerkmal verwendet wird, können Farbfehlsichtige einzelne Diagramm-Bestandteile nicht mehr unterscheiden. Hier ist bei der Farbumsetzung auf gute Kontrastwerte zu achten, dafür gibt es den Color Contrast Analyser, https://www.uni-bielefeld.de/einrichtungen/zab/digitale-barrierefreiheit/barrierefreie-webseiten/barrieren-a-z/#comp_00005f56e5a6_0000002f5f_7f7d

  In jedem Fall sollten die im Diagramm dargestellten Ergebnisse auch als normale HTML-Tabelle ausgegeben werden, damit auch Blinde die Ergebnisse erkennen können. Eine tabellarische Alternative sollte angeboten werden. Es ist nicht sinnvoll, ausführliche Ergebnisse im Alternativ- oder Titeltext unterzubringen, weil diese dann viel zu lang und unübersichtlich werden. Also Alternativtexte werden für Kurzbeschreibungen eingesetzt, Tabellen für Daten.
  Aber auch die Datentabellen müssen barrierefrei sein. Wie man das anstellt und auf was zu achten ist, ist auf unseren Seiten beschrieben: https://www.uni-bielefeld.de/einrichtungen/zab/digitale-barrierefreiheit/barrierefreie-webseiten/barrieren-a-z/#comp_00005f850a25_0000002e09_5ced

  Also je komplexer eine Abbildung ist, desto länger müsste der Alternativtext werden, so dass nicht immer ist der Alternativtext eine gute Lösung ist. Bei Diagrammen landet man schon mal bei mehreren tausend Zeichen.
  
  Wie kann man mit Diagrammen redaktionell und durchaus auch konzeptionell umgehen? Denn nur den Titel eines Diagramms in den Alternativtext zu schreiben, ist in der Regel nicht ausreichend. Auch stellt sich die Frage, wie man etwa bei Alternativtexten mit Screenshots eines Presseartikels umgeht, z.B. bei Broschüren, Jahresberichten oder Projektdokumentationen. Da sollte immer eine Transkription des Inhalts angeboten werden, damit Screenreader den Text vorlesen.

  Unter folgendem Link wird der Umgang mit unterschiedlichen Grafiken ganz gut aufbereitet (insb. der Punkt 'Informationsgrafiken': https://www.einfach-fuer-alle.de/artikel/bilder-grafiken-barrierefrei/ 
  
  Zusammengefasst ist zu sagen, Grafiken mit wenig Inhalt können mit dem ALT-Text für Grafiken gut beschrieben werden, Grafiken mit viel Text brauchen eine Transkription des Textes. Und Diagramme, Schaubilder mit Daten, Zahlen und Fakten sind in alternativen Tabellen umzusetzen.

Eingeblendete Inhalte

• Eingeblendete Inhalte bedienbar
  
  Was bedeutet das?

  Zusätzliche Inhalte, die angezeigt werden, wenn Elemente den Zeiger- oder Tastaturfokus erhalten, z.B. benutzerdefinierte Tooltips oder Ausklapp-Menüs oder, sollten drei Anforderungen erfüllen:

  • Wenn zusätzliche Inhalte durch Darüberfahren mit dem Zeiger erscheinen, können Benutzer*innen den Zeiger über diesen Inhalt bewegen, ohne dass er verschwindet.

  • Es gibt die Möglichkeit einen eingeblendeten Inhalt zu schließen, ohne den Fokus zu verschieben (z.B. durch Drücken der Escape-Taste oder durch Aktivieren des Elements, dessen Fokussierung den Inhalt einblendet).

  • Der Inhalt schließt nicht selbsttätig nach einer gewissen Zeitspanne.

    Hinweis: Die Anforderung gilt nicht für eingeblendete Inhalte, deren Verhalten durch den Nutzer-Agenten bestimmt wird (etwa native title-Attribute).

Warum es wichtig ist: Für sehbehinderte Nutzer*innen, die mit starker Zoomvergrößerung arbeiten, sind zusätzliche Inhalte, die bei Zeiger- oder Tastatur-Fokussierung eingeblendet werden, aus mehreren Gründen problematisch:

• Inhalte sind wegen des starken Zoomfaktors oft nur teilweise sichtbar. Nutzer*innen müssen in der Lage sein, den Zeiger von dem auslösenden Element über den eingeblendeten Inhalt zu bewegen (was meist den sichtbaren Ausschnitt verschiebt), ohne dass der eingeblendete Inhalt schließt.
• Eingeblendete Inhalte verdecken häufig andere Inhalte. Nutzer*innen müssen in der Lage sein, den eingeblendeten Inhalt wieder zu schließen, ohne den Fokus zu bewegen (was passieren würde, wenn etwa nach einem Schließen-Element gesucht werden müsste). Die Escape-Taste oder ein Aktivieren des auslösenden Elements, das zur Zeit den Fokus hat, sollte den eingeblendeten Inhalt schließen.
• Sehbehinderte Nutzer*innen brauchen ggf. mehr Zeit, Inhalte zu lesen. Eingeblendete Inhalte sollten deshalb solange zur Verfügung stehen, bis sie vom*von der Nutzer*in geschlossen werden (etwa über Weiter-Tabben, Wegbewegen des Zeigers von auslösenden Element und eingeblendetem Inhalt, oder explizites Schließen über die Tastatur).

Wie man es beheben kann:
Benutzen Sie nicht JavaScript Funktionalitäten, die oben genannte Fehler erzeugen.
Normen und Richtlinien:
1.4.13a Eingeblendete Inhalte bedienbar

Farbe

• Ohne Farben nutzbar

  Über Farben vermittelte Informationen sollen auch ohne Wahrnehmung der Farbe verfügbar sein, also zusätzlich durch andere Mittel (etwa Fettung oder Einrückung) hervorgehoben sein.
  
  Ausschließlich über Farben vermittelte Informationen sind für blinde Benutzer*innen nicht zugänglich. Auch farbfehlsichtige Benutzer*innen, die unter Umständen mit eigenen Farbschemata arbeiten, können Farben nicht oder nur eingeschränkt identifizieren und unterscheiden.
  Normen und Richtlinien:
  1.4.1a Ohne Farben nutzbar

  
   

Fehlerseite

• Eine nicht barrierefreie Seite
  
  Eine Seite, auf der Barrieren ganz bewusst gesetzt wurden. Das ermöglicht bei einem Durchgang mit Screenreadern Barrieren sozusagen hörbar zu machen. Die Seite ist sozusagen ein schlechtes Beispiel für eine Seite mit vielen Barrieren. An ihr kann demonstriert werden, welche Umsetzungen zu vermeiden sind.
  
  https://uni-bielefeld.de/einrichtungen/zab/digitale-barrierefreiheit/fehlerseite.xml

Formulare

• Barrierefreie Vorlage
  
  Formulare barrierefrei zu gestalten, ist nicht einfach. Dafür haben wir eine barrierefreie Vorlage erstellt, die ganz oder in ihren einzelnen Feldtypen kopiert werden kann:

  https://www.uni-bielefeld.de/einrichtungen/zab/servicedesk/vorlagen/web/index.xml
   

• Fehlende Form Labels
  Was bedeutet das?
  Ein Formularsteuerelement hat kein entsprechendes Label.
  Warum es wichtig ist:
  Wenn ein Formularsteuerelement nicht über eine ordnungsgemäß zugeordnete Textbeschriftung verfügt, wird die Funktion oder der Zweck dieses Formularsteuerelements den Benutzer*innen von Bildschirmlesegeräten möglicherweise nicht angezeigt. Formularbeschriftungen bieten auch sichtbare Beschreibungen und größere anklickbare Ziele für Formularsteuerelemente.
  Wie wird es behoben?
  Wenn ein Text-Label für ein Formularsteuerelement sichtbar ist, verwenden Sie das Element <label>, um es mit dem entsprechenden Formularsteuerelement zu verknüpfen. Wenn es kein sichtbares Label gibt, stellen Sie entweder ein zugeordnetes Label bereit, fügen Sie dem Formularsteuerelement ein beschreibendes Titelattribut hinzu oder verweisen Sie mit aria-labelledby auf das/die Label. Labels sind nicht erforderlich für Bild-, Submit-, Reset-, Button- oder versteckte Formularsteuerelemente.
  Der Algorithmus:
  Ein <input> (außer Bildtypen, Submit, Reset, Button oder versteckt), <select> oder <textarea> hat keine korrekt zugeordnete Beschriftung. Eine ordnungsgemäß zugeordnete Beschriftung ist:
   
  - ein <label>-Element mit einem for-Attributwert, der gleich der Id eines eindeutigen Formularsteuerelements ist
  
  - ein <label>-Element, das das Formularsteuerelement umgibt, keine anderen Formularsteuerelemente umgibt und kein anderes Element mit seinem for-Attribut referenziert
  
  - ein nicht leeres Titelattribut oder
  
  - eine nicht leere Arie, die durch ein Attribut gekennzeichnet ist.
  
  Html-Code:
  Für die Bezeichnung von Steuerelementen mit Namen gibt es unterschiedliche Techniken. Während Schaltflächen ihre Beschriftung quasi mit sich bringen (sollten), wird für Eingabefelder, Auswahllisten, Radio-Buttons oder Checkboxen ein Text vor oder nach dem Steuerelement platziert. Im Allgemeinen muss dieser Text mit LABEL ausgezeichnet werden und mit dem for-Attribut mit dem Steuerelement verknüpft werden. Dabei muss der Wert des for-Attributs mit dem Wert für id des Steuerelements identisch sein:
  <p> <label for="vorname">Vorname:</label> <input type="text" name="vorname" id="vorname" /> </p>

  Die Steuerelemente, die eine zusätzliche Beschriftung benötigen, sind:

  <input type="text" /> <input type="checkbox" /> <input type="radio" /> <input type="file" /> <input type="password" /> <textarea> </textarea> <select> </select>
  
  Schaltflächen benötigen keine zusätzliche Beschriftung, denn Schaltflächen besitzen einen Namen bzw. textlichen Inhalt. Dabei geht es nicht um das name-Attribut, sondern um den Namen, wie er im Glossar der Web Content Accessibility Guidelines (WCAG) 2.0 definiert ist; es geht um die Bezeichnung eines Steuerelements, die von Software genutzt wird, um das Steuerelement für Menschen zu identifizieren.

  Für einfache Schaltflächen wird der Name mit dem value-Attribut festgelegt:

  <p> <input type="submit" value="Jetzt abschicken" /> </p>
  
  Quellen:
  Mehr zu Labels: https://www.barrierefreies-webdesign.de/knowhow/formulare/label.html
  
  Normen und Richtlinien:
  3.3.2a Beschriftungen von Formularelementen vorhanden
   
• Fehlendes Fieldset
  
  Was bedeutet das?
  Eine Gruppe von Kontrollkästchen oder Auswahlknöpfen ist nicht in einem Fieldset eingeschlossen.
  Warum es wichtig ist:
  Ein Fieldset bietet eine visuelle und strukturelle Gruppierung von verwandten Formularelementen. Sie ist typischerweise für Gruppen von Kontrollkästchen oder Auswahlknöpfen erforderlich, bei denen eine Beschreibung auf höherer Ebene (Legende genannt) notwendig ist, um die Funktion der Kontrollkästchen oder Auswahlknöpfe zu verstehen. Die Beschreibung wird von einem Screenreader nur dann erkannt, wenn sie in einer Fieldset-Legende bereitgestellt wird.
  Wie wird es behoben:
  Bestimmen Sie, ob die Gruppierung von Ankreuzfeldern oder Auswahlknöpfen Text hat oder benötigt, der den Zweck der Ankreuzfelder oder der Gruppierung von Auswahlknöpfen erklärt. Wenn ja, markieren Sie die Gruppe innerhalb eines Fieldsets und fügen Sie die Gruppenbeschreibung in ein Legendenelement ein.
  Der Algorithmus:
  Zwei oder mehr Kontrollkästchen- oder Funkeingabeelemente innerhalb eines Formulars haben den gleichen Namenswert, sind aber nicht in einem Fieldset eingeschlossen.
  
  HTML-Code:
  statt:
  <label><input type="checkbox" name="auswahl" value="auswahl2">
  Auswahl 1
  </label>
  <label><input type="checkbox" name="auswahl" value="auswahl2">
  Auswahl 2
  </label>
  korrekt:
  <fieldset>
  <legend>Auswahl treffen und Option wählen</legend>
  <p>Bitte wählen Sie aus:</p>
  <label><input type="checkbox" name="auswahl" value="auswahl1" /> Auswahl 1</label><br />
  <label><input type="checkbox" name="auswahl" value="auswahl2" /> Auswahl 2</label><br />
  <label><input type="checkbox" name="auswahl" value="auswahl3" /> Auswahl 3</label><br />
  <label><input type="checkbox" name="auswahl" value="auswahl4" /> Auswahl 4</label><br />
  </fieldset>
  
  Normen und Richtlinien:
  3.3.2a Beschriftungen von Formularelementen vorhanden
   
• Unbeschriftetes form label mit Titel
  
  Was bedeutet das?
  Ein Formularsteuerelement hat kein Label, sondern einen Titel.
  Warum es wichtig ist:
  Der Wert des title-Attributs für nicht bezeichnete Formularsteuerelemente wird den Benutzer*innen von Screenreadern angezeigt. Ein richtig zugeordnetes Text-Label bietet jedoch eine bessere Benutzerfreundlichkeit und Zugänglichkeit und sollte verwendet werden, es sei denn, der Zweck des Formularsteuerelements lässt sich ohne das Label intuitiv erfassen.
  Wie wird es behoben:
  Wenn eine sichtbare Textbeschriftung für das Formularsteuerelement verfügbar ist, verknüpfen Sie die Textbeschriftung über das Label-Element mit dem Formularsteuerelement. Dies bietet zusätzliche Funktionalität für Endbenutzer, denn wenn auf das Label geklickt wird, wird der Fokus auf das Formularsteuerelement gesetzt. Wenn das Formularsteuerelement ohne <label> intuitiv bedienbar ist, kann der Wert des title-Attributs verwendet werden. Beachten Sie, dass der Wert des Titelattributs in der Regel nicht von einem Screenreader gelesen wird, wenn das Steuerelement ein Label hat, und möglicherweise für sehende Benutzer*innen, insbesondere für Benutzer*innen, die ausschließlich mit der Tastatur arbeiten, nicht verfügbar ist.
  Der Algorithmus:
  Ein <input> (außer Bildtypen, Submit, Reset, Button oder versteckt), <textarea> oder <select> Element hat einen nicht leeren Titelattributwert und es fehlt eine Beschriftung oder eine gültige 'aria-labelledby' Referenz, die durch einen Verweis gekennzeichnet ist.

• Vorbelegung von Eingabefeldern

  Die Beschriftung eines Eingabefelds sollte grundsätzlich mit sichtbarem Text erfolgen. In der Regel wird der sichtbare Text außerhalb des Eingabefelds positioniert und mit dem Intern: LABEL-Element mit dem Eingabefeld verknüpft. Somit erhält das Eingabefeld einen eindeutigen Namen.

  Eine ungünstige Variante dieser Technik ist die Verwendung des value-Attributs:

  <input name="suche" id="schnellsuche" type="text" value="Suchbegriffe eingeben" />

  Alternativ zum value-Attribut kann auch das placeholder-Attribut eingesetzt werden. Mit dem placeholder-Attribut wird erreicht, dass ein Hinweistext solange in einem Eingabefeld angezeigt wird, wie der Fokus nicht darauf liegt und solange der*die Nutzer*in keine Eingabe vorgenommen hat:

  Das Attribut wird immerhin von Screenreadern unterstützt, d.h. der Wert des placeholder-Attributs wird in Ergänzung zu der eigentlichen Beschriftung erfasst. Um Redundanzen zu vermeiden, sollten deshalb placeholder-Texte keine Wiederholungen der Beschriftungstexte enthalten.

  Der "Platzhalter" ist in den meisten Fällen dennoch kein Ersatz für eine korrekte Beschriftung eines Eingabefelds. Während eine sichtbare Beschriftung immer angezeigt wird, wird die Vorbelegung in dem Moment, in dem es konkret gebraucht wird, ausgeblendet. Außerdem könnte die Vorbelegung als Eingabewert missverstanden werden. Schließlich weist die standardmäßige Darstellung der Vorbelegung (eingegraut) ein geringes Kontrastverhältnis auf. Es gibt also mehrere Gründe, dieses Attribut aus Sicht der Barrierefreiheit nicht zu nutzen (auch wenn es in der Praxis legitime Gründe für dessen Einsatz gibt).
   

• Lieber type=radio als select?

  Wenn die Wahlmöglichkeiten begrenzt sind, ist input type=radio informativer, weil es immer alle Optionen anzeigt und nur eine Aktion erfordert. Der*die Benutzer*in müsste die select-Liste erst aufklappen, bevor er seine Wahl treffen kann.

  Weitere Informationen: https://www.barrierefreies-webdesign.de/knowhow/formulare/placeholder.html

Kontrast

• Kontraste der Schrift
  
  Was bedeutet es? Ein sehr geringer Kontrast zwischen Text- und Hintergrundfarben.
  Warum es wichtig ist: Ein ausreichender Textkontrast ist für alle Anwender erforderlich, insbesondere für Anwender mit Sehschwäche.
  Wie wird es behoben: Erhöhen Sie den Kontrast zwischen der Vordergrundfarbe (Text) und der Hintergrundfarbe. Großer Text (größer als 18 Punkt oder 14 Punkt fett) erfordert nicht so viel Kontrast wie kleinerer Text.
  Der Algorithmus: Es liegt Text vor, der ein Kontrastverhältnis von weniger als 4,5:1 hat, oder großer Text (größer als 18 Punkt oder 14 Punkt fett) hat ein Kontrastverhältnis von weniger als 3:1. WCAG erfordert, dass für Seitenelemente sowohl Vordergrund- als auch Hintergrundfarben definiert (oder vererbt) sind, die einen ausreichenden Kontrast bieten. Wenn Text über ein Hintergrundbild dargestellt wird, muss der Text eine definierte Hintergrundfarbe haben (normalerweise in CSS), die einen ausreichenden Textkontrast bietet, wenn das Hintergrundbild deaktiviert oder nicht verfügbar ist.
  Standards und Richtlinien: 1.4.3a Kontraste von Texten ausreichend
  Quellen: ein sehr informatives YouTube-Video (https://www.youtube.com/watch?v=2qdtRTLLru4) - - - ContrastAnalyser - Programm um Kontraste unter Windows und macOS zu testen (https://developer.paciellogroup.com/resources/contrastanalyser/)

  - - - Alternativ: Contrast Checker (https://webaim.org/resources/contrastchecker/)

• Kontraste von Grafiken und grafischen Bedienelementen
  
  Was bedeutet es? Die für die Identifizierung notwendige visuelle Information von informationstragenden Grafiken und grafischen Bedienelementen sowie deren Zuständen soll einen Kontrast von mindestens 3:1 zu angrenzenden Farben haben. In vielen Fällen, wie etwa bei einfarbigen Icons, bedeutet das einfach, dass der Kontrast zwischen der Farbe des Elements und der Hintergrundfarbe gemessen wird.
  Warum es wichtig ist: Ein ausreichender Kontrast ist für alle Anwender erforderlich, insbesondere für Anwender mit Sehschwäche.
  Wie wird es behoben: Stellen Sie die Grafiken um, so dass die grafischen Elemente über genügend Kontrast zueinander verfügen. Wenn grafische Elemente zusätzlich eingesetzt werden, ein Text also das Bedienelement bzw. dessen Zustand hinreichend kennzeichnet, müssen grafische Elemente die Kontrastanforderung nicht erfüllen.
  Standards und Richtlinien:
  1.4.11a Kontraste von Grafiken und grafischen Bedienelementen ausreichend

Weiterführende Informationen zu Barrierefreien Kontrasten: https://tollwerk.de/projekte/tipps-techniken-inklusiv-barrierefrei/barrierefreie-kontraste

Links

• leerer Link
  
  Was bedeutet das?
  Ein Link enthält keinen Text.
  Warum es wichtig ist:
  Wenn ein Link keinen Text enthält, wird die Funktion oder der Zweck des Links dem*der Nutzer*in nicht präsentiert. Dies kann bei Benutzer*innen von Tastatur und Bildschirmlesegeräten zu Verwirrung führen.
  Wie wird es behoben:
  Entfernen Sie den leeren Link oder geben Sie einen Text innerhalb des Links an, der die Funktionalität und/oder das Ziel dieses Links beschreibt.
  Der Algorithmus:
  Ein Anker-Element hat ein href-Attribut, enthält aber keinen Text (oder nur Leerzeichen) und keine Bilder mit Alternativtext.
  Normen und Richtlinien:
  2.4.4 Link-Zweck (im Kontext) (Ebene A)
• Redundanter Link
  
  Was bedeutet das?
  Benachbarte Links gehen auf die gleiche URL.
  Warum es wichtig ist:
  Wenn benachbarte Links zum gleichen Ort führen (z. B. ein verlinktes Produktbild und ein benachbarter verlinkter Produktname, die zur gleichen Produktseite führen), führt dies zu zusätzlicher Navigation und Wiederholung für Benutzer*innen von Tastatur und Screenreader.
  Wie wird es behoben:
  Wenn möglich, fassen Sie die redundanten Links zu einem Link zusammen und entfernen Sie überflüssigen oder alternativen Text (wenn z.B. ein Produktbild und ein Produktname im selben Link enthalten sind, kann dem Bild normalerweise alt="" gegeben werden).
  Der Algorithmus:
  Zwei benachbarte Links gehen auf die gleiche URL.
  Normen und Richtlinien:
  2.4.4 Link-Zweck (im Kontext) (Ebene A)
   
• Link mit unverständlichem Linktext wie 'mehr...' oder 'hier...'
  
  Was bedeutet das?
  Ein Link wird nur mit den Bezeichnungen 'mehr..', 'hier' oder 'weiter' von Screenreadern vorgelesen, wenn die*der Nutzer*in mit TAB-Steuerung in der Seite navigiert.
  Warum es wichtig ist:
  Der Kontext des Links bleibt dem*der Nutzer*in verborgen, da der Inhalt alleine aus dem Linktext besteht. Bei TAB-Steuerung wird der textliche Kontext, der den Link erläutert, nicht vorgelesen. Ziel oder Zweck des Links sollen aus dem Linktext hervorgehen oder aus dem direkten Kontext des Links ermittelbar sein.
  Wie man es beheben kann:

  Benutzen Sie aussagekräftige Links. Wie zum Beispiel: 'Aktuelle Meldungen aus dem BLOG Barrierefrei' und nicht 'Aktuelle Meldungen aus dem BLOG Barrierefrei finden Sie hier.' Der ganze Text sollte verlinkt sein. Nur so kann sich der*die Nutzer*in eine Vorstellung des verlinkten Inhalts machen.
  Der Algorithmus:
  Ein Linktext ist uneindeutig.
  Normen und Richtlinien:
  2.4.4a Aussagekräftige Linktexte

Listen

• HTML-Strukturelemente für Listen
  
  Was bedeutet das?
  Zur Auszeichnung von Listen auf der Seite sollen HTML-Strukturelemente für Listen (ul, ol und so weiter) genutzt werden.
  Warum es wichtig ist:
  Die Verwendung der HTML-Strukturelemente stellt sicher, dass der Aufbau einer Seite unabhängig von der Präsentation auf einer abstrakten Ebene festgelegt und zugänglich ist.

  Benutzer*innen, die mit der vorgegebenen visuellen Präsentation der Elemente auf der Seite nichts anfangen können, finden sich dann trotzdem zurecht oder sie können eine eigene, besser passende Präsentation anwenden.

  Mögliche Anwendungen der Strukturelemente für Listen:

• Listen oder Listeneinträge überspringen (Screenreader-Nutzer*in)

• Listen können hierarchische Strukturen angemessen abbilden

  Wie man es beheben kann:
  HTML-Strukturelemente für Listen (ul, ol und so weiter) nutzen.
  Normen und Richtlinien:
  1.3.1b HTML-Strukturelemente für Listen
  2.4.4 Link-Zweck (im Kontext) (Ebene A)
   

Navigation

• Konsistente Navigation
  
  Was bedeutet das?
  Navigationsmechanismen sollen innerhalb des Webauftritts einheitlich sein.
  Warum es wichtig ist: Eine einheitliche Navigation innerhalb des Webauftritts erleichtert das Verständnis, Gesuchtes wird leichter gefunden.
  Wie man es beheben kann: Die Navigation auf der Startseite unterscheidet sich häufig von der Navigation auf anderen Seiten, weil dort noch kein Bereichsmenü angezeigt werden muss oder weil zusätzliche Navigationsmöglichkeiten nur auf der Startseite angeboten werden. Falls Inhalte über geskriptete Layer eingeblendet werden, sollte geprüft werden, ob sich diese Inhalte deutlich von sonstigen Seiten und Seitenwechseln unterscheiden, da hier die üblichen Navigationsmöglichkeiten (etwa der Zurück-Button des Browsers) nicht gleichermaßen greifen.
  Normen und Richtlinien:
  3.2.3a Konsistente Navigation
  3.2.4a Konsistente Bezeichnung

Rechtliches / Richtlinien

• Verpflichtend und Rechtsgrundlage für die Hochschulen in NRW ist die Barrierefreie-Informationstechnik-Verordnung Nordrhein-Westfalen – BITVNRW und das Behindertengleichstellungsgesetz Nordrhein-Westfalen - BGG NRW. In der BITV NRW ist eine Grundlage der Stand der Technik und eine weitere die Erfüllung der Richtlinie (EU) 2016/2102, welche die EU-Norm EN 301 549 (PDF) als spezifizierten EU-Standard zugrunde legt.
• Europa ist mit der EU Richtlinie 2016/2102 einen grundlegenden Schritt Richtung Barrierefreiheit gegangen. Sie trat EU-weit am 23. September 2018 in Kraft. In dieser Richtlinie geht es um die Barrierefreiheit auf Webseiten und Apps öffentlicher Stellen. Verständlich erläutert auf der Seite 'Einfach für Alle'.
• der Gesetzestext der EU Richtlinie 2016/2102 - eur-lex.europa.eu
• weitere Infos zur EU-Webseitenrichtlinie - bundesfachstelle-barrierefreiheit.de
• Grundlage aller gesetzlichen Vorgaben sind die Web Content Accessibility Guidelines (WCAG) 2.1, hier auch in der Version 2.0 in deutscher Übersetzung - www.w3.org
• Mit der BITV 2.0, der Barrierefreien Informationstechnikverordnung des Bundes, liegt für Deutschland grundsätzlich ein Regelwerk vor, das den Mindeststandards der Richtlinie fast gänzlich entspricht. Der Mindeststandard laut Artikel 6 der Richtlinie entspricht den WCAG 2.1 Level AA vom Juni 2018 - gesetze-im-internet.de
• European Accessibility Act - Am 28. Juni 2019 trat das Europäische Gesetz zur Barrierefreiheit (englisch: European Accessibility Act - EAA) in Kraft. Der EAA zielt darauf ab, das Funktionieren des Binnenmarkts für barrierefreie Produkte und Dienstleistungen zu verbessern, indem Hindernisse beseitigt werden, die durch unterschiedliche Vorschriften in den Mitgliedsstaaten entstehen. Die Richtlinie ist bis zum 28. Juni 2022 in nationales Recht umzusetzen und muss - abgesehen von Ausnahmen - ab dem 28. Juli 2025 angewendet werden. (weitere Informationen: Boysen, Steinbrück: Vom European Accessibility Act zum Barrierefreiheitsstärkungsgesetz – Teil I: Hintergrund und Anwendungsbereich des EAA und des BFSG; Beitrag E2-2021 unter www.reha-recht.de; 25.08.2021)

Responsive Webseiten

• Umbruch der Inhalte
  
  Was bedeutet das?
  Seiten-Inhalte sollen bei einer Browserfensterbreite von 320 CSS-Pixeln (bzw. bei einer Browserfensterbreite von 1280 CSS-Pixeln und 400% Zoomvergrößerung) so umbrechen, dass alle Informationen und Funktionen verfügbar sind, ohne dass Nutzer*innen horizontal scrollen müssen.
  Warum es wichtig ist:

  Sehbehinderte Nutzer*innen vergrößern häufig Seiten-Inhalte über die Zoomfunktion, die in gängigen Desktop-Browsern vorhanden ist. Über eine responsive Gestaltung mittels CSS media queries sollen Web-Seiten die Nutzung mit starkem Zoom durch eine dynamische Anpassung des Seiten-Umbruchs unterstützen.

  Responsive Seiten-Layouts ordnen die Inhaltsblöcke neu an. Mehrspaltige Inhalte werden dabei meist so umbrochen, dass sie bei starkem Zoom einspaltig untereinander angeordnet sind. Bei Fließtexten entstehen auch neue Zeilenumbrüche mit kürzeren Zeilen.

  Der Vorteil: Nutzer*innen müssen beim Lesen nur in eine Richtung scrollen (bei westlichen Sprachen: vertikal). Wenn Zeilen bei Zoomvergrößerung nicht umgebrochen werden, sind Nutzer*innen dagegen gezwungen, beim Lesen jeder Zeile horizontal hin- und her zu scrollen, was die Aufnahme der Inhalte sehr stark beeinträchtigt und verlangsamt.

  Wie man es beheben kann:
  Sind Seiten nicht responsiv, dann müssen sie oder die Templates aufwendig umgestellt werden. Eine einfache Formel gibt es nicht. Ob die Seiten responsiv sind, kann man übrigens einfach feststellen. Im Browser mit Hilfe der Web Developer Toolbar die Viewport-Breite auf 320 CSS-Pixel einstellen (Resize -> Edit Resize Dimensions...) und die Seite neu laden. So kann man feststellen, ob Inhalte so umbrechen, dass eine Nutzung ohne horizontales Scrollen möglich ist und keine Inhalte und Funktionen verloren gehen. Alternativ ist es auch immer gut, Seiten auf einem Smartphone oder einem Tablet in verschiedenen Auflösungen oder Ausrichtungen zu testen.
  Normen und Richtlinien:
  1.4.10a Inhalte brechen um

Robust

• Robust (Die vier Prinzipien der WCAG 2.0 stellen die Basis der Richtlinien dar)
  
  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.
   
• 4.1 Maximieren Sie die Kompatibilität mit aktuellen und zukünftigen Benutzeragenten, einschließlich assistierender Techniken.

Schreiben

• Einfache und klare Sprache ist wichtig. Gute Verständlichkeit ist das A und O für alle Menschen, die Ihre Seite lesen.
   
• Wir nutzen täglich Abkürzungen, die aber vielleicht anderen unverständlich sind. Vermeiden Sie solche, außer zum Beispiel 'PDF' oder 'CD' sowie 'Nr.' oder 'usw.' Alles andere sollte ausgeschrieben werden.
   
• Erläutern Sie Fach- und Fremdwörter.
   
• Texte werden lesbarer, wenn sie diese in kleine Einheiten unterteilen und lesbar gestalten. Nutzen Sie Aufzählungen, Fettmarkierungen und Überschriften. Aber nicht zu viele davon, das kann wieder unübersichtlich wirken.
   
• Links sollten durch einen geeigneten Linktext selbsterklärend sein und nicht nur aus 'hier' oder 'mehr' bestehen.
   
• Orientierung schaffen Sie durch klare Seitentitel und dementsprechend auch eine Navigation mit eindeutigen Seitentiteln.

Schriftgrafiken

• Verzicht auf Schriftgrafiken
  
  Was bedeutet das?
  Grafiken sollen nicht für die Darstellung von Schriften verwendet werden. Logos sind hiervon ausgenommen.
  Warum es wichtig ist:
  Schriftgrafiken, die als Bitmap-Grafik eingebunden werden (z.B. als JPEG, PNG, oder GIF), können nicht oder nur eingeschränkt an Benutzeranforderungen angepasst werden. Ihre Farben können nicht individuell eingestellt werden, auch die individuelle Anpassung der Schriftgröße wirkt nicht auf grafische Schriften. Und bei Zoomvergrößerung werden die Schriftkanten unscharf.
  Wie man es beheben kann:
  Schriften sollten grundsätzlich skalierbar und als Schrift-Type eingebettet sein. Wenn Sie Text markieren und kopieren können, handelt es sich nicht um eine Grafik.
  Normen und Richtlinien:
  1.4.5. Schriftgrafiken

Screenreader

• Wir nutzen für unsere Tests folgende Screenreader:
  
  - NVDA für Windows (NVDA ist wohl der zur Zeit beste OpenSource ScreenReader für Windows Vista, Windows 7, Windows 8.1 und Windows 10. Er unterstützt SAPI4, SAPI5, MS Speech Platform SDK (SAPI 5.3, 5.4) und einige Sprachausgaben direkt. Ebenso unterstützt NVDA viele Braillezeilen direkt und viele über den BRLTTY Treiber. NVDA lässt sich sehr einfach auf einem USB-Stick installieren und ist somit als mobiler ScreenReader sehr gut geeignet. http://nvda.bhvd.de)
  
  Eine gute Anleitung zur Nutzung von NVDA findet sich auf den Seiten von 'Einfach für Alle'. (https://www.einfach-fuer-alle.de/artikel/screenreader-NVDA/)
  
  - VoiceOver am iPhone/iPad und Mac (VoiceOver ist keine separate Bildschirm­lesefunktion. Es ist ein fester Bestandteil von macOS und allen integrierten Apps auf dem Mac. https://www.apple.com/de/accessibility/mac/vision/)
  
  - Zudem gibt es weitere Screenreader auf dem Markt, wie zum Beispiel der Screenreader JAWS, den wir an einem Arbeitsplatz in unseren Arbeitsräumen installiert haben und der dort zur Verfügung steht.
  
  - Wikipedia-Artikel zu Screenreadern
  - Hilfreiche Seite zur Nutzung von Screenreadern: Screen Reader Keyboard Shortcuts and Gestures

Sensorische Merkmale

• Ohne Bezug auf sensorische Merkmale nutzbar
  
  Was bedeutet das?
  Verweise auf Inhalte der Seite sollen nicht ausschließlich sensorische Merkmale wie Farbe, Form oder Position nutzen, sondern auch ohne bestimmte Sinneswahrnehmungen verständlich sein (etwa durch den Verweis auf die Überschrift von Inhalten).
  Warum es wichtig ist:
  Auch der Bezug auf die Form, Farbe oder Position von bestimmten Seiteninhalten ist für blinde Nutzer*innen und auch Nutzer*innen, die die Seite ohne das mitgelieferte Stylesheet oder auf anderen Ausgabegeräten sehen, nicht brauchbar.
  Wie man es beheben kann:
  Vermeiden Sie folgende Ausdrücke:
   
• Klicken Sie auf den grünen Knopf, um ...
• Über die runde Taste können Sie...
• Der rot eingerahmte Kasten enthält Infos zu ...
• Klicken Sie im Menü rechts...
• In der breiten Spalte steht...
• Die rechtsbündigen Absätze zeigen.. Solche Bezugnahmen sind ohne die Wahrnehmung sensorischer Merkmale nicht nachzuvollziehen.
  
  Dies gilt auch für Alternativtexte von Informationsgrafiken: sie sollen alle für das Verständnis relevanten Informationen nicht allein durch Bezug auf sensorische Merkmale vermitteln.
  Normen und Richtlinien:
  1.3.3a Ohne Bezug auf sensorische Merkmale nutzbar

Sichtbar / Unsichtbar

• Verbergen von Inhalten
   

  Manchmal müssen Inhalte auf Webseiten versteckt werden. Inhalte, die kontextabhängig angezeigt oder erst später als Teil eines Prozesses werden, sollten zunächst vor jedem*jeder Nutzer*in verborgen werden. Auch im barrierefreien Webdesign gehört das Verstecken von Inhalten zu den klassischen Techniken, aber dann geht es meist darum, zusätzliche Inhalte nur für Screenreader bereitzustellen. Die verschiedenen Gründe, Inhalte zu verstecken, benötigen unterschiedliche Umsetzungstechniken. Hier eine schnelle einfache Lösung.

  Hinweis: in der Roxen Text&Picture Komponente wird dieser Source-Code mit html-Source Fenster automatisch verändert, daher nutzen Sie die RXML-Komponente für den HTML-Code.

  Code: <span class="">Angezeigter und vorgelesener Text <span aria-hidden="true">Nur am Bildschirm</span><span class="sr-only">nur für Screenreader</span></span>

  Zu beachten: Manche Screenreader (NVDA, Sprachassistent Windows) lesen den Screenreader-Text korrekt, VoiceOver im Mac dagegen nicht, hier werden beide Varianten vorgelesen. Zur Verwendung des aria-hidden="true"-Elementes ist das auf folgender Seite zu beachten: https://tollwerk.de/projekte/tipps-techniken-inklusiv-barrierefrei/barrierefrei-verstecken#aria-hiddentrue

  Weitere Infos: https://www.barrierefreies-webdesign.de/knowhow/verstecken-von-inhalten/
  
  
  Alternative mit CSS: Die gängigste aller Techniken kursiert in mehreren Varianten und nutzt eine Kombination verschiedener CSS-Einstellungen, um Inhalte aus dem Sichtbereich zu entfernen, aber weiterhin für Screenreader erfassbar zu lassen. Ein Element, dem die CSS-Klasse 'visually-hidden' gegeben wird, wird durch folgende CSS-Regel für Screenreader unsichtbar:
  
  .visually-hidden:not(:focus):not(:active) {
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px; }
  
  der entsprechende Code sieht so aus:
  
  <a href="barrierefrei-verstecken.html"> Mehr erfahren <span class="visually-hidden"> über Techniken zum barrierefreien Verstecken </span> </a>
  
  Mehr Details zu dieser Variante findet sich unter: https://tollwerk.de/projekte/tipps-techniken-inklusiv-barrierefrei/barrierefrei-verstecken

Hyphenation

• Since hyphenation may not be desired by the user - for example, because subjective legibility is made more difficult - the user should also be able to switch off hyphenation. It would be better if the user had to activate the hyphenation option in the browser first. Such options are currently not available.
• Hyphenation is particularly suitable for narrow columns on the web. It should be used with caution and should not, for example, be used by default for longer texts; only for texts in a closed line case should hyphenation always be used.

• More Information: https://www.barrierefreies-webdesign.de/knowhow/silbentrennung/

• In principle, words are automatically separated in Roxen CMS 17 at Bielefeld University.

  With long words, it can happen in individual cases that the separation is not set optimally in some displays. In these cases, there is an option in the edit area to overwrite the automatic separation logic with your own specifications.

  In allen Inhaltskomponenten inklusive Kopfbereich kann nun für den Chrome-Browser das ­­ ­-Tag an den Stellen verwendet werden, an denen bevorzugt getrennt werden soll. Beispiel: „Wirtschafts­­­wissenschaften“ stellt ein, dass für den Fall einer Trennung bevorzugt nach dem Wortteil „Wirtschafts“ getrennt wird. Es können auch mehrere ­­-Argumente pro Wort vergeben werden. Bitte beachten Sie, dass die automatische Trennungslogik immer für den jeweiligen Absatz überschrieben wird. Dies sollte in der Praxis jedoch selten Auswirkungen haben, da sich der Bedarf nach manueller Trennung fast ausschließlich im Kopfbereich oder bei Überschriften ergibt. Parallel wird weiter an einer Lösung für weitere Browser gearbeitet.

Sprache

• Hauptsprache angegeben
  
  Was bedeutet das?
  Die Hauptsprache der Webseite soll angegeben werden. Und: Wenn innerhalb einer Seite Wörter und Textabschnitte in einer anderen Sprache vorkommen, müssen diese mithilfe des lang-Attributs ausgezeichnet werden.
  Warum es wichtig ist:
  Screenreader verwenden Wortlisten, in denen die Aussprache der Wörter festgelegt ist. Sie müssen wissen, in welcher Sprache ein Text verfasst ist, damit sie die richtige Wortliste verwenden und den Text korrekt aussprechen können.
  Wie man es beheben kann: Den Quelltext der Seite ansehen und prüfen, ob im öffnenden html-Element das lang-Attribut (bzw. bei xhtml-Seiten das xml:lang-Attribut) verwendet wird und darin die Hauptsprache der Seite richtig angegeben ist.
  Normen und Richtlinien:
  3.1.1a Hauptsprache angegeben
  3.1.2a Anderssprachige Wörter und Abschnitte ausgezeichnet

Tabellen

• Layout-Tabelle
  
  Was bedeutet das?
  Eine Layout-Tabelle ist vorhanden.
  Warum es wichtig ist:
  Layout-Tabellen dienen lediglich dazu, Inhalte visuell zu positionieren, d. h. Spalten zu erstellen, Abstände einzufügen oder Inhalte für sehbehinderte Benutzer*innen ordentlich auszurichten. Ihr Inhalt ist keineswegs tabellarischer Natur. Layout-Tabellen sollten in HTML5 nicht verwendet werden. Sie können Fragen der Lese- und Navigationsreihenfolge aufwerfen. Screenreader können sie als Datentabellen interpretieren (d.h. Spalten- und Zeilennummern ankündigen), insbesondere wenn sie Tabellenkopfzellen (<th>) enthalten. Dies führt zu einem erheblichen Overhead für Benutzer*innen von Screenreadern.
  Wie man es beheben kann:
  In fast allen Fällen können Layout-Tabellen durch andere HTML-Elemente ersetzt und mit CSS formatiert werden, um die gewünschte visuelle Darstellung zu erreichen. Wenn die Tabelle tabellarische Daten enthält, stellen Sie entsprechende Kopfzellen (<th>) zur Verfügung. Wenn die Layout-Tabelle bestehen bleibt, überprüfen Sie, ob die Lese- und Navigationsreihenfolge des Tabelleninhalts (basierend auf der zugrundeliegenden Quellcode-Reihenfolge) logisch ist, und geben Sie ihr die role="presentation", um sicherzustellen, dass sie für Benutzer*innen von Screenreadern nicht als Tabelle identifiziert wird.
  Der Algorithmus:
  Es ist ein <table>-Element vorhanden, das keine Kopfzellen (<th>) enthält.
  Normen und Richtlinien:
  1.3.1g Kein Strukturmarkup für Layouttabellen
  1.3.2a Sinnvolle Reihenfolge
   
• Datentabellen richtig aufgebaut
  
  Was bedeutet das?
  Datentabellen sind strukturell richtig aufgebaut, Zeilen- und Spaltenüberschriften sind mit th ausgezeichnet.
  Warum es wichtig ist:
  Visuell orientierte Personen nutzen für die Orientierung in einer Datentabelle neben den Überschriften wenn nötig auch den Wertebereich. Es ist für sie daher relativ leicht möglich, strukturelle Mängel, zum Beispiel Wechsel in der Bedeutung von Zeilen oder Spalten zu erkennen und mit ihnen umzugehen.

  Sehbehinderte und blinde Benutzer*innen erschließen sich das Angebot von Datentabellen dagegen eher analytisch. Sie entwickeln ausgehend von den Überschriften und anderen im Kontext verfügbaren Informationen eine Vorstellung vom Aufbau der Tabelle. Diese Vorstellung ist die Grundlage für den Zugriff auf die angebotenen Daten.
  Wie man es beheben kann:
  Damit das möglich ist und funktioniert, müssen zwei Bedingungen erfüllt sein:

1. Die Tabelle muss eine klare Struktur haben, die Bedeutung der Zeilen und Spalten muss fassbar sein und sie muss möglichst gut den Überschriften oder unterstützenden Kontextinformationen zu entnehmen sein.

2. Die Überschriften müssen auffindbar sein und es muss klar sein, auf welche Daten sie sich beziehen, sie müssen also korrekt ausgezeichnet sein.

   Die klare Struktur ist die Grundlage der Barrierefreiheit von Datentabellen. Es ist nicht möglich, eine mangelhaft strukturierte Datentabelle durch spezielle Auszeichnung barrierefrei zugänglich zu machen. Auf Grundlage einer klaren, nachvollziehbaren Struktur ist die korrekte Auszeichnung aber nützlich und wichtig. Mögliche Anwendungen der Auszeichnung von Tabellenüberschriften:

• Der Screenreader informiert über die Position und Anzahl der Überschriftenreihen.
• Der Screenreader liest die (neue) Zeilen- oder Spaltenüberschrift vor, wenn der*die Benutzer*in die Tabellenzeile oder die Tabellenspalte wechselt.
• Überschriften werden in einer für den*die Benutzer*in besser geeigneten Form hervorgehoben.
  Hinweis:
  Für Benutzer*innen von Screenreadern sind komplexe Tabellen schwerer zu erfassen als einfache, selbst bei perfekter Auszeichnung. Zu empfehlen ist also die Vermeidung von Tabellen mit mehreren logischen Ebenen (siehe Frage zu Tabellen mit mehreren logischen Ebenen). In vielen Fällen können komplexe Tabellen geteilt und durch mehrere einfache Tabellen ersetzt werden.
  
  
  Normen und Richtlinien:
  1.3.1e Datentabellen richtig aufgebaut
  1.3.1f Zuordnung von Tabellenzellen

Tastaturbedienbarkeit / Focusreihenfolge

• Ohne Maus nutzbar
  
  Was bedeutet das?
  Die Webseite soll auch ohne Maus - also ausschließlich mit der Tastatur - zu benutzen sein und die Reihenfolge, in der Links, Formularelemente und Objekte angesteuert werden, soll schlüssig und nachvollziehbar sein.
  Warum es wichtig ist:
  Alle Funktionen einer Webseite müssen auch mit der Tastatur zu bedienen sein, weil viele motorisch eingeschränkte Menschen oder Blinde eine Seite nur mit der Tastatur bedienen können. Oft sind wir an die Maus-Bedienung so gewöhnt, dass eine Tastatur-Bedienung oft vernachlässigt wird.

  Hinweis zu Drag-and-Drop-Funktionen: Für wichtige Bedienfunktionen, die mittels Drag-and-Drop bedienbar sind, müssen auch tastaturnutzbare Alternativen angeboten werden.
  Überdies: Kann der Tastaturfokus auf ein Element der Seite bewegt werden, muss er auch von diesem Element wieder wegbewegt werden können. Der Inhalt darf keine Tastaturfalle erzeugen. Und Tastatur-Kurzbefehle müssen abschaltbar oder anpassbar sein. Zudem: Der Tastaturfokus soll deutlich hervorgehoben werden, damit Tastaturnutzer sehen, wo sich ihr Fokus befindet, wenn sie interaktive Elemente aktivieren wollen. Für den Tastaturbenutzer ist es wichtig, zu sehen, wo sich der Tastaturfokus gerade befindet, welcher Link also ausgelöst wird, wenn er die Enter-Taste drückt.
  Wie man es beheben kann:
  Testen Sie die Tastaturbedienung, öffnen Sie die Seite im Browser Firefox und Chrome und prüfen Sie, ob alle wesentlichen Links und Formularelemente erreicht und benutzt werden können. Probleme bei der Bedienung werden in der Regel durch die Verwendung von JavaScript verursacht. Die Prüfung erfolgt also bei eingeschaltetem JavaScript.

  Normen und Richtlinien:
  2.1.1a Ohne Maus nutzbar
  2.1.2a Keine Tastaturfalle
  2.1.4a Tastatur-Kurzbefehle abschaltbar oder anpassbar
  2.4.3a Schlüssige Reihenfolge bei der Tastaturbedienung
  2.4.7a Aktuelle Position des Fokus deutlich

Testing

• Testen von Barrierefreiheit
  
  Folgende Tools und Umgebungen werden genutzt:
  
  - Test Siteimprove  (Erweiterung in Chrome)
  
  - Test WAVE (Erweiterung in Chrome)
  
  - ContrastAnalyser - Programm um Kontraste unter Windows und macOS zu testen
  
  
  Screenreader
  
  - Test VoiceOver Mac/iPad/iPhone 
  
  - NVDA (Windows Programm http://nvda.bhvd.de/)

ausführliche Informationen auf unserer Testseite

Text

• Text ist sehr klein
  
  Was bedeutet das?
  Der Text ist zu klein.
  Warum es wichtig ist:
  Text, der sehr klein ist, ist schwierig zu lesen, insbesondere für Menschen mit Sehschwäche.
  Wie man es beheben kann:

  Text soll um bis zu 200 Prozent geändert werden können, ohne dass dabei Inhalt oder Funktionalität verloren geht. Eine der folgenden Voraussetzung soll erfüllt sein:

• Mit der Zoom-Funktion des Browsers kann das gesamte Layout proportional zur Schriftgröße vergrößert werden.

• Mit der Nur-Text-Vergrößerung im Browser kann der Text vergrößert werden.

• Über ein Bedienelement der Seite kann die Schriftgröße vergrößert werden.

  Der Algorithmus:
  Es ist Text vorhanden, der 10 Pixel oder kleiner ist.
  Normen und Richtlinien:
  1.4.4a Text auf 200% vergrößerbar

Textabstand

• Textabstände anpassbar
  
  Was bedeutet das?
  Zeilen- Absatz- Wort- und Buchstaben-Abstände lassen sich von Nutzer*innen auf folgende Werte einstellen, ohne dass Inhalte oder Funktionalitäten nicht mehr verfügbar sind: Zeilen: 1,5-fache Textgröße; Abstände nach Absätzen: 2-fache Textgröße; Buchstaben-Kerning: 0,12-fache Textgröße; Wortabstände: 0,16-fache Textgröße.
  Warum es wichtig ist: Menschen mit Sehbehinderungen können die Lesbarkeit von Texten verbessern, wenn sie über Werkzeuge wie Bookmarklets oder über eigene Stylesheets die Abstände zwischen Zeilen, Absätzen, Zeichen und Worten anpassen können. Solche Anpassungen führen dazu, das Texte ggf. mehr Platz brauchen und Container dementsprechend dynamisch angelegt sein müssen, um den längeren Text ohne Verlust zu zeigen.
  Normen und Richtlinien:
  1.4.12a Textabstände anpassbar

Titel

• Sinnvoller Webseiten-Titel
  
  Was bedeutet das?
  Seitentitel bezeichnen den Inhalt einer Seite, hier sollte auf eine möglichst eindeutige Wahl des Titels geachtet werden.
  Warum es wichtig ist:
  Falsche oder allgemein gehaltene Seitentitel sowie typographische Schmuckelemente werden Screenreader-Nutzer*innen vorgelesen und verhindern eine Orientierung.
  Wie man es beheben kann:
  Der Dokumenttitel enthält zwei Bestandteile: eine immer gleiche, allgemeine Bezeichnung des Webauftritts und eine unterscheidende, individuelle Bezeichnung der jeweiligen Seite.
  Normen und Richtlinien:
  2.4.2a Sinnvolle Dokumenttitel

Überschriften

• Leere Überschrift
  
  Was bedeutet das? Eine Überschrift enthält keinen Inhalt.
  Warum es wichtig ist: Einige Benutzer*innen, insbesondere Tastatur- und Screenreader-Benutzer*innen, navigieren häufig nach Überschriftenelementen. Eine leere Überschrift enthält keine Informationen und kann Verwirrung stiften.
  Wie man sie behebt: Stellen Sie sicher, dass alle Überschriften informativen Inhalt enthalten.
  Der Algorithmus: Es ist ein Überschriftenelement vorhanden, das keinen Text (oder nur Leerzeichen) und keine Bilder mit Alternativtext enthält.
  Normen und Richtlinien: 1.3.1 Informationen und Beziehungen (Ebene A) 2.4.1 Umgehungsblöcke (Ebene A) 2.4.6 Überschriften und Bezeichnungen (Ebene AA) Symbol-Index
   
• H1-H6 Überschriften
  
  Warum die strukturierten Überschriften?
  Überschriften müssen korrekt mit den HTML-Strukturelementen h1 bis h6 ausgezeichnet sein und die Inhalte der Seite erschließen.
  Warum es wichtig ist:
  Überschriften erleichtern die Seitennavigation für Benutzer*innen von assistiven Technologien. Sie geben dem Dokument auch semantische und visuelle Bedeutung und Struktur. Überschriften der ersten Ebene sollten die wichtigste(n) Überschrift(en) auf der Seite enthalten (im Allgemeinen den Titel des Dokuments) und nur einmal vorkommen.

  Benutzer*innen, die diese visuelle Ordnung nicht nutzen können, zum Beispiel, weil sie blind sind oder nur einen kleinen Ausschnitt der Seite sehen können, sind darauf angewiesen, dass die Struktur unabhängig von der Darstellung auf dem Bildschirm zugänglich und nutzbar ist. Die Verwendung von Überschriften-Elementen ist dafür eine wesentliche Voraussetzung.

  So können Benutzer*innen die Überschriften-Elemente anwenden:

• Nur die Überschriften anzeigen lassen - als Inhaltsverzeichnis für die schnelle Orientierung (besonders wichtig für blinde Benutzer*innen)

• Von Überschrift zu Überschrift springen (blinde Nutzer*innen)

• Überschriften anders hervorheben, wenn die vom Anbieter vorgesehene Hervorhebung nicht geeignet ist (zum Beispiel andere Farbe oder Stimme)
   

  Was zu beachten ist:
  Stellen Sie sicher, dass es sich bei dem betreffenden Text wirklich um eine Überschrift handelt und dass er im Seitenumriss richtig strukturiert ist.
  Der Algorithmus:
  <h1> - <h6> Elemente sollten benutzt werden.
  
  Html-Code:
  <h1>
  Zentrale Anlaufstelle Barrierefrei
  </h1>
  
  Normen und Richtlinien:
  1.3.1a HTML-Strukturelemente für Überschriften
  2.4.6a Aussagekräftige Überschriften und Beschriftungen
   
• Tipp: Nutzen Sie das Bookmarklet h123, das Ihnen schnell eine Übersicht über die h-Struktur einer Seite gibt. Installation und Anwendung

Überspringbar

• Bereiche wie Navigation, Suche oder Seiteninhalt überspringbar
  
  Was bedeutet das?
  Nur wenn eine Webseite sinnvolle Bereichsüberschriften hat (HTML-Strukturelemente h1 bis h6), Sprunglinks vorhanden sind und HTML5 Elemente zur Auszeichnung von Bereichen (header, nav, main, aside, footer) den Seitenaufbau erschließen sowie WAI-ARIA document landmarks die Seitenbereiche sinnvoll strukturieren, dann ist die Seite auch für Nutzer*innen, die die visuelle Ordnung nicht nutzen können, bedienbar. Zudem brauchen Frames und Iframes brauchen ein sinnvolles title-Attribut.
  Warum es wichtig ist:
  Benutzer*innen, die diese visuelle Ordnung nicht nutzen können – zum Beispiel, weil sie blind sind oder nur einen kleinen Ausschnitt der Seite sehen können – sind darauf angewiesen, dass die Struktur unabhängig von der Darstellung auf dem Bildschirm zugänglich und nutzbar ist. Die Verwendung von (oft unsichtbaren) Bereichsüberschriften, Sprunglinks oder HTML5 Elementen zur Auszeichnung von Regionen ist dafür eine wesentliche Voraussetzung.
  Wie man es beheben kann:
  Benutzer*innen sollten die Bereichsüberschriften, Sprunglinks, HTML5-Elmente für Regionen bzw. WAI-ARIA document landmarks anwenden. Konstante Bereiche am Seitenbeginn, etwa Navigation oder Seitenkopf, überspringen, um direkt zum Inhalt zu gelangen, um zwischen Bereichen hin- und her wechseln, sollten vorhanden sein. Normen und Richtlinien:
  2.4.1a Bereiche überspringbar

Verständlich

• Verständlich (die vier Prinzipien der WCAG 2.0 stellen die Basis der Richtlinien dar)
  
  Informationen und Bedienung der Benutzerschnittstelle müssen verständlich sein.
   
• 3.1 Machen Sie Textinhalte lesbar und verständlich.
• 3.2 Sorgen Sie dafür, dass Webseiten vorhersehbar aussehen und funktionieren.
• 3.3 Helfen Sie den Benutzer*innen dabei, Fehler zu vermeiden und zu korrigieren.

Vorgelesen

• Vermeiden Sie Abkürzungen
  
  Abkürzungen wie PLZ und FAQ werden von Screenreadern zum Teil anders vorgelesen, als gedacht (hier zum Beispiel 'Please' oder 'F*ck'). Auch kann die Mischung von deutschen und englischen Inhalten zu merkwürdigen Aussprachen führen.
  
  Achten Sie also auf die Ausdrücke, denn diese sollten gut von den Screenreadern interpretiert werden.

Wahrnehmbar

• Wahrnehmbar (die vier Prinzipien der WCAG 2.0 stellen die Basis der Richtlinien dar)
  
  Informationen und Bestandteile der Benutzerschnittstelle müssen den Benutzer*innen so präsentiert werden, dass diese sie wahrnehmen können.
   
• 1.1 Stellen Sie Textalternativen für alle Nicht-Text-Inhalte zur Verfügung, so dass diese in andere vom*von der Benutzer*in benötigte Formen geändert werden können, wie zum Beispiel Großschrift, Braille, Symbole oder einfachere Sprache.
• 1.2 Stellen Sie Alternativen für zeitbasierte Medien zur Verfügung.
• 1.3 Erstellen Sie Inhalte, die auf verschiedene Arten dargestellt werden können (zum Beispiel mit einfacherem Layout), ohne dass Informationen oder Strukturen verloren gehen.
• 1.4 Machen Sie es für den Benutzer*innen leichter, Inhalte zu sehen und zu hören, einschließlich der Trennung zwischen Vordergrund und Hintergrund.

WAI-Area

• WAI-Area
   

  Hinweis: WAI-ARIA wird zwar von einigen Screenreadern unterstützt, aber nicht von allen und auch nicht vollständig. Es ist also Vorsicht geboten! Von den drei Attributen funktioniert derzeit aria-describedby noch am besten.

  Accessible Rich Internet Applications (ARIA) ermöglichen Webentwicklern Webinhalte und Web-Applikationen (insbesondere solche mit Ajax und JavaScript) besser zugänglich für Menschen mit Behinderungen und anderen Einschränkungen zu machen. Zum Beispiel lassen sich mit ARIA Navigations-Landmarken, JavaScript-Widgets, Formular-Hinweise und Fehlermeldungen hinzufügen und Live-Content-Aktualisierungen barrierefrei gestalten.

  ARIA ist ein Satz von speziellen Attributen, die beliebigem Markup-Content hinzugefügt werden können, wurde jedoch vorwiegend für HTML entwickelt. Das Attribut role definiert, um welche Art von Element es sich bei einem Objekt handelt (z. B. article, alert, oder slider). Andere ARIA-Attribute erweitern den Inhalt einer Website um nützliche Hilfsfunktionen, wie z. B. Formularbeschreibungen und Anzeigen für den aktuellen Wert bei Fortschrittsanzeigen.

  Wenn es ein HTML-Element oder -Attribut mit der erforderlichen Semantik oder Verhalten gibt, dann sollte HTML eingesetzt werden und nicht ARIA.
  Mit ARIA sollte die Semantik von HTML nicht verändert werden.
  die allermeisten fertigen Widgets haben mit Barrierefreiheit nichts zu tun und führen manchmal sogar durch den falschen Einsatz von ARIA zu nicht nutzbaren Widgets.

  ARIA ist bei den meisten Browsern und Screen-Readern implementiert. Die Implementierungen weichen jedoch teilweise voneinander ab. Bei älterer Technologie ist die Unterstützung oft nicht vollständig (oder gar nicht vorhanden), daher sollte am besten "sicheres" ARIA eingesetzt werden, das bei schlechter Unterstützung keine Probleme verursacht, oder der Benutzer*in aufgefordert werden, neuere Technologie zu benutzen.

  Eine Einführung findet sich hier: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA
  
  Name, Rolle, Wert
  
  Was bedeutet das?
  Standard-HTML-Bedienelemente wie Links (a-Element) und Formularelemente (input, button, checkbox etc.) haben Namen, Rollen, Wert und Zustände, sofern sie gemäß Spezifikation umgesetzt sind und sind für Hilfsmittel wie Screenreader generell erkennbar. So bekommen etwa blinde Nutzer*innen mit, wenn sie auf einen Link tabben und können diesem dann folgen. Auch Zustände, beispielsweise einer Checkbox (ausgewählt oder nicht ausgewählt) werden vermittelt. Interaktive Schaltflächen sollten deshalb mit Hilfe von geeigneten HTML-Elementen umgesetzt werden, damit ihre Bedeutung klar wird.
  Warum es wichtig ist:
  Falls ungeeignete (weil nicht semantische) Elemente (etwa div oder span) mithilfe von JavaScript zu Links oder Bedienelementen umfunktioniert werden, kann die Semantik mit Hilfe von WAI-ARIA bereit gestellt werden. Dies betrifft auch Komponenten (Widgets wie z.B. Tabpanels, Akkordeons etc.), die in nativem HTML so nicht zur Verfügung stehen und mit Hilfe von nicht semantischen Elementen und Scripten umgesetzt sind. WAI-ARIA Attribute helfen, diese zu verstehen, indem semantische Informationen vom Browser an die Hilfsmitteltechnologien übermittelt werden.
  Normen und Richtlinien:
  4.1.2a Name, Rolle, Wert verfügbar

Zeigergesten

• Alternativen für komplexe Zeiger-Gesten
  
  Was bedeutet das?
  Für Menschen mit Bewegungseinschränkungen ist es oft schwierig und teilweise unmöglich, komplexe Zeiger-Gesten erfolgreich auszuführen.
  Warum es wichtig ist:
  Deshalb sollen solche Gesten, wenn Sie von Web-Inhalten implementiert werden, nicht der einzige Weg sein, eine Funktion auszuführen. Beispiele für komplexe Gesten sind Streichgesten vom Rand her, um Menüs einzublenden, Wischgesten zum Bewegen von Karussell-Inhalten, Zieh-Gesten zum Verstellen von Schiebereglern, oder Mehrpunktgesten wie die Spreizgeste zum Vergrößern eines Kartenausschnitts.
  Wie man es beheben kann:
  Prüfen, ob die über komplexe Zeigergesten auslösbare Funktion auch über einfache Zeiger-Gesten wie Tippen, Doppeltippen oder Tippen-und-Halten ausgelöst werden kann, etwa durch Aktivierung von alternativen statischen Elementen (z.B. Tasten, die Slider bewegen, Werte erhöhen oder verringern, oder Menüs einblenden). Für alle in Web-Inhalten implementierten komplexen Gesten gibt es alternative Eingabemöglichkeiten über einfache Zeiger-Gesten.
  Normen und Richtlinien:
  2.5.1a Alternativen für komplexe Zeiger-Gesten

Zeit

• Zeitbegrenzungen anpassbar
  
  Was bedeutet das?
  Seiteninhalte werden ohne Zeitbegrenzung angezeigt, eine Zeitbegrenzung ist abschaltbar, oder sie kann verlängert werden.
  Warum es wichtig ist:
  Die Auto-Aktualisierung durch das Neu-Laden einer Seite kann bei Screenreader-Nutzer*innen das Vorlesen der Seiteninhalte unterbrechen und unvermittelt von vorne beginnen.

  Bei zeitverzögerten Weiterleitungen sollen Nutzer*innen etwas lesen, bevor sie auf eine andere Seite weitergeleitet werden. Die Zeitbegrenzung macht die zwischendurch angezeigte Seite für viele nicht zugänglich.

  Wenn Zeitbegrenzungen sich nicht abschalten oder verlängern lassen, können Nutzer*innen, die mehr Zeit für Eingaben brauchen, Online-Transaktionen oft nicht rechtzeitig abzuschließen.

  Wie man es beheben kann:
  Eine Zeitbegrenzung muss abschaltbar sein.
  Normen und Richtlinien:
  2.2.1a Zeitbegrenzungen anpassbar

Zitate

• HTML-Strukturelemente für Zitate
  
  Zur Auszeichnung von Zitaten, die als eigenständige Textabschnitte gefasst sind, soll das dafür vorgesehene HTML-Strukturelement blockquote genutzt werden.
  1.3.1c HTML-Strukturelemente für Zitate