Kontakt
Barrierefreiheit

Leitfaden Webseiten

Eine Handreichung der Arbeitsgruppe „Web“ in der Task Force Barrierefreiheit des Börsenvereins des Deutschen Buchhandels e. V.

Autor*innen:

AG WEB der Taskforce Barrierefreiheit im Börsenverein des Deutschen Buchhandels e. V.

Version: 1.02 – Dezember 2021

Webinar barrierefreie Webseiten

Aufzeichnung des Webinars vom 8. März 2022

Einleitung

Der demografische Wandel und die Digitalisierung gehören zu den entscheidenden Entwicklungen, die unsere Gesellschaft prägen. Hinsichtlich der kulturellen und gesellschaftlichen Teilhabe kommt in diesen Prozessen der digitalen Barrierefreiheit eine grundlegende Bedeutung zu.

Die EU-Richtlinie „European Accessibility Act (EAA)“ aus dem Jahr 2019 dient dazu, der Durchsetzung barrierefreier Produkte und Dienstleistungen den Weg zu ebnen. Die Richtlinie wurde mit dem „Barrierefreiheitsstärkungsgesetz“ im Mai 2021 in deutsches Recht überführt. Der Buchhandel, Buchgroßhandel, Aggregatoren und Verlage teilen das Ziel einer inklusiven Gesellschaft, in der alle Menschen – mit und ohne Behinderungen – ein selbstbestimmtes Leben führen. Daher sollen sie ihre Produkte in deren ganzer Vielfalt allen Menschen in gleicher Weise zugänglich machen. Dies ist Anspruch und Ziel der „Task Force Barrierefreiheit“ im Börsenverein des Deutschen Buchhandels. Der Börsenverein wie auch die Teilnehmenden in der Task Force wollen die Branche bis 2025 und darüber hinaus auf dem Weg zur Barrierefreiheit begleiten. Die gut 30 Expertinnen und Experten geben konkrete Empfehlungen und Hilfestellungen. Der Börsenverein des Deutschen Buchhandels koordiniert in Zusammenarbeit mit dem Deutschen Zentrum für barrierefreies Lesen (dzb lesen) die Arbeit der Task Force, nimmt am nationalen Gesetzgebungsprozess aktiv teil und gewährleistet den Austausch mit den internationalen Partnern.

Neben dem Handbuch “E-Books ohne Barrieren” bereitet die Task Force drei weitere Leitfäden für die Publikationsbereiche „PDF“, „EPUB“ und den hier vorliegenden Leitfaden „Web“ vor. Mit dieser Veröffentlichung zum Teilgebiet barrierefreier Webgestaltung mit dem Fokus Buchmarkt gibt die Task Force einen Überblick und benennt wesentliche Aspekte des barrierefreien Zugangs zu Inhalten über vorbildhafte Webshops.

In der Theorie gestatten die heutigen digitalen Möglichkeiten Menschen mit und ohne Behinderung, Inhalte durch entsprechende technologische Unterstützung leicht aufzunehmen. Allerdings entstehen gerade bei der Produktion digitaler Publikationen unbewusst Hürden, die auch Benutzer*innen ohne vermeintliche Beeinträchtigung situativ behindern. Die allgemeine Annahme, dass Barrierefreiheit in digitalen Dokumenten oder Produkten ausschließlich Menschen mit Behinderung oder Menschen im fortgeschrittenen Alter betrifft, ist eine falsche. Die prominenteste Personengruppe, die sich unzugänglichen Inhalten gegenübersieht, sind seh- und lesebehinderte Menschen wie auch Menschen mit einer altersbedingten Seheinschränkung. Jedoch werden weitaus mehr Personen vom Zugang zu Inhalten ausgenommen. In Deutschland geht man derzeit von rund acht Millionen schwerbehinderten Menschen aus. Davon sind etwa 1,2 Millionen Menschen sehbehindert und davon wiederum etwa 200.000 Menschen blind, das heißt sie haben ein Sehvermögen von unter 3 Prozent (Stand 2019). Nach aktuellen Schätzungen der „European Blind Union“ leben in der EU rund 30 Mio. sehbehinderte Menschen. Aber neben blinden und sehbehinderten Menschen gehören auch Personen mit Legasthenie, einer Körperbehinderung oder geistigen Einschränkungen zu denjenigen, die von barrierefreien Produkten profitieren können. Neben dem oben beschriebenen Inklusionsziel bedeutet „Zugang für alle“ auch, dass der Branche große Zielgruppen erschlossen werden.

