Eine barrierefrei gestaltete Webseite ermöglicht es „allen“, ihren Inhalt zu erschließen und mit ihr zu interagieren. So sollen beispielsweise Sehbehinderungen oder motorische Einschränkung keine Ausschlusskriterien für die Bedienung einer Webseite oder das Verständnis ihres Inhaltes sein. Jedoch ist es auch im Jahr 2022 weiterhin der Normalfall, dass bei der technischen und inhaltlichen Umsetzung von Webseiten und IT-Systemen Aspekte der Barrierefreiheit nicht oder nur im geringen Maße beachtet werden, was Menschen mit Behinderungen in der medialen Interaktion benachteiligt oder sie gänzlich davon ausschließt — beispielsweise beschreibt der Artikel Surfen im Dunkeln eindrucksvoll, wie frustrierend für einen Blinden die Interaktion mit barriere-behafteten Webseiten ist.
Weltweit haben Gesetzgeber das Recht auf den Zugang für Alle festgeschrieben; in Deutschland regelt die Barrierefreie-Informationstechnik-Verordnung (BITV) auch speziell die barrierefreie Gestaltung von IT-Systemen. Desweiteren sind die Leibniz-Gemeinschaft und damit GESIS durch die WGL-Beschlüsse der Gemeinsamen Wissenschaftskonferenz dazu aufgerufen, für eine zugängliche Umsetzung ihrer Produkte und Ergebnisse zu sorgen.
Auf englisch heißt Barrierefreiheit Accessibility. Die Web Accessiblity Initiative (WAI) des W3C, dem „Hüter“ des HTML-Standards, definiert mit ihren Web Content Accessibility Guidelines (WCAG), welche Kriterien erfüllt sein müssen, damit ein Webseite und ihre Elemente als barrierefrei gelten. Diese Initiative bietet mit ihren Authoring Practices auch konkrete, pragmatische Musterlösungen, mit denen typische Bedienelemente des Webs wie beispielsweise Menüleisten oder Dialogboxen frei von Hindernissen umgesetzt werden können. Die WCAG dienen in internationalen Standards wie der ETSI EN 301 549 als maßgebliche Beurteilungskriterien für Barrierefreiheit. Jene ETSI-EN-Norm dient wiederum als Spezifikation für Erfolgskriterien in der EU-Richtlinie über den barrierefreien Zugang zu den Websites und mobilen Anwendungen öffentlicher Stellen (2016/2102), welche in Deutschland durch die BITV umgesetzt wird. Zusammengefasst: Zur Beurteilung der Barrierefreiheit von Webseiten und Software gelten nach deutschem, europäischem und internationalem Recht die WCAG.
„Aber lohnt sich der ganze Aufwand für Barrierefreiheit überhaupt?“ Gewiss, denn laut des Deutschen Blinden- und Sehbehindertenverbands liegt die Anzahl sehbehinderter Menschen in Deutschland bei mindestens 570.000. Und Inhalte mit Tonspur, beispielsweise Konferenzmitschnitte, Trainingsvideos und Podcasts, erschließen sich für die in Deutschland lebenden 83.000 gehörlosen und eine Million hochgradig oder an Taubheit grenzend schwerhörigen Menschen häufig erst, wenn sie mit Untertiteln ausgestattet werden. Und für Menschen mit motorischen Einschränkungen wie Parkinson-Erkrankte, Menschen mit Multipler Sklerose und Gelähmte kann ein zu klein geratener und nur per Maus auwählbarer Weiterlesen-Button zur großen Inhaltsbarriere werden.
Aber nicht nur die bis jetzt genannten Personengruppen profitieren von einem barrierefrei gestalteten Webauftritt: Wenn man den Best Practices der Barrierefreiheit folgt, bedient man sich auch allgemeingültiger Usability-Regeln des guten Webdesigns, deren Konsistenz und Klarheit jedem Nutzer helfen - schließlich bevorzugen alle Webseitenbesucher*innen leicht lesbare Texte statt grauem Text auf grauem Hintergrund, und präferieren einen vernünftig dimensionierten Button statt Geduldsproben pixelgenauer Mauszeigerpositionierung. Zu diesem Ergebnis kamen auch Schmutz, Sonderegger und Sauer in ihrer Untersuchung Implementing Recommendations from Web Accessibility Guidelines: Would They Aso Provide Benefits to Nondisabld Users.
Und außer Menschen profitieren auch Computer vom semantisch präzisen HTML-Stil, den Barrierefreiheit voraussetzt: Webcrawler verstehen den den Inhalt barrierebefreiter Webseiten besser, wodurch beispielsweise die Platzierung der Webseite in Suchmaschinen-Ergebnissen erheblich profitiert.
Dieses Dokument zeigt anhand von Beispielen, wie man den Stand der Barrierefreiheit einer Webseite beurteilt kann, sowie wie eine Webseite unter Beachtung des GESIS-Styleguides barrierefrei umgesetzt werden kann. Als Referenzbeispiel dient das GESIS-Web, GESIS' TYPO3-basiertes Content Management System ( https://www.gesis.org/ ); im GESIS-Web wurden im Jahr 2020 viele Barrieren abgebaut, und seither ist Barrierefreiheit eine primäre Anforderung und ein Antreiber ihrer weiteren Entwicklung. Daher umfasst dieses Dokument die bei dieser Umgestaltung gelernten Best Practices inklusive Fallstudien.
Um Barrierefreiheit verstehen und effektiv umsetzen zu können, sollte man sich mit jenen Werkzeugen vertraut machen, welche von Menschen mit Behinderungen genutzt werden, um Computer zu bedienen und Inhalte zu erschließen: diese Werkzeuge nennt man assistiven Technologien.
Menschen mit Behinderungen nutzen häufig folgende Werkzeuge, um Webseiten zu erschließen und zu bedienen.
Das Windows-Tool Bildschirmlupe (Ubuntu Vergrößerung, macOS Zoomen) ermöglicht stark vergrößerte Darstellungen des Bildschirminhaltes.
Viele sehbehinderte Menschen können Texte erst lesen, wenn einzelne Wörter die gesamte Bildschirmgröße einnehmen, beispielsweise mit Bildschirmlupen-Einstellungen ab Zoomstufe 1000%. Es lohnt sich daher, eine Webseite mit der Bildschirmlupe zu betrachten und zu bedienen, um Barrieren ausfindig zu machen.
Beispielsweise sind Pop-ups („Bitte bestätigen Sie die Buchung durch Klick auf Fortfahren“) häufig Ursachen für Barrieren, die während der Nutzung der Bildschirmlupe offensichtlich werden: Ein Benutzer kann ein barrierenbehaftetes Pop-up nicht unmittelbar wahrnehmen, wenn es außerhalb des aktuellen Lupenbereiches erscheint; er kann nur durch Zufall beim Hin- und Herschieben des Lupenbereiches auf das unerwartete Dialogfenster aufmerksam werden.
Weitere Barrieren entstehen, wenn Webseiten etablierte Bedienungskonventionen nicht umsetzen. Zu diesen Konventionen gehört, dass Pop-ups durch Drücken der Escape-Taste geschlossen werden können (siehe BITV-Prüfschritt 9.1.4.13). Für barriere-behaftete Navigationsmenüs vieler Webseiten bedeutet dies: zwar erscheint beim Öffnen des Navigationsmenüs ein Pop-Up auffällig in unmittelbarer Nähe zu seinem auslösenden Menüeintrag. Allerdings schließt das Pop-up nur durch Heraushovern, aber nicht durch Drücken der Escape-Taste.
Für einen normalsichtigen Mausbediener mag es aus konventioneller Erfahrung erkennbar sein, dass sich das Megamenü durch Heraushovern aus dem Pop-up bzw. durch Hereinhovern in einen derzeit verdunkelten Bereich außerhalb des Pop-ups schließt.
Hingegen ist während der Verwendung der Bildschirmlupe der räumliche Kontext des Pop-ups nicht sichtbar. Eine sehbehinderte Person kann daher nicht beurteilen, welche Mauszeigerbewegung der richtige oder kürzeste Weg wäre, um das Popup zu schließen. Aufgrund des fehlenden Kontexts zum verdunkelten Bereich mag auch gar nicht erkenntlich sein, dass ein Pop-up geöffnet ist. Daher setzt Barrierefreiheit voraus, dass das Pop-up auch durch Drücken der Escape-Taste geschlossen werden kann - und für Exklusiv-Tastaturbediener wie motorisch eingeschränkte Personen wird es so erst möglich, diese „Pop-up-Falle“ zu verlassen.
Blinde und sehbehinderte Menschen nutzen Screenreader wie den kostenfreien und als Open Source veröffentlichen NVDA, um Webseiten auf nicht-visuelle Weise zu lesen und zu bedienen. Dafür verarbeiten Screenreader die der Webseite zugrunde liegenden HTML-, JavaScript- und CSS-Quelltexte und präsentieren den Seiteninhalt beispielsweise in akustischer Form als Sprachausgabe oder haptisch wahrnehmbar über eine Braille-Zeile.
Für viele Sehbehinderte und Körperbehinderte ist die Bedienung einer Webseite mit Maus oder Gesten (Touchscreen am Smartphone oder Tablet) unmöglich: Sehbehinderte können den räumlichen Kontext des Zeigers nicht wahrnehmen; und körperliche Behinderungen machen präzise und komplexe Eingaben (Anzielen eines kleines Buttons, Drag and Drop, Text mit gedrückter Maustaste selektieren, etc.) sehr schwierig.
Daher ist für Barrierefreiheit eine vollständige alternative Bedienungsmöglichkeit per Tastatur wichtig. Mit speziellen Tastaturen können Körperbehinderte auch kompliziertere Eingaben vornehmen, beispielsweise beim deutschen Tastaturlayout die Eingabe des @-Zeichens über AltGr + Q.
Die von der WCAG definierten Konventionen für Tastaturbedienung entsprechen allgemeinen Best Practices der Benutzerbedienung: Mit der Escape-Taste schließen sich Pop-ups, mit den Pfeiltasten navigiert man entlang von Auswahlmöglichkeiten und so weiter. Ein Benutzer, der mit diesen Konventionen vertraut ist, kann dadurch effizient mit den Komponenten auf einer Webseite interagieren.
Folgende Tools helfen Entwicklern bei der Entwicklung barrierefreier Webseiten.
Mit Chromes Entwicklertools (F12) kann über Lighthouse die aktuell geöffnete Webseite auf Accessibility (Barrierefreiheit) überprüft werden.
Die Ergebnisse dieser Tools helfen dabei, Barrieren zu identifizieren, ersetzen aber keine manuelle Beurteilungen der Barrierefreiheit, da es zu falsch-positiven Beanstandungen ebenso kommen kann wie zu tatsächlichen Problemen, die nicht gemeldet werden.
Webseiten müssen in korrektem HTML geschrieben sein, um von Screenreadern verarbeitet werden zu können. Beispielsweise verlangt der HTML-Standard, dass Überschriftenhierarchien logisch sortiert sein müssen: Auf eine <h1>-Überschrift kann im Laufe der Seite entweder eine thematisch vertiefende <h2>-Überschrift oder eine thematisch neue <h1>-Überschrift folgen. Aber das Überspringen einer vertiefenden Überschrift ist unlogisch und daher nicht gestattet - direkt von <h1> zu <h3> ist verboten.
Unlogische Sortierung von <h1>- bis <h6>-Überschriften mögen für einen Normalsichtigen zwar keine Verständnisprobleme verursachen, da beispielsweise durch CSS-Regeln die eigentlich beabsichtigte Hierarchie visuell wiederhergestellt wird. Für einen Sehbeeinträchtigten hingegen, der sich für die Inhaltserschließung auf eine vom Screenreader aufbereitete Seitengliederung verlässt, kann eine unlogische Überschriften-Verschachtelung das Zurechtfinden und Verständnis der Seite erheblich beeinträchtigen.
Durch die visuelle Darstellung der GESIS-Homepage ist klar, dass die Überschriften in den News-Karussellen einen in sich geschlossenen Zusammenhang bilden …
… in der Aufbereitung der Seitengliederung durch den Screenreader NVDA (Tastenkombination Einfügen + F7) wird jedoch deutlich, dass aufgrund der fehlerhaften Verschachtelung von <h1>- und <h2>-Überschriften Software-Werkzeuge inkorrekte Zusammenhänge bilden.
Der W3C Markup Validation Service überprüft HTML-Quelltexte auf Konformität zum HTML-Standard und meldet etwaige Fehler. Nicht nur die menschliche Barrierefreiheit ist es sinnvoll, diese Fehler zu beheben: Syntaktisch und semantisch korrekter HTML-Code unterstützt auch Maschinen wie beispielsweise Suchmaschinen-Crawler dabei, die Gliederung einer Seite zu verstehen und damit diese Seite in den Ergebnissen einer Suchanfrage besser darzustellen.
Die MDN Web Docs der Mozilla Foundation sind eine hochwertige Referenz für die Webseitenentwicklung. Nahezu alle HTML-, JavaScript- und CSS-Begrifflichkeiten werden nicht nur erklärt, sondern auch mit Live-Code-Beispielen anschaulich präsentiert, und es wird auf ihre Aspekte zur Barrierefreiheit eingegangen. Eine Suchmaschinen-Anfrage mit vorangestellten mdn, beispielsweise mdn img, liefert meistens als ersten Treffer den entsprechenden Artikel in den MDN Web Docs. Der Artikel zum <img>-HTML-Element ( https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#accessibility_concerns ) erklärt zum Beispiel, dass für eine barrierefreie Einbindung eines inhaltrelevanten Bildes ein zusätzliches sinnvolles alt-Attribute gesetzt werden muss.
Der Suchschlitz in der GESIS-Web-Kopfzeile listet Suchergebnisse aus der GESIS-weiten Suche auf. Der Informationsgehalt der Suchergebnisdarstellung ist umfangreich: Die Darstellung beinhaltet die Gesamtzahl der gefundenen Ergebnisse, die Aufteilung der Suchergebnisse auf sechs verschiedene Kategorien („Facetten“), sowie ein Karussell mit passenden GESIS-Angeboten und -Veranstaltungen. Desweiteren werden die Suchergebnisse dynamisch, also ohne Neuladen der aktuellen Seite, in einem Pop-up angezeigt.
Diese maßgeschneiderte Funktionalität erhöht die Benutzerfreundlichkeit - eine alternative Standardsuche per HTML-Formular mit Ergebnisanzeige auf einer separaten Seite würde den Benutzer aus seinem aktuellen Seitenkontext werfen und ihn beim schnellen Ausprobieren verschiedener Suchanfragen ausbremsen.
Andererseits verlangen diese Abweichungen vom Standard auch zusätzliche Entwicklungen, um Barrierefreiheit beizubehalten. Im Vergleich zu dieser Maßschneiderei ist ein Standard-HTML-Suchformular mit nachgelagerter Suchergebnisanzeige direkt barrierefrei.
Der Suchschlitz im GESIS-Web eignet sich daher als anschauliche Fallstudie, um verschiedene Anforderungen der Barrierefreiheit aufzuzeigen, sowie wie diese umgesetzt werden können.
Webseiten sollen ihren Besuchern Inhalte, Seitenfunktionen und Navigationsmöglichkeiten auf effiziente Weise vermitteln. Um diese Ziele mit einer visuellen Repräsentation zu erreichen, bedienen sich Webseiten unter anderem an Farben, Bildern, Größenunterschieden und einem zweidimensionalen Layout. Hinzu kommen erlernte Konventionen - Betrachtern ist der Zweck und Funktion des weißen, länglichen Kästchens im Kopfbereich der GESIS-Web-Homepage als Suchschlitz durch ihre Erfahrungen mit anderen Webseiten klar; tippt man in den Schlitz etwas ein, erscheint ein Pop-up mit Suchergebnissen.
Normalsichtige werden im gesamten Suchanfrage-Prozess visuell unterstützt: Angefangen beim Wahrnehmen des Suchschlitzes, seiner Auswahl durch Anzielen und Anklicken mithilfe des Mauszeigers, dem Eintippen einer Suchanfrage inklusive Wahrnehmung eines Rechtschreibfehlers und dessen Korrektur, über die Wahrnehmung des erscheinenden Pop-ups bis hin zur Differenzierung der verschiedenen Suchergebniskategorien durch farbliche und räumliche Gruppierung - bei allen Schritten helfen visuelle Reize, den Suchprozess bis zum erfolgreichen Abschluss voranzutreiben. Wird aber nur ausschließlich eine visuelle Darstellung der Webseite angeboten, scheitert bei blinder Bedienung der Suchprozess bereits beim Ausfindigmachen eines möglichen Suchschlitzes.
Eine gelungene barrierefreie Seite vermittelt alle Inhalte, Seitenfunktionen und Navigationsmöglichkeiten auch in textueller Repräsentation, wie beispielsweise durch Sprachausgabe, effizient. Dies setzt einen syntaktisch korrekten und semantisch aufbereiteten Webseiten-Quelltext voraus, der durch den Screenreader interpretiert wird und den reinen Textinhalt einer Webseite mit zusätzlichen Vermerken erweitert. Außerdem können motorisch Behinderten durch eine vollständige Tastaturunterstützung die Webseite ohne Maus und Touchscreen zu bedienen. Die folgende Auflistung zeigt die entsprechenden Erweiterungen der Suchfunktion um barrierefreie Aspekte:
Die Sprungmarken-Übersicht (NVDA-Tastaturkürzel Einfügen+F7), ein automatisiert erstellter Seitenüberblick ähnlich einem Inhaltsverzeichnis, listet den Suchbereich als Suche auf.
Bei Navigation in den Suchschlitz-Bereich (durch Sprungmarken-Auswahl, Tastaturnavigation, Mausklick etc.) meldet der Screenreader (über Sprachausgabe oder Braille-Zeile):
„Suche: Sprungmarke. Kombinationsfeld: reduziert. Suche: Eingabefeld. GESIS durchsuchen. Leer.“
Für einen geübten Screenreader-Nutzer beinhalten diese Meldungen folgende Informationen in konzentrierter Form: Der Benutzer befindet sich aktuell im Kontext des (Sprungmarken-)Bereiches Suche. Der Eingabecursor ist für Eingaben in ein Suche-Eingabefeld mit der Beschreibung GESIS durchsuchen bereit. Es handelt sich um ein Einabefeld mit einem Pop-up (Kombinationsfeld), und dieses Pop-up wird aktuell nicht angezeigt wird („reduziert“).
Der Benutzer beginnt nun mit der Eingabe der Suchanfrage social (per Tastatur, Spracheingabe etc.). Über die Screenreader-Ausgabe erhält der Benutzer bei jedem Tastendruck Rückkopplung zum eingegebenen Zeichen, wodurch Rechtschreibfehler erkannt werden können.
Sobald Suchergebnisse zurückgeliefert wurden, meldet der Screenreader Folgendes:
„135137 Treffer für social, die GESIS in verschiedenen Angeboten zur Verfügung stellt. Auswahl mit den Pfeiltasten aufwärts und abwärts. Auswahl bestätigen mit Eingabetaste.“
Die barrierefreie Darstellung wurde also um eine Tastatur-Bedienungserklärung erweitert. Diese Erklärung wurde durch den GESIS-Suchschlitz-Entwickler hinzugefügt, da die Darstellung und Auswahl der GESIS-Suchergebnisse wesentlich umfangreicher als eine konventionelle und daher selbsterklärende und aus Erfahrung bedienbare Drop-Down-Box ist.
Der Benutzer navigiert nun mit der Pfeiltaste abwärts durch die Suchergebnisse. Beim ersten Drücken meldet der Screenreader
„Liste. Forschungsdaten 50876. 1 von 6.“
Dem Nutzer wird mit dieser Information vermittelt, dass es sechs Suchergebnis-Kategorien gibt und aktuell die erste Kategorie Forschungsdaten ausgewählt ist.
Der Benutzer drückt ein weiteres Mal auf die Abwärts-Pfeiltaste. Nun verkündet der Screenreader lediglich
„Variablen 157. 2 von 6.“
Die Information „Liste“ wird nicht mehr genannt, da diese Kontextinformation bereits zuvor genannt wurde; eine ausreichende Knappheit an Informationsvermittlung ist der effizienten Zeitnutzung bei Bedienung mit einem Screenreader dienlich.
Diese die Barrierefreiheit unterstützenden Funktionen und Beschreibungen wurden durch folgende Webseiten-Quelltexte erreicht:
Eintrag „Suche“ in Sprungmarken-Übersicht - durch search="role":
<div class="gs_center_search" role="search" aria-live="polite"> ... </div> Beschreibungen zum Typ, Zustand, Namen und Beschreibung des Suchschlitz mit Pop-up - durch role="combobox", aria-expanded="false", <label for="gs_searchterm">Suche</label> und <input name="query" id="gs_searchterm" class="gs_searchterm" type="search" placeholder="GESIS durchsuchen…">:
<div role="combobox" aria-expanded="false" aria-owns="gs_hitlist" aria-haspopup="listbox"> <label for="gs_searchterm">Suche</label> <input name="query" id="gs_searchterm" type="search" placeholder="GESIS durchsuchen…"> ... <div id="gs_hitlist" role="listbox"></div> </div> Automatische Ausgabe von Informationen, wenn Suchergebnisse geliefert wurden - durch aria-live="polite" im kapselnden <div class="gs_center_search" aria-live="polite">: Mit „aria-live“ zeichnet eine Webseite jene dynamischen und interaktiven Bereiche aus, über deren Änderung ein Screenreader-Benutzer informiert werden soll. Ohne diese explizite Auszeichnung bleiben Screenreader stumm. Weitere Beispiele für Live-Elemente sind „Toaster-Meldungen“ („Sie haben eine neue Nachricht erhalten“) und Content-Karusselle. Durch ein knalliges Aufpoppen und eine flüssige Blätter-Animation können solche Widgets ihren Zweck visuell erfüllen, bedürfen aber zusätzlicher Auszeichnung als Live-Region, um auch inklusiv und barrierefrei wahrgenommen werden zu können.
Ausgabe von Tastatur-Bedienungserklärungen bei Screenreaderverwendung, ohne visuelle Darstellung - durch ein <span>-Element, welches aufgrund seiner berechneten CSS-Regeln und aufgrund fehlenden Elementinhaltes zwar nicht visuell sichtbar ist, aber über aria-label-Attribut eine textuelle Beschreibung speziell für Screenreader hat:
<span aria-label="Auswahl mit den Pfeiltasten aufwärts und abwärts. Auswahl bestätigen mit Eingabetaste."></span> Individuelle Tastaturbedienung zur Suchergebnisauswahl mit Pfeiltasten und Schließen durch Drücken der Escape-Taste - durch JavaScript. Bei der Seiteninitialisierung sucht der GESIS-Web-JavaScript-Code nach HTML-Element-IDs und -Klassen, die den Suchschlitz auszeichnen. Findet der JavaScript-Code diese Elemente, werden sie mit der Suchschlitz-spezifischen Logik erweitert:
function init_gws() { var gwsCombobox = document.getElementById('gs_gws_combobox'); var gwsInput = document.getElementById('gs_searchterm'); var gwsOutput = document.getElementById('gs_hitlist'); var gwsClearButton = document.getElementById('gs_search_clear'); var gwsToggleButton = document.getElementById('gs_search_toggle'); if (gwsCombobox && gwsInput && gwsOutput) { var gwsWidget = new aria.ListboxCombobox(gwsCombobox, gwsInput, gwsOutput, fadeMainContent, unfadeMainContent); gwsToggleButton.addEventListener('click', function() { if (gwsWidget.shown) { gwsWidget.hideListbox(); } else { gwsWidget.showListbox(); } }); gwsClearButton.addEventListener('click', function() { gwsWidget.clearInput(); gwsWidget.clearListbox(); }); } } // ... init_gws(); Ausgabe der Gesamtanzahl („sechs“) an auswählbaren Ergebniskategorien, sowie Nummerierung des aktuell ausgewählten Kategorie („zwei von sechs“) - automatisch durch den Browser und Screenreader. Die Suchergebnisse befinden sich innerhalb eines HTML-Elements mit der role="listbox" ( https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/listbox_role ). Diese Rolle resultiert in einen „Vertrag“ zwischen Browser und Webseite: Erfüllt die Webseite die Vorgaben des Vertrags, kümmert sich der Browser darum, weitere Kontext-Informationen zur Verfügung zu stellen. Beispielsweise: Liefert die Webseite ein Vorfahren-Element mit role="listbox" und beinhaltet dieses Element Nachfahren-Elemente mit dem Attribut role="option", dann übernimmt der Browser die Durchnummerierung der Elemente:
<div id="gs_hitlist" class="gs_hitlist" role="listbox" aria-activedescendant="result-2"> <!-- Suchergebnis mit der ID "result-2" ist das aktuell ausgewählte Element --> <div class="..."> <a id="result-1" href="..." role="option" aria-selected="false">Forschungsdaten 3622</a> <a id="result-2" href="..." role="option" aria-selected="true">Variablen 157</a> <a id="result-3" href="..." role="option" aria-selected="false">Messinstrumente & Tools 82</a> <a id="result-4" href="..." role="option" aria-selected="false">Publikationen 79055</a> <a id="result-5" href="..." role="option" aria-selected="false">GESIS-Bibliothek 12382</a> <a id="result-6" href="..." role="option" aria-selected="false">GESIS-Webseiten 2069</a> </div> ... </div> Zu den weiteren Vorgaben, die von der Webseite erfüllt werden müssen, um den Vorgaben von role="listbox" zu entsprechen, gehören:
die Umsetzung der vorgeschriebenen Tastaturbedienungsmöglichkeit (z.B. Aufwärts-Abwärts-Pfeiltasten zur Auswahl eines Ergebnisses) und
die Aktualisierung der Attribute aria-activedescendant=“$SELECTED_ELEMENT“ und aria-selected=“{true, false}“ bei Auswahl eines neuen Elementes.
Die Erfüllung solcher „MUST“-Anforderungen ist notwendig, um Barrierefreiheit zu erreichen; aber ihre Erfüllung ist noch nicht zu Barrierefreiheit hinreichend - dafür bedarf es einer menschlichen Prüfung - schließlich muss es von einem Menschen beurteilt werden, ob beispielsweise die Bedienungserklärung Sinn ergibt.
Zusätzlich gib es optionale „SHOULD“-Vorgaben, deren Umsetzung die Bedienbarkeit weiter steigern - zum Beispiel bei einer „Listbox“ das direkte Selektieren der ersten Option durch Drücken der Pos1/Home“-Taste, sowie der letzten Option durch Drücken der *Ende/End-Taste.
Die W3C pflegt die vollständige Spezifikation dieser Vorgaben in der „Recommendation WAI-ARIA“. Diese Dokumentation ist international maßgeblich bei der Beurteilung, ob eine Webseite und ihre Komponenten barrierefrei sind.
Typische Anwendungsfälle und ihre Erfolgskriterien definieren, z.B.
Diese Anwendungsfälle mit verschiedenen Bedienungshilfen testen:
document.body.style="filter: blur(10px);";window.document.styleSheets[0].insertRule('* { cursor: none !important; }');