Basiswissen

Für die kommenden Module gehe ich von einem gewissen Grundverständnis aus. Wenn Sie allerdings die Barrierefreiheits-Basics auffrischen wollen, sei Ihnen diese Resource ans Herz gelegt. Ich versuche im Folgenden vier Schlaglichter bezüglich Methoden und Bausteinen barrierefreien Arbeitens zu setzen. Konkret sind das

  • WCAG
  • ARIA
  • Das Ausklapp-Muster (auch unter „Disclosure“ oder „(lang: en text: Disclosure Widget)“ bekannt)
  • Die unterschiedlichen Arten, Dinge zu verstecken – vor allen Nutzungsformen, nur sichtbar/visuell, nur vor Hilfstechnologien
  • Landmarks, d.h. die Kunst, Seitenbereiche als solche auszuzeichnen

Die Schlaglichter bauen teilweise auf einander auf.

WCAG

„WCAG“ steht für Web Content Accessibility Guidelines, also in etwa „Webinhalts-Barrierefreiheits-Richtlinien“. Sie sind eine Zusammenstellung von Prüfschritten in Bezug auf Zugänglichkeit von Websites und -apps, die verhindern sollen, dass diese Nutzungs- und Verständnisbarrieren aufweisen.

Dabei sind die WCAG in vier Grundprinzipien aufgeteilt, wenn man so will: in vier Basis-Schlaglichter:

  • Wahrnehmbarkeit
  • Bedienbarkeit
  • Verständlichkeit
  • Robustheit

In den Zusammenhang ist Ihnen vielleicht auch das Akronym „POUR“ über den Weg gelaufen: Das sind die Anfangsbuchstaben der Originalbegriffe für diese Prinzipien (nämlich: Perceivable, Operable, Understandable, Robust). Allgemein kann man sagen, dass WCAG-Vorgaben den Dreh- und Angelpunkt in Sachen Web-Barrierefreiheit darstellen. Auch weil sie (in ihrer üblich referenzierten Stufe „Level AA“) nicht der Weisheit (bzw. der Nutzungsfreundlichkeits) letzter Schluss sind, definieren sie doch die absoluten Mindestanforderungen. Diese müssen als Minimum erfüllt werden, damit ein Webprojekt überhaupt als „barrierefrei“ (besser: „zugänglich“) gelten können. Das Prüfen und Einhalten dieser Anforderungen nennt man „Konformität“.

Dabei hat die WCAG ziemlich binäre Konformitätsbedingungen. Ein Erfolgskriterium (das heißt etwa „ein Testschritt“) ist entweder erfüllt oder nicht (pass oder fail). Man kann zudem nur einen Webauftritt als WCAG-konform bezeichnen, wenn alle Anforderungen einer Konformitätsstufe (zum Beispiel AA) erfüllt (pass) sind.

Die WCAG wird in vielen Rechtssprechungen weltweit entweder direkt oder indirekt referenziert (aktuell mehrheitlich in Version 2.1). So sind die Web Content Accessibility Guidelines beispielsweise Teil der harmonisierten Europäischen Norm (EN) 301 549. Diese ist für die Erfüllung des BFSG sehr zentral (siehe Blogartikel zur Europäischen Norm 301 549) . Auch in beispielsweise der „Section 508“, ein amerikanisches Bundesgesetz, das die Web-Zugänglichkeit der US-Regierung selbst regelt, findet sich die WCAG 2.1 wieder.

Screenshot: Die WCAG als 'W3 Recommendation', also W3 Standard.

ARIA

Sie haben eventuell schon mal von ARIA gehört, und es hat in Ihrem Kopf eventuell schon einen Zusammenhang mit Barrierefreiheit. Möglicherweise gilt es Ihnen sogar als Indikator von Barrierefreiheit oder gar als Mittel zur Behebung vieler Barrieren. Während an diesem Ruf in bestimmten Fällen etwas dran ist, ist es eher so, dass man ARIA wie ein sehr scharfes Messerset in der Küche sehen sollte: Sehr praktisch und nützlich, wenn man weiß, damit umzugehen: Denn manchmal erfordern Schneidearbeiten eine sehr scharfe Klinge. Der Vergleich zum Messer soll aber auch verdeutlichen, dass ein falscher Umgang mit ARIA zu Verletzungen führen kann, und das meist auf der Seite Ihrer Website-Besuchenden (oder Kundinnen und Kunden). Das Tragische ist zudem, dass Ihnen als ARIA-Koch/Köchin die angerichteten Verletzungen Ihrer Gäste unter Umständen gar nicht auffällt.

