WCAG 1.3.3: Sensorische Merkmale

WCAG 1.3.3 verlangt, dass Anweisungen zur Nutzung von Inhalten sich nicht ausschließlich auf sensorische Merkmale wie Form, Farbe, Größe, visuelle Position, Ausrichtung oder Klang stützen. Dies stellt sicher, dass Nutzer, die diese sensorischen Hinweise aufgrund von Blindheit, Farbenblindheit, Taubheit oder anderen Behinderungen nicht wahrnehmen können, dennoch alle Funktionen verstehen und bedienen können.

Was diese Regel bedeutet

Das WCAG-Erfolgskriterium 1.3.3 — Sensorische Eigenschaften (Level A) besagt, dass Anweisungen zum Verständnis und zur Bedienung von Inhalten sich nicht ausschließlich auf sensorische Eigenschaften von Komponenten wie Form, Größe, visuelle Position, Ausrichtung oder Klang stützen dürfen. Anders ausgedrückt: Wenn Ihre Benutzeroberfläche Nutzer*innen anweist, mit etwas zu interagieren, indem sie sich nur darauf bezieht, wie es aussieht, wo es auf dem Bildschirm erscheint oder wie es klingt, ist diese Anweisung für Nutzer*innen bedeutungslos, die diese spezifischen sensorischen Eigenschaften nicht wahrnehmen können.

Das Schlüsselwort hier ist ausschließlich. Das Kriterium verbietet nicht die Verwendung sensorischer Bezüge — es verbietet, dass sie das einzige Mittel zur Identifikation sind. Eine Anweisung wie „Klicken Sie auf die runde grüne Schaltfläche links“ scheitert, wenn ein*e Nutzer*in Grün nicht unterscheiden kann, die Form der Schaltfläche nicht sehen kann oder aufgrund eines Reflow-Layouts nicht zwischen links und rechts unterscheiden kann. „Klicken Sie jedoch auf die Schaltfläche Absenden (die runde grüne Schaltfläche links)“ besteht, weil die Textbeschriftung „Absenden“ einen nicht-sensorischen Identifikator bereitstellt, der unabhängig von Farbe, Form und Position funktioniert.

Von diesem Kriterium betroffene Anweisungen umfassen alle Text-, Audio- oder visuellen Inhalte, die Nutzer*innen anweisen, eine Aktion auszuführen oder Informationen zu finden. Häufige Fehlermuster sind:

„Klicken Sie auf die Schaltfläche rechts, um fortzufahren“ — stützt sich ausschließlich auf die visuelle Position.
„Wählen Sie das quadratische Symbol, um die Einstellungen zu öffnen“ — stützt sich ausschließlich auf die Form.
„Die Pflichtfelder sind in Rot dargestellt“ — stützt sich ausschließlich auf die Farbe.
„Wenn Sie den Glockenton hören, fahren Sie mit dem nächsten Schritt fort“ — stützt sich ausschließlich auf den Klang.
„Tippen Sie auf die große Kachel, um den Abschnitt zu erweitern“ — stützt sich ausschließlich auf die Größe.

Eine konforme Anweisung enthält immer mindestens einen nicht-sensorischen Identifikator — typischerweise eine Textbeschriftung, einen programmatischen Namen oder eine Überschrift —, sodass Nutzer*innen, die auf unterstützende Technologien angewiesen sind oder in Umgebungen arbeiten, in denen sensorische Hinweise nicht verfügbar sind, den Anweisungen dennoch folgen können. Beachten Sie, dass dieses Kriterium speziell Anweisungen abdeckt; es verlangt nicht, dass jedes UI-Element neu gestaltet wird, aber es verlangt, dass jede textliche oder gesprochene Anleitung zu diesen Elementen ohne sensorische Unterscheidung wahrnehmbar ist.

Es gibt keine offiziellen Ausnahmen innerhalb von 1.3.3 selbst, obwohl das „Understanding“-Dokument klarstellt, dass Inhalte, die sensorische Eigenschaften zusätzlich zu nicht-sensorischen Identifikatoren verwenden, vollständig konform sind. Das Kriterium ergänzt, ist aber von 1.4.1 (Verwendung von Farbe) getrennt, das sich speziell nur mit Farbe befasst; 1.3.3 hat einen breiteren Anwendungsbereich und umfasst alle sensorischen Modalitäten.

Warum es wichtig ist