Erfahrungen bei der Produktion barrierefreier Produkte aus der Vergangenheit machen deutlich, dass die notwendigen Anforderungen an Zugänglichkeit bereits im Entstehungsprozess von Inhalten berücksichtigt werden müssen. Jedes Produkt, das ‘born digital’ (originär in digitaler Form produziert) ist, kann auch ‘born accessible’ (originär barrierefrei) werden. Wenn Zugänglichkeit bereits bei der Konzeption von Produkten mitgedacht wird, die wesentlichen Akteure in den Prozess einbezogen werden und so das für Zugänglichkeit notwendige Wissen aufgebaut wird, so lassen sich für fast alle Produkte barrierefreie Lösungen finden. Im Ergebnis können E-Book-Reader, Sprachassistenten, Screenreader, mobile Anwendungen und inklusive funktionale Webshops von einer deutlich größeren Zahl Lesender gut bedient werden. Der Mehrwert, auch bezogen auf den Markt, sollte für alle Beteiligten offensichtlich sein.

Leitfaden für Online-Buchhandlungen und Websites

Die folgenden Ausführungen gelten generell für Websites, gehen an einigen Stellen aber auf Besonderheiten der Buchbranche ein. Sie bilden eine Auswahl der in WCAG 2.1 („Web Content Accessibility Guidelines“) aufgeführten Vorgaben für barrierefreie Websites und sollen damit den Zugang zum Thema vereinfachen.

Die für die Produktdarstellung und die Produktsuche barrierefreier Produkte notwendigen Informationen werden in den Metadaten der Produkte gemeldet. Die Metadatenmeldung in ONIX, dem XML-Metadatenformat der Buchbranche, stellt die Basis für die Hinweise dar, die weiter unten in Abschnitt 8 zur Produktdarstellung und Produktsuche gegeben werden. Die wichtigen ONIX-Listen für die Darstellung von Barrierefreiheit von Produkten sind die folgend genannten: Liste 175 <ProductFormDetail>, oder short tag <b333> listet Produktinformationen zu den DAISY Standards (Digital Accessible Information System) und zu Blindenschriften. Liste 79, <ProductFormFeatureType> oder short tag <b334> Informationen zu Schriftgrößen und zur Zugänglichkeit von eBooks (E-publication Accessibility), die in Liste 196 <ProductFormFeatureValue>, in short tag <b335>, näher beschrieben werden (z. B. LIA Compliance Scheme). Textliche Darstellung der Zugänglichkeit erfolgt im Freitext via tag <ProductFormFeatureDescription> bzw. short tag <b336>. In  Liste 145 <EpubUsageType> oder short tag  <x318> findet sich die auf Produktebene getroffene Festlegung für die Zulässigkeit der Text-to-speech-Funktionalität. Die Informationen werden zur Darstellung des Produktes herangezogen und können über die strukturierte Verwendung im Suchindex auch als Filter und Facettensuche in Shops implementiert werden.

1. Überschriften-Hierarchie (H1, H2, H3)

  • Zeichnen Sie möglichst nur Überschriften mit dem Heading-Tag aus.
  • Jede Überschrift beschreibt den Inhalt darunter.
  • Verwenden Sie je Seite höchstens ein H1-Heading, die das Thema der Seite beschreibt.