Kurz zusammengefasst ist ARIA ein mächtiges Tool in Ihrem Web-Werkzeugkasten. Mit diesem Werkzeug hat man entweder Potentiale in der Hand, Dinge zielgenau zu lösen, die mit HTML in der Form gar nicht möglich wären (oder noch nicht möglich sind). Oder aber, unter Umständen Schaden oder Irritationen anzurichten, ohne es zwingend zu merken.

Bevor ich versuche, das mit einem konkreten Beispiel zu erläutern, lassen Sie uns anschauen, was ARIA eigentlich ist: Es ist eine technische Spezifikation, die insbesondere die Zugänglichkeit von Webanwendungen verbessern soll, und nach aktueller Umsetzung insbesondere Screenreader-(Vorleseprogramm-)Nutzenden bestimmte Aspekte von Anwendungen (Zustände oder Interface-„Rollen“) näher bringen soll. Dafür arbeitet ARIA mit einem Satz von programmatischen Attributen, die (aktuell faktisch nur) auf HTML aufsetzen, sodass diese Meta-Informationen von Hilfstechnologien ausgelesen werden können. Mit ihrer Hilfe können ihre Nutzenden dann die Programmoberfläche und ihre Eigenschaften und eventuell dort ausgelöste Prozess besser verstehen.

Frustrierenderweise ist die Unterstützung von ARIA in verschiedenen Hilfstechnologien unterschiedlich gut. Aus diesem Grund achte ich in diesem Kurs auf gut unterstützte Patterns – sofern überhaupt ARIA-Muster vorgestellt werden. Ein Cummunity-Projekt, das versucht, Hilfstechnologie-Ünterstützung zu ARIA-Funktionen zu erfassen, findet sich übrigens hier: https://a11ysupport.io/.