Rein sensorische Anweisungen schaffen harte Barrieren für eine Vielzahl von Nutzer*innen. Betrachten Sie jede betroffene Gruppe:

Blinde und sehbehinderte Nutzer*innen sind auf Screenreader oder Vergrößerungssoftware angewiesen. Wenn eine Anweisung sagt „Klicken Sie auf das Symbol in der oberen rechten Ecke“, hat ein*e Screenreader-Nutzer*in, der*die per Tab-Reihenfolge oder Überschriftenstruktur navigiert, kein Konzept von „oberer rechter Ecke“ im visuellen Layout. Ebenso sieht ein*e Nutzer*in mit starker Sehbehinderung, der*die auf 400 % gezoomt hat, möglicherweise immer nur einen kleinen Teil des Bildschirms, sodass Positionsangaben wie „linke Leiste“ oder „unterer Abschnitt“ völlig unzuverlässig werden. Laut Weltgesundheitsorganisation haben weltweit etwa 2,2 Milliarden Menschen irgendeine Form von Sehbeeinträchtigung, was dies zu einer der größten betroffenen Gruppen macht.

Farbenblinde Nutzer*innen — etwa 1 von 12 Männern und 1 von 200 Frauen — können bestimmte Farbkombinationen nicht unterscheiden. Eine Anweisung wie „in Rot hervorgehobene Felder sind Pflichtfelder“ ist für jemanden mit Rot-Grün-Sehschwäche als Unterscheidungsmerkmal unsichtbar. Während 1.4.1 dies für das UI-Element selbst adressiert, stellt 1.3.3 sicher, dass auch der Anweisungstext eine Alternative bietet.

Gehörlose und schwerhörige Nutzer*innen sind von rein akustischen Hinweisen betroffen. Wenn eine E-Learning-Plattform Nutzer*innen anweist, „fortzufahren, wenn Sie die Glocke hören“, werden Nutzer*innen, die die Glocke nicht hören können, ausgeschlossen. Dieses Muster tritt in interaktiven Präsentationen, videobasierten Tutorials und zeitgesteuerten Prüfungen auf.

Nutzer*innen mit kognitiven und Lernbehinderungen können Schwierigkeiten mit Richtungsangaben haben, insbesondere wenn ihre unterstützende Technologie Inhalte in linearer Form wiedergibt und die visuelle Positionierung entfernt. Eine Person, die ein Schaltgerät oder ein Eye-Tracking-System verwendet, navigiert ebenfalls in Sequenzen, die möglicherweise keinerlei Beziehung zu dem zweidimensionalen räumlichen Layout haben, das sich ein sehender Designer vorgestellt hat.

Betrachten Sie ein konkretes Szenario aus der realen Welt: Ein türkisches E-Government-Portal weist Bürger*innen an, „die blau umrandeten Felder auszufüllen und dann auf die dreieckige Schaltfläche zu drücken, um den Antrag abzusenden“. Ein*e blinde Nutzer*in, der*die per Screenreader durch die Formularfelder navigiert, hört die Feldbeschriftungen, hat aber keine Möglichkeit zu wissen, welche Felder blau umrandet sind, und kann eine Schaltfläche nicht anhand ihrer dreieckigen Form identifizieren. Der Antragsprozess ist faktisch blockiert. Das Hinzufügen der tatsächlichen Feldbezeichnungen (z. B. „Name, Ausweisnummer und Geburtsdatum sind erforderlich“) und der Textbeschriftung der Schaltfläche („Antrag absenden“) beseitigt die Barriere sofort.

Über die Barrierefreiheit hinaus verbessert die Entfernung rein sensorischer Anweisungen die Nutzbarkeit für alle. Responsive Designs lassen Inhalte umfließen, sodass Positionsangaben auf Mobilgeräten ungenau werden. Der Dunkelmodus oder Hochkontrast-Themen verändern die Farbdarstellung. Sprachassistenten, die Seitenanweisungen vorlesen, entfernen jeglichen visuellen Kontext. Anweisungen, die auf stabilen, programmatischen Beschriftungen statt auf flüchtigen sensorischen Eigenschaften basieren, machen Inhalte robuster über alle Geräte und Kontexte hinweg — ein direkter Vorteil für SEO und Wartung.

Wie man testet

Führen Sie zuerst einen automatisierten Scan durch (axe DevTools oder Lighthouse): Öffnen Sie die Seite in Chrome, aktivieren Sie die axe-DevTools-Erweiterung und führen Sie einen Scan der gesamten Seite aus. Obwohl keine Regel direkt 1.3.3 abbildet, sollten Sie alle markierten Probleme in den Kategorien „color“, „label“ und „name“ prüfen. Diese Ergebnisse liefern eine Basis — wenn UI-Elemente keine zugänglichen Namen haben, stützt sich der Anweisungstext, der sich auf sie bezieht, mit hoher Wahrscheinlichkeit auf sensorische Hinweise. Exportieren Sie die Ergebnisse und notieren Sie alle interaktiven Elemente ohne programmatische Beschriftungen.
Identifizieren Sie alle Anweisungstexte manuell: Lesen Sie jeden Satz auf der Seite, der Nutzer*innen anweist, eine Aktion auszuführen oder Informationen zu finden. Dazu gehören Hilfetexte, Formularhinweise, Tooltips, Tutorial-Overlays, Fehlermeldungen und Onboarding-Flows. Erstellen Sie eine Liste jeder Anweisung und markieren Sie alle sensorischen Bezüge: Farbwörter (rot, blau, grün), Formwörter (rund, quadratisch, dreieckig), Größenwörter (groß, klein), Positionswörter (links, rechts, oben, unten, über, unter, Ecke), Ausrichtungswörter (horizontal, vertikal) und Klangbezüge (Glockenton, Piepton, Warnton).
Bewerten Sie jeden sensorischen Bezug auf zusätzliche nicht-sensorische Identifikatoren: Bestimmen Sie für jeden gefundenen sensorischen Bezug, ob auch ein nicht-sensorischer Identifikator vorhanden ist. Ein nicht-sensorischer Identifikator umfasst eine Textbeschriftung, die der sichtbaren Beschriftung oder dem zugänglichen Namen des Elements entspricht, eine Überschrift, einen nummerierten Schritt, eine eindeutige programmatische Rolle oder ein ARIA-Label. Wenn die einzige Möglichkeit, das referenzierte Element zu identifizieren, in der sensorischen Wahrnehmung besteht, verstößt die Anweisung gegen 1.3.3.
Testen Sie mit einem Screenreader (NVDA + Firefox): Navigieren Sie mit Tastatur und NVDA über die Seite. Tabben Sie durch alle interaktiven Elemente und hören Sie, wie NVDA jedes Element ankündigt. Lesen Sie dann die Anweisungstexte auf der Seite und fragen Sie sich: Könnte ein*e Nutzer*in, der*die nur diese Ansagen hört, den Anweisungen folgen? Wenn eine Anweisung sagt „Klicken Sie auf das Symbol rechts“, NVDA das Element aber als „Einstellungen, Schaltfläche“ ankündigt, ist der Positionsbezug überflüssig, aber die Beschriftung macht die Anweisung nutzbar. Wenn NVDA das Element als „Schaltfläche“ ohne Namen ankündigt, scheitert die Anweisung, die sich auf die visuelle Position stützt, vollständig.
Testen Sie mit VoiceOver + Safari (macOS/iOS): Aktivieren Sie VoiceOver und navigieren Sie über die Seite. Verwenden Sie den Rotor, um nach Schaltflächen, Links und Formularelementen zu browsen. Vergewissern Sie sich, dass jedes in einer Anweisung referenzierte Element allein über seinen angesagten Namen erreichbar und identifizierbar ist, ohne auf seine Position im visuellen Layout angewiesen zu sein.
Testen Sie mit JAWS + Chrome: Öffnen Sie die Seite in Chrome mit aktivem JAWS. Verwenden Sie den Formularmodus, um Eingabefelder zu durchlaufen, und hören Sie sich die Feldankündigungen an. Vergleichen Sie diese mit allen formularbezogenen Anweisungen, die Farbe oder Position verwenden, um Pflichtfelder zu kennzeichnen.
Testen Sie in Hochkontrast- und Dunkelmodus: Schalten Sie das Betriebssystem in den Hochkontrastmodus und laden Sie die Seite neu. Farblich codierte Anweisungen, die sich auf bestimmte Farben beziehen, können mehrdeutig oder unsichtbar werden, wenn sich die Farbdarstellung ändert. Dies hilft, eine versteckte Abhängigkeit von Farbe als einzigem sensorischen Hinweis aufzudecken.
Testen Sie in einer gezoomten oder umfließenden mobilen Ansicht: Ändern Sie die Größe des Browserfensters auf 320 px Breite oder verwenden Sie ein Mobilgerät. Anweisungen mit Positionssprache wie „linke Seitenleiste“ oder „obere Navigation“ sollten weiterhin sinnvoll sein, wenn das Layout in eine einspaltige Darstellung umfließt.

Wie man es behebt

Nur farbbasierte Formularfeld-Anweisungen — falsch

<p>Fields shown in red are required.</p>
<label for='email'>Email Address</label>
<input type='email' id='email' style='border-color: red;' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

Nur farbbasierte Formularfeld-Anweisungen — korrekt

<!-- The instruction now uses a text marker AND color, not color alone.
     The asterisk and the word "required" provide non-sensory identification. -->
<p>Fields marked with an asterisk (*) are required.</p>
<label for='email'>Email Address <span aria-hidden='true'>*</span></label>
<input type='email' id='email' aria-required='true' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

Positionsbezogener Schaltflächenverweis — falsch

<p>To save your work, click the button on the right side of the toolbar.</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

Positionsbezogener Schaltflächenverweis — korrekt

<!-- The instruction now references the button by its visible text label "Save",
     which matches the button's accessible name. Position is still mentioned
     but is no longer the sole identifier. -->
<p>To save your work, click the <strong>Save</strong> button (located on the right side of the toolbar).</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

Nur formbasierte Icon-Navigation — falsch

<p>Tap the circular icon to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

Nur formbasierte Icon-Navigation — korrekt

<!-- The button now has an accessible name via aria-label.
     The instruction references "Home" by name, not just by shape. -->
<p>Tap the <strong>Home</strong> button (the circular icon) to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home' aria-label='Home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

Nur akustischer Fortschritts-Hinweis — falsch

<p>Listen for the beep to know when the upload is complete.</p>
<button type='button' id='upload-btn'>Upload File</button>
<audio id='complete-chime' src='chime.mp3'></audio>

Nur akustischer Fortschritts-Hinweis — korrekt

<!-- A visible and screen-reader-accessible status message supplements the audio cue.
     Deaf users and users in silent environments now receive the same information. -->
<p>When the upload is complete, you will hear a chime and a <strong>"Upload Complete"</strong> message will appear below.</p>
<button type='button' id='upload-btn'>Upload File</button>
<div role='status' aria-live='polite' id='upload-status'></div>
<audio id='complete-chime' src='chime.mp3'></audio>
<!-- JavaScript sets #upload-status text to "Upload Complete" on success -->

Häufige Fehler

„Die rote Schaltfläche“ oder „das grüne Feld“ als einzigen Identifikator in Formularanweisungen oder Hilfetexten zu verwenden, ohne zusätzlich die sichtbare Beschriftung der Schaltfläche oder den Namen des Feldes anzugeben — dies verstößt sowohl gegen 1.3.3 als auch gegen 1.4.1.
Positionsphrasen wie „das Menü links“ oder „das Panel oben“ in Hilfedokumentation oder Onboarding-Flows zu verwenden, ohne das Menü oder Panel zu benennen, wodurch Anweisungen nutzlos werden, nachdem ein responsives Reflow das Layout auf eine einzelne Spalte reduziert hat.
Symbole nur über ihre Form zu beschreiben („Klicken Sie auf die dreieckige Wiedergabe-Schaltfläche“) statt den zugänglichen Namen oder die Beschriftung des Symbols zu verwenden, die ein*e Screenreader-Nutzer*in tatsächlich über Tastaturnavigation finden könnte.
Pflichtfelder ausschließlich über Rahmen- oder Hintergrundfarbe zu kennzeichnen in Inline-Anweisungen („orange Felder müssen ausgefüllt werden“), ohne ein Symbol, einen Beschriftungszusatz oder das Attribut aria-required='true', um dieselbe Information programmatisch zu vermitteln.
Nur akustische Rückmeldungen für interaktive Prozesse zu platzieren (Datei-Uploads, Formularübermittlungen, Ablauf von Timern), ohne eine entsprechende sichtbare Textstatus-Aktualisierung mit role='status' oder aria-live='polite'.
Größe als einziges Unterscheidungsmerkmal zu verwenden — Anweisungen wie „Klicken Sie auf die große Karte, um sie zu erweitern“ scheitern, wenn Nutzer*innen hineinzoomen, wenn Karten bei kleineren Viewports identisch groß dargestellt werden oder wenn ein*e Screenreader-Nutzer*in kein Konzept relativer Kartengrößen im DOM hat.
Sich auf Ausrichtungshinweise zu verlassen wie „wischen Sie horizontal, um zu navigieren“, ohne eine alternative Interaktionsmethode und eine nicht ausrichtungsbasierte Bezeichnung für das beschriebene Karussell oder den Slider bereitzustellen.
Zu vergessen, dass Fehlermeldungen ebenfalls Anweisungen sind — eine Fehlermeldung, die sagt „die hervorgehobenen Felder unten enthalten Fehler“, stützt sich auf visuelle Hervorhebung und räumliche Nähe und ist für Screenreader-Nutzer*innen nutzlos, sofern nicht jedes fehlerhafte Feld auch explizit in der Fehlermeldung benannt wird.
Davon auszugehen, dass das Hinzufügen eines Alt-Textes für ein Symbol die Anweisung behebt — wenn der Anweisungstext weiterhin nur sagt „Klicken Sie auf das runde Symbol“, macht der Alt-Text auf dem Bildelement die textliche Anweisung nicht konform; der Anweisungstext selbst muss einen nicht-sensorischen Identifikator enthalten.
Dynamisch eingefügte Anweisungen in Single-Page-Anwendungen zu vernachlässigen — Tooltips, Modale und Assistentenschritte, die per JavaScript eingefügt werden, enthalten häufig rein sensorische Hinweise, die der QS-Prüfung entgehen, weil sie in einem statischen Seiten-Audit nicht sichtbar sind.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die Präsidialverfügung 2025/10 der Türkei, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Anforderungen an die Web-Barrierefreiheit für eine breite Palette öffentlicher und privater Einrichtungen fest, die in der Türkei tätig sind. Die Verfügung schreibt die Konformität mit WCAG 2.1 Level AA als Basisstandard vor, und WCAG 1.3.3 — als Kriterium der Stufe A — ist daher für alle erfassten Einrichtungen vollständig verpflichtend.

Zu den von der Verfügung erfassten Einrichtungen gehören öffentliche Institutionen und Behörden, E-Commerce-Plattformen, Banken und Finanzinstitute, Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnent*innen, Reisebüros, private Transportunternehmen und Privatschulen, die vom Ministerium für Nationale Bildung (MoNE) zugelassen sind. Öffentliche Institutionen müssen innerhalb eines Jahres nach Veröffentlichung der Verfügung vollständige Konformität erreichen, während privaten Unternehmen ein Zeitraum von zwei Jahren eingeräumt wird.

WCAG 1.3.3 ist für türkische digitale Dienste besonders relevant, angesichts der weit verbreiteten Verwendung farbcodierter Formularhinweise und rein symbolbasierter Navigation in türkischen E-Government-Portalen, Bankanwendungen und E-Commerce-Checkout-Flows. Ein Online-Antragsformular einer öffentlichen Institution, das Bürger*innen anweist, „die in Rot markierten Felder auszufüllen“ und den Antrag durch „Drücken der Schaltfläche in der unteren rechten Ecke“ abzusenden, würde beispielsweise direkt gegen 1.3.3 verstoßen und einen Verstoß gegen die Präsidialverfügung darstellen. Ebenso müsste eine mobile Weboberfläche einer Bank, die Nutzer*innen durch mehrstufige Transaktionen ausschließlich mit Positions- und Farbhilfen führt, vor Ablauf der zweijährigen Frist für den Privatsektor überarbeitet werden.

Nichtkonformität birgt Reputations- und Rechtsrisiken, da sich das regulatorische Umfeld der Türkei im Bereich digitale Barrierefreiheit weiterentwickelt. Erfasste Einrichtungen sollten die Einhaltung von 1.3.3 nicht als kleine redaktionelle Korrektur betrachten, sondern als systematische Überprüfung aller Anweisungstexte — einschließlich Hilfetexten, Fehlermeldungen, Onboarding-Flows und Support-Dokumentation —, um sicherzustellen, dass sensorische Bezüge stets von stabilen, programmatischen, textbasierten Identifikatoren begleitet werden. Das Overlay-SDK von Accsible kann dabei helfen, viele verwandte Probleme sichtbar zu machen und zu beheben, doch die manuelle Inhaltsprüfung, die 1.3.3 erfordert, muss letztlich von einer qualifizierten menschlichen Prüfer*in in Zusammenarbeit mit automatisierten Werkzeugen durchgeführt werden.