Tipp: Zur übersichtlichen und einfachen Überprüfung der Überschriftenhierarchien auf Websites kann man die Browser-Erweiterung HeadingsMap für Google Chrome, Mozilla Firefox etc. als hilfreiches Add-on installieren und sich einen schnellen Überblick über die korrekte Strukturierung verschaffen. Empfohlen werden ausschließlich Prüfwerkzeuge, die im Web frei verfügbar sind (siehe Linkliste).

2. Aussagekräftige Meta-Tags

  • Der Seitentitel (<title>-Element im <head>-Bereich) sollte aussagekräftig sein.
  • Verwenden Sie individuelle Seitentitel pro Seite (keine Duplikate).
  • Fügen Sie pro Seite möglichst eine individuelle Meta-Description hinzu, die den Inhalt der Seite verständlich zusammenfasst.

Tipp: Ein wesentlicher Aspekt digitaler Barrierefreiheit ist es, Inhalte zu strukturieren und semantisch auszuzeichnen und somit für alle Menschen zugänglich zu machen, unabhängig von der Art eines Endgerätes und der verfügbaren Benutzeroberfläche. Nicht zuletzt ist ein barrierefreier Zugang auch für das Ranking der Website für Suchmaschinen von Vorteil. Sogenannte Webcrawler ermöglichen Ihnen somit eine größere Reichweite Ihrer Produkte und Dienstleistungen.

3. Layout von Websites

3.1 Texte

Für die barrierefreie Gestaltung von Websites und Apps gelten die gleichen Bedingungen wie für gedruckte Dokumente. Besondere Beachtung verdienen Schriftart und Schriftgröße, Strichstärke, Schriftweite, aber auch Zeichen- und Zeilenabstand und beim Blick auf die gesamte Textseite Hervorhebungen, Kontraste und Farben.

Die Seite www.leserlich.info des Deutschen Blinden- und Sehbehindertenverbandes (DBSV) bietet alles Wissenswerte dazu in übersichtlicher, gut gegliederter, komprimierter und einfach aufbereiteter Form.

Alle Fragen rund um Schrift und Leserlichkeit von Schriften und Texten beantwortet darüber hinaus die DIN 1450:2013-04 (ein Dokument von etwa 26 Seiten).

3.2 Bilder und Piktogramme

  • Jedes Bild sollte einen individuellen Alternativtext (sog. ALT-Text) haben.
  • Der ALT-Text sollte das Bild mit seinen Motiven bzw. das Link-Ziel eines verlinkten Bildes beschreiben (in HTML: <img>-Element: alt-Attribut enthalten).
  • Piktogramme (Icons) müssen leicht verständlich und nachvollziehbar sein.

