WCAG 1.3.6: Zweck identifizieren

Was diese Regel bedeutet

\n

WCAG 1.3.6 — Identify Purpose ist ein Kriterium der Stufe AAA unter Prinzip 1 (Wahrnehmbar), das die bestehenden Anforderungen an Struktur und Semantik auf ein feineres Granularitätsniveau ausdehnt. Konkret verlangt es, dass der Zweck jeder Benutzeroberflächenkomponente, jedes Symbols, jeder Region und bestimmter Eingabefelder programmatisch ermittelbar ist – das heißt, dass die semantischen Informationen so offengelegt werden, dass Browser, Browser-Erweiterungen und unterstützende Technologien sie lesen und darauf reagieren können.

\n

Das Kriterium baut direkt auf 1.3.1 (Info and Relationships) und 1.3.5 (Identify Input Purpose) auf. Während sich 1.3.5 auf gängige Eingabefelder für personenbezogene Daten (Name, E-Mail, Telefon usw.) konzentriert, erweitert 1.3.6 die Anforderung auf alle Bereiche und Komponenten der Benutzeroberfläche, einschließlich Navigations-Landmarks, Symbole, Schaltflächen und interaktive Widgets. Die Kernidee ist, dass ein User Agent oder ein Personalisierungs-Tool die Standardpräsentation austauschen können sollte – etwa Textbeschriftungen durch Symbole ersetzen, eine überladene Navigation vereinfachen oder die relevantesten Steuerelemente hervorheben – basierend auf maschinenlesbaren Zweckdaten, die im Markup eingebettet sind.

\n

Praktisch besteht eine Seite 1.3.6, wenn sie HTML5-Landmark-Elemente (wie <header>, <nav>, <main>, <aside>, <footer> und <section>) verwendet, geeignete ARIA-Landmark-Rollen dort anwendet, wo keine Landmark-Elemente genutzt werden, den Zweck von Symbolen und anderen nicht-textuellen UI-Komponenten über zugängliche Namen oder Rollen offenlegt und – sofern zutreffend – standardisierte Zweck-Tokens verwendet, wie sie in der W3C Personalization Semantics-Spezifikation (früher als COGA Semantics-Vorschlag bekannt) definiert sind, zum Beispiel über das aui--Attribut-Vokabular.

\n

Eine Seite verfehlt das Kriterium, wenn ihre Bereiche als generische <div>- oder <span>-Container ohne semantische Rolle implementiert sind, wenn Symbole eine Bedeutung tragen, aber keinen zugänglichen Namen oder unterstützende Semantik haben, oder wenn interaktive Komponenten außer ihrem sichtbaren Erscheinungsbild keinen programmatischen Hinweis auf ihre Funktion liefern. Es gilt eine offizielle Ausnahme: Die Anforderung gilt nur für Inhalte, die mit Technologien implementiert sind, die die Identifizierung der erwarteten Bedeutung unterstützen. Wenn für einen bestimmten Komponententyp in einem gegebenen Technologiestack keine unterstützende Technologie oder Spezifikation existiert, kann das Kriterium vernünftigerweise nicht auf diese Komponente angewendet werden.

\n\n

Warum es wichtig ist

\n

Die Hauptnutznießer von WCAG 1.3.6 sind Menschen mit kognitiven Beeinträchtigungen und Lernbehinderungen, einschließlich Dyslexie, Aufmerksamkeitsdefizitstörungen, Autismus-Spektrum-Störungen, Gedächtnisbeeinträchtigungen und intellektuellen Beeinträchtigungen. Laut Weltgesundheitsorganisation lebt weltweit etwa 1 von 6 Menschen – über eine Milliarde Personen – mit einer Form einer erheblichen Behinderung, und kognitive Beeinträchtigungen stellen eine der größten und am wenigsten versorgten Gruppen dar. Viele dieser Nutzerinnen und Nutzer haben Schwierigkeiten mit komplexen Navigationsstrukturen, dichten Textmenüs und reinen Symbol-Steuerelementen, die keinen semantischen Anker bieten.

\n

Betrachten Sie ein konkretes Szenario: Eine Nutzerin mit schwerer Dyslexie verlässt sich auf eine Browser-Erweiterung, die Standard-Navigationsbeschriftungen durch persönliche Symbolsets ersetzt – bildbasierte Symbole von einer Kommunikations-Tafel, die sie im Alltag verwendet. Damit dieser Austausch funktioniert, muss die Erweiterung erkennen können, dass ein bestimmtes <div> tatsächlich ein Navigations-Landmark ist, dass ein Sternsymbol „Zu Favoriten hinzufügen“ bedeutet und dass ein kreisförmiger Pfeil „Aktualisieren“ darstellt. Ohne programmatisch ermittelbaren Zweck hat die Erweiterung keinen Anknüpfungspunkt, und der Austausch schlägt stillschweigend fehl, sodass die Nutzerin mit einer Oberfläche zurückbleibt, die sie nicht erfassen kann.

\n

Motorisch beeinträchtigte Nutzerinnen und Nutzer, die auf Switch Access oder Sprachsteuerung angewiesen sind, profitieren ebenfalls erheblich, da zweckbewusste Tools nur für Steuerelemente, deren Funktion maschinenlesbar ist, Shortcut-Overlays oder Sprachbefehlszuordnungen generieren können. Blinde Nutzerinnen und Nutzer, die über Screenreader interagieren, profitieren von klar beschrifteten Landmark-Bereichen, die es ihnen ermöglichen, direkt zum <main>-Inhalt zu springen oder wiederholte Navigation zu überspringen. Nutzerinnen und Nutzer mit Sehbehinderungen, die Browser-Zoom oder benutzerdefinierte Stylesheets verwenden, profitieren von der Landmark-Struktur, weil sie es dem Browser ermöglicht, Inhalte vorhersagbar umzubrechen.

\n

Über die Barrierefreiheit hinaus bringt die Implementierung der von 1.3.6 geforderten Semantik messbare SEO-Vorteile. Suchmaschinen-Crawler nutzen Landmark- und Schema-Markup, um die Seitenstruktur zu verstehen, Inhalts-Hierarchien zu indexieren und Rich Results zu generieren. Eine gut strukturierte Seite mit aussagekräftigen Landmark-Bereichen hat eine höhere Chance auf Featured Snippets und höhere Relevanzbewertungen. Es gibt außerdem eine direkte Usability-Dividende: Seiten mit klarer semantischer Struktur sind für Entwicklungsteams leichter zu warten, zu testen und zu erweitern, was die langfristige technische Schuld reduziert.

\n\n

Verwandte Axe-core-Regeln

\n

WCAG 1.3.6 erfordert manuelle Tests zusätzlich zu allen automatisierten Prüfungen. Automatisierte Tools können das Vorhandensein semantischen Markups überprüfen, aber nicht feststellen, ob dieses Markup den Zweck jeder Komponente so genau und vollständig vermittelt, wie es eine menschliche Testerin tun würde. Die folgenden axe-core-Regeln sind eng verwandt und dienen als automatisierte Stellvertreter für Aspekte dieses Kriteriums:

\n