Fassen wir mal kurz zusammen: ARIA ist also mächtig; man kann mit seinen Attributen viel Gutes und Schlechtes anrichten – je nach ARIA-Wissen der implementierenden Person. Deswegen hat die Initiative hinter WAI-ARIA der Spezifikation folgende (inoffizielle, aber wichtige) Regeln gegeben:

  1. Wenn Sie Zielsetzungen mit einem HTML-Element oder -Attribut lösen können, anstatt auf ARIA zurückzugreifen, dann tun Sie das bitte (Diese Regel wird häufig unzulässig auf „Don't use ARIA“ verkürzt).
  2. Verändern Sie nur die semantische Rolle von Elementen per ARIA, wenn Sie wirklich müssen (ich würde gerne ergänzen: „…und wenn Sie genau wissen, was Sie damit tun“, mehr dazu weiter unten).
  3. Kontrollelemente und Widgets, die mit ARIA gebaut werden, müssen tastataturbedienbar sein.
  4. Verwenden Sie nicht role="presentation" oder aria-hidden="true" (das „Abklemmen“ von aussagekräftiger Semantik bzw. das Verstecken vor Hilfstechnologie) auf einem fokussierbaren Element. Diese Regel ist unter Umständen nicht gleich auf Anhieb verständlich, ich bemühe mich aber, die unklaren Punkte später zu erklären.
  5. Interaktive (ARIA-)Elemente benötigen einen zugänglichen Namen, das bedeutet: eine sichtbare oder programmatische Beschriftung.

Neben der Beachtung dieser Regeln, neben dem Wissen, dass – ganz im Spiderman-Sinne – zu viel Macht viel Verantwortung gehört, ist mir noch ein Aspekt sehr wichtig: ARIA selbst implementiert in der absoluten Mehrheit der Fälle keine Funktionen, sondern kündigt nur an, dass welche implementiert sind. Das wird am deutlichsten am Beispiel der semantischen Rolle (role-Attribut; es heißt übrigens ausdrücklich nicht: aria-role): Bekommt ein Element eine bestimmte semantische Rolle wie button, kündigt dies eine bestimmte Tastaturnutzung an. Im Falle der button-Rolle ist das: „Ich als Schaltfläche bin per Eingabe- und Leertaste aktivierbar“. Geben Sie die Rolle einem ansonsten nicht-interaktivem Element, müssen Sie also das Versprechen einlösen, und zwar manuell und ausdrücklich. Und weil natürlich auch ein Klick-Ereignis zu einem Button gehört, müssen Sie insgesamt drei Events implementieren:

  • Klick-Event: was passiert, wenn das Element geklickt wird?
  • Tastatur-Event: was passiert, wenn die heruntergedrückte Taste die Leertaste war?
  • Tastatur-Event: was passiert, wenn die heruntergedrückte Taste die Eingabetaste war?

Ganz schön viele Einzelschritte, nicht war? Und wir sind tastatur-seitig noch nicht mal fertig: Wenn wir zum Beispiel davon ausgehen, dass wir aus irgendwelchen Gründen aus einem <div> einen <button> machen müssen oder wollen, steht allem Tastatur-Handling noch vor, dass "Schaltflächen"-Element überhaupt erst tastaturerreichbar zu machen. Das ist mit dem HTML-Attribut-Wertpaar tabindex="0" möglich. Und noch ein Punkt, den es zu beachten gilt (weil es so schön ist): Erinnern Sie sich noch an die fünfte ARIA-Regel? Wir müssen zusätzlich noch sicher gehen, dass unser frisch aus anderen Mitteln gebauter Button einen zugänglichen Namen hat.

All die genannten Einzelschritte sind der Grund, warum Web-Barrierefreiheits-Sachverständige besonders im konkreten Fall des Buttons sagen: Nutzen Sie lieber das native HTML-Element für Schaltflächen, also <button>. Dies hat nämlich folgende Vorteile:

  1. Ein <button>-Element hat wenig überraschend auch die semantische Rolle button, gibt sich also als Schaltfläche zu erkennen.
  2. Ein Klick-Event, das auf einem <button>-Element registriert ist, implementiert auch gleichzeitig das Tastaturhandling, das die Rolle verspricht: Sie müssen sich also nicht darum kümmern, dass das Eingabetaste-wird-gedrückt- oder Leertaste-wird-gedrückt-Ereignis den Klick-Event-Handler aufruft – das passiert bereits als „Inklusiv-Leistung“, wenn sie das native <button>-Element nutzen.
  3. Genauso sind <button>-Elemente bereits „ab Werk“ tastaturerreichbar und es sind keine weiteren Maßnahmen wie ausdrückliche tabindex-Attribute nötig.

Halten wir also fest:

  • Theoretisch und praktisch kann man mit WAI-ARIA HTML-Elemente nachbauen. Das ist aber nicht empfehlenswert, wenn einem ein gleichwertiges natives HTML-Element zur Verfügung steht. Denn die Gefahr lauert darin, Funktionen anzukündigen, aber dann nicht zu liefern. Natives HTML (wie ein <button>-Element) liefert schon automatisch sehr viele Funktionen und Zustände, die ansonsten alle manuell eingebaut werden müssen. Die Gefahr, dass man einen versprochenen Aspekt vergisst, ist durchaus gegeben und macht die Bedienung des Interfaces dann schlechter oder unmöglich.
  • ARIA ist kein Feenstaub, den man über eine Website oder -applikation streut und wundersam für mehr Zugänglichkeit sorgt. Im Gegenteil: Der ARIA-Werkzeugkasten besteht aus „scharfen“ und mächtigen Tools, die fähige Hände im Umgang mit ihnen erfordern. Denken Sie an das Messerset, dass aufgrund der scharfen Klingen beim Kochen manchmal nötig sein wird - aber viel häufiger bei Ungeübten zu Schnittverletzungen führen könnte. Der mächtigste Hebel bzw. das schärfste Messer sind hier wahrscheinlich das Konzept „semantische Rolle“, denn:
  • Eine ARIA-Rolle ist ein Nutzungsversprechen. Wenn man sie verteilt, kündigt man gleichzeitig eine Tastaturnutzungsart an. Bei der Rolle button ist das beispielsweise Aktivierung durch Eingabe- und Leertaste (neben dem Klick-Ereignis). Haben Sie das immer im Hinterkopf, wenn Sie die semantische Rolle eines Elements ändern (siehe auch ARIA-Regel 2). Einen Versuch einer Übersicht über alle möglichen Versprechen verschafft diese Seite: (bitte beachten Sie, dass die Betrachtung der Muster im „(lang: en text: ARIA Authoring Practices Guide)“ eher akademisch und mit der Haltung „so sollte es in einer perfekten Welt sein“ erstellt wurden – nicht alle der dort zu findenden Patterns sind gut unterstützt oder funktionieren auch mobil).
Screenshot: WAI-ARIA als 'W3 Recommendation', also W3 Standard.

Fazit

Insbesondere (ARIA-)Rollen bieten das Potential, sogar für neue Barrieren zu sorgen, selbst wenn ihr Einsatz mit den besten Absichten erfolgte.

Um das Thema „ARIA-Zustände“ kümmern wir uns in der nächsten Sektion, beispielhaft am Attribut aria-expanded demonstriert, mit dem man beschreiben kann, ob etwas ein- oder ausgeklappt ist.

Disclosure/Ausklapp-Bereiche

Screenshot: Die Schalfläche 'Mein Konto' löst eine Unternavigation in Form eines Auskappbereiches aus.

Das „Ausklapp-Muster“ (auch als „Disclosure Widget“ bekannt) ist eines der Grundbausteine moderner, webbasierter Interfaces. Und häufig ist dieses einfache Pattern auch die beste Wahl, um Widgets zu bauen, die etwas sichtbar machen und wieder verstecken, beispielsweise in so genannten Megamenüs (siehe entsprechendes Modul). Ist nämlich ein Unter-Navigationsmenü als korrekt gebautes Disclosure-Widget eingeklappt, sind auch alle seine interaktiven Kindelemente in diesem Zustand nicht tastaturerreichbar – und Nutzende haben keine überflüssigen/uninteressanten Fokushaltepunkte zu besuchen.

Dabei besteht das Ausklapp-Muster aus zwei wesentlichen Bestandteilen:

  1. Einem Ausklapp-Auslöser: dies ist eine interaktive Kontrollfläche, die bei Aktivierung einen Inhalt (siehe 2.) entweder versteckt oder wahrnehmbar macht. Auch wenn rein von der ARIA-Spezifikation her dieser Auslöser ein Link sein darf, ist in der Praxis ein Element der Rolle button zu empfehlen (denn diese Rolle ist prädestiniert für „Zustandsänderungen“ im Interface wie diese – Links dagegen führen eher zu einer anderen Ressource). Die Schaltfläche kommuniziert über das Attribut aria-expanded, ob der beeinflusste Inhalt wahrnehmbar ist (true, "ausgeklappt") oder nicht (false, "eingeklappt"). Der Attributswert von aria-expanded muss - je nach Zustand des Widgets – dynamisch gesetzt werden. Ein besonderes Fokusmanagement darf hier nicht stattfinden: Der Tastaturfokus bleibt auf dem Auslöser und der oder die Nutzende bekommt per dynamischem Wert-Wechsel von aria-expanded kommuniziert, ob das Widget sich in einem ein- oder ausgeklappten Zustand befindet. Screenreader geben z. B. „Schaltfläche, ausgeklappt“ oder „Schaltfläche, eingeklappt“ aus.
  2. Dem vom Auslöser beeinflussten Container. Besondere Eigenschaften oder gar Rollen benötigt dieser Container nicht, solange man zwei Dinge sicherstellt:
    • a) der Container muss im Dokument direkt auf den Auslöser folgen. Wenn das nicht der Fall ist, wird unter Umständen ein Fokus-Versetzen nötig (und wir reden dann wahrscheinlich von einem Dialog, also einem anderen Interface-Pattern).
    • b) wenn der Container im Modus "nicht wahrnehmbar" ist (der Auslöser das entsprechend mit aria-expanded="false" kommuniziert), muss er mit einer zulässigen Versteck-Methode vor wirklich allen Nutzergruppen verborgen werden. Mehr dazu im nächsten Abschnitt, aber display: none im CSS oder das hidden-Attribut im HTML sind jeweils eine angemessene Wahl dafür, denn sie sorgen dafür, dass die interaktiven Kindelemente der Container mit diesen Eigenschaften nicht mehr tastaturerreichbar oder überhaupt wahrnehmbar sind. Beim „Wieder-wahrnehmbar-machen“ kann dann z. B. display: block oder das Entfernen des hidden-Attributs genutzt werden und interaktive Elemente sind zurück im so genannten "Tabindex".