Es gibt zumindest zwei entwickelte Piktogramme im Zusammenhang mit Barrierefreiheit: Ein Icon für die Bebilderung von Videos in deutscher Gebärdensprache und ein weiteres Icon zur Kennzeichnung einfacher Sprache (https://www.bundesfachstelle-barrierefreiheit.de/DE/Praxishilfen/Information-und-Kommunikation/Logos/logos_node.html).

3.3 Kontraste

  • Schriften, Bilder und Icons müssen möglichst kontrastreich sein.
  • Nutzen Sie zur Prüfung einen sog. Colour Contrast Analyser (in der Regel ist 4,5:1 ausreichend, siehe Linkliste).

4. Vorlesefunktion

Einige Lesegeräte und Lese-Apps bringen eine Vorlesefunktion mit, mit der sich Textinhalte vorlesen lassen. Dabei erscheint auf dem Bildschirm eine Art Player mit Tasten zum Starten und Stoppen des Vorlesens sowie zum Vor- und Zurückspulen (ähnlich wie man es auch von Video-Playern kennt). Diese Vorlesefunktion ist unter anderem für Menschen mit Legasthenie oder auch für sehbehinderte Menschen praktisch, die das Ausgabegerät bzw. die Leseanwendung grundsätzlich sehend bedienen können, aber Schwierigkeiten beim Lesen von Texten haben. Für blinde Menschen reicht diese Vorlesefunktion allein nicht aus, da sie die Schaltflächen des Players nicht sehen und damit auch nicht bedienen können. Sie benötigen eine Vorlesesoftware.

Eine Vorlesesoftware (auch Screenreader genannt) ermöglicht es blinden Menschen, Ausgabegeräte mit einer grafischen Benutzeroberfläche, wie Computer oder Smartphone, zu bedienen. Dazu werden sämtliche Bildschirminhalte – seien es Schaltflächen, Menüs, Texte, Abbildungen oder Ähnliches – akustisch ausgegeben. Gesteuert wird die Vorlesesoftware je nach Ausgabegerät per Tastatur, über Gesten oder andere Eingabegeräte. Der Funktionsumfang einer Vorlesesoftware bzw. eines Screenreaders geht also noch deutlich über den einer Vorlesefunktion hinaus.

Eine Vorlesefunktion für Websites oder mobile Anwendungen ist gesetzlich nicht vorgeschrieben.

5. Videos

Die visuellen und auditiven Inhalte eines Videos sind für Menschen mit Seh- oder Hörbehinderung und auch weitere Zielgruppen häufig nicht wahrnehmbar. Daher braucht es Alternativen, z. B. Transkription, Untertitel und/oder Audiodeskription), damit die Videoinhalte für verschiedene Zielgruppen wahrnehmbar werden. Sofern ein Video nicht allein mittels <video>-Element und zugehörigen Attributen in HTML eingebunden ist, muss weiterhin darauf geachtet werden, dass auch der Video-Player barrierefrei bedienbar ist.

  • Bei der Konzeption eines Videos sollte die Barrierefreiheit bereits mit bedacht werden.
  • Sind die Videos selbst barrierefrei eingebunden, erreichbar und bedienbar?
  • Die Einbindung von Mediaelementen auf Websites erfolgt mittels HTML 5 <video> Element, Hinweise für Entwickler: https://bik-fuer-alle.de/fuer-webentwickler-einbindung-in-die-internetseite.html
  • Barrierefreie Videoplayer:
    • Videoplayer der Aktion Mensch
    • mediaelement.js
    • Able Player
    • video.js
    • OzPlayer
    • YouTube-Videos über einen HTML5-Player wiedergeben
  • Steht höreingeschränkten Menschen eine Untertitelung zur Verfügung?
  • Werden mittels Untertitelung auch relevante Hintergrundgeräusche beschrieben?
  • Binden Sie nach Möglichkeit nur Video-Plattformen ein, die Untertitel anbieten.
  • Kostenfreie Online-Untertitel-Editoren, mit deren Hilfe Untertitel-Text eingegeben und getimed werden kann:
  • Ist eine Audiodeskription vorhanden? Sie dient dazu, blinden Menschen das Filmgeschehen möglichst handlungssynchron ohne Wertung zu beschreiben. Realisierbar zum Beispiel über Video- und Tonschnittsoftware:
    • Movie Maker
    • Audacity
    • Adobe Premiere
    • Frazier
  • Einbindung mittels HTML 5 <track> Element auf Webseiten; alternativ zur Audiodeskription kann man die Audioinhalte auch in Textform in unmittelbarerer Nähe platzieren, verlinken und transkribiert anbieten.
  • Videos in Gebärdensprache sind noch nicht verpflichtend.

6. Audios

Damit Inhalte einer Audio-Datei (z. B. ein Literaturpodcast) für Menschen mit Höreinschränkungen wahrnehmbar sind, muss eine Transkription bereitgestellt werden, die sämtliche auditiven Informationen (z. B. Sprache, Dialoge, Geräusche etc.) in Textform abbildet.

7. Einbindung von Fremdinhalten

