Anforderung 1.3: Anpassbar

Anforderung 1.3 der BITV 2.0 betrifft semantisches HTML – also Inhalte, deren Struktur und Beziehungen nicht nur optisch, sondern auch technisch erkennbar sind. Für Screenreader, barrierefreie Formulare und eine verständliche Bildschirmausrichtung ist das wichtig, weil Inhalte sonst zwar sichtbar, aber schwer nutzbar sein können. WCAG 1.3.1 bis 1.3.5 und EN 301 549 beschreiben, wie Informationen, Reihenfolge, Orientierung und Eingabefelder zugänglich bleiben. Das ist für öffentliche Stellen ebenso relevant wie für bestimmte Produkte und Dienstleistungen für Verbraucherinnen und Verbraucher im BFSG-Kontext.

Was wird bei Anforderung 1.3 gefordert?

• 1.3.1 Informationen und Beziehungen: Struktur, Überschriften, Listen, Tabellen und Formularbezüge müssen technisch nachvollziehbar sein.
• 1.3.2 Aussagekräftige Reihenfolge: Die Lesereihenfolge muss den Sinn erhalten, auch wenn Inhalte visuell anders angeordnet sind.
• 1.3.3 Sensorische Merkmale: Hinweise dürfen nicht nur auf Farbe, Form, Position oder Klang bauen.
• 1.3.4 Bildschirmausrichtung: Inhalte sollen nicht auf Hoch- oder Querformat festgelegt sein, außer wenn die Orientierung wesentlich ist.
• 1.3.5 Eingabefelder: Felder für Nutzerdaten sollen ihren Zweck vermitteln, damit Autocomplete und Hilfstechnologien sie erkennen können.

1.3.1 Informationen und Beziehungen im semantischen HTML

Wenn eine Überschrift nur groß aussieht, aber im Code nicht als Überschrift markiert ist, geht ihre Struktur für Screenreader verloren. Gleiches gilt für Listen, Tabellen, Formulare und Zuordnungen zwischen Label und Eingabefeld. Die Anforderung stellt sicher, dass Beziehungen nicht nur optisch wirken, sondern technisch auslesbar sind. Das ist wichtig für Menschen, die mit Screenreader oder eigener Stilvorgabe navigieren.

Umsetzung: Semantisches HTML verwenden: h1 bis h6, ul/ol, table, th, label und passende Formularelemente. Eine Preisliste sollte als Tabelle mit Kopfzellen aufgebaut sein, nicht als Reihe von divs. Ein Formularfeld braucht ein echtes Label, damit der Zweck auch dann klar bleibt, wenn das Layout sich ändert.

1.3.2 Aussagekräftige Reihenfolge für Screenreader und Layout

Die visuelle Anordnung einer Seite darf die inhaltliche Reihenfolge nicht verfälschen. Das ist besonders relevant bei Spaltenlayouts, Kartenansichten oder Teasern, die im Code anders stehen als auf dem Bildschirm. Screenreader lesen in der Reihenfolge des DOM, nicht in der Reihenfolge der Optik. Wenn diese Reihenfolge unlogisch ist, kann der Inhalt schwer verständlich werden.

Umsetzung: DOM-Reihenfolge und sichtbare Reihenfolge möglichst gleich halten. Ein Artikel-Teaser sollte zuerst Überschrift, dann Text und dann Link enthalten – nicht erst ein Bild, dann ein Button und irgendwo später den Kontext. Bei einem zweispaltigen Layout prüfen, ob die Lesereihenfolge auch ohne CSS noch nachvollziehbar ist.

1.3.3 Sensorische Merkmale vermeiden: klare Hinweise statt Farbe

Hinweise, die nur auf Farbe, Position oder Form verweisen, können Menschen ausschließen, die diese Merkmale nicht wahrnehmen. Formulierungen wie „der grüne Button links oben" oder „das runde Symbol rechts" sind allein oft nicht genug. Die Anforderung verlangt Hinweise, die auch ohne diese Sinnesmerkmale verständlich sind. Das ist relevant für Fehlermeldungen, Anweisungen und Navigation.

Umsetzung: Statt „klicke auf das grüne Feld" lieber „klicke auf ‚Speichern'" schreiben. Wenn ein Formularfehler unter dem zweiten Eingabefeld erscheint, sollte der Hinweis das Feld namentlich nennen. In einer Kartenansicht nicht nur auf „oben rechts" zeigen, sondern die Schaltfläche beschreiben.

1.3.4 Bildschirmausrichtung nicht beschränken

Inhalte sollen sich nicht auf Hoch- oder Querformat festlegen, wenn die Ausrichtung dafür nicht wesentlich ist. Das betrifft vor allem mobile Nutzung, aber auch Geräte, die fest montiert sind oder von Nutzerinnen und Nutzern in einer bestimmten Lage verwendet werden. Wenn eine Seite nur im Landscape-Modus funktioniert, kann das Menschen ausschließen, die ihr Gerät anders halten oder fixiert nutzen. Ausnahmen gibt es nur, wenn die Orientierung für den Inhalt selbst wichtig ist.

Umsetzung: Orientation-Locks vermeiden und responsive Layouts so bauen, dass sie in beiden Ausrichtungen funktionieren. Eine Spezialanwendung kann ausnahmsweise eine bestimmte Ausrichtung brauchen, wenn die Funktion sonst nicht sinnvoll nutzbar ist. Bei normalen Webinhalten sollte eine Meldung „Bitte drehen Sie das Gerät" nicht die einzige Lösung sein.

1.3.5 Eingabefelder zu Nutzerdaten mit Zweck und Autocomplete

Eingabefelder sollen ihren Zweck technisch vermitteln, damit Browser und Hilfstechnologien den passenden Kontext erkennen können. Das ist vor allem für barrierefreie Formulare wichtig, weil Autocomplete dann Vorname, E-Mail, Straße oder Telefonnummer besser zuordnen kann. Die Anforderung betrifft Felder, in denen persönliche Nutzerdaten eingegeben werden. Sie hilft Menschen, die Formulare häufiger ausfüllen oder auf Assistenzfunktionen angewiesen sind.

Umsetzung: Passende autocomplete-Werte verwenden: given-name, family-name, email, street-address oder tel. Ein Kontaktformular sollte nicht nur optisch klar sein, sondern im Code den Zweck der Felder ausdrücklich nennen. Das erleichtert Autofill, mobile Eingabe und die Nutzung mit Assistenztechnik.

Häufige Fragen zu Anforderung 1.3

Einordnung in weitere Normen

Anforderung 1.3 basiert auf WCAG 2.2 Richtlinie 1.3. Im europäischen Standard EN 301 549 sind die Anforderungen unter Abschnitt 9.1.3 normativ verankert.