\n
• region — Prüft, ob alle Inhalte auf der Seite innerhalb eines Landmark-Bereichs enthalten sind. Es markiert Inhalte, die außerhalb eines anerkannten Landmark-Elements oder einer ARIA-Landmark-Rolle liegen. Obwohl diese Regel die Genauigkeit der Zweckidentifikation nicht testet, stellt sie sicher, dass die strukturelle Grundlage, die 1.3.6 erfordert, vorhanden ist. Ein Fehler bedeutet, dass wesentliche Inhalte für die Landmark-basierte Navigation unsichtbar sind.
\n
• landmark-one-main — Überprüft, ob die Seite genau ein <main>-Element oder ein Element mit role='main' enthält. Dies ist grundlegend für 1.3.6, da der Hauptinhaltsbereich eine der wichtigsten Regionen ist, deren Zweck identifizierbar sein muss. Mehrere oder fehlende <main>-Landmarks machen es Personalisierungs-Tools unmöglich, Primärinhalte zu isolieren.
\n
• landmark-complementary-is-top-level — Prüft, dass <aside>-Elemente oder Bereiche mit role='complementary' nicht innerhalb des Hauptinhaltsbereichs verschachtelt sind, sodass ihr Zweck falsch dargestellt wird. Falsche Verschachtelung führt unterstützende Technologien über die Beziehung zwischen Bereichen in die Irre.
\n
• aria-allowed-role und aria-valid-attr-value — Markieren ungültige oder unpassende ARIA-Rollen-Zuweisungen. Da 1.3.6 von korrekter Rollen-Semantik abhängt, untergräbt die Verwendung einer falschen Rolle (z. B. role='navigation' für eine Schaltflächengruppe) die Zweckidentifikation aktiv, und diese Regeln machen solche Fehlanpassungen sichtbar.
\n
• button-name und link-name — Überprüfen, ob interaktive Steuerelemente zugängliche Namen haben. Reine Symbol-Schaltflächen und Links ohne zugängliche Namen sind ein primärer Fehlertyp für 1.3.6, da für ein Steuerelement ohne Namen kein Zweck ermittelt werden kann. Diese Regeln markieren das Fehlen von aria-label, aria-labelledby oder sichtbarem Text.
\n

\n

Manuelle Tests sind erforderlich, weil automatisierte Tools nicht beurteilen können, ob die gewählten Zweck-Tokens oder semantischen Rollen die tatsächliche Funktion der Komponente im Kontext der Anwendung korrekt repräsentieren. Eine Schaltfläche kann einen zugänglichen Namen und eine gültige ARIA-Rolle haben und dennoch 1.3.6 verfehlen, wenn der Name irreführend ist oder die Rolle nicht widerspiegelt, was das Steuerelement tatsächlich tut.

\n\n

Wie man testet

\n

\n
1. Führen Sie einen automatisierten Scan mit axe DevTools oder Lighthouse durch. Öffnen Sie die Seite in Chrome, aktivieren Sie die axe DevTools-Erweiterung und führen Sie einen Scan der gesamten Seite aus. Filtern Sie die Ergebnisse nach den oben aufgeführten Regeln: region, landmark-one-main, button-name und link-name. Notieren Sie alle Verstöße und deren Impact-Bewertungen. Führen Sie in Lighthouse ein Accessibility-Audit durch und überprüfen Sie die Bereiche zu Landmarks und ARIA. Dokumentieren Sie alle Fehler als Basis, verstehen Sie jedoch, dass diese nur einen Teil der 1.3.6-Konformität abbilden.
\n
2. Überprüfen Sie die Landmark-Struktur manuell mit den Entwicklerwerkzeugen des Browsers. Öffnen Sie DevTools, navigieren Sie zum Accessibility Tree-Panel (Chrome) oder zum Accessibility Inspector (Firefox) und vergewissern Sie sich, dass die Seite eine kohärente Landmark-Hierarchie offenlegt: ein <header> auf oberster Ebene, ein <main>, mindestens ein <nav> (mit unterscheidender Beschriftung, wenn mehrere vorhanden sind) und ein <footer>. Bestätigen Sie, dass kein bedeutungsvoller Inhaltsbereich nur in ein generisches <div> oder <span> gehüllt ist.
\n
3. Testen Sie mit NVDA und Firefox. Starten Sie NVDA, öffnen Sie die Seite in Firefox und drücken Sie D, um durch die Landmarks zu wechseln. Vergewissern Sie sich, dass jedes Landmark mit einer aussagekräftigen Rolle angekündigt wird und – wenn mehrere Landmarks desselben Typs vorhanden sind – mit einer eindeutigen Beschriftung. Navigieren Sie mit der Tabulatortaste zu jeder reinen Symbol-Schaltfläche und bestätigen Sie, dass NVDA einen beschreibenden zugänglichen Namen ankündigt – nicht eine leere Zeichenkette, einen Dateinamen oder eine generische Bezeichnung wie „Schaltfläche“.
\n
4. Testen Sie mit VoiceOver und Safari (macOS/iOS). Aktivieren Sie VoiceOver (Cmd+F5 auf macOS). Verwenden Sie den Rotor (Vo+U), um die Liste der Landmarks zu öffnen, und vergewissern Sie sich, dass alle erwarteten Bereiche erscheinen. Tabben Sie durch interaktive Steuerelemente und achten Sie auf aussagekräftige Beschreibungen. Verwenden Sie auf iOS eine Drei-Finger-Wischgeste, um nach Überschriften und Landmarks zu navigieren, und bestätigen Sie, dass der Zweck jedes Bereichs korrekt angekündigt wird.
\n
5. Testen Sie mit JAWS und Chrome. Öffnen Sie die Seite in Chrome mit laufendem JAWS. Drücken Sie R, um durch die Bereiche zu navigieren, und bestätigen Sie, dass Rolle und Beschriftung jedes Bereichs korrekt sind. Verwenden Sie den JAWS Virtual Cursor, um Symbol-Schaltflächen zu lesen, und vergewissern Sie sich, dass ihr Zweck vermittelt wird. Nutzen Sie die JAWS Linkliste (Einfg+F7), um alle Linknamen auf ihre Aussagekraft zu prüfen.
\n
6. Testen Sie Personalisierungs-Semantik (falls implementiert). Wenn Ihre Seite das W3C Personalization Semantics-Vokabular verwendet (z. B. data-purpose oder aui--Attribute), verwenden Sie das Personalization Semantics-Testtool oder eine kompatible Browser-Erweiterung, um zu überprüfen, ob Zweck-Tokens korrekt angewendet werden und von User Agents, die die Spezifikation unterstützen, maschinenlesbar sind.
\n
7. Führen Sie ein komponentenweises Purpose-Audit durch. Fragen Sie sich für jede interaktive Komponente und jedes Symbol auf der Seite: Kann der Zweck dieser Komponente ohne visuellen Kontext ermittelt werden? Wenn der Zweck der Komponente auch dann klar bleibt, wenn alle CSS und Bilder entfernt werden und nur DOM- und ARIA-Attribute übrig bleiben, besteht sie den Test. Wenn der Zweck nur visuell vermittelt wird, fällt sie durch.
\n

\n\n

Wie man es behebt

\n\n

Generische div-Bereiche ohne Landmarks — Falsch

\n

<div class='site-header'>\n  <div class='logo'>Accsible</div>\n  <div class='main-nav'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </div>\n</div>\n<div class='main-content'>\n  <p>Welcome to our platform.</p>\n</div>\n<div class='sidebar'>\n  <p>Related articles</p>\n</div>\n<div class='site-footer'>\n  <p>© 2025 Accsible</p>\n</div>

\n\n

Generische div-Bereiche ohne Landmarks — Richtig

\n

<!-- Use native HTML5 landmark elements so browsers and AT\n     can programmatically identify the purpose of each region -->\n<header>\n  <a href='/' aria-label='Accsible home'>\n    <img src='logo.svg' alt='Accsible' />\n  </a>\n  <nav aria-label='Primary navigation'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </nav>\n</header>\n<main>\n  <p>Welcome to our platform.</p>\n</main>\n<aside aria-label='Related articles'>\n  <p>Related articles</p>\n</aside>\n<footer>\n  <p>© 2025 Accsible</p>\n</footer>

\n\n

Reine Symbol-Schaltfläche ohne zugänglichen Namen — Falsch

\n

<!-- An icon button whose purpose cannot be determined\n     programmatically — it has no accessible name at all -->\n<button class='btn-icon'>\n  <svg viewBox='0 0 24 24' width='24' height='24'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

Reine Symbol-Schaltfläche ohne zugänglichen Namen — Richtig

\n

<!-- aria-label gives the button a programmatically determinable\n     purpose; the SVG is hidden from AT since the label covers it -->\n<button class='btn-icon' aria-label='Add to favourites'>\n  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

Mehrere Navigations-Landmarks ohne unterscheidende Beschriftungen — Falsch

\n

<!-- Two nav elements with identical roles but no labels:\n     screen readers cannot distinguish their purpose -->\n<nav>\n  <a href='/home'>Home</a>\n  <a href='/about'>About</a>\n</nav>\n\n<nav>\n  <a href='/page1'>Chapter 1</a>

(Content truncated due to token limit — please retry this article.)