Achten Sie bei der Einbindung von Inhalten Dritter darauf, dass diese möglichst konkret bezeichnet werden:

  • Einbindung von Links: Links sollten u. a. auch für Suchmaschinen einen möglichst sprechenden Anchortext (Linknamen) haben, der erklärt, was sich hinter dem Link verbirgt. 
  • Einbindung von iFrames: Inhalte per iFrame sollten einen möglichst eindeutigen Namen haben, der Rückschlüsse auf den Inhalt zulässt, da Sie nicht gewährleisten können, wie barrierefrei Dritte ihre Inhalte anbieten. Eine eindeutige Bezeichnung (z. B. name="Werbung") hilft aber, den iFrame zu interpretieren.

8. Produktsuche und Produktdarstellung

Produktsuchen sind meist mittig auf einer Website platziert, Detailsuchen über den Webseiteninhalt an sich befinden sich in der Regel oben rechts auf einer Startseite.

Um eine Vorstellung davon zu erhalten, wie lesebehinderte Menschen auf Webseiten mit Barrieren bspw. Suchfunktionen nicht finden oder Formulare sowie Fehlermeldungen nicht ohne erheblichen Aufwand erschließen können, bietet ‘Access and Use’ kurze, eingängige Videoszenarien dazu an und beleuchtet ebenso Hintergründe zu den Hürden: https://accessuse.eu/de/formulare-fehlerbehandlung.html.

Produktsuchen (mit oder ohne Autovervollständigung) werden auch Kombinationsfeld oder Combobox genannt. Sie sind Bedien- bzw. Formularelemente, die die Funktionen von Eingabe- und Auswahlfeld kombinieren. Nutzer*innen haben damit die Möglichkeit, einen eigenen Suchbegriff einzugeben und/oder einen Suchbegriff aus einer Liste vorgeschlagener Möglichkeiten auszuwählen.

Je nach Funktionsweise lassen sich vier Arten der Autovervollständigung für Kombinationsfelder unterscheiden:

  1. Keine Autovervollständigung: Die Auswahlmöglichkeiten, die über die eingeblendete Liste vorgeschlagen werden, sind statisch: Bei Eingabe eines Textes bleiben die vorgeschlagenen Optionen unverändert.
  2. Autovervollständigung über eine Liste mit manueller Auswahl: Bei Eingabe eines Textes wird eine Liste mit Auswahlmöglichkeiten vorgeschlagen, die (vollständig oder logisch) dem eingegeben Text entsprechen. Doch solange keine Option aus der Vorschlagsliste ausgewählt wird, bestimmt der eingegebene Text den Wert des Eingabefeldes.
  3. Autovervollständigung über eine Liste mit automatischer Auswahl: Bei Eingabe eines Textes wird eine Liste mit Auswahlmöglichkeiten vorgeschlagen, die (vollständig oder logisch) dem eingegeben Text entsprechen. Der erste Vorschlag der Liste wird dabei automatisch ausgewählt und bestimmt den Wert des Eingabefeldes – es sei denn, es wird aktiv ein anderer Vorschlag der Liste ausgewählt oder der Text im Eingabefeld verändert.
  4. Liste mit Inline-Autovervollständigung: Entspricht der Autovervollständigung über eine Liste mit automatischer Auswahl, bloß mit einer zusätzlichen Funktion: Der Text im Eingabefeld wird automatisch ergänzt, indem hinter dem Textcursor die noch fehlenden Zeichen des ausgewählten Vorschlages angezeigt werden.

Barrierefreie Gestaltung eines Kombinationsfeldes

