WCAG-succescriteria · Level A

WCAG 1.3.3: Zintuiglijke kenmerken

WCAG 1.3.3 vereist dat instructies voor het gebruik van content niet uitsluitend afhankelijk zijn van zintuiglijke kenmerken zoals vorm, kleur, grootte, visuele locatie, oriëntatie of geluid. Dit zorgt ervoor dat gebruikers die deze zintuiglijke signalen niet kunnen waarnemen — door blindheid, kleurenblindheid, doofheid of andere beperkingen — nog steeds alle functies kunnen begrijpen en bedienen.

Wat Deze Regel Betekent

WCAG Succescriterium 1.3.3 — Zintuiglijke Kenmerken (Niveau A) stelt dat instructies die worden gegeven voor het begrijpen en bedienen van content niet uitsluitend mogen steunen op zintuiglijke kenmerken van componenten, zoals vorm, grootte, visuele locatie, oriëntatie of geluid. Met andere woorden: als je interface een gebruiker vertelt om met iets te interageren door alleen te verwijzen naar hoe het eruitziet, waar het op het scherm verschijnt of hoe het klinkt, is die instructie zinloos voor gebruikers die die specifieke zintuiglijke eigenschappen niet kunnen waarnemen.

Het sleutelwoord hier is uitsluitend. Het criterium verbiedt het gebruik van zintuiglijke verwijzingen niet — het verbiedt dat ze het enige middel tot identificatie zijn. Een instructie als "klik op de ronde groene knop links" faalt wanneer een gebruiker groen niet kan onderscheiden, de vorm van de knop niet kan zien of links en rechts niet kan bepalen door een reflow-layout. "Klik echter op de knop Verzenden (de ronde groene knop links)" voldoet wel, omdat het tekstlabel "Verzenden" een niet-zintuiglijke identificatie biedt die onafhankelijk werkt van kleur, vorm en positie.

Instructies waarop dit criterium van toepassing is, omvatten alle tekstuele, auditieve of visuele content die gebruikers aanstuurt om een handeling uit te voeren of informatie te lokaliseren. Veelvoorkomende foutpatronen zijn onder andere:

  • "Klik op de knop rechts om door te gaan" — steunt uitsluitend op visuele locatie.
  • "Selecteer het vierkante pictogram om de instellingen te openen" — steunt uitsluitend op vorm.
  • "De verplichte velden worden in het rood weergegeven" — steunt uitsluitend op kleur.
  • "Wanneer je de gong hoort, ga je door naar de volgende stap" — steunt uitsluitend op geluid.
  • "Tik op de grote tegel om de sectie uit te klappen" — steunt uitsluitend op grootte.

Een geldige instructie bevat altijd minstens één niet-zintuiglijke identificatie — meestal een tekstlabel, een programmatische naam of een kop — zodat gebruikers die afhankelijk zijn van ondersteunende technologie of werken in omstandigheden waarin zintuiglijke aanwijzingen niet beschikbaar zijn, de aanwijzingen toch kunnen volgen. Let op dat dit criterium specifiek betrekking heeft op instructies; het vereist niet dat elk UI-element wordt herontworpen, maar wel dat alle tekstuele of gesproken aanwijzingen over die elementen waarneembaar zijn zonder zintuiglijke discriminatie.

Er zijn geen officiële uitzonderingen gedefinieerd binnen 1.3.3 zelf, al verduidelijkt het Understanding-document dat content die zintuiglijke kenmerken gebruikt naast niet-zintuiglijke identificaties volledig conform is. Het criterium vult 1.4.1 (Gebruik van kleur) aan, maar is daarvan onderscheiden; 1.4.1 gaat specifiek over kleur alleen, terwijl 1.3.3 een bredere reikwijdte heeft en alle zintuiglijke modaliteiten omvat.

Waarom Het Belangrijk Is

Instructies die uitsluitend op zintuiglijke kenmerken steunen, vormen harde barrières voor een brede groep gebruikers. Beschouw elke getroffen groep:

Blinde en slechtziende gebruikers zijn afhankelijk van schermlezers of vergrotingssoftware. Wanneer een instructie zegt "klik op het pictogram in de rechterbovenhoek", heeft een schermlezergebruiker die navigeert op tabvolgorde of kopstructuur geen enkel concept van "rechterbovenhoek" in de visuele layout. Evenzo ziet een gebruiker met ernstige slechtziendheid die tot 400% heeft ingezoomd mogelijk slechts een klein deel van het scherm tegelijk, waardoor positionele verwijzingen als "linker paneel" of "onderste sectie" volledig onbetrouwbaar worden. Volgens de Wereldgezondheidsorganisatie hebben wereldwijd ongeveer 2,2 miljard mensen een vorm van visuele beperking, wat dit tot een van de grootste getroffen populaties maakt.

Kleurenblinde gebruikers — ongeveer 1 op de 12 mannen en 1 op de 200 vrouwen — kunnen bepaalde kleurparen niet onderscheiden. Een instructie als "velden die in het rood zijn gemarkeerd, zijn verplicht" is onzichtbaar als onderscheidende aanwijzing voor iemand met rood-groene kleurenblindheid. Hoewel 1.4.1 dit adresseert voor het UI-element zelf, zorgt 1.3.3 ervoor dat de instructietekst ook een alternatief biedt.

Dove en slechthorende gebruikers worden geraakt door uitsluitend auditieve aanwijzingen. Als een e-learningplatform gebruikers instrueert om "door te gaan wanneer je de bel hoort", worden gebruikers die de bel niet kunnen horen uitgesloten. Dit patroon komt voor in interactieve presentaties, videobased tutorials en getimede toetsen.

Gebruikers met cognitieve en leerstoornissen kunnen moeite hebben met directionele taal, vooral wanneer hun ondersteunende technologie content in een gelinieariseerde vorm weergeeft die visuele positionering wegneemt. Iemand die een schakelapparaat of oogvolgsysteem gebruikt, navigeert bovendien in sequenties die geen relatie hoeven te hebben met de tweedimensionale ruimtelijke layout die een ziende ontwerper voor ogen had.

Beschouw een concreet scenario uit de echte wereld: een Turks e-overheidsportaal instrueert burgers om "de velden met een blauwe rand in te vullen en vervolgens op de driehoekige knop te drukken om je aanvraag in te dienen." Een blinde gebruiker die op formulier­velden navigeert, hoort veldlabels via de schermlezer, maar heeft geen manier om te weten welke velden een blauwe rand hebben, en kan een knop ook niet identificeren aan de hand van zijn driehoekige vorm. Het aanvraagproces wordt feitelijk geblokkeerd. Door de daadwerkelijke veldlabels toe te voegen (bijv. "Naam, ID-nummer en geboortedatum zijn verplicht") en het tekstlabel van de knop ("Aanvraag indienen") wordt de barrière direct weggenomen.

Los van toegankelijkheid verbetert het verwijderen van uitsluitend zintuiglijke instructies de bruikbaarheid voor iedereen. Responsive designs laten content reflowen, waardoor positionele verwijzingen onnauwkeurig worden op mobiel. Donkere modus of hoogcontrastthema’s veranderen de kleurweergave. Spraakassistenten die pagina-instructies voorlezen, strippen alle visuele context weg. Instructies baseren op stabiele, programmatische labels in plaats van vluchtige zintuiglijke eigenschappen maakt content robuuster op alle apparaten en in alle contexten — ook een direct voordeel voor SEO en onderhoud.

Gerelateerde Axe-core Regels

