Checkliste

Diese praxisorientierte Checkliste unterstützt Sie dabei, den Zustand Ihres digitalen Angebots hinsichtlich der Barrierefreiheit zu beurteilen. Zielgruppe der Accessibility-Checkliste sind Design-, Entwicklungs- und Content-Teams ebenso wie Qualitätssicherungsverantwortliche und Projektleitende.

WCAG Stufe:
Filter nach:
1.1.1

Nicht-Text-Inhalt

A pdf design dev content QS
1
Informative Grafiken weisen einen Alternativtext auf, der äquivalente Informationen vermittelt.
Web Developer Toolbar: Images > Display Alt Attributes: Angezeigte Alternativtexte mit Bildern abgleichen. Oder: Code-Analyse.
A pdf dev content QS

2
Video- und Audio-Inhalte weisen einen Alternativtext auf, der den Titel und/oder eine kurze Umschreibung vermittelt.
Manuelle Prüfung: Alternativtext mit Inhalt vergleichen: Ist der Titel bzw. die Umschreibung passend?
A dev content QS

3
Tests und Übungen, deren Inhalt zwingend aus Nicht-Text-Inhalt bestehen muss, weisen einen Alternativtext auf, der dessen Zweck beschreibt (aber nicht die Information, die benötigt wird, um den Test oder die Übung zu bestehen).
Manuelle Prüfung: Alternativtext mit Inhalt vergleichen: Beschreibt dieser den Zweck des Inhalts passend?
A dev content QS

4
Sensorische Inhalte, die zwingend aus Nicht-Text-Inhalt bestehen, weil sie durch Worte nicht ausreichend ersetzt werden können (z.B. Musikaufführungen, Kunstwerke), weisen einen Alternativtext auf, der den Zweck des Nicht-Text-Inhalts beschreibt.
Manuelle Prüfung: Alternativtext mit Inhalt vergleichen: Beschreibt dieser den Zweck des Inhalts passend?
A dev content QS

5
Als Webfont eingebundene Symbole sind so umgesetzt, dass sie nicht zu unverständlichen Ausgaben durch Screenreader führen.
Screenreader: Symbole vorlesen lassen und sicher stellen, dass keine unerwarteten/unpassenden Ausgaben passieren.
A dev QS

6
Verlinkte Grafiken weisen einen Alternativtext auf, der Linkziel oder -zweck beschreibt.
Web Developer Toolbar: Images > Display Alt Attributes: Angezeigte Alternativtexte mit Bildern abgleichen.
A pdf dev content QS

7
Alternativtexte von Grafiken beinhalten keine redundanten Informationen, z.B. eine bereits in einer Bildlegende oder einem Linktext vorhandene Information oder eine Information wie «Grafik …», «Bild …».
Web Developer Toolbar: Images > Display Alt Attributes: Angezeigte Alternativtexte mit Bildern abgleichen.
A pdf dev content QS

8
Grafische Schalter sind korrekt beschriftet.
Web Developer Toolbar: Images > Display Alt Attributes: Angezeigte Alternativtexte mit Bildern abgleichen.
A pdf dev QS

9
Informative Grafiken sind bei benutzerdefinierten Farbeinstellungen sichtbar.
Windows High Contrast Mode aktivieren (Alt + Shift + PrtScn): Sind alle informativen Grafiken nach wie vor sichtbar?
A pdf dev QS

10
Das Seiten-Logo (mit Link zur Startseite) verfügt über eine sinnvolle Textalternative (Muster alt="Logo Firmenname, zur Startseite")
Web Developer Toolbar: Images > Display Alt Attributes: Angezeigte Alternativtexte mit Bildern abgleichen.
A dev QS

11
Sonderzeichen vermitteln Informationen auf zugängliche Weise.
Screenreader: Symbole vorlesen lassen und sicher stellen, dass die Ausgabe verständlich ist.
A pdf dev content QS

12
Wenn Alternativtext nicht ausreicht (z.B. bei komplexen Grafiken wie Infografiken oder Diagrammen), wird eine lange Beschreibung bereitgestellt und im Alternativtext darauf hingewiesen.
Web Developer Toolbar: Images > Display Alt Attributes: Angezeigte Alternativtexte sowie lange Beschreibungen mit Bildern abgleichen.
A pdf design dev content QS

13
Dekorative Grafiken weisen ein leeres alt-Attribut auf.
Web Developer Toolbar: Images > Display Alt Attributes: Angezeigte Alternativtexte mit Bildern abgleichen.
A pdf dev content QS

14
Grafische CAPTCHAs sind barrierefrei umgesetzt oder es gibt eine Alternative.
Screenreader: Versuchen, das Captcha erfolgreich abzuschicken.
A dev QS

1.2.1
15
Für aufgezeichnete reine Audio-Inhalte (z.B. Podcasts) existieren Textabschriften oder eine Audiodeskription. Ausnahme: Wenn der reine Audio-Inhalt eine Alternative für bereits bestehenden Text (und als solche deutlich gekennzeichnet) ist, dann ist keine zusätzliche Textabschrift erforderlich.
Manuelle Prüfung: Textabschrift bzw. Audiodeskription mit Audio-Inhalt vergleichen: Sind die Inhalte gleichwertig?
A design dev content QS

16
Für aufgezeichnete reine Video-Inhalte (z.B. Stummfilme) existieren Textabschriften oder gleichwertige Alternativen als Audio-Inhalt. Ausnahme: Wenn der reine Video-Inhalt eine Alternative für bereits bestehenden Text (und als solche deutlich gekennzeichnet) ist, dann ist keine zusätzliche Textabschrift oder gleichwertige Alternative als Audio-Inhalt erforderlich.
Manuelle Prüfung: Textabschrift mit Video-Inhalt vergleichen: Sind die Inhalte gleichwertig?
A design dev content QS

1.2.2

Untertitel (aufgezeichnet)

A design dev content QS
17
Für aufgezeichnete Video-Inhalte mit Audio (z.B. Spielfilme) existieren gleichwertige, synchrone Untertitel.
Manuelle Prüfung: Untertitel mit Gesprochenem vergleichen: Sind die Inhalte gleichwertig?
A design dev content QS