Bei der Umsetzung eines barrierefreien Kombinationsfeldes ist darauf zu achten, dass die Liste mit den vorgeschlagenen Auswahlmöglichkeiten auch für blinde Menschen wahrnehmbar ist. Dafür gibt es verschiedene Ansätze:

  1. Umsetzung als einfaches Eingabefeld mit Live-Region: Das Eingabefeld wird als einfaches input-Element umgesetzt. Zusätzlich wird eine Live-Region (role="status") angelegt, die bei Eingabe eines Textes bzw. beim Erscheinen der Autovervollständigungsliste automatisch die aktuelle Anzahl verfügbarerer Vorschläge/Auswahlmöglichkeiten ausgibt (z. B. „8 Suchvorschläge vorhanden, nutzen Sie die Pfeiltasten, um eine Option auszuwählen“). Die passende Tastaturbedienung kann mithilfe von tabindex-Attributen sichergestellt werden (tabindex="0" auf der Autovervollständigungslisten-Komponente und tabindex="-1" auf den Listenelementen – siehe Praxisbeispiel vom Deutschen Hygienemuseum Dresden).
  2. Semantische Auszeichnung mit ARIA-Attributen: Anstelle einer Live-Region können die semantischen Informationen auch mithilfe entsprechender ARIA-Attribute vermittelt werden (siehe Umsetzungsbeispiele in den WAI-ARIA Authoring Practices), z. B.:
      • role-Attribute zur semantischen Auszeichnung des Kombinationsfeldes und seiner Bestandteile ("combobox", "listbox", "option")
      • aria-autocomplete zur Kennzeichnung des Vorhandenseins einer Autovervollständigung
      • aria-expanded zur Kennzeichnung des Aufklappzustandes der Liste mit den Auswahlvorschlägen
      • aria-selected zur Kennzeichnung der aktuell ausgewählten Option in der Vorschlagsliste,
      • aria-owns / aria-controls für die Lesereihenfolge des Screenreaders
      • usw.

Produktbeschreibungen oder Detailansichten zu einem Produkt sollten aussagekräftig, kurz und prägnant gehalten werden und, wenn vorhanden, Bildalternativen bereithalten. Wenn es allgemeingültige Bestimmungen hinsichtlich der Metadaten zur Anzeige der Barrierefreiheit von Produkten geben wird, sollten diese hier ebenso auffindbar platziert werden. Möglich sind auch Labels (grafisch oder alternativ beschrieben) als Qualitätssiegel hinsichtlich der Produktbarrierefreiheit.

9. Tastaturbedienbarkeit interaktiver Elemente