WCAG 1.3.3 vereist handmatige tests omdat geautomatiseerde tools de betekenis of intentie van instructies in natuurlijke taal niet betrouwbaar kunnen interpreteren. Een statische analyse-engine kan detecteren dat er een knop bestaat of dat er een kleur wordt gebruikt, maar kan geen alinea met instructietekst lezen, begrijpen dat die naar een knop verwijst en vervolgens bepalen of die verwijzing uitsluitend zintuiglijk is. Dit is een semantisch en contextueel oordeel dat menselijke beoordeling vereist.

  • Handmatige beoordeling vereist — er bestaat geen specifieke axe-core-regel voor 1.3.3. Axe-core-regels zoals color-contrast en label kunnen gerelateerde problemen aan het licht brengen (bijvoorbeeld een knop zonder toegankelijke naam), maar ze behandelen andere criteria. Voor 1.3.3 moet een menselijke tester elke instructiezin op de pagina lezen, alle zintuiglijke verwijzingen (vorm, kleur, grootte, locatie, oriëntatie, geluid) identificeren en verifiëren dat elke verwijzing vergezeld gaat van minstens één niet-zintuiglijke identificatie. Geautomatiseerde tools zullen een zin als "klik op de groene knop hieronder" niet als overtreding markeren, omdat het ontleden van intentie in natuurlijke taal buiten het bereik van huidige regelgebaseerde automatisering valt.
  • Waarom automatisering hier faalt: Neem "klik op de grote knop" — deze zin bevat het woord "knop", wat een geautomatiseerde tool zou kunnen interpreteren als een verwijzing naar een toegankelijk role. Maar de instructie steunt nog steeds uitsluitend op grootte ("grote") om deze knop van andere te onderscheiden. Geautomatiseerde tools kunnen niet bepalen of "grote" het enige onderscheidende kenmerk is of dat er maar één knop op de pagina staat (waardoor "grote" overbodig maar niet schadelijk is). Menselijk oordeel is essentieel om deze nuances in context te beoordelen.
  • Aanvullende axe-regels om naast handmatige beoordeling te draaien: Het uitvoeren van color-contrast-, label-, button-name- en aria-label-controles helpt ervoor te zorgen dat de UI-elementen waar in instructies naar wordt verwezen daadwerkelijk programmatische namen hebben — een voorwaarde om niet-zintuiglijke instructies te kunnen schrijven. Als een knop geen toegankelijke naam heeft, kan geen enkele instructie er zinvol naar verwijzen zonder terug te vallen op zintuiglijke aanwijzingen.

Hoe te Testen

  1. Voer eerst een geautomatiseerde scan uit (axe DevTools of Lighthouse): Open de pagina in Chrome, activeer de axe DevTools-extensie en voer een scan van de volledige pagina uit. Hoewel er geen regel direct aan 1.3.3 is gekoppeld, bekijk je alle gemarkeerde problemen in de categorieën "color", "label" en "name". Deze resultaten vormen een basislijn — als UI-elementen geen toegankelijke namen hebben, steunt de instructietekst die ernaar verwijst vrijwel zeker op zintuiglijke aanwijzingen. Exporteer de resultaten en noteer alle interactieve elementen zonder programmatische labels.
  2. Identificeer alle instructietekst handmatig: Lees elke zin op de pagina die een gebruiker aanstuurt om een handeling uit te voeren of informatie te lokaliseren. Dit omvat helpteksten, formulierhints, tooltips, tutorial-overlays, foutmeldingen en onboarding-flows. Maak een lijst van elke instructie en markeer alle zintuiglijke verwijzingen: kleurwoorden (rood, blauw, groen), vormwoorden (rond, vierkant, driehoekig), groottewoorden (groot, klein, big), positionele woorden (links, rechts, boven, onder, boven, onder, hoek), oriëntatiewoorden (horizontaal, verticaal) en geluidsverwijzingen (gong, piep, waarschuwingsgeluid).
  3. Beoordeel elke zintuiglijke verwijzing op aanvullende niet-zintuiglijke identificaties: Bepaal voor elke gevonden zintuiglijke verwijzing of er ook een niet-zintuiglijke identificatie aanwezig is. Een niet-zintuiglijke identificatie omvat een tekstlabel dat overeenkomt met het zichtbare label of de toegankelijke naam van het element, een kop, een genummerde stap, een unieke programmatische role of een ARIA-label. Als de enige manier om het bedoelde element te identificeren zintuiglijke waarneming is, voldoet de instructie niet aan 1.3.3.
  4. Test met een schermlezer (NVDA + Firefox): Navigeer op de pagina met alleen het toetsenbord en NVDA. Tab door alle interactieve elementen en luister hoe NVDA elk element aankondigt. Lees vervolgens de instructietekst op de pagina en vraag je af: zou een gebruiker die alleen deze aankondigingen hoort de instructies kunnen volgen? Als een instructie zegt "klik op het pictogram rechts" maar NVDA het element aankondigt als "Instellingen, knop", dan is de positionele verwijzing in de instructie overbodig, maar maakt het label de instructie navigeerbaar. Als NVDA het element aankondigt als "knop" zonder naam, faalt de instructie die op visuele positie steunt volledig.
  5. Test met VoiceOver + Safari (macOS/iOS): Schakel VoiceOver in en navigeer op de pagina. Gebruik de rotor om te bladeren op knoppen, links en formulierbesturingselementen. Controleer of elk element waar in een instructie naar wordt verwezen, bereikbaar en identificeerbaar is op basis van alleen de aangekondigde naam, zonder te steunen op de positie in de visuele layout.
  6. Test met JAWS + Chrome: Open de pagina in Chrome met JAWS actief. Gebruik Forms Mode om door invoervelden te navigeren en luister naar de aankondigingen van de velden. Vergelijk deze met alle formulierinstructies op hoger niveau die kleur of positie gebruiken om verplichte velden aan te geven.
  7. Test in hoogcontrast- en donkere modus: Schakel het besturingssysteem over naar hoogcontrastmodus en laad de pagina opnieuw. Op kleur gecodeerde instructies die naar specifieke kleuren verwijzen, kunnen dubbelzinnig of onzichtbaar worden wanneer de kleurweergave verandert. Dit helpt verborgen afhankelijkheid van kleur als enige zintuiglijke aanwijzing bloot te leggen.
  8. Test in een ingezoomde of gereflowde mobiele weergave: Verklein het browservenster tot 320px breed of gebruik een mobiel apparaat. Instructies met positionele taal zoals "linker zijbalk" of "bovenste navigatie" moeten nog steeds betekenisvol zijn wanneer de layout is gereflowd naar één kolom.

Hoe te Herstellen

Alleen-kleur Formulierveldinstructies — Onjuist

<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' />

Alleen-kleur Formulierveldinstructies — Juist

<!-- 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' />

Positionele Knopverwijzing — Onjuist

<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>

Positionele Knopverwijzing — Juist

<!-- 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>

Alleen-vorm Pictogramnavigatie — Onjuist

<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>

Alleen-vorm Pictogramnavigatie — Juist

<!-- 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>

Alleen-audio Voortgangssignaal — Onjuist

<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>

Alleen-audio Voortgangssignaal — Juist

<!-- 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 -->

Veelvoorkomende Fouten

  • "De rode knop" of "het groene veld" als enige identificatie schrijven in formulierinstructies of helpteksten, zonder ook het zichtbare label van de knop of de naam van het veld te geven — dit is in strijd met zowel 1.3.3 als 1.4.1.
  • Positionele uitdrukkingen gebruiken zoals "het menu links" of "het paneel bovenaan" in helpdocumentatie of onboarding-flows zonder het menu of paneel te benoemen, waardoor instructies nutteloos worden nadat responsive reflow de layout tot één kolom heeft samengevouwen.
  • Pictogrammen alleen beschrijven op basis van vorm ("klik op de driehoekige afspeelknop") in plaats van de toegankelijke naam of het label van het pictogram te gebruiken, dat een schermlezergebruiker daadwerkelijk via toetsenbordnavigatie kan lokaliseren.
  • Verplichte formuliervelden uitsluitend aangeven via randkleur of achtergrondkleur in inline-instructies ("oranje velden moeten worden ingevuld") zonder een symbool, labelsuffix of aria-required='true'-attribuut om dezelfde informatie programmatisch over te brengen.
  • Alleen-audio feedback plaatsen voor interactieve processen (bestanduploads, formulierverzendingen, timerverlopen) zonder een bijbehorende zichtbare tekststatusupdate met role='status' of aria-live='polite'.
  • Grootte als enige onderscheidende aanwijzing gebruiken — instructies als "klik op de grote kaart om uit te klappen" falen wanneer de gebruiker inzoomt, wanneer kaarten op kleinere viewports identiek groot worden weergegeven of wanneer een schermlezergebruiker geen concept heeft van relatieve kaartgroottes in de DOM.
  • Steunen op oriëntatie-aanwijzingen zoals "veeg horizontaal om te navigeren" zonder een alternatieve interactiemethode en een niet-oriëntatiegebaseerd label voor de beschreven carrousel of slider te bieden.
  • Vergeten dat foutmeldingen ook instructies zijn — een foutmelding die zegt "de gemarkeerde velden hieronder bevatten fouten" steunt op visuele markering en positionele nabijheid, en is nutteloos voor een schermlezergebruiker tenzij elk foutief veld ook expliciet in de foutmelding wordt genoemd.
  • Aannemen dat het toevoegen van alt-tekst aan een pictogram de instructie oplost — als de instructietekst nog steeds alleen zegt "klik op het ronde pictogram", zorgt alt-tekst op het image-element er niet voor dat de tekstinstructie conform is; de tekst zelf moet een niet-zintuiglijke identificatie bevatten.
  • Dynamisch ingespoten instructies negeren in single-page-applicaties — tooltips, modals en wizardstappen die via JavaScript worden ingespoten, bevatten vaak uitsluitend zintuiglijke aanwijzingen die aan QA-controle ontsnappen omdat ze niet zichtbaar zijn in een statische pagina-audit.

Relatie met de Turkse Toegankelijkheidsregelgeving

De Turkse Presidentiële Circulaire 2025/10, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, stelt verplichte webtoegankelijkheidseisen vast voor een brede groep publieke en private organisaties die in Turkije actief zijn. De circulaire schrijft conformiteit met WCAG 2.1 Niveau AA voor als basisnorm, en WCAG 1.3.3 — als criterium op Niveau A — is daarom volledig verplicht voor alle betrokken organisaties.

De organisaties die onder de circulaire vallen, omvatten overheidsinstellingen en -agentschappen, e-commerceplatforms, banken en financiële instellingen, ziekenhuizen en zorgaanbieders, telecombedrijven met 200,000 of meer abonnees, reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministerie van Nationaal Onderwijs (MoNE). Overheidsinstellingen moeten binnen één jaar na de publicatiedatum van de circulaire volledige conformiteit bereiken, terwijl private sectororganisaties een termijn van twee jaar krijgen.

WCAG 1.3.3 is bijzonder relevant voor Turkse digitale diensten gezien het wijdverbreide gebruik van kleurgecodeerde formulierbegeleiding en navigatiepatronen die uitsluitend uit pictogrammen bestaan in Turkse e-overheidsportalen, bankapplicaties en e-commerce-checkoutflows. Een online aanvraagformulier van een overheidsinstelling dat burgers bijvoorbeeld instrueert om "de velden in te vullen die in het rood zijn gemarkeerd" en in te dienen door "op de knop in de rechterbenedenhoek te drukken", zou een directe schending van 1.3.3 zijn en een niet-naleving van de Presidentiële Circulaire vormen. Evenzo zou een mobiele webinterface van een bank die gebruikers door meerstaps­transacties leidt met uitsluitend positionele en kleur­aanwijzingen, moeten worden herzien vóór de tweejarige deadline voor de private sector.

Niet-naleving brengt reputatie- en juridische risico’s met zich mee naarmate de Turkse regulatoire omgeving rond digitale toegankelijkheid volwassen wordt. Betrokken organisaties moeten conformiteit met 1.3.3 niet zien als een kleine redactionele aanpassing, maar als een systematische herziening van alle instructiecontent — inclusief helpteksten, foutmeldingen, onboarding-flows en ondersteunende documentatie — om ervoor te zorgen dat zintuiglijke verwijzingen altijd worden vergezeld door stabiele, programmatische, tekstgebaseerde identificaties. De overlay-SDK van Accsible kan helpen bij het signaleren en verhelpen van veel gerelateerde problemen, maar de handmatige contentreview die 1.3.3 vereist, moet uiteindelijk worden uitgevoerd door een gekwalificeerde menselijke auditor die samenwerkt met geautomatiseerde tooling.