Eine Handreichung der uAG Technische Überwachung
Herausgeber: Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik, Unterarbeitsgruppe Technische Überwachung
Die hier dargestellten Inhalte wurden gemeinsam von den Überwachungsstellen der Länder und des Bundes erarbeitet.
Version: 1.0
Sie können diese Handreichung als PDF-Datei (Öffnet PDF-Dokument) oder DOCX-Datei (Öffnet Word-Dokument) herunterladen.
Einleitung (2 min)
Benutzergruppen (5 min)
Tastaturbedienung (9 min)
Webseitenstruktur (5 min)
Es sollen Auffälligkeiten aus den Prüfungen der Barrierefreiheit von digitalen Angeboten dargestellt werden. Als digitales Angebot werden Webanwendungen und Webauftritte im Inter-, Intra- und Extranet sowie mobile Anwendungen verstanden.
Ziel ist es, neben den Auffälligkeiten, die Auswirkungen auf Menschen mit Beeinträchtigungen darzustellen und mögliche Lösungsideen zu geben.
Die hier beschriebenen Auffälligkeiten/Probleme werden regelmäßig überprüft bzw. ergänzt. Im Folgenden werden die Ziffern aus der WCAG genannt, wenn die Anforderung der harmonisierten-europäischen Norm EN 301 549 aus Abschnitt 9, 10 oder 11 darauf verweist.
Mit der Einhaltung von Barrierefreiheitsvorgaben soll Menschen mit Beeinträchtigungen gleichwertiger Zugang zu Informationen und Funktionalität von digitalen Angeboten ermöglicht werden. In diesem Dokument sollen häufige Probleme, die bei Prüfungen aufgefallen sind, dargestellt und Lösungsvorschläge gemacht werden.
Die harmonisierte-europäische Norm EN 301 549, die eine maßgebliche Rolle im Rahmen der Barrierefreiheit einnimmt, definiert verschiedene Benutzergruppen, die hier kurz dargestellt werden.
Menschen mit kognitiven Einschränkungen, z. B. Menschen mit Lernbeeinträchtigungen, Lernschwierigkeiten und Aufmerksamkeitsschwierigkeiten können Probleme beim Erfassen und Verstehen von Inhalten einer Anwendung haben. Sie haben meist Probleme, lange und umständlich formulierte Texte mit schwierigen Schachtelsätzen und Fremdwörtern sowie eine komplexe Navigation bzw. Maskenstruktur zu verstehen. Deswegen ist es sinnvoll und notwendig, Anwendungen in Leichter Sprache zu verfassen oder Übersetzungen in „Leichte Sprache“ anzubieten. Der Aufbau einer Anwendungsmaske muss für diese Nutzergruppe einfach strukturiert sein. Des Weiteren werden kognitiv eingeschränkte Personen z. B. bei Aufmerksamkeits-Defizit-Hyperaktivitäts-Störung (ADHS) leicht durch sich bewegende und kontinuierlich aktualisierende Elemente abgelenkt, sodass sie sich nicht auf ihr Ziel konzentrieren können.
Blinde Menschen sind solche, die entweder eine hochgradige (Sehrest von 2 % oder weniger) oder eine vollständige Sehbeeinträchtigung aufweisen. Ein Mensch ist hochgradig sehbehindert, wenn er auf dem besser sehenden Auge selbst mit Brille oder Kontaktlinsen nicht mehr als 5 % von dem sieht, was ein Mensch mit normaler Sehkraft erkennt. Blinde und auch hochgradig sehbehinderte Menschen können einen gut strukturierten Text über eine Braillezeile oder Sprachausgabe mit entsprechender Software (Screenreader) lesen bzw. abrufen. Informative Grafiken, Bilder oder Text, der in Bildern enthalten ist, sind für Menschen mit Blindheit unzugänglich und sind daher mit einem alternativen Text zu ergänzen. Wichtig ist für blinde Menschen die Trennung von Inhalt und Design innerhalb einer Anwendung.
Sehbehinderte Menschen verfügen über eine Sehkraft von weniger als 30 %. Sehschwache Menschen verfügen über eine Sehkraft von mehr als 30 %. Die Nutzergruppe der sehbehinderten und sehschwachen Menschen verwendet eine Vergrößerungssoftware, die den Bildschirminhalt vergrößert oder vorliest. Manche Menschen nehmen nur geringe Kontraste wahr und profitieren daher von kontrastreichen Texten und Grafiken. Darüber hinaus verwenden sie Betriebssystemeinstellungen zur Anpassung des Farbschemas und der Schriftgröße.
Menschen mit einer Farbsehschwäche können Farbkombinationen nicht unterscheiden (z. B. rot/grün). Sie benötigen starke Kontraste und gut lesbare Schriften sowie Kontrolle über die Farbe von Schrift und Hintergrund.
Gehörlose Menschen sind solche, die nicht in der Lage sind, akustische Informationen wahrzunehmen. Sie sind vollständig oder nahezu vollständig gehörlos. Gehörlosigkeit kann über den Grad des Hörverlustes definiert werden. Dies reicht von einer hochgradigen Schwerhörigkeit bis hin zu einem gewissen Grad der Resthörigkeit. Ihre Muttersprache ist oft die deutsche Gebärdensprache. Diese ist eine eigenständige Sprache, die z. B. einer Übersetzung durch Dolmetschende bedarf. Für sie ist die Schriftsprache eine Fremdsprache. Akustische Informationen sind durch visuell wahrnehmbare Inhalte zu ergänzen oder von ihnen zu begleiten. Der Hörverlust kann auch nach Erlernen der Schriftsprache eingetreten sein. In diesem Fall wird deutsche Gebärdensprache nicht immer erlernt. Hörbeeinträchtigte Menschen haben bei der Wahrnehmung von sprachlichen Inhalten Verständnisprobleme, die auch von modernen Hörgeräten nicht beseitigt werden können. Auch Umgebungs- und Hintergrundgeräusche können störend sein.
Menschen mit motorischen Beeinträchtigungen haben Einschränkungen im Bereich der Bewegung, Motorik und Gliedmaßen-Koordination. Personen mit z. B. Spastiken oder anderen motorischen Störungen, die keine Maus bedienen können, müssen z. B. mit der Tastatur oder Sprachsteuerung navigieren. Eine Navigation ist nur möglich, wenn alle Elemente programmatisch ermittelbar sind, z. B. wenn Elemente über die Spracheingabe angesteuert werden können.
Alle Funktionen des digitalen Angebots müssen über eine Tastatur bedienbar und zugänglich sein. Es gibt eine „echte“ Tastatur, Bildschirmtastatur oder Sprachsteuerung, über die Anweisungen mit Tastatureingaben erzeugt werden können. Diese Funktionalität ist für blinde Menschen mit Screenreader, die keine Maus benutzen, und den Computer mit Hilfe von einer Sprachausgabe oder Braillezeile bedienen, besonders wichtig. Aber auch sehbeeinträchtigte Menschen profitieren, wenn eine starke Vergrößerung verwendet wird. Es können dann immer nur kleine Teile bzw. Ausschnitte des Bildschirms eingesehen werden. Der Ausschnitt muss entsprechend verschoben werden. Diese Arbeitsweise ist mit der Maus umständlich. Die Eingabeelemente und Links können stattdessen mit der Tastatur angesprungen werden. Auf diese Weise wird immer der entsprechende Ausschnitt auf dem Bildschirm angezeigt. Auch motorisch eingeschränkte Menschen, die keine Zeigegeräte (z. B. Maus, Eye-Tracking), jedoch stattdessen vielleicht eine Tastatur evtl. mit Fingerführraster oder auch eine Bildschirmtastatur zusammen mit einem Schalter verwenden, sind auf Tastatureingaben angewiesen. Darüber hinaus können Benutzende, die Sprachsteuerung verwenden, mit Hilfe dieser auf einfache Weise, Text und Tastatureingaben erzeugen. Für Tastaturnutzende ist es besonders wichtig, dass der Fokus gut sichtbar ist, um erkennen zu können, an welcher Stelle sich der Tastaturfokus gerade befindet. Ebenfalls wichtig ist auch die Reihenfolge, in der die Elemente mit Hilfe der Tastatursteuerung angesteuert werden. Screenreader lesen die Elemente in einem digitalen Angebot in der Reihenfolge nacheinander vor, wie sie im Quellcode angeordnet sind. Daher muss die Reihenfolge aller interaktiven Elemente gut verständlich und nutzbar sein.
Ein Bedienelement, wie z. B. eine Schaltfläche, ein Link oder ein Formularelement ist nicht mit der Tastatur (z. B. Tabulator-Taste) erreichbar. Die nutzende Person kann den Tastaturfokus nicht erkennen.
2.1.1 Tastatur
2.4.7 Fokus sichtbar
4.1.2 Name, Rolle, Wert
Es wurde ein Element verwendet, welches für Interaktionen mit Maus/Tastatur nicht vorgesehen ist, z. B. <h3>, <img>, <div>. Diesem ist ein click-Ereignis zugeordnet, das in diesem Fall nicht die Tastaturbedienung unterstützt.
Es sollten native Elemente verwendet werden, mit denen eine Interaktion möglich ist (z. B. Buttons, Links). Diese wurden speziell für die Interaktion mit den Benutzenden zur Verfügung gestellt. Sie sind standardmäßig fokussierbar. Der Zugriff erfolgt in der Reihenfolge, wie sie im Quellcode angezeigt werden. Werden selbst erstellte Elemente, z. B. DIV-Container verwendet, muss über die Accessibility API kommuniziert werden, welchen Namen, welche Rolle und welchen Zustand (Wert) das Element hat. Interaktive Elemente, die mit nicht nativen Elementen erstellt wurden, werden nicht in den Accessibility Tree aufgenommen. Daher können diese Elemente nicht mit der Tabulatortaste fokussiert werden. Damit ein Element fokussiert werden kann, ist ein tabindex-Attribut notwendig. Mit dem Attribut tabindex=“0“ wird das Element in die Tabulatorreihenfolge des digitalen Angebots aufgenommen. Der Wert gibt an, an welcher Stelle das Element an der sequenziellen Tastaturnavigation beteiligt ist.
Element ist nicht mit der Tastatur erreichbar.
<div>Aktion auslösen</div>
Element wird fokussiert und ist mit der Tastatur erreichbar.
<div tabindex="0">Aktion auslösen</div>
Element wird fokussiert, als Button ausgezeichnet und ist mit der Tastatur erreichbar.
<div role="button" tabindex="0">Aktion auslösen</div>
Interaktives natives Element (Button) ist mit der Tastatur erreichbar.
<button>Aktion auslösen</button>
Neben dem onclick-Event-Handler muss ein tastaturspezifischer Event-Handler ergänzt werden, so dass mit der Eingabe- oder Leertaste das Ereignis auch über die Tastatur ausgelöst werden kann.
Element ist mit der Tastatur erreichbar, aber nur mit Maus ist eine Aktion auslösbar.
<div onclick="myFunction()" tabindex="0">Aktion auslösen</div>
Element ist mit der Tastatur erreichbar. Eine Aktion ist mit Maus und Tastatur auslösbar.
<div onclick="myFunction()" onkeypress="myFunction()" tabindex="0">Aktion auslösen</div>
Interaktives natives Element (Button) ist mit der Tastatur erreichbar. Eine Aktion ist sowohl mit Maus als auch mit Tastatur auslösbar.
<button onclick="myFunction()">Aktion auslösen</button>
[Access & Use](https://accessuse.eu/de/" lang=“en)
Ein sichtbarer Fokus ist notwendig, damit Tastaturnutzende erkennen können, auf welchem Element sie sich befinden. Dies erleichtert die Orientierung auf digitalen Angeboten. Der vom Benutzeragenten (z. B. Browser) vorgegebene Tastaturfokus hebt sich von Hintergründen oft nicht gut ab und wird in verschiedenen Browsern unterschiedlich dargestellt.
Menschen, die die Seite mit der Tastatur bedienen, können nicht erkennen, auf welchem Element sie sich befinden.
2.4.7 Fokus sichtbar
Es wird beispielsweise in CSS outline: 0 oder outline: none verwendet. Dies führt dazu, dass der Tastaturfokus nicht sichtbar ist.
Benutzeragenten stellen den Tastaturfokus unterschiedlich dar. Für eine einheitliche Darstellung empfehlen wir einen eigenen Fokus zu definieren. Mit der künftig maßgeblichen WCAG 2.2 wird eine bessere Fokusdarstellung vorgeschrieben. Der Tastaturfokus kann mit Hilfe von CSS deutlich sichtbarer gestaltet werden, z. B. über die Eigenschaft „outline“ oder durch die Verwendung einer Hintergrundfarbe (Kontrastwechsel). Das Kontrastverhältnis zwischen fokussiertem und nicht fokussiertem Zustand muss mindestens 3:1 betragen. Alternativ kann die Fokushervorhebung auch durch Unterstreichungen hervorgehoben werden.
In CSS die Eigenschaft color und background-color mit ausreichendem Kontrast bei Flächenfokus setzen.
Maus und Tastaturfokus auf einem Link-Element hervorheben.
[WCAG 2.1 2.4.7](https://www.w3.org/WAI/WCAG21/Understanding/focus-visible)
dazugehöriges CSS
a:hover, a:focus {
background-color: #DCFFFF;
color:#000066;
}
In CSS die Eigenschaft border oder outline mit ausreichendem Kontrast von 3:1 bei Rahmenfokus setzen.
Maus und Tastaturfokus ist auf einem Button-Element nicht sichtbar.
`<button class="notvisible">Fokus ist nicht sichtbar</button>`
dazugehöriges CSS
.notvisible:focus, .notvisible:hover{
outline: none;
}
Maus und Tastaturfokus sind auf einem Button-Element hervorzuheben.
<button>Fokus ist sichtbar</button>
dazugehöriges CSS
button:focus, button:hover{
box-shadow: 0 0 0px 2px white;
outline: dotted;
}
Durch eine korrekte Fokusreihenfolge ist das digitale Angebot effektiv und nachvollziehbar bedienbar.
Benutzende werden irritiert und können sich im digitalen Angebot nicht orientieren.
1.3.2 Sinnvolle Reihenfolge
2.4.3 Fokusreihenfolge
Im Quellcode wurden die Elemente nicht in der richtigen Reihenfolge positioniert. Möglicherweise wurden falsche Werte für das Attribut tabindex gesetzt.
Korrekte Positionierung der Elemente im Quellcode.
Falsche Positionierung der Elemente im Quellcode
<div>
<h4>Falsche Positionierung der Elemente im Quellcode</h4>
<div style="float:right; width:33%">Position 1</div>
<div style="float:right; width:33%">Position 2</div>
<div style="float:right; width:33%">Position 3</div>
</div>
Korrekte Positionierung der Elemente im Quellcode
<div>
<h4>Richtige Positionierung der Elemente im Quellcode</h4>
<div style="float:left; width:33%">Position 1</div>
<div style="float:left; width:33%">Position 2</div>
<div style="float:left; width:33%">Position 3</div>
</div>
Durch Festlegung eines Wertes für das Attribut tabindex größer 0 (ganze Zahl zwischen 1- 32.767) wird die Tastaturnavigationsreihenfolge verändert, beginnend mit dem kleinsten Wert bis zum größten. Nachdem alle Elemente nacheinander mit positiven tabindex-Werten mit der Tabulatortaste durchlaufen wurden, werden andere fokussierbare Elemente durchlaufen, deren tabindex-Wert = 0 ist.
Ein tabindex=0 bewirkt, dass das Element in den Accessibility Tree und die Tab-Reihenfolge aufgenommen wurde.
Mit einem tabindex=-1 kann ein programmatischer Fokus gesetzt werden. Ein Element kann fokussiert werden, ohne dass es in die Tab-Reihenfolge aufgenommen wurde (Beispiel 7). Dadurch bleibt das Element mit Javascript weiterhin fokussierbar.
Es wird empfohlen, auf eine geänderte Tastaturnavigationsreihenfolge zu verzichten.
Lesereihenfolge ist aufgrund der falschen Verwendung des tabindex-Attribut nicht korrekt
<div>
<h4>Falsche Verwendung des Attributs tabindex</h4>
<a href="" tabindex="1">eins</a>
<a href="" tabindex="2">zwei</a>
<a href="" tabindex="1">drei</a>
<a href="" tabindex="2">vier</a>
</div>
korrekte Lesereihenfolge
<div>
<h4>Verzicht auf das Attribut tabindex</h4>
<a href="">eins</a>
<a href="">zwei</a>
<a href="">drei</a>
<a href="">vier</a>
</div>
Versteckte Menüs bei mobilen Ansichten (z. B. Hamburger-Menü) werden mittels eines Schalters eingeblendet. Alle Bedienelemente außerhalb des Menüs können dynamisch mittels tabindex="-1” aus der Tab-Reihenfolge entfernt werden, sodass das Menü iterativ durchlaufen werden kann. Nach dem Schließen des Menüs werden die Bedienelemente mittels tabindex=“0” wieder in die Tab-Reihenfolge aufgenommen.
Der Kontrast ist ein Unterscheidungsmerkmal für den Helligkeitsverlauf eines Bildes oder zwischen zwei Bildpunkten. Allgemein betrachtet geht es um das Verhältnis zwischen hellen und dunklen Farben. Das Kontrastverhältnis 10:1 besagt, dass eine Farbe um das 10-fache heller als eine andere Farbe ist. Kontraste ermöglichen Besuchenden des digitalen Angebots den Vordergrund vom Hintergrund und Hervorgehobenes von Normalem zu unterscheiden. Je besser die Kontrastwerte von Texten, Textgrafiken, Grafiken und Bedienelementen zum Hintergrund sind, umso besser ist deren Lesbarkeit. Sehbehinderte und sehschwache Menschen, sowie Menschen mit einer Farbsehschwäche profitieren von guten Kontrasten.
Oft werden Farbkombinationen für Vorder- und Hintergrund benutzt, die zueinander schlechte, also unzureichende Kontrastwerte aufweisen. So können notwendige visuelle Informationen sowie Bedienelemente und deren Zustände nicht oder nur schlecht erfasst werden.
1.4.1 Benutzung von Farbe
1.4.3 Kontrast (Minimum)
1.4.11 Kontrast für Nicht-Text
2.4.7 Fokus sichtbar
Die nach der EU-Norm vorgegebenen Kontrastwerte für Text und Grafik werden nicht beachtet bzw. es werden Techniken wie Transparenz oder Unschärfe benutzt.
Die notwendigen Mindestwerte für das Kontrastverhältnis sind für Text und Textgrafiken in kleiner Schrift mit 4,5:1, in großer Schrift mit 3:1 angegeben. Als große Schrift gilt Text mit einer Größe von mindestens 18 pt (Punkt) oder 24 px (Pixel nach CSS) oder 14 pt bei fetter Schrift. Als kleine Schrift gilt Text mit einer Größe von unter 18 pt oder unter 24 px oder unter 14 pt bei fetter Schrift. Für Grafiken und Bedienelemente gilt das Kontrastverhältnis 3:1. Die im CSS angegebenen Farbwerte für den Hintergrund, den Text und die Bedienelemente müssen den EU-Vorgaben entsprechen. Wenn eine Textfarbe definiert wird, muss auch immer eine passende Hintergrundfarbe festgelegt werden. Empfehlenswert ist bei bedeutungstragenden Texten, Grafiken und Bedienelementen auf die Anwendung von Transparenz- und Unschärfe-Attributen zu verzichten. Des Weiteren gilt zu beachten, dass Text auf Hintergrundbildern ohne eine unterlegte Farbe seine Lesbarkeit stark einschränken kann (siehe Abb. 1).
Ein besonderes Augenmerk liegt auf den verschiedenen Zuständen, die der Link, die Grafik oder das Bedienelement einnehmen kann. Dabei muss trotzdem das den Vorgaben entsprechende Kontrastverhältnis erfüllt sein. Das folgende Beispiel soll verdeutlichen, welchen Umfang diese möglichen Zustände haben können.
Es braucht beispielsweise mindestens 15 Prüfschritte, um die Konformität dieses einfachen Kontrollkästchens mit Beschriftungstext und Link, mit den WCAG-Anforderungen für Kontrast und Farbverwendung zu testen.
Für die WCAG-Konformität erfordert dieses einfache Beispiel:
Mindestens 4,5:1 Kontrast zwischen:
Beschriftungstext - Hintergrund
Linktext - Hintergrund
Linktext – Mauszeiger (Hover)
Linktext – Tastaturfokus
Linktext – aktiv
Linktext – besucht
Mindestens 3:1 Kontrast:
zwischen Labeltext und Linktext
visueller Hinweis, wenn der Link den Tastaturfokus hat
visueller Hinweis, dass das Kontrollkästchen den Tastaturfokus hat
Checkbox-Rahmen – Standard (unfokussiert)
Checkbox-Rahmen – Mauszeiger (Hover)
Checkbox-Rahmen – Tastaturfokus
Checkbox-Rahmen – aktiv (onclick)
Checkbox-Rahmen – aktiviert
Das Häkchen, das das Kontrollkästchen anzeigt, ist aktiviert.
Quelle: Bewertung von Farbe und Kontrast - Wie schwer kann das sein?
Dies schließt mögliche Farb- und Kontrastprobleme im Zusammenhang mit Fehlerzuständen oder Rückmeldungen nicht ein. Daher ist 15 die niedrigste Anzahl von erforderlichen Prüfungen.
WCAG 2.1 - 1.4.6 Kontraste von Texten ausreichend (erweitert)
WCAG 2.1 - 1.4.11 Kontraste von Grafiken und grafischen Bedienelementen ausreichend
Alle Webseiten haben eine sichtbare Struktur, die für Sehende visuell als verschiedene Seitenbereiche wahrgenommen, unterschieden und als solche erkennbar sind. Sie sehen durch Überschriften und Spalten, Kästen oder Trennlinien was zusammengehört und können somit den Inhalt leicht überblicken. Das erleichtert den Zugriff auf die gesuchte Information.
Für Nutzende von assistiven Technologien gilt dies nicht. Für sie muss der Seitenaufbau unabhängig von der Darstellung deutlich werden. Überschriften-Elemente unterstützen dabei den Seiteninhalt zu strukturieren. Absätze und Texthervorhebungen mit geeigneten Strukturelementen erleichtern die Handhabung und das Verständnis des Inhalts. Darüber hinaus sind diese Nutzenden auf programmatisch ermittelbare Bereichsauszeichnungen angewiesen. Das können Bereichsüberschriften, Sprunglinks (Skip-Links oder Anker) zu einzelnen Seitenbereichen, HTML5-Elemente für Regionen bzw. WAI-ARIA document landmarks sein.
Oft werden die Überschriften nicht richtig deklariert, deutlich sichtbare Überschriften werden nicht mit HTML-Strukturelementen ausgezeichnet. Außerdem werden die Ebenen der Überschriftenstruktur häufig durcheinandergebracht oder übersprungen. Meistens werden Überschriften aus visuellen Gründen ausgewählt und die inhaltliche Struktur wird dabei nicht berücksichtigt. Dies führt zu einer erschwerten Orientierung und einer schlechten Verständlichkeit. Beispielsweise wird der Überschrift auf Ebene 3 eine Überschrift der Ebene 2 zugeordnet, obwohl sie inhaltlich nicht dazu gehört oder es werden Ebenen übersprungen, so das auf Ebene 1 auf einmal Ebene 5 folgt.
<h3>Überschrift</h3>
<h2>Überschrift</h2>
<h1>Überschrift</h1>
<h5>Überschrift</h5>
Ein weiteres Problem ist die mangelhafte Auszeichnung der Bereiche und Regionen. Der Kopfbereich (header) und der Fußbereich (Footer) sind gekennzeichnet, der Hauptbereich (main) aber nicht. Bei mehreren Navigations-Bereichen wird keine Unterscheidung vorgenommen. Sie werden alle nur mit Navigation (nav) gekennzeichnet. Dabei sind das meist das Hauptmenü und das Seitenmenü oder der Brotkrummenpfad (breadcrumb).
9.1.3.1 Info und Beziehungen
9.2.4.1 Blöcke überspringen
Eine technische Ursache kann die Benutzung von Content Management Systemen sein, die eine korrekte Setzung von Bereichsüberschriften oder die Deklarierung von Bereichen oder Regionen reglementieren bzw. verhindern.
Die eigentliche Ursache ist aber keine technische, sondern eher eine menschliche. Mangelndes Wissen um die programmatische Auszeichnung von Überschriftenstrukturen und einzelnen Seitenbereichen führt zu eben jenen Problemen, die hier aufgeführt sind.
Um eine schnelle Navigation auf einem Webauftritt zu gewährleisten sind für Personen mit oder ohne Hilfsmittel unterschiedliche Voraussetzung erforderlich. So sind zum Beispiel Tastaturnutzer ohne Hilfsmittel zwingend auf Sprunglinks angewiesen, wenn der Webauftritt eine besonders hohe Anzahl an Bedienelementen enthält. Weitere Möglichkeiten sind:
Es werden sinnvolle Bereichsüberschriften mit den HTML-Strukturelementen h1 - h6 eingesetzt (auch visuell versteckte Überschriften sind möglich).
Es sind Sprunglinks vorhanden, mit denen zu den verschiedenen Seitenbereichen gesprungen werden kann.
HTML5 Elemente zur Auszeichnung von Bereichen (z. B. header, nav, main, aside, footer) erschließen den Seitenaufbau sinnvoll.
Bei Verwendung von mehreren nav-Strukturelementen sind diese mit einer eindeutigen Bezeichnung mit Hilfe von z.B.: aria-label ausgezeichnet. Dabei ist der Name des Bereichs nicht Teil der Bezeichnung.
WAI-ARIA document landmarks (z. B. role=“navigation“, role=“main“, role=“search“) strukturieren die Seitenbereiche sinnvoll, sofern keine HTML5-Elemente verwendet wurden.
iFrames verfügen über ein title-Attribut mit einer sinnvollen, kurzen Beschreibung zum Inhalt.
Es wird empfohlen die genannten Möglichkeiten zu nutzen um einen gut strukturierten Webauftritt für alle Nutzende gleichermaßen bereitzustellen.
Diese Handreichung hat die Version 1.0 und wurde am 28.05.2026 erstellt.
Die Deutsche Rentenversicherung Knappschaft-Bahn-See ist eine rechtsfähige Körperschaft des öffentlichen Rechts mit Selbstverwaltung und besitzt Dienstherrnfähigkeit (§ 29 SGB IV in Verbindung mit § 143 Abs. 1 SGB VI).
Dieses Impressum gilt für dieses Dokument der Arbeitsgruppen des Ausschusses für barrierefreie Informationstechnik nach § 5 BITV 2.0. Die Arbeitsgruppen werden von der Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik organisiert.
Deutsche Rentenversicherung Knappschaft-Bahn-See
Pieperstraße 14 - 28
44789 Bochum
Tel. 0234 304 - 0
Fax 0234 304 - 66050
E-Mail an die Zentrale der KBS: zentrale@kbs.de
Umsatzsteuer-Identifikationsnummer: DE 124089627
Dieses Dokument wird herausgegeben von der Deutschen Rentenversicherung Knappschaft-Bahn-See, vertreten durch die Geschäftsführung, Dr. Rainer Wilhelm.
Bundesministerium für Arbeit und Soziales
Wilhelmstraße 49
10117 Berlin
Die Inhalte dieser Handreichung werden mit größtmöglicher Sorgfalt verfasst. Unser Anspruch ist es, richtige, vollständige und aktuelle Inhalte bereitzustellen. Wir übernehmen dennoch keine Gewähr für versehentlich gemachte falsche Angaben.
Diese Handreichung enthält Verknüpfungen zu Webauftritten Dritter (“externe Links”). Wir haben bei der erstmaligen Verknüpfung zu externen Links die fremden Inhalte daraufhin überprüft, ob etwaige Rechtsverstöße bestehen. Zu diesem Zeitpunkt haben wir keine Rechtsverstöße vorgefunden. Wir haben jedoch weder Einfluss auf die aktuelle und zukünftige Gestaltung der verknüpften Seiten noch auf deren Inhalte oder Angebote. Sollten uns Rechtsverstöße bekannt werden, löschen wir die betreffenden externen Links unverzüglich. Bitte weisen Sie uns gegebenenfalls darauf hin.