Interaktive Elemente einer Website sind meist übergeordnete Inhalte, die einfache Texte, Bedienelemente oder Multimedia-Inhalte enthalten. Sämtliche dazugehörende Schaltflächen und Formularfelder müssen über die Tabulator-Taste und ggf. Pfeiltasten erreichbar und/oder bedienbar sein. Beispiele dafür können sein:

  • Dialoge, Modalboxen oder Lightboxen (Elemente, die meist durch Nutzeraktion im Vordergrund vor den übrigen Elementen der Seite dargestellt werden)
  • Datepicker (Steuerelement in der Optik eines Kalendariums/Kalenderrasters, das die Anzeige, Eingabe und Auswahl eines Kalenderdatums ermöglicht)
  • Formulare (Tipp: https://wiki.selfhtml.org/wiki/HTML/Tutorials/Formulare/Beschriftungen)
  • Karussells, Slider, Slideshows (Komponenten, die eine Reihe von Folien mit verschiedenen Inhalten – üblicherweise Bilder oder Bilder samt Text – beinhalten, die sequentiell angezeigt werden)
  • Menü (als Navigationseintrag)
  • Pop-Up/Tooltip (Aktivierung bei Bewegen der Maus über Elemente)
  • einfache/komplexe Datentabellen
  • etc.

Über die jeweils passenden HTML-Elemente sollten diese interaktiven Bedienelemente realisiert werden. Zu beachten ist auch, dass Anwendungen wie virtuelle 3D-Rundgänge einer ergänzenden bzw. zusätzlichen Medienalternative bedürfen, um dadurch reduzierter und linearer erfassbar zu werden. Das Gleiche gilt für Videoeinbindung oder geografische Karten zur Navigation.

Websites und deren Anwendungen können ebenso über Sprachein- und -ausgabe gesteuert werden. Besonders hilfreich ist diese Technik für Menschen mit Seh- oder motorischen Behinderungen, aber auch in Situationen, wo man auf Sprachsteuerung angewiesen ist, weil man beispielsweise keine Hand zur Bedienung frei hat. Die Voice Browser Working Group des W3C hat einen aktuellen Entwurf der Voice Browser Call Control: CCXML Version 1.0 veröffentlicht. CCXML ergänzt die Sprache VoiceXML.

10. Fokus interaktiver Elemente

Für die Tastaturbenutzer ist es wichtig zu sehen, wo sich der Tastaturfokus gerade befindet, welcher Link also ausgelöst wird, wenn sie die Enter-Taste drücken. Man muss erkennen können, wo man sich mit der Maus und Tabulator-Taste aktuell auf der Website befindet. Die vom Browser vorgesehene Kennzeichnung des Tastaturfokus hebt sich von dunklen Seitenhintergründen meist nicht so gut ab. Dies muss zum Beispiel durch farbige Hinterlegung des angesteuerten Links ausgeglichen werden. Hinweise zur Umsetzung in HTML finden Sie hier: https://www.einfach-fuer-alle.de/artikel/tastaturfokus/ (Mouse-Over, Highlight-Funktion; z. B. color / background-color oder outline für :hover/:focus (CSS))

11. Eingabefelder

  • Ist eine gut sichtbare und aussagekräftige Beschriftung (z. B. <label>-Element) vorhanden?
  • Ist die Beschriftung mit dem jeweils zugehörigen Feld verknüpft (z. B. for-Attribut)?
  • Automatisches Ausfüllen von Nutzerdaten in Formularen: Es müssen die korrekten Attribute verwendet werden (z. B. Autocomplete-Attribut wie autocomplete="family-name" für Familienname).

12. Fehlermeldungen in Formularen

  • Fehlermeldungen müssen so ausgespielt werden, dass sie deutlich lesbar bzw. maschinenlesbar sind. Auch die Timeout-Meldung muss maschinenlesbar sein.
  • Fehlermeldungen sollten verständlich und aussagekräftig formuliert sein.
  • Fehlermeldungen in Formularen müssen leicht auffindbar sein (z. B. als Teil des Labels oder vor dem Formular).

13. Vergrößerung – 200 % Zoom (Strg+Plus) / kleine Smartphones

Die Nutzenden von Websites sollten die Schriftgröße nach ihren Bedürfnissen einstellen können. Es ist sicherzustellen, dass bei einem Zoomfaktor von 200 % sowie auch auf kleinen Smartphones alle Funktionen bedienbar und alle Inhalte lesbar (ohne zeilenweises Hin- und Herscrollen) sind. Es darf zu keinen Überlagerungen, keinem Verschwinden von Text/Elementen kommen. Ein horizontales Scrollen innerhalb eines Seitenbereiches soll vermieden werden. Alle Buttons oder Formularelemente sollten sichtbar und nutzbar bleiben.

14. Checkout & Warenkorb

Hinsichtlich der Barrierefreiheit gelten für Warenkorb, Check-Out oder Bestellvorgänge auf Websites prinzipiell die gleichen Anforderungen wie für alle anderen Websitebereiche. Es muss jedoch klar erkenntlich sein, dass z. B. eine Ware im Shop in den Warenkorb gelegt oder eine genaue Anzahl Bücher der Merkliste hinzugefügt wurden. Dies wird mittels einer Statusnachricht realisiert, die eine Inhaltsveränderung anzeigt, die aber keine Kontextänderung ist. Sie gibt dem Nutzer Informationen über Erfolg/Fehler/Ergebnis einer Aktion, über den Wartestatus einer Anwendung („Bitte warten!“) oder über den Fortschritt eines Prozesses.

Wird die Statusnachricht mit einer Markup-Sprache (z. B. HTML) realisiert, wird sie über geeignete Rollen oder Eigenschaften für assistive Technologien zur Ausgabe bereitgestellt, ohne dass sie den Fokus erhält. Umgesetzt werden kann es wie folgt: https://www.w3.org/TR/wai-aria-1.1/#live_region_roles

CAPTCHAs (Mensch-Maschine-Authentifizierung) sind sogenannte Nicht-Text-Inhalte und müssen als solche durch eine Textalternative gekennzeichnet werden. Es sollten alternative Formen von CAPTCHAs für andere sensorische Wahrnehmungen bereitgestellt werden. Möglich sind auch Frage-CAPTCHAs mit einfachen und logischen Fragen. Das World Wide Web Consortium (W3C) hat in einem Artikel die generelle Sicherheit von CAPTCHAs infrage gestellt und Alternativen zu CAPTCHAs an sich aufgeführt: https://www.w3.org/TR/turingtest/

Neben einer schnellen, intuitiven, logischen und auffindbaren Platzierung essentieller Elemente (Warenkorb ist rechts oben, Suche ist oben mittig oder rechts, Registrieren, Login, Sprachwahl ebenso oben rechts etc.) sollte auch die Reihenfolge der Formularfelder während eines Kaufprozesses linear und erwartbar sein. Es muss sichergestellt werden, dass ein Onlineshop auch ohne die Verwendung einer Maus navigierbar ist.

Wenden Sie sich an Ihren Bezahldienstleister (Amazon, DKB etc.), wenn dessen Website, auf die Ihre Käufer weitergeleitet werden, nicht barrierefrei ist.

15. Werkzeuge für Website-Tests

Für die Website-Tests werden nach aktuellem Stand in erster Linie die Werkzeuge verwendet, welche in der Werkzeugliste des BITV-/WCAG-Tests aufgeführt sind. Ergänzend dazu gibt es dort eine Reihe von Browser-Erweiterungen oder Bookmarklets, die man leicht implementieren und anwenden kann.

Vom W3C empfohlene Werkzeuge sind im Folgenden aufgeführt. Vielfach werden vom W3C automatische Syntax-Validatoren für HTML erwähnt, außerdem kostenpflichtige Angebote, Kontrast-Checker, Prüftools zum Leseniveau (allerdings nur für englische Sprache), nützliche Bookmarklets und allgemein Tools, die eher Webentwicklern als Prüfpersonen helfen.

Über Online-Anbieter für Accessibility Checker oder Tools, wie ‘axe’ oder ‘siteimprove’, können keine allgemeingültigen Empfehlungen ausgesprochen werden. Sie sind generell hilfreich, jedoch sollte man genau prüfen, ob alle relevanten Fehler durch die Software gemeldet werden, ob bestimmte Dinge so von der WCAG gefordert sind oder keine Fehler darstellen.

16. Hinweise zu Apps

Im vorliegenden Barrierefreiheitsstärkungsgesetz der Bundesregierung werden auch auf Mobilgeräten angebotene Dienstleistungen, einschließlich mobile Anwendungen (Apps), einbezogen.

Auch hier sind – bis auf Widerruf – die Anforderungen der aktuellen WCAG 2.1 (Konformitätsstufen A und AA) wie bei Websites einzuhalten. Die zugrundeliegende europäische Norm sei hier im Detail für mobile Anwendungen verlinkt: EN 301 549, Version 3.1.1 (PDF, englischsprachig), siehe Anhang A, Tabelle A2.

Vom W3C wird derzeit für das Testen von Apps folgende Anwendung empfohlen: forapp.org. Es handelt sich hierbei um einen Online-Service, der Apps testet. Da ein persönlicher Account erforderlich ist, sollte man prüfen, ob Kosten anfallen.

Wenden Sie sich auch hier an Ihren App-Store-Anbieter, sollte dessen Website-Umgebung, auf die ggf. weitergeleitet wird, nicht barrierefrei sein.

Quellen & hilfreiche Links