Prüfung nach offiziellem WCAG 2.2 (https://www.w3.org/TR/WCAG22/) auf Level AA
Sinnvolle alt Attribute für inhaltswichtige Bilder und Bedienelemente, ein leeres alt Attribut (alt=““) für unwichtige Bilder wie z.B. Teaserbilder mit dabeistehender Textinformation oder Dekografiken, eine Ersatzlösung für grafische Captchas (Audio Captcha), Beschreibung für Diagramme oder Charts, title Attribut bei zeitbasierten Medien (Audio, Video, Animationen…), title Attribut für (i)frames, zusätzlicher (visuell versteckter) Text bei informationstragenden Hintergrundbildern, Überprüfung der Screenreaderausgabe bei Font-Icons (ev. Verstecken mit aria-hidden Attribut und zusätzliche Textinformation), ev. aria-label bei grafischen Buttons
Keine Bilder enthalten, wenn ein benutzerdefiniertes Logo enthalten ist kann hier selber ein ALT Attribut vergeben werden.
Der Link auf Datareporter wird mit einem Logo angezeigt, das über Aria labels verfügt und bei Bedarf ausgeblendet werden kann.
sofern sie nicht nur eine Medienalternative zu Textinhalten sind und klar als solche markiert werden
Transkription von Hörbeiträgen für Menschen mit Hörbehinderung, bei Video ohne Sprache wäre statt der Beschreibung in Textform auch eine Beschreibung des visuellen Inhalts im Audiotrack für blinde User möglich.
Keine Audio- und Videobeiträge im Banner enthalten
Untertitel mit Dialog, Sprecheridentifikation, wichtigen Geräuschen in vertonten Videos für Menschen mit Hörbehinderung
Keine Audio- und Videobeiträge im Banner enthalten
Transkription oder Beschreibung des Videoinhaltes im Audiotrack für blinde Menschen
Keine Audio- und Videobeiträge im Banner enthalten
Keine live Audio- und Videobeiträge im Banner enthalten
Keine live Audio- und Videobeiträge im Banner enthalten
Webnutzer:innen können Websites individuell anpassen, z.B. ohne Farbe, ohne Bilder, vergrößert, mit Zoomsoftware, mit Braillezeile, am Handy lesen…
Inhalte sind maschinenlesbar, auch für blinde Menschen mit Screen Readern, oder sie sind als Text verfügbar.
Die Inhalte wurden mit Screen Readern getestet und sind strukturell korrekt. Alle Inhalte sind als Text verfügbar.
auch ohne grafische Ansicht, korrekte Lesereihenfolge (bei Navigation mit Pfeiltasten mit Screenreader), lineare Lesbarkeit bei Tabellen.
Die Reihenfolge der Bedienung wurde in einen sinnvollen logischen Kontext gesetzt, um den Banner einfach bedienen zu können. Die Reihenfolge wurde mit sehbehinderten Menschen abgestimmt.
Bedienbarkeit und Verständnis hängen nicht von grafischer Oberfläche (von Form, Größe oder Positionierung von Komponenten) oder Sound ab.
Farbe und Größe der Inhalte können in WebCare individuell eingestellt werden. Hier ist es in der Verantwortung des Benutzers, eine barrierefreie Einstellung zu treffen.
Keine Display Fixierung auf Touchscreens, Wechsel zwischen Landscape oder Portraitmodus ist möglich.
Der Banner wurde sowohl auf Mobile (Landscape und Portrait) als auch auf Desktopansichten optimiert.
Benutzen standardisierter vordefinierter Taxonomie bei Inputfeldern, damit Browser bereits gespeicherte Daten wiederverwenden können (für z.B. die E-Mail Adresse), HTML autocomplete funktioniert.
Die einzigen Eingabefelder sind die Checkboxen zum Zustimmen einzelner Kategorien. Diese sind intern als INPUT(checkbox) realisiert und
werden von gängigen Screenreadern auch interpretiert.
z.B. bei Links im Fließtext zusätzliche visuelle Markierung (wie unterstreichen), zusätzliches Muster bei Diagrammen mit verschiedenfarbigen Teilen, Fehlermarkierung bei Formularen nicht nur durch Farbe (wichtig für Menschen mit Farbfehlsichtigkeiten)
Farben werden nur als Zusatz zur Beschriftung verwendet (z.B. bei Switches).
Automatisch abspielendes Audio (länger als 3 sec.) muss abschaltbar oder unabhängig von Systemlautstärke-Regelung steuerbar sein (damit Vorlesesoftware nicht gestört wird)
Es gibt keine Audioausgabe.
außer er ist rein dekorativ oder ein Logo, größerer Text (18pt oder 14pt fettgedruckt) hat eine Kontrastverhältnis von 3:1
Farben sind vollständig durch den Benutzer konfigurierbar.
ohne Verlust von Inhalt oder Funktionalität, bei Browserbreite von 1280px, ausgenommen sind Captions und Text in Grafikform; Browserzoom ist ausreichend, mögliche Nur-Textvergrößerung ideal, Zoom muss auch auf mobilen Geräten möglich (d.h. darf nicht deaktiviert) sein.
Browserzoom jederzeit möglich, auch Textzoom bis 200 % möglich (Desktop). Mobil ist der Zoom ebenfalls verfügbar.
Sollten Texte oder Wörter falsch umbegrochen werden, so kann der Umbruch bei den WebCare - Texten mittels
­erzwungen werden. So würde zum Beispiel die Überschrift "Speicherdauer" in den Cookietabellen mittelsSpeicher­dauerkorrekt umgebrochen werden.
soweit mit verwendeter Technik für die visuelle Präsentation möglich, außer Grafik ist notwendig wie z.B bei Logos, oder die Textgrafiken sind visuell anpassbar an Nutzerbedürfnisse. Webfonts statt grafischer Text, Textwiedergabe im alt-Attribut bei Textgrafiken, Hintergrundbilder im CSS mit visuell versteckter Textinformation sind nicht geeignet für Accessibility Anpassungen im Betriebssystem (Kontrastmodus) oder Verwendung eigener User Stylesheets; PDFs müssen extrahierbaren Text enthalten.
Es werden keine Grafiken verwendet die Text enthalten
responsives Design, damit Inhalte auch bei 320px Auflösung (iPhone) ohne Scrollen in 2 Dimensionen lesbar sind, das entspricht 400% Zoom bei 1280px.
Der Banner ist auch bei 320 x 256 Pixel CSS Auflösung ohne scrollen in beide Richtungen bedienbar.
Icons, Grafiken, Diagramme benötigen Kontrastwert 3:1
Keine nicht-text Inhalt im Banner enthalten
Text ist noch gut lesbar bzw. ohne Überlagerungen bei Anpassung von Abständen durch eigene Stylesheets: Zeilenhöhe 1,5 x Schriftgröße, Abstand nach Absätzen 2 x Schriftgröße, Abstand zwischen Wörtern ( 0,16 x Schriftgröße) und Buchstaben (0,12x Schriftgröße).
Der Text passt sich responsive an, daher kein Verlust von Funktionalität oder Inhalten.
Es gibt keine Hover / Fokus Elemente im Banner
Alle interaktiven Elemente sind mit Tabtaste erreichbar und Entertaste bedienbar.
Sämtliche Elemente sind rein mit der Tastatur in logischer Reihenfolge bedienbar.
Overlays müssen sich (auch mit Tastatur) schließen lassen, aus eingebetteten Anwendungen muss man mit Pfeil-, Tab- oder Escapetaste wieder hinauskommen, kein endlos Scrollen, keine Tastaturkürzel, die bereits im Browsermenü oder Screen Reader in Verwendung sind.
Der gesamte Banner lässt sich mit ESC (Nich Einwilligen) oder Return (Einwilligen) schliessen. Es sind keine Tastaturfallen enthalten.
Relevant, wenn selbstdefinierte Tastatur Shortcuts nur aus Buchstaben, Punktuation, Zahlen, Symbolen bestehen, sie müssen sich abschalten oder umdefinieren lassen oder dürfen nur bei Fokus aktivierbar sein.
Keine sonderdefinierten Shortcuts im Banner enthalten.
Keine Zeitlimits im Banner enthalten
Keine animierten Inhalte enthalten.
oder der Helligkeitsunterschied muss unterhalb definierter Schwellenwerte (general flash and red flash thresholds) bleiben. (A)
Es werden keine blinkenden Animationen verwendet.
Keine wiederholenden Inhaltsblöcke enthalten
Nicht für Banner anwendbar
z.B. bei Links, Formularelementen, dynamischer Einbindung oder Änderung von Content; Fokushandling – Fokus wird in Lightboxen und Modale Dialoge gesetzt, Darüberhinaustabben wird unterbunden; tabindex nur setzen, wenn absolut notwendig, tabindex=“0″ bei Verwendung von nicht nativen interaktiven Elementen, Links mit href
Da der Banner auf der eigentlichen Webseite eingebunden wird, muss die Standard-tabindex Reihenfolge der Seite überschrieben werden solange der Banner angezeigt wird (absolut notwendig). Die Fokus Reihenfolge wurde logisch in Zusammenarbeit mit sehbehinderten Personen definiert.
Selbsterklärende oder zumindestens im unmittelbaren Kontext verständliche Links
Linkziel im alt Attribut bei verlinkten Bildern, Vermeiden von unklaren Linkbezeichnungen wie „Klicken Sie hier“. Erlaubt sind sich wiederholende, gleichlautende, nicht selbsterklärende Links (z.B. „Mehr“, „Download“…) unterhalb von unterscheidenden Überschriften, Tableheadern oder innerhalb von untergeordneten Listen, im gleichen Satz oder Absatz.
Sämtliche Texte in Links sind bearbeitbar und einem Bereich zuordenbar. Die "Details anzeigen" Links sind im gleichen Absatz wie die Kategorie und deshalb erlaubt.
Für Banner nicht relevant.
Sämtliche Überschriften und Labels sind vom Benutzer bearbeitbar.
Der Tastaturfokus wurde extra für den Banner implementiert um gut sichtbar zu sein.
Der Tastaturfokus wird nicht von fix positioniertem Inhalt überlagert, z.B. darf ein Aufklappmenü nicht gerade fokussierten Inhalt im Hintergrund überlagern, wenn man den Tastaturfokus verändern muss, um es zu schließen.
Keine überlappende Inhalte im Banner, daher wird nichts verdeckt.
Machen Sie es einfach für User, Funktionalitäten mit verschiedenen Inputmethoden zu bedienen, abgesehen von der Tastatur
Relevant bei Mobilen Applikationen, Gesten auf Touchscreens, Mauszeiger, Stift, Laser-Pointer. Für komplexe Pointer-Gesten (Maus oder Touch) gibt es einfache (tastaturbedienbare) Alternativen.
Keine Gesten für die Bedienung erforderlich.
Pointer-Eingaben können widerrufen werden bzw. lösen den Event erst beim Abheben des Pointers aus, (up-Event) nicht beim down-Event.
Sämtliche Aktionen erfolgen beim UP Event.
Sichtbare Label sind im programmatisch ermittelbaren Namen von Bedienelementen enthalten (es ist nicht das html name Attribut gemeint)
Keine Eingabecontrols (ausser Checkbox für Kategorien) im Banner enthalten. Die Checkbox ist eindeutig dem jeweiligen Bereich zuordenbar.
Keine Aktionen über Bewegung aktivierbar.
Keine Dragging Aktionen im Banner möglich.
Klickflächen wie Buttons haben eine Mindestklickfläche von 24 x 24 px, Links innerhalb von Text sind davon nicht betroffen.
Buttons sind größer, Switches sind minimal 60 x 24 px groß
Für Banner nicht relevant.
Sprache ist über Banner hinweg einheitlich (Benutzerdefiniert). Die Beschriftung "ON / OFF" bei den Schaltern wird als Teil des allgemeinen Sprachgebrauchs für Schalter angesehen.
keine automatischen Popups beim Laden der Seite, eher activate als focus als Formulartrigger.
Nichts dergleichen ist im Banner enthalten.
Kein onChange Eventhandler in Selectboxen, keine automatische von Screenreadern nicht nachvollziehbare Änderung von Formularen beim Anklicken eines Radio Buttons oder einer Checkbox, keine automatische Formularversendung ohne Klick auf Submitbutton oder Enter.
Keine automatischen Aktionen im Banner enthalten
Nicht relevant für Banner.
Logische, übereinstimmende names, labels, sinnvolle Alternativtexte z.B. für Icons…
Vorgegeben wo möglich, durch eigene Texte jederzeit anpassbar.
Kontakt und Hilfe Optionen befinden sich immer an derselben Stelle.
Für Banner nicht relevant.
Eingabefehler bei Banner nicht möglich.
Semantische Zuordnung von Formularfeldbeschreibungen durch label Element. title oder aria-label Attribut, wenn label nicht möglich ist. Beispiele für erwartetes Datenformat (z.B. tt.mm.jjjj)
Keine Eingabemöglichkeit ausserhalb von Kategorien-Checkboxen
Keine Fehleingabe möglich im Banner.
Keine Eingabe von sensiblen Daten im Banner möglich.
Keine Eingabe möglich im Banner.
Keine Authentifizierung im Banner möglich.
Interaktive Elemente müssen auch mit assistiven Technologien verständlich und bedienbar sein, standardgemäß verwendete HTML Kontrollelemente erfüllen das von vornherein.
Bei Entwicklung eigener User Interface Controls, Verwendung von Webcomponents, korrekte DOM Funktionen, um Inhalte hinzuzufügen, WAI-ARIA, um Zusatzinformationen für Screen Reader zu geben für Widgets, für die es keine native HTML Semantik gibt (z.B. Slider, Treenavigation, Tooltip, Carousel….), für Autosuggest bei einem Suchformular, Autoaktualisierung von Inhalt etc…, korrekte Verwendung von Wai-ARIA, keine redundante Semantik (d.h. störend zuviel Information für Screenreader).
Da der Banner auf unterschiedlichsten Websites eingesetzt wird, die die Standard Kontrollelemente zum Teil erheblich modifizieren, mussten eigene Elemente eingebunden werden. Diese wurden jedoch so gut wie möglich gekennzeichnet und mit Screen Reader Technologien getestet.
Statusmeldungen können programmtechnisch bestimmt werden (durch ARIA roles oder attributes, z.b. alert, status, aria-live), so dass assistive Technologien sie interpretieren können, ohne dass der Fokus dort sein muss. Wenn Inhalte zu einer Seite hinzugefügt werden, ohne dass sich der Kontext ändert.
Der Banner enthält keine Statusmeldungen.