18
Für synchronisierte Video-Inhalte (Videos, in denen Audio- und Videospur zusammen die komplette Information ergeben) existieren Textabschriften oder Audiodeskriptionen. Für die Audiodeskription gilt: Wenn alle Informationen der Videospur bereits in der Audiospur enthalten sind, ist keine Audiodeskription erforderlich. Ausnahme: Wenn der synchronisierte Video-Inhalt eine Medienalternative für bereits bestehenden Text (und als solche deutlich gekennzeichnet) ist, dann ist keine zusätzliche Textalternative oder Audiodeskription erforderlich. (Dieser Checkpunkt kann vernachlässigt werden, falls Level AA angestrebt wird und damit 1.2.5 in Kraft tritt. Um Konformitätsstufe A zu erreichen, benötigen synchronisierte Video-Inhalte entweder eine Textabschrift oder eine Audiodeskription. Für Konformitätsstufe AA ist immer eine Audiodeskription erforderlich.)
Manuelle Prüfung: Textabschrift mit Video-Inhalt vergleichen: Sind die Inhalte gleichwertig?
A design dev content QS

1.2.4

Untertitel (Live)

AA design dev content QS
19
Für Live Video-Inhalte mit Audio (z.B. Nachrichtensendung) existieren gleichwertige, synchrone Untertitel.
Manuelle Prüfung: Untertitel mit Gesprochenem vergleichen: Sind die Inhalte gleichwertig?
AA design dev content QS

1.2.5

Audiodeskription (aufgezeichnet)

AA design dev content QS
20
Für synchronisierte Video-Inhalte (Videos, in denen Audio- und Videospur zusammen die komplette Information ergeben) existieren Audiodeskriptionen für inhaltlich relevante, rein visuelle Inhalte. Für die Audiodeskription gilt: Wenn alle Informationen der Videospur bereits in der Audiospur enthalten sind, ist keine Audiodeskription erforderlich. (Dieser Checkpunkt kann vernachlässigt werden, falls Konformitätsstufe A angestrebt wird und damit 1.2.3 in Kraft ist. Um Konformitätsstufe A zu erreichen, benötigen synchronisierte Video-Inhalte entweder eine Textabschrift oder eine Audiodeskription. Für Konformitätsstufe AA ist immer eine Audiodeskription erforderlich.)
Manuelle Prüfung: Audiodeskription mit Video-Inhalt vergleichen, inkl. rein visuell wahrnehmbare Handlung: Sind die Inhalte gleichwertig?
AA design dev content QS

1.3.1

Info und Beziehungen

A pdf dev QS
21
Aktive Elemente (z.B. der aktive Menüpunkt in einer Navigation) sind semantisch erkennbar ausgezeichnet, wenn sie visuell klar als aktiv erkennbar sind.
Screenreader: Erkunden und Ausgaben prüfen: Werden aktive Punkte als solche erkennbar ausgegeben?
A dev QS

22
Landmark Roles (HTML5-Elemente wie <header>, <main>, etc. sowie ARIA-Rollen) werden korrekt vergeben. Sie werden mit Bedacht verwendet und konsistent eingesetzt (möglichst keine Mehrfach-Verwendung derselben Rolle, konsistentes Auszeichnen aller wichtigen Seitenbereiche).
Screenreader: Erkunden und Ausgaben prüfen: Werden Seitenbereiche als solche erkennbar ausgegeben?
A dev QS

23
Breadcrumbs oder Prozessanzeigen sind auch nicht-visuell als solche erkennbar.
Screenreader: Erkunden und Ausgaben prüfen: Werden Elemente als solche erkennbar ausgegeben?
A dev QS

24
Fussnoten sind barrierefrei umgesetzt: Auch mit einem Screenreader ist beim Fussnoten-Zeichen der Zugriff auf den Fussnotentext gegeben, ohne dass der ursprüngliche Kontext verloren geht.
Screenreader: Elemente erkunden, mit ihnen interagieren und Ausgaben prüfen: Sind verbundene Informationen einfach auffindbar? Gelingt etwaige Navigation zwischen Text und Fussnote?
A pdf dev QS

1.3.1a

Info und Beziehungen: Überschriften

A pdf design dev content QS
25
Überschriften: Die Hierarchie der Überschriften-Ebenen ist inhaltlich-logisch korrekt und vermittelt die Struktur der Inhalte.
Bookmarklet h123: Ausführen und mit Seite abgleichen: Ist die Hierarchie in sich logisch korrekt?
A pdf design dev content QS

26
Überschriften: Es werden keine Überschriften-Ebenen ausgelassen.
Bookmarklet h123: Ausführen und nach Hierarchiesprüngen suchen.
A pdf design dev content QS

27
Überschriften: Eigenständige Seitenbereiche weisen eine eigene Überschrift auf, da sie sonst der vorausgehenden Überschrift falsch untergeordnet werden. Für Inhalts- und Funktionsblöcke wie Kopf- und Fussbereich, Navigation, Breadcrumb, etc. können visuell unsichtbare Überschriften eingesetzt werden.
Bookmarklet h123: Ausführen und mit Seite abgleichen: Hat jeder Seitenbereich eine Überschrift? Ist deren Beschriftung zutreffend?
A pdf design dev content QS

28
Überschriften: Überschriften weisen nachfolgenden Inhalt (bzw. darunter liegende Überschriften) auf.
Bookmarklet «Inhalte gegliedert»: Ausführen und mit Seite abgleichen: Hat jede Überschrift einen nachfolgenden Inhalt?
A pdf design dev content QS

29
Überschriften: Überschriften sind im Code vor den ihnen zugehörigen Inhalten platziert.
Bookmarklet «Inhalte gegliedert»: Ausführen und mit Seite abgleichen. Zur Sicherheit mit Screenreader nachprüfen.
A pdf design dev content QS

30
Überschriften: Überschriften für Akkordeons sind als solche ausgezeichnet.
Bookmarklet «Inhalte gegliedert»: Ausführen und mit Seite abgleichen: Sind Überschriften in Akkordeons als solche ausgezeichnet?
A dev QS

31
Überschriften: Überschriften sind semantisch korrekt mit dem Überschriften-Element (<h1> bis <h6>) ausgezeichnet.
Bookmarklet «Inhalte gegliedert»: Ausführen und mit Seite abgleichen: Sind Überschriften als solche ausgezeichnet?
A pdf dev content QS

1.3.1b

Info und Beziehungen: Listen

A pdf design dev content QS
32
Listen: Aufzählungen sind semantisch korrekt als Listen (<ul>, <ol>, <dl>) formatiert.
Bookmarklet «Inhalte gegliedert»: Ausführen und mit Seite abgleichen: Sind Aufzählungen als solche ausgezeichnet?
A pdf dev content QS

33
Listen: Listen mit nur einem Eintrag werden vermieden (ausser sie werden automatisch generiert).
Bookmarklet «Inhalte gegliedert»: Ausführen und mit Seite abgleichen: Hat jede Liste mindestens zwei Elemente?
A pdf design dev content QS

34
Listen: Glossare und ähnliche Informationslisten sind als Definitionslisten formatiert.
Bookmarklet «Inhalte gegliedert»: Ausführen und mit Seite abgleichen.
A pdf dev content QS

1.3.1c
35
Formulare: In umfangreichen Formularen werden inhaltlich zusammengehörige Formularfelder mittels <fieldset>/<legend>-Kombination gruppiert.
Bookmarklet «Inhalte gegliedert»: Sind
- und -Elemente vorhanden?
A pdf dev QS

36
Formulare: Informationen, die sich zwischen den Eingabefeldern befinden (z.B. als <p> zwischen mehreren Eingabefeldern) sind verknüpft mit den relevanten Formularfeldern, sodass sie auch mit Screenreadern wahrgenommen werden können (z.B. mit aria-describedby).
Screenreader: Durch Eingabefelder navigieren mittels Tab-Taste und prüfen, ob verknüpfte Elemente dabei auch ausgegeben werden.
A pdf dev QS

37
Formulare: Formularfelder weisen korrekt verknüpfte Labels auf.
Screenreader: Durch Eingabefelder navigieren mittels Tab-Taste und prüfen, ob
A pdf dev QS

1.3.1d

Info und Beziehungen: Daten-Tabellen

A pdf design dev content QS
38
Tabellen: Daten-Tabellen weisen Tabellenüberschriften (<caption>) auf.
Screenreader: Tabelle erkunden und prüfen, ob -Element dabei auch ausgegeben wird.
A pdf design dev content QS

39
Tabellen: Daten-Tabellen weisen Spalten- oder Zeilentitel (<th>) auf, idealerweise beides.
Web Developer Toolbar: Outline > «Show Element Tag Names» aktivieren > Outline Table Cells: Tabelle erkunden und prüfen, ob entsprechende -Elemente vorhanden sind.
A pdf design dev content QS

40
Tabellen: Daten, welche eindeutig tabellarischen Charakter aufweisen, sind semantisch korrekt als Tabelle formatiert und enthalten nur die semantisch zugelassenen Attribute, z.B. keine Paragraphen- (<p>) oder Überschriften-Elemente (<h1> bis <h6>).
Web Developer Toolbar: Outline > «Show Element Tag Names» aktivieren > Outline Table Cells: Tabelle erkunden und prüfen, ob sie semantisch korrekt formatiert sind.
A pdf design dev content QS

41
Tabellen: Daten-Tabellen weisen keine leeren Spalten oder Zeilen auf.
Web Developer Toolbar: Outline > «Show Element Tag Names» aktivieren > Outline Table Cells: Tabelle erkunden und prüfen, ob keine leeren Spalten oder Zeilen vorhanden sind.
A pdf design dev content QS

1.3.1e
42
Zeichenverwendung: Absätze sind semantisch korrekt ausgezeichnet, nicht nur visuell (z.B. mittels doppelten <br>).
Bookmarklet «Inhalte gegliedert»: Ausführen und mit Seite abgleichen: Sind Absätze korrekt ausgezeichnet? Fallen irgendwo
-Elemente ungünstig auf?
A pdf dev content QS

43
Zeichenverwendung: Inhalte befinden sich innerhalb semantisch bedeutsamer HTML-Elemente (z.B. <h#>, <p>, <ul>, <ol>, etc.); das Verwenden von <div>- oder <span>-Elementen (die keine semantische Relevanz aufweisen) ist nicht ausreichend.
Bookmarklet «Inhalte gegliedert»: Ausführen und mit Seite abgleichen: Befinden sich Inhalte in semantisch bedeutsamen Containern?
A dev content QS

44
Zeichenverwendung: Leere bedeutungstragende Elemente werden vermieden.
Bookmarklet «Inhalte gegliedert»: Ausführen und mit Seite abgleichen: Befinden sich irgendwo leere bedeutungstragende Elemente?
A pdf dev content QS

45
Zeichenverwendung: Schriftformatierungen mit Informationsgehalt (z.B. durchgestrichen) sind auch nicht-visuell zugänglich.
Screenreader: Inhalte erkunden und prüfen, ob sie verständlich sind.
A pdf dev content QS

46
Zeichenverwendung: Visuell erkennbare Zitate sind semantisch korrekt ausgezeichnet (z.B. als <blockquote> und <cite>), sodass der jeweilige Text auch beim Einsatz von assistierenden Technologien als Zitat erkannt wird.
Bookmarklet «Inhalte gegliedert»: Ausführen und mit Seite abgleichen: Sind Zitate als solche ausgezeichnet?
A pdf dev content QS

1.3.2
47
Inhalte müssen im Code (DOM) eine korrekte Reihenfolge aufweisen (unabhängig von CSS)
Screenreader: Inhalte erkunden und prüfen, ob sie in der erwarteten Reihenfolge ausgegeben werden.
A dev content QS

1.3.3

Sensorische Eigenschaften

A pdf dev content QS
48
Inhalte weisen nicht ausschliesslich auf sensorische Eigenschaften (rein visuell erkennbar, rein akustisch verständlich) hin, z.B. «Den grünen Schalter links betätigen», «Korrigieren Sie die Eingaben in den rot umrandeten Feldern», «Mit Klick auf das Bild rechts …».
Manuelle Prüfung: Inhalte durchlesen und auf Nennung sensorischer Eigenschaften achten.
A pdf dev content QS

1.3.4

Ausrichtung

AA design dev content QS
49
Inhalte sind in beiden Bildschirmorientierungen (Hoch- und Querformat) korrekt dargestellt und nutzbar. Passt sich der Inhalt nicht automatisch an die Bildschirmorientierung an, steht ein Schalter zur Verfügung zum manuellen Drehen des Bildschirminhalts (für Websites vom Browser sichergestellt, für Mobile Apps durch Design und Entwicklung sicherzustellen).
Manuelle Prüfung: Statt ein echtes mobiles Gerät zu verwenden, können diverse Browser das Rotieren der Ausrichtung auch simulieren, in etwa Firefox: Responsive Design Mode > Rotate View Port.
AA design dev content QS

1.3.5

Eingabezweck erkennen

AA pdf dev QS
50
Eingabefelder zu Nutzerdaten können automatisch ausgefüllt werden.
Web Developer Toolbar: Forms > Display Form Details: Werte des autocomplete-Attributs mit Eingabefeldern vergleichen.
AA pdf dev QS

1.4.1

Benutzung von Farbe

A pdf design dev content QS
51
Information wird nicht durch Farbe allein vermittelt. Das gilt auch für Hover- und Fokus-Zustände. Wenn Information farblich übermittelt wird (z.B. rot hervorgehobene Teile eines Texts, um deren Wichtigkeit zu markieren), ist ein weiterer visueller Reiz vorhanden, um diese Information zu vermitteln (z.B. Fettschrift oder Unterstreichung, unterschiedliche Symbole, zusätzlicher Text).
Manuelle Prüfung: Inhalte durchsehen und auf rein farblich vermittelte Information achten. Kontrastermittlung ggf. durch Colour Contrast Analyser.
A pdf design dev content QS

52
Wenn Links innerhalb von Fliesstext nur durch Farbe vom Fliesstext unterschieden werden, muss der Kontrast zwischen Link und umgebendem Fliesstext den minimalen Kontrastwert von 3:1 erreichen. Als Alternative kann eine weitere visuelle Auszeichnung von Links verwendet werden (z.B. Unterstreichung, Fettschrift, Rahmen, etc.).
Manuelle Prüfung: Inhalte durchsehen und auf rein farblich vermittelte Links achten. Kontrastermittlung ggf. durch Colour Contrast Analyser.
A pdf design dev content QS

1.4.2

Audio-Steuerelement

A design dev QS
53
Automatisch abspielender Audio-Inhalt von mehr als 3 Sekunden wird nach Möglichkeit vermieden. Ist er doch vorhanden, ist er steuerbar (Wiedergabe stoppen, Lautstärke unabhängig von der Systemlautstärke regeln). Die Steuerung befindet sich am Anfang der Seite.
Manuelle Prüfung: Inhalte durchsehen und auf automatisch abspielenden Audio-Inhalt achten.
A design dev QS

1.4.3

Kontrast (Minimum)

AA pdf design dev QS
54
Das Kontrastverhältnis bei Text und Bildern von Text zum Hintergrund beträgt mindstens 4.5:1 bei normaler Schriftgrösse und mindestens 3:1 bei grosser Schrift (definiert als mindestens 18pt oder 14pt + fett). Das gilt sowohl für normale Schrift zur Hintergrundfarbe (alle Texte und Hinweise) als auch für Texte in informativen grafischen Elementen, ist aber nicht zwingend für Logos oder rein dekorative Grafiken.
Manuelle Prüfung: Inhalte durchsehen und auf schwache Kontraste achten. Kontrastermittlung ggf. durch Colour Contrast Analyser.
AA pdf design dev QS

55
Interaktive Textelemente (z.B. Schalterbeschriftungen) erfüllen die Kontrastanforderung von 4.5:1 in allen Zuständen (fokussiert, bei Mouseover, etc.) gleichermassen. Für die Unterscheidbarkeit zwischen den Zuständen eines interaktiven Elements gelten keine strikten Kontrastanforderungen.
Manuelle Prüfung: Elemente durchsehen, mit ihnen interagieren und auf schwache Kontraste achten. Kontrastermittlung ggf. durch Colour Contrast Analyser.
AA design dev QS

1.4.4

Textgrösse ändern

AA pdf design dev content QS
56
Elemente sind auf mindestens 200% zoombar, entweder der Text allein oder die komplette Seite (für Websites in der Regel vom Browser sichergestellt, für Mobile Apps durch Design und Entwicklung sicherzustellen).
Browser: Zoom schrittweise auf 200% erhöhen und auf erwartungsgemässe Anpassung der Inhalte achten.
AA pdf design dev content QS

1.4.5

Bilder eines Textes

AA pdf dev content QS
57
Texte werden nicht nur als Grafiken eingebunden, denn diese lassen keine Anpassungen zu (z.B. Grösse skalieren, Vorder- und Hintergrund-Farben verändern, etc.). Ausgenommen sind Texte, bei denen eine bestimmte Art der Präsentation für die vermittelte Information unentbehrlich ist (z.B. Logos oder Markennamen).
Manuelle Prüfung: Elemente durchsehen und Schriftgrafiken ermitteln.
AA pdf dev content QS

1.4.10

Reflow (Umbruch)

AA design dev content QS
58
Inhalt lässt sich ohne Einschränkungen (z.B. Überlappungen) und ohne horizontales Scrollen in den Viewport-Mindestdimensionen von 320x256 CSS-Pixel darstellen. Das entspricht einer Vergrösserung auf 400%.
Browser: Zoom schrittweise auf 400% erhöhen und darauf achten, dass keine Darstellungsprobleme auftreten (z.B. Überlappungen), sowie dass höchstens in eine Richtung gescrollt werden muss.
AA design dev content QS

1.4.11

Kontrast von Nicht-Text-Inhalten

AA pdf design dev QS
59
Das Kontrastverhältnis von Bedienelementen (z.B. Textfelder, Radiobuttons, Checkboxen, Schalter, Tabs, etc.) zu den umgebenden Farben beträgt mindestens 3:1. Das gilt für alle visuellen Hinweise, die für die Wahrnehmung und Bedienung erforderlich sind (z.B. Formularfeldbegrenzungen, Ausklappindikatoren bei Flyouts/Dropdowns, Häkchen in einer Checkbox, etc.), insbesondere auch für die Wahrnehmung des Zustands eines Elements. Der Hover-Zustand eines Elements muss nicht unterscheidbar sein vom Standard-Zustand.
Manuelle Prüfung: Elemente durchsehen, mit ihnen interagieren und auf schwache Kontraste achten. Kontrastermittlung ggf. durch Colour Contrast Analyser.
AA pdf design dev QS

60
Das Kontrastverhältnis bei informativen grafischen Elementen (z.B. Linien und Kurven in Diagrammen) zu den umgebenden Farben beträgt mindestens 3:1. Das gilt für alle visuellen Hinweise, die für die Wahrnehmung und Bedienung erforderlich sind (z.B. Schalter zum Anpassen der Kurven). Der Hover-Zustand eines Elements muss nicht unterscheidbar sein vom Standard-Zustand.
Manuelle Prüfung: Inhalte durchsehen und auf schwache Kontraste achten. Kontrastermittlung ggf. durch Colour Contrast Analyser.
AA pdf design dev QS

1.4.12

Textabstände

AA design dev QS
61
Abstände zwischen Zeilen, Wörtern und Buchstaben sowie nach Absätzen sind ohne resultierende Einschränkungen um bestimmte Werte vergrösserbar. Ausnahmen sind: Untertitel in Video-Inhalten, PDF-Dokumente.
Bookmarklet «Text-Spacing»: Ausführen und auf erwartungsgemässe Anpassung der Inhalte achten.
AA design dev QS

1.4.13
62
Inhalte, die per Hover oder Fokus eingeblendet werden, sind nicht störend und es kann mit ihnen interagiert werden. Folgende drei Bedingungen sind erfüllt: Per Hover oder Fokus eingeblendete Inhalte sind ausblendbar, hoverbar und dauerhaft (persistent).
Manuelle Prüfung: Elemente durchsehen, mit ihnen interagieren und darauf achten, dass sie sich erwartungsgemäss verhalten: Können Inhalte ein-/ausgeblendet werden? Können per Hover eingeblendete Inhalte selbst auch gehovert werden? Bleiben dauerhaft Inhalte angezeigt?
AA dev QS

2.1.1

Tastatur

A dev QS
63
Inhalte/Funktionalitäten (Seitenfunktionalitäten, Seitenelemente, Formularfelder, Kontrollelemente, Schalter, Links, Dialoge, Multimedia-Steuerungen, etc.) sind mit der Tastatur alleine (d.h. ohne Zeigegerät) bedienbar. Elemente sind in der logischen Tab-Reihenfolge erreichbar und können erwartungsgemäss bedient werden.
Tastatur: Durch Elemente navigieren mittels Tab-Taste, mit ihnen interagieren und darauf achten, dass sie sich erwartungsgemäss verhalten: Aktivieren mittels Enter- oder Leer-Taste, weitere Interaktionsmöglichkeiten oftmals mittels Pfeiltasten.
A dev QS

64
Elemente, die einzeln ausgegeben werden sollen, sind als display: block ausgezeichnet, sonst können sie im Browse-Mode (normale Inhaltsnavigation mittels Pfeil-Tasten) nicht einzeln angesteuert werden. Dies gilt hauptsächlich für interaktive Elemente (Links, Buttons, etc.).
Screenreader: Inhalte erkunden und prüfen, ob sie erwartungsgemäss einzeln ausgegeben werden.
A dev QS

65
Elemente, die von Screenreadern zusammen ausgegeben werden sollen (etwa eine Überschrift, die sowohl eine Kategorie als auch ein Datum enthält), sind als display: inline bzw. display: inline-block ausgezeichnet und befinden sich zusammen in einem display: block-Container.
Screenreader: Inhalte erkunden und prüfen, ob sie erwartungsgemäss gemeinsam ausgegeben werden.
A dev QS

2.1.2

Keine Tastaturfalle

A pdf dev QS
66
Es treten keine Tastaturfallen auf. Alle Bedienelemente können mit der Tastatur erreicht und wieder verlassen werden. Die uneingeschränkte Navigation rückwärts mit Shift+Tab ist sichergestellt.
Tastatur: Durch Elemente navigieren mittels Tab-Taste und darauf achten, dass alle Elemente erreicht und wieder verlassen werden können.
A pdf dev QS

2.1.4

Zeichen-Tastenkürzel

A design dev QS
67
Einzeltasten-Kurzbefehle (bestehend aus einer einzelnen Buchstaben-, Interpunktions-, Zahlen- oder Symbolzeichentaste) sind entweder deaktivierbar oder veränderbar oder nur bei Fokus aktiv.
Bookmarklet «Tastatur-Kurzbefehle auslösen»: Ausführen und auf Veränderungen der Inhalte achten: Hat sich irgendwo ein Element verändert, oder ist eines neu aufgetaucht bzw. verschwunden? Wurde der Fokus irgendwohin gesetzt?
A design dev QS

2.2.1

Zeiteinteilung anpassbar

A design dev QS
68
Timeout-Zeitintervalle sind anpassbar oder können deaktiviert werden. Es ist ein deutlicher Hinweis auf diese Möglichkeiten erforderlich. Für die Anpassungsmöglichkeiten gilt: Entweder ist das Timeout auf mindestens den zehnfachen Wert der Standardeinstellung möglich oder es erfolgt eine Warnung, bevor das Timeout abläuft, und es werden mindestens 20 Sekunden zur Verfügung gestellt, um mit einer einfachen Aktion (z.B. «Drücken Sie die Leertaste») die verfügbare Zeit zu verlängern. Diese Option muss mindestens zehn Mal bestehen.
Manuelle Prüfung: Prozesse durchlaufen und darauf achten, dass sie sich erwartungsgemäss verhalten: Können Zeitintervalle angepasst werden? Sind sie frühzeitig erfahrbar und verlängerbar (auch mittels Tastatur bzw. Screenreader)? Ggf. Rücksprache mit Seitenbetreiber halten, um keine Zeitintervalle zu übersehen.
A design dev QS

2.2.2

Pausieren, beenden, ausblenden

A design dev content QS
69
Dauerhaft animierte Inhalte (länger als fünf Sekunden) können mittels gut sichtbarer Bedienelemente pausiert, gestoppt oder ausgeblendet werden. Als dauerhaft animiert gelten Inhalte, die sich bewegen und/oder automatisch aktualisieren, die blinken oder scrollen. Sie beginnen automatisch und werden parallel zu anderen Inhalten dargestellt.
Manuelle Prüfung: Inhalte durchsehen, mit ihnen interagieren und darauf achten, dass sie sich erwartungsgemäss verhalten: Können animierte Inhalte pausiert, gestoppt oder ausgeblendet werden?
A design dev content QS

2.3.1
70
Es gibt keine Elemente, die öfter als dreimal in einer Sekunde blitzen, oder der Blitz ist unterhalb eines definierten Grenzwerts für Blitze.
Photosensitive Epilepsy Analysis Tool (PEAT): Im Zweifelsfall Screencapture-Video als .avi erstellen und mit Prüftool analysieren.
A design dev content QS

2.4.1

Blöcke umgehen

A design dev QS
71
Sprunglinks ermöglichen das einfache Überspringen von sich wiederholenden Informationsblöcken (z.B. Navigation, Headerbereich) mit der Tastatur.
Tastatur: Nach Seiten-Laden direkt die Tab-Taste drücken und darauf achten, ob angewähltes Element ein Sprunglink ist, und ob er wie erwartet funktioniert.
A design dev QS

2.4.2

Seite mit Titel versehen

A pdf design dev content QS
72
Seiten haben einen eindeutigen, aussagekräftigen Titel, der Thema oder Zweck der Seite sowie den Betreiber enthält (Muster: "Thema/Zweck der Seite - Seitenbetreiberin")
Manuelle Prüfung: Seiten durchsehen und darauf achten, dass deren Titel den Erwarungen entsprechen: Thema/Zweck vorhanden? Betreiberin vorhanden?
A pdf design dev content QS

2.4.3

Fokus-Reihenfolge

A pdf design dev QS
73
Die Fokus-Reihenfolge ist sinnvoll, d.h. intuitiv verständlich und nachvollziehbar.
Tastatur: Durch Elemente navigieren mittels Tab-Taste und darauf achten, dass die Reihenfolge der Elemente sinnvoll ist.
A pdf design dev QS

74
Der Tastatur-Fokus wird sinnvoll geführt, wenn jemand mit Elementen auf der Seite interagiert, die zu einer Veränderung innerhalb der Seite führen (ohne Page-Refresh), z.B. nach dem Klick auf einen Schalter, der einen Dialog anzeigt (Erreichen des Dialogs und Interagieren im Dialog, Verlassen desselben, Fokus zurück auf das dialog-auslösende Element, Weiternavigieren auf der Seite).
Tastatur: Durch Elemente navigieren mittels Tab-Taste, mit ihnen interagieren und darauf achten, dass die Fokusführung sinnvoll ist.
A pdf design dev QS

75
Unternavigationspunkte können mit der Tastatur übersprungen werden. Unternavigationen werden entweder erst auf Auslösen geöffnet (z.B. mittels Enter- oder Pfeil-nach unten-Taste) oder Unternavigationen werden zwar angezeigt, mit der Tabulator-Taste wird aber zum nächsten Hauptnavigationspunkt gesprungen (Hineinnavigieren in die Unternavigation nur mit Pfeil-Tasten).
Tastatur: Durch Elemente navigieren mittels Tab-Taste, mit ihnen interagieren und darauf achten, dass Unternavigationspunkte übersprungen werden können.
A design dev QS

76
Elemente sind korrekt versteckt und zwar so, dass sie auch durch assistierende Technologien nicht ausgegeben werden, wenn sie visuell nicht sichtbar sind.
Screenreader: Inhalte erkunden und prüfen, ob sie erwartungsgemäss ausgegeben werden. Tastatur: Durch Elemente navigieren mittels Tab-Taste und darauf achten, dass keine visuell versteckten Elemente fokussiert werden können.
A pdf dev QS

2.4.4

Linkzweck (im Kontext)

A pdf design dev content QS
77
Link-Texte sind selbstsprechend, d.h. aus sich selbst heraus oder über den Kontext (gleiches <p>-Element, gleiches Listenelement, gleiche Tabellenzelle, Spalten- oder Zeilenüberschrift in Tabelle) verständlich.
Screenreader: Links auflisten und prüfen, ob diese selbstsprechend sind.
A pdf dev content QS

78
Mehrfache, unterschiedliche Links (z.B. eine Überschrift, eine Grafik und ein zusätzlicher Textlink) auf dasselbe Ziel werden vermieden.
Screenreader: Links auflisten und prüfen, ob mehrfache Verlinkungen vorhanden sind.
A pdf design dev content QS

2.4.5

Verschiedene Methoden

AA design dev QS
79
Es existieren mindestens zwei der folgenden drei Methoden, um Zugang zu Inhalten zu bekommen: Navigation, Suchfunktion, Sitemap.
Manuelle Prüfung: Webauftritt durchsehen und prüfen, ob eine Suchfunktion oder Sitemap existiert.
AA design dev QS

2.4.6

Überschriften und Beschriftungen (Labels)

AA pdf design dev content QS
80
Überschriften und Labels (z.B. in Eingabefeldern, bei Schaltern, etc.) sind ausreichend informativ und korrekt und bezeichnen den zugeordneten Web-Inhalt verständlich. Es gibt keine gleichlautenden Überschriften oder Labels auf einer Seite.
Bookmarklet h123: Ausführen und mit Seite abgleichen: Sind Überschriften informativ?
AA pdf design dev content QS

2.4.7

Fokus sichtbar

AA design dev QS
81
Der Tastaturfokus ist genügend sichtbar, z.B. durch einen gut sichtbaren Rahmen (für alle fokussierbaren Elemente wie Links, Schaltflächen, Radio-Buttons, Checkboxen, Ausklapplisten, verlinkte grafische Elemente, etc.).
Tastatur: Durch Elemente navigieren mittels Tab-Taste und darauf achten, dass Fokus sichtbar ist.
AA design dev QS

82
Sprunglinks werden bei Tastaturbedienung sichtbar.
Tastatur: Nach Seiten-Laden direkt die Tab-Taste drücken und darauf achten, ob angewähltes Element ein Sprunglink ist, und ob er wie erwartet angezeigt wird.
AA design dev QS

2.5.1

Zeigergesten

A design dev QS
83
Zeigergesten erfordern keinen bestimmten Pfad oder Mehrfach-Touch oder es bestehen konventionelle Alternativen dazu.
Manuelle Prüfung: Elemente durchsehen, mit ihnen interagieren und sicherstellen, dass gleichwertige alternative Eingabemethoden vorhanden sind.
A design dev QS

2.5.2
84
Zeigereingaben sind abbrechbar oder können rückgängig gemacht werden.
Bookmarklet «Down-Events auslösen»: Ausführen und auf Veränderungen achten. Wenn ein Down-Event ausgelöst wurde, prüfen, ob eine Ausnahme zutrifft (Abort, Undo, Up Reversal, Essential).
A pdf dev QS

85
Die zugängliche Beschriftung eines Bedienelements entspricht exakt der visuellen oder beinhaltet sie (ermöglicht v.a. Sprachsteuerung).
Screenreader: Durch Bedienelemente navigieren mittels Tab-Taste und prüfen, ob Ausgabe der visuellen Beschriftung entspricht.
A pdf dev QS

2.5.4

Ausführen durch Bewegung

A design dev QS
86
Durch Gerätebewegung ausgeführte Funktionalität kann auch durch konventionelle Eingabemethoden angesteuert und deaktiviert werden.
Manuelle Prüfung: Elemente durchsehen, mit ihnen interagieren und sicherstellen, dass mit ihnen auch durch konventionelle Eingabemethoden gleichwertig interagiert werden kann.
A design dev QS

3.1.1

Sprache der Seite

A pdf dev QS
87
Die Sprachdeklaration ist vorhanden und korrekt.
Manuelle Prüfung: Seiten durchsehen und darauf achten, dass sie das korrekte lang-Attribut im -Tag gesetzt haben.
A pdf dev QS

3.1.2

Sprache von Teilen

AA pdf dev content QS
88
Sprachwechsel bei längeren Textpassagen werden angegeben: Anderssprachige Textabschnitte sind mit dem lang-Attribut ausgezeichnet. Bei kurzen anderssprachigen Textpassagen (einzelne Wörter) wird auf den Sprachwechsel verzichtet.
Manuelle Prüfung: Seiten durchsehen und darauf achten, dass Inhalte mit Sprachwechsel das korrekte lang-Attribut gesetzt haben.
AA pdf dev content QS

3.2.1

Bei Fokus

A dev QS
89
Der Kontext ändert sich nicht automatisch bei Fokus (z.B. Weiterleitung auf eine andere Seite).
Tastatur: Durch Elemente navigieren mittels Tab-Taste und darauf achten, dass bei Fokus keine Änderung des Kontexts geschieht.
A dev QS

3.2.2

Bei Eingabe

A dev QS
90
Der Kontext ändert sich nicht automatisch bei Eingabe (z.B. Weiterleitung auf eine andere Seite).
Tastatur: Durch Elemente navigieren mittels Tab-Taste und darauf achten, dass bei Eingabe keine Änderung des Kontexts geschieht.
A dev QS

3.2.3

Konsistente Navigation

AA design dev QS
91
Die Navigation ist konsistent, d.h. innerhalb einer Anwendung gleichbleibend angeordnet und aufgebaut.
Manuelle Prüfung: Seiten durchsehen und darauf achten, dass die Navigation konsistent ist.
AA design dev QS

3.2.4

Konsistente Erkennung

AA pdf design dev QS
92
Bestandteile mit gleicher Funktion sind konsistent umgesetzt, sowohl auf visueller wie auch auf semantischer Ebene.
Manuelle Prüfung: Seiten durchsehen und darauf achten, dass Elemente konsistent umgesetzt sind.
AA pdf design dev QS

3.3.1

Fehlererkennung

A pdf dev QS
93
Fehlermeldungen in Formularen sind barrierefrei umgesetzt: Automatisch erkannte Eingabefehler geben in der Fehlermeldung einen klaren Hinweis (in Textform) auf das fehlerhafte Element und sind mit diesem eindeutig verknüpft.
Screenreader: Mit Formular interagieren und prüfen, ob Fehlermeldungen wie erwartet ausgegeben werden.
A pdf dev QS

3.3.2
94
Pflichtfelder sind zugänglich ausgezeichnet, sowohl auf visueller wie nicht-visueller Ebene, z.B. mit required-Attribut.
Screenreader: Durch Pflichtfelder navigieren mittels Tab-Taste und prüfen, ob diese als solche ausgegeben werden.
A pdf design dev QS

95
Formularfelder verfügen über visuell sichtbare Labels. Die alleinige Verwendung von placeholder-Attributen zur Beschriftung von Formularfeldern wird vermieden.
Tastatur: Durch Eingabefelder navigieren mittels Tab-Taste und darauf achten, dass sie immer ein Label haben und dass dieses auch bei Fokus sichtbar bleibt.
A pdf design dev QS

96
Formatangaben bei Formularfeldern sind zugänglich und mit den zugehörigen Eingabefeldern eindeutig verknüpft, d.h. zusätzlich angegebene Hinweise zu Eingabeformaten sind auch durch assistierende Technologien korrekt erfassbar.
Screenreader: Durch Pflichtfelder navigieren mittels Tab-Taste und prüfen, ob Formatangaben und zusätzliche Hinweise ausgegeben werden.
A pdf dev QS

3.3.3

Fehlerempfehlung

AA pdf dev QS
97
Fehlermeldungen sind informativ und mit den zugehörigen Eingabefeldern eindeutig verknüpft: Es sind Korrekturempfehlungen vorhanden, wenn falsche Benutzereingaben erfolgen.
Manuelle Prüfung: Fehlermeldungen durchsehen und Informationsgehalt beurteilen.
AA pdf dev QS

98
Nutzereingaben müssen überprüfbar sein vor Prozess-Abschluss mit finanziellen/rechtlichen Folgen. Es ist sichergestellt, dass die Gelegenheit besteht, eingegebenen Daten zu überprüfen und gegebenenfalls zu korrigieren, bevor ein endgültiger Abschluss erfolgt.
Manuelle Prüfung: Prozesse durchlaufen und darauf achten, dass vor Abschluss eine Zusammenfassung der Daten (mit Möglichkeit zur Korrektur) angezeigt wird.
AA design dev QS

4.1.1

Syntaxanalyse

A dev QS
99
Der HTML-Code weist keine für die Barrierefreiheit relevanten Fehler auf.
TotalValidator: Seiten validieren und Resultate auf relevante Probleme hin prüfen.
A dev QS

4.1.2

Name, Rolle, Wert

A pdf dev QS
100
Akkordeons sind barrierefrei umgesetzt. Sie werden durch Screenreader korrekt angesagt, ihr Status wird vermittelt (z.B. «reduziert» bzw. «erweitert»).
Screenreader: Mit Akkordeons interagieren und sicherstellen, dass sie sich wie erwartet verhalten.
A dev QS

101
Autocompletes sind barrierefrei umgesetzt. Sie werden durch Screenreader korrekt angesagt, die Anzahl aktuell verfügbarer Vorschläge, der aktuelle Eintrag beim Navigieren der Optionen sowie die schlussendlich gewählte Option werden durch Screenreader vermittelt.
Screenreader: Mit Autocompletes interagieren und sicherstellen, dass sie sich wie erwartet verhalten.
A dev QS

102
Datumswähler sind barrierefrei umgesetzt, sofern keine Alternative dazu besteht (z.B. manuelle Datumseingabe in Formularfeld). Sie werden durch Screenreader korrekt angesagt, der aktuelle Eintrag beim Navigieren der Optionen sowie die schlussendlich gewählte Option werden durch Screenreader vermittelt.
Screenreader: Mit Datumswählern interagieren und sicherstellen, dass sie sich wie erwartet verhalten.
A dev QS

103
Dialoge (auch Modale, Overlays, Lightboxes, etc. genannt) sind barrierefrei umgesetzt. Sie werden durch Screenreader korrekt angesagt; das Element, das den Dialog öffnet, weist auf den Dialog hin.
Screenreader: Mit Dialogen interagieren und sicherstellen, dass sie sich wie erwartet verhalten.
A dev QS

104
Dropdowns (auch Mega-Dropdowns) sind barrierefrei umgesetzt. Sie werden durch Screenreader korrekt angesagt, ihr Status wird vermittelt (z.B. «erweitert» bzw. «reduziert»), der aktuelle Eintrag beim Navigieren der Optionen wird durch Screenreader vermittelt.
Screenreader: Mit Dropdowns interagieren und sicherstellen, dass sie sich wie erwartet verhalten.
A dev QS

105
Karusselle (Slider) sind barrierefrei umgesetzt. Sie werden durch Screenreader korrekt angesagt.
Screenreader: Mit Karussellen interagieren und sicherstellen, dass sie sich wie erwartet verhalten.
A dev QS

106
Tabs (Registerkarten) sind barrierefrei umgesetzt. Sie werden durch Screenreader korrekt angesagt, ihr Status wird vermittelt (z.B. «aktiv» bzw. «nicht aktiv»).
Screenreader: Mit Tabs interagieren und sicherstellen, dass sie sich wie erwartet verhalten.
A dev QS

107
Tooltips sind barrierefrei umgesetzt. Einfache, kurze Inhalte werden durch Screenreader sogleich angesagt. Beinhalten Tooltips komplexe Inhalte, so müssen diese manuell gelesen werden können (in diesem Fall handelt es sich eher um einen Dialog).
Screenreader: Mit Tooltips interagieren und sicherstellen, dass sie sich wie erwartet verhalten. Tastatur: Obige Prozedur wiederholen.
A dev QS

108
Weitere JavaScript-Widgets sind barrierefrei zugänglich, d.h. so programmiert, dass sie mittels assistierender Technologien verstanden und uneingeschränkt verwendet werden können. Sie werden z.B. durch Screenreader korrekt angesagt; Funktion, Rolle und Status werden korrekt und aktuell vermittelt.
Screenreader: Mit JavaScript-Widgets interagieren und sicherstellen, dass sie sich wie erwartet verhalten.
A dev QS

109
Der Einsatz von ARIA ist sinnvoll und korrekt. Wann immer möglich werden Standard-HTML-Elemente verwendet; ARIA wird eingesetzt wenn kein entsprechendes HTML-Element existiert oder weil eine technische Notwendigkeit dafür besteht.
Screenreader: Mit JavaScript-Widgets interagieren und sicherstellen, dass sie sich wie erwartet verhalten.
A dev QS

110
Formular-Schalter sind korrekt umgesetzt (als <button>-Element oder <input type="submit">-Element).
Screenreader: Formularelemente auflisten und prüfen, ob Schalter korrekt umgesetzt sind.
A pdf dev QS

4.1.3

Statusmeldungen

AA pdf dev QS
111
Statusmeldungen sind für assistierende Technologien zugänglich und überstrapazieren den Audiokanal nicht.
Screenreader: Sicherstellen, dass Statusmeldungen sich wie erwartet verhalten.
AA pdf dev QS