Codebeispiel:

<button id="menu" aria-expanded="false">
Navigation
</button>
<div id="navigation" hidden>
	<ul>
		<li>Do</li>
		<li>Re</li>
		<li>Mi</li>
	</ul>
</div>
const btn = document.querySelector('#menu');
const container = document.querySelector('#navigation');

btn.addEventlistener('click', () => {
// Wenn Auslöser-Klick und eingeklappt:
	if (btn.getAttribute('aria-expanded') == 'false') {
		// Der Container wird wahrnehmbar gemacht
		container.removeAttribut('hidden');
		
		// Das Ausklapp-Widget kommuniziert nun, dass es ausgeklappt ist
		btn.setAttribute('aria-expanded', 'true');
	} else {
			// Der Container wird versteckt
		container.addAttribute('hidden', true);
		
		// Das Ausklapp-Widget kommuniziert nun, dass es eingeklappt ist
		btn.setAttribute('aria-expanded', 'false');
	}
});

Zwei Hinweise:

  • Wenn der Container per display: none versteckt wird, bietet sich ein so genannter Attributselektor im CSS an, der fest mit dem ARIA-Zustand „verdrahtet“ ist, also z. B. #menu[aria-expanded="true"] + #container { display: block; } und umgekehrt #menu[aria-expanded="false"] + #container { display: none; }. Wenn das hidden-Attribut dynamisch entfernt bzw. ergänzt wird, wie im Beispiel oben, ist dies nicht nötig.
  • Die Werte von aria-expanded müssen "true" und "false" als Strings mit diesem Namen, nicht etwa die entsprechenden Boolean-Werte sein (siehe Codebeispiel – die Hochkommata sind hier entscheidend).

Ausklapp-Elemente finden sich im Praxiseinsatz auf ecbf.shop zum Beispiel im Megamenü (im „Desktop“- wie „Mobil“-Design) oder wie abgebildet in „Mein Konto“.

Verstecken

Einen Teil Interface zu bauen, um jenen dann wieder zu verstecken, ist weniger ungewöhnlich als man denkt. Beispielsweise werden - üblicherweise - Sprunglinks [^ Dokumenteninterne Links, mit denen man große Seitenbereiche mit vielen Fokusstationen, z. B. Hauptnavigationen, überspringen kann] visuell versteckt, bis sie den Fokus erhalten und sichtbar werden. Oder man konstruiert einen Ausklapp-Bereich (siehe letzte Sektion), der einen Container ein- und wieder ausblenden kann. Wenn dieser nicht wahrnehmbar ist, möchte man auch nicht, dass interaktive Elemente in ihm per Tastatur bedienbar oder auf sonstigen Wegen entdeckbar sind. Oder man möchte ein Piktogramm für eine bestimmte Gruppe an Nutzenden verstecken, da seine Bedeutung bereits durch einen nebenstehenden Text klar wird, es also nur wiederholende Funktion hat.

Zum eigenen Werkzeugkasten der Web-Barrierefreiheit gehört auch die Fähigkeit, Dinge auf genau die richtige Art zu verstecken und sich der Vor- und Nachteile dieser Methoden im Klaren zu sein. Deswegen hier im Folgenden eine Kurzvorstellung der verschiedenen Methoden:

Verstecken vor allen Nutzenden

Diese extremste oder konsequenteste Art des Versteckens verbirgt Inhalte vor wirklich allen Nutzungsformen. Für visuell Nutzende und auch Nutzerinnen und Nutzer von Hilfstechnolgien wie Screenreader existieren Elemente quasi nicht, die entweder das hidden-HTML-Attribut, display: none oder visibility: hidden per CSS bekommen haben. Letztgenanntes ist ein sehr spezielles Werkzeug, da das Element zwar vor allen versteckt wird, aber seinen Platz im Browser noch reserviert (wenn es nicht ohnehin per position: absolute platziert ist).

Wichtig ist hier: Hat ein Elternelement beispielsweise das hidden-Element (oder ist anderweitig konsequent vor allen versteckt), so sind etwaig existierende interaktive Kindelemente ebenfalls unerreichbar. Das bedeutet beispielsweise, dass Links in einem Ausklapp-Container, der „geschlossen“ oder „eingeklappt“ ist, nicht per Tastatur erreichbar sind.

Nur visuelles Verstecken

Manchmal braucht man jedoch einen Weg, um Dinge zielgenauer zu verstecken. Will man beispielsweise typische Sprungmarken implementieren, so erfordert das, dass sie im Startzustand erst einmal nicht (visuell) sichtbar, aber sehr wohl tastaturerreichbar sind. Erst wenn sie den Tastaturfokus erhalten, werden sie auch sichtbar (Es spricht übrigens auch nichts dagegen, mit initial sichtbaren Skiplinks zu arbeiten).

Oder man möchte die Überschriftenstruktur eines Dokumentes verbessern (Seitenbereiche überschreiben und damit ein schnelles Scannen nur der Überschriften ermöglichen) – allerdings ohne das visuelle Design zu beeinflussen.

Für beide dieser Beispielfälle (Sprunglink-Initialzustand und Überschrift) gibt es mehrere Techniken des nur visuellen Versteckens.

Möglicherweise kennt der eine oder die Andere schon CSS-Hilfsklassen, die meist sr-only oder visually-hidden heißen. Und auch in einem komplexen E-Commerce-Projekt lohnt es sich deswegen, eine „Werkzeug-CSS-Klasse“ wie die folgende zu etablieren:

.visually-hidden:not(:focus):not(:active) {
  clip: rect(0 0 0 0); 
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap; 
  width: 1px;
}

Wichtig im Umgang mit den nur visuellen Verstecken sind zwei Dinge:

  • Dieser Ansatz und auch der nächste sollten nur in Ausnahmefällen (wie den oben genannten) eingesetzt werden. So sollten Hilfstechnologien wie beispielsweise Screenreader nur in gut begründeten Sonderfällen mehr (oder – wie im kommenden Fall – weniger) Inhalte ausgegeben bekommen. Es ist gut noch einmal daran zu erinnern: Nicht jeder Screenreader-Nutzende ist blind (auch für beispielsweise Menschen mit Legasthenie kann er eine Hilfstechnologie sein). Und „blind sein“ ist ein Spektrum unter einer fließenden Definition – blind und sehend binär auf „Null oder Eins“ zu verengen wird der Realität nicht gerecht.
  • Rein visuell versteckte Inhalte sind nach wie vor per Tastatur erreichbar – ansonsten wäre ihr Einsatz im Startzustand eines Skiplinks die kollossal falsche Wahl. Das heißt im Umkehrschluss aber auch, dass diese Strategie z. B. für den Container eines Ausklapp-Bereiches der falsche Ansatz wäre, da ansonsten unsichtbare und damit verwirrende, unsichtbare Fokushaltepunkte entstehen würden.

Verstecken nur vor Hilfstechnologie

Es gibt einige wenige Umstände, in denen man Elemente nicht visuell, aber vor Hilfstechnologien verstecken will (quasi als genaues Gegenteil des vorherigen Ansatzes) – und diese haben meistens mit dem Vermeiden von Wiederholungen zu tun. Wenn z. B. ein Piktogramm als dekorativ (z. B. als redundant) betrachtet wird und ein HTML-<img>-Element ist, genügt ein leeres alt-Attribut, um es als solches auszuzeichnen und somit vor z. B. Screenreader-Nutzenden zu verstecken. Ist das Icon aber ein Vektor, der per eingebettetem <svg>-Element implementiert ist, fällt diese Option weg (da ein alt-Element auf einem <svg> nicht funktioniert).

Für diese Sonderfälle steht aria-hidden="true" bereit, das das Element und übrigens auch all seine Kindelemente vor Hilfstechnologie versteckt. Wie aber im Abschnitt zu ARIA bereits zu lesen und lernen war, ist es immens wichtig, mit ARIA-Werkzeugen verantwortungsvoll umzugehen. Und wie auch mit der Option des „visuellen Versteckens“ kann hier ein Unterschied zwischen wahrnehmbaren Interface und z. B. Screenreader-Ausgabe entstehen, was gut begründet sein muss. Beispielsweise um eine befremdliche Ausgabe von SVGs in dieser Hilfstechnologie zu vermeiden (siehe englischsprachiger Artikel zu SVG-Fehlausgaben).

Landmarks/Seitenbereiche

So genannte ARIA-Landmark-Bereiche zeichnen einzelne Seitenbereiche aus und dienen vor allem Screenreader-Nutzenden dazu, schnell ein Dokument zu erfassen und zu seinen Sektionen wie z. B. Fussbereichen, Hauptinhalt oder auch Navigationen zu springen.

Möglicherweise sind Ihnen in der Praxis schon HTML-Elemente wie <header>, <main> oder <footer> über den Weg gelaufen – das sind die Landmarks (wörtlich: Wahrzeichen), von denen hier die Rede ist. Wie jedes HTML-Element auch besitzen sie eine „eingebaute“ bzw. implizite semantische Rolle. Diese ausdrücklich oder „explizit“ zu verteilen, wurde in einer Übergangsphase nötig bzw. empfohlen – eventuell sind deswegen die Landmarks so ähnlich auch über eine role-Verteilung bekannt. Im Folgenden die Elemente mit ihren eingebauten Rollen und weiteren Eigenschaften:

  • <nav>-Elemente haben die Rolle navigation. Wie es der Name erahnen lässt, werden auf diesem Wege Navigationsbereiche ausgezeichnet. Gibt es mehrere Navigationsbereiche, verlangen viele Barrierefreiheits-Prüfende, dass man sie per z. B. aria-label="Rechtliches" oder aria-labelledby="IdDesEelementsInDessenTextEinSinnvollerNameSteht" – also individuellem, aussagekräftigen Namen – voneinander unterscheidbar macht.
  • <main>-Elemente haben die implizite Rolle main und sind für Hauptinhaltsbereiche zuständig.
  • <header>-Elemente, zumindest jene, die am Nähesten am <body>-Element sind, haben die Rolle banner. Wichtig ist hier, dass nicht Banner wie Werbe- oder Cookiebanner gemeint sind. Einen Bereich, der kein Kopfbereich ist, mit role=banner auszuzeichnen, ist aus diesem Grund falsch und wird Nutzende irritieren.
  • <footer>-Elemente haben die Rolle contentinfo (nicht etwa „footer“). Dass lässt sich gut herleiten, da ein Fussbereich häufig den Charakter einer „Inhaltsinfo“ hat, beispielsweise mit Metanavigation und Copyright-Angaben aufwartet.
  • Ein <aside>-Element hat die Rolle aside und zeichnet einen Seitenbereich aus, der nur im indirekten Zusammenhang zum Hauptinhalt steht. Häufig finden sich aside-Inhalte auch grafisch in einer Art Marginalspalte oder Sidebar/Seitenleiste.
  • Seit ziemlich kurzer Zeit gibt es auch ein <search>-Element, dass als Landmark einen Bereich mit einer Suche auszeichnet. Auch hier gilt das Prinzip, das bei mehreren Landmarks des gleichen Typs greift (wie bei Navigationsbereichen): Ein je eigener zugänglicher Name muss existieren, damit die betreffenden Bereiche unterschieden werden können.

Darüber hinaus gibt es noch einige weitere Landmark-Arten:

So markiert ein <search>-Element den zentralen Suchbereich eines Dokumentes. In ihm finden sich gerade in einem E-Commerce-Kontext häufig die mächtige Suchfunktion wieder. Da das <search>-Element noch relativ neu ist und die Unterstützung in Browsern und Hilfstechnologien entsprechend lückenhaft, wird empfohlen, mit impliziter und expliziter Rolle zu arbeiten:

Code: 

<search role="search"><label for="suche">Suche</label><input id="suche" type="text" /></search>

Zu guter Letzt kann man auch einen „generellen Seitenbereich“ auszeichnen - falls die Standard-Elemente aus dem Werkzeugkasten nicht zu hundert Prozent zu den Anforderungen eines Projektes passen. Dazu muss man ein bestehendes Element, das zu einem Bereichscontainer werden soll (ein z. B. <div>) mit zwei Eigenschaften ausstatten:

  • 1. Der expliziten ARIA-Rolle region, also z. B. role="region".
  • 2. Einen so genannten zugänglichen Namen. Das kann per aria-label oder aria-labelledby="IdDesEelementsInDessenTextEinSinnvollerNameSteht" passieren.

Beispiel für eine selbstgebaute Landmark-Region:

<div role="region" aria-label="Produktlistung">
<!-- hier die Produkte -->
</div>
Zusammenfassung
  • Die Web Content Accessibility Guidelines (WCAG) sind der relevante internationale Web-Barrierefreiheitsstandard. Auch die Europäische Norm (EN) 301 549 verweist in ihrem Kapitel 9 auf diesen in Level AA (ergänzt aber noch weitere Aspekte). Die aktuellste Version ist der WCAG ist 2.2, in der aktuellen Version der EN wird aber noch auf Version 2.1 verwiesen. Es ist aber absehbar, dass die nächste Version der EN WCAG 2.2 umfassen wird.
  • ARIA ist eine semantische Erweiterung von HTML im Speziellen für Hilfstechnologien wie Screenreader. Dabei implementiert es in der absoluten Mehrheit der Fälle keine Funktionen, sondern kündigt nur ihre Anwesenheit an. Ein falscher Einsatz von ARIA kann - egal, wie gut er gemeint ist - zu mehr und neuen Barrieren führen. Insofern ist ein Verantwortungsvoller Umgang und der Einsatz von passenden HTML-Elementen angeraten.
  • Der Ausklapp-Bereich (auch: (lang: en text: Disclosure Widget)) ist ein zentrales Nutzungsmuster in Interfaces. Dabei ist es simpel aufgebaut: Der Auslöser hat das Attribut aria-expanded, dessen Wert true oder false dem Zustand des beeinflussten Bereichs entspricht (wahrnehmbar oder nicht). Dabei sollten Auslöser und Bereich im Dokument direkt aufeinanderfolgen. Es gibt mit <details> und <summary> eine native HTML-Implementation, die aber „semantisch“ und nicht als abstraktes Pattern eingesetzt werden sollte (in dem Fall ist das ARIA-Pattern zu bevorzugen).
  • Es gibt unterschiedliche Arten, Dinge zu verstecken:
    • nur visuell
    • nur vor Hilfstechnologie, aber visuell sichtbar
    • vor allen Nutzungsformen Es ist zu beachten, dass nur die letzte Form auch Fokushaltepunkte im versteckten Element aus der Gesamtheit aller Fokushaltepunkte (Tabindex) entfernt.
  • ARIA-Landmarks zeichnen Seitenbereiche aus, beispielweise Hauptinhaltsbereiche (<main>), Kopf- und Fussbereicheiche (der äußerste <header>, <footer>) und Navigationen (<nav>). Letztgenannte müssen durch verschiedene Bezeichnungen von einander unterscheidbar sein (z. B. „Rechtliches“ und „Social Media“).