WCAG 1.3.3: Sensoriska kännetecken

Vad den här regeln innebär

WCAG framgångskriterium 1.3.3 — Sensoriska kännetecken (Nivå A) anger att instruktioner som ges för att förstå och använda innehåll inte får förlita sig enbart på sensoriska egenskaper hos komponenter, såsom form, storlek, visuell placering, orientering eller ljud. Med andra ord, om ditt gränssnitt säger åt en användare att interagera med något genom att endast hänvisa till hur det ser ut, var det visas på skärmen eller hur det låter, kommer den instruktionen att vara meningslös för användare som inte kan uppfatta just dessa sensoriska egenskaper.

Nyckelordet här är enbart. Kriteriet förbjuder inte användning av sensoriska referenser — det förbjuder att göra dem till det enda sättet att identifiera något. En instruktion som "klicka på den runda gröna knappen till vänster" misslyckas när en användare inte kan skilja på grönt, inte kan se knappens form eller inte kan avgöra vänster från höger på grund av en omflödeslayout. Däremot klarar "klicka på knappen Skicka (den runda gröna knappen till vänster)" kravet eftersom textetiketten "Skicka" ger en icke-sensorisk identifierare som fungerar oberoende av färg, form och position.

Instruktioner som påverkas av detta kriterium inkluderar all text, ljud- eller visuellt innehåll som instruerar användare att utföra en åtgärd eller hitta information. Vanliga felmönster inkluderar:

• "Klicka på knappen till höger för att fortsätta" — förlitar sig enbart på visuell placering.
• "Välj den fyrkantiga ikonen för att öppna inställningar" — förlitar sig enbart på form.
• "De obligatoriska fälten visas i rött" — förlitar sig enbart på färg.
• "När du hör klangen går du vidare till nästa steg" — förlitar sig enbart på ljud.
• "Tryck på den stora rutan för att expandera avsnittet" — förlitar sig enbart på storlek.

En godkänd instruktion innehåller alltid minst en icke-sensorisk identifierare — vanligtvis en textetikett, ett programmatiskt namn eller en rubrik — så att användare som förlitar sig på hjälpmedel eller befinner sig i situationer där sensoriska signaler inte är tillgängliga ändå kan följa instruktionerna. Observera att detta kriterium specifikt gäller instruktioner; det kräver inte att varje UI-element designas om, men det kräver att all textuell eller talad vägledning om dessa element kan uppfattas utan sensorisk diskriminering.

Det finns inga officiella undantag definierade i 1.3.3 i sig, men dokumentet Understanding klargör att innehåll som använder sensoriska kännetecken utöver icke-sensoriska identifierare är fullt förenligt. Kriteriet kompletterar men är skilt från 1.4.1 (Användning av färg), som specifikt behandlar färg; 1.3.3 har ett bredare omfång som omfattar alla sensoriska modaliteter.

Varför det är viktigt

Instruktioner som enbart bygger på sensorik skapar stora hinder för en bred grupp användare. Tänk på varje berörd grupp:

Blinda och synsvaga användare förlitar sig på skärmläsare eller förstoringsprogram. När en instruktion säger "klicka på ikonen i det övre högra hörnet" har en skärmläsaranvändare som navigerar via tabb-ordning eller rubrikstruktur ingen uppfattning om "övre högra hörnet" i den visuella layouten. På samma sätt kan en användare med svår synnedsättning som har zoomat in till 400 % bara se en liten del av skärmen åt gången, vilket gör positionsreferenser som "vänster panel" eller "nedre avsnittet" helt opålitliga. Enligt Världshälsoorganisationen har cirka 2,2 miljarder människor globalt någon form av synnedsättning, vilket gör detta till en av de största berörda grupperna.

Färgblinda användare — ungefär 1 av 12 män och 1 av 200 kvinnor — kan inte skilja vissa färgpar. En instruktion som "fält markerade i rött är obligatoriska" är osynlig som särskiljande signal för någon med röd-grön färgblindhet. Medan 1.4.1 behandlar detta för själva UI-elementet, säkerställer 1.3.3 att den instruktionstext som hör till också ger ett alternativ.

Döva och hörselskadade användare påverkas av signaler som enbart bygger på ljud. Om en e-lärandeplattform instruerar användare att "gå vidare när du hör klockan" utesluts användare som inte kan höra klockan. Detta mönster förekommer i interaktiva presentationer, videobaserade handledningar och tidsbegränsade prov.

Användare med kognitiva och inlärningssvårigheter kan ha svårt med riktningsspråk, särskilt när deras hjälpmedel återger innehåll i en linjär form som tar bort visuell positionering. En person som använder en switch-enhet eller ögonstyrning navigerar också i sekvenser som kanske inte har någon relation till den tvådimensionella layout som en seende designer föreställt sig.

Fundera på ett konkret scenario i verkligheten: en turkisk e-tjänsteportal för myndigheter instruerar medborgare att "fylla i fälten markerade i blått och sedan trycka på den triangulära knappen för att skicka in din ansökan." En blind användare som navigerar via formulärfält hör fältetiketter via sin skärmläsare men har ingen möjlighet att veta vilka fält som är markerade i blått, och kan inte heller identifiera en knapp utifrån dess triangulära form. Ansökningsprocessen blockeras i praktiken. Genom att lägga till de faktiska fältetiketterna (t.ex. "Namn, ID-nummer och födelsedatum är obligatoriska") och knappens textetikett ("Skicka ansökan") undanröjs hindret omedelbart.

Utöver tillgänglighet förbättrar borttagning av sensorik-baserade instruktioner användbarheten för alla. Responsiva designer låter innehåll flöda om så att positionsreferenser blir felaktiga på mobiler. Mörkt läge eller högkontrastlägen ändrar färgåtergivningen. Röstassistenter som läser upp sidinstruktioner tar bort all visuell kontext. Att bygga instruktioner kring stabila, programmatiska etiketter i stället för flyktiga sensoriska egenskaper gör innehåll mer robust i alla enheter och sammanhang — också en direkt SEO- och underhållsfördel.

Relaterade Axe-core-regler

WCAG 1.3.3 kräver manuell testning eftersom automatiserade verktyg inte pålitligt kan tolka innebörden eller avsikten i instruktioner i naturligt språk. En statisk analysmotor kan upptäcka att en knapp finns eller att en färg används, men den kan inte läsa ett stycke instruktionstext, förstå att det hänvisar till en knapp och sedan avgöra om den hänvisningen är uteslutande sensorisk. Detta är en semantisk och kontextuell bedömning som kräver mänsklig granskning.

• Manuell granskning krävs — ingen dedikerad axe-core-regel finns för 1.3.3. Axe-core-regler som color-contrast och label kan lyfta fram relaterade problem (till exempel en knapp utan tillgängligt namn), men de behandlar andra kriterier. För 1.3.3 måste en mänsklig testare läsa varje instruktionstext på sidan, identifiera alla sensoriska referenser (form, färg, storlek, placering, orientering, ljud) och verifiera att minst en icke-sensorisk identifierare åtföljer varje referens. Automatiserade verktyg kommer inte att flagga en mening som "klicka på den gröna knappen nedan" som ett brott, eftersom tolkning av avsikt i naturligt språk ligger bortom nuvarande regelbaserad automatisering.
• Varför automatisering misslyckas här: Tänk på att "klicka på den stora knappen" innehåller ordet "knapp", vilket ett automatiserat verktyg kan tolka som en hänvisning till en tillgänglig roll. Men instruktionen förlitar sig fortfarande enbart på storlek ("stora") för att skilja denna knapp från andra. Automatiserade verktyg kan inte avgöra om "stor" är det enda särskiljande kännetecknet eller om det bara finns en knapp på sidan (vilket gör "stor" överflödigt men inte skadligt). Mänsklig bedömning är avgörande för att utvärdera dessa nyanser i sitt sammanhang.
• Kompletterande axe-regler att köra parallellt med manuell granskning: Att köra kontrollerna color-contrast, label, button-name och aria-label hjälper till att säkerställa att de UI-element som refereras i instruktioner faktiskt har programmatiska namn — en förutsättning för att kunna skriva icke-sensoriska instruktioner. Om en knapp saknar tillgängligt namn kan ingen instruktion meningsfullt referera till den utan att ta till sensoriska signaler.

Hur man testar

1. Kör först en automatiserad skanning (axe DevTools eller Lighthouse): Öppna sidan i Chrome, aktivera tillägget axe DevTools och kör en fullständig sidskanning. Även om ingen regel mappar direkt till 1.3.3, granska alla flaggade problem under kategorierna "color", "label" och "name". Dessa resultat ger en baslinje — om UI-element saknar tillgängliga namn förlitar sig instruktionstext som refererar till dem nästan säkert på sensoriska signaler. Exportera resultaten och notera alla interaktiva element utan programmatiska etiketter.
2. Identifiera all instruktionstext manuellt: Läs varje mening på sidan som instruerar en användare att utföra en åtgärd eller hitta information. Detta inkluderar hjälptester, formulärtips, verktygstips, handledningsöverlägg, felmeddelanden och onboarding-flöden. Skapa en lista över varje instruktion och markera alla sensoriska referenser: färgord (röd, blå, grön), formord (rund, fyrkantig, triangulär), storleksord (stor, liten), positionsord (vänster, höger, överst, nederst, ovanför, nedanför, hörn), orienteringsord (horisontell, vertikal) och ljudreferenser (klang, pip, varningsljud).
3. Utvärdera varje sensorisk referens för ytterligare icke-sensoriska identifierare: För varje sensorisk referens, avgör om en icke-sensorisk identifierare också finns. En icke-sensorisk identifierare inkluderar en textetikett som matchar elementets synliga etikett eller tillgängliga namn, en rubrik, ett numrerat steg, en unik programmatisk roll eller en ARIA-etikett. Om det enda sättet att identifiera det refererade elementet är genom sensorisk perception misslyckas instruktionen med 1.3.3.
4. Testa med en skärmläsare (NVDA + Firefox): Navigera på sidan med enbart tangentbordet och NVDA. Tabba genom alla interaktiva element och lyssna på hur NVDA annonserar vart och ett. Läs sedan instruktionstexten på sidan och fråga: skulle en användare som bara hör dessa annonseringar kunna följa instruktionerna? Om en instruktion säger "klicka på ikonen till höger" men NVDA annonserar elementet som "Inställningar, knapp", är positionsreferensen överflödig men etiketten gör instruktionen möjlig att följa. Om NVDA annonserar elementet som "knapp" utan namn misslyckas instruktionen som förlitar sig på visuell position helt.
5. Testa med VoiceOver + Safari (macOS/iOS): Aktivera VoiceOver och navigera på sidan. Använd rotorn för att bläddra efter knappar, länkar och formulärkontroller. Verifiera att varje element som refereras i en instruktion är nåbart och identifierbart enbart via sitt annonserade namn, utan att förlita sig på dess position i den visuella layouten.
6. Testa med JAWS + Chrome: Öppna sidan i Chrome med JAWS aktivt. Använd Forms Mode för att navigera mellan inmatningsfält och lyssna på fältannonseringar. Korsreferera med alla formulärinstruktioner på hög nivå som använder färg eller position för att ange obligatoriska fält.
7. Testa i högkontrast- och mörka lägen: Växla operativsystemet till högkontrastläge och ladda om sidan. Färgkodade instruktioner som hänvisar till specifika färger kan bli tvetydiga eller osynliga när färgåtergivningen ändras. Detta hjälper till att avslöja dold användning av färg som enda sensoriska signal.
8. Testa i inzoomad eller omflödad mobilvy: Ändra storleken på webbläsarfönstret till 320 px bredd eller använd en mobil enhet. Instruktioner som använder positionsspråk som "vänster sidofält" eller "övre navigeringen" ska fortfarande vara meningsfulla när layouten har flödat om till en enda kolumn.

Hur man åtgärdar

Formulärinstruktioner enbart med färg — felaktigt

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

Formulärinstruktioner enbart med färg — 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' />

Positionsbaserad knappreferens — felaktigt

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

Positionsbaserad knappreferens — 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>

Ikonnavigering enbart med form — felaktigt

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

Ikonnavigering enbart med form — 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>

Ljudbaserad framstegssignal — felaktigt

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

Ljudbaserad framstegssignal — 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 -->

Vanliga misstag

• Att skriva "den röda knappen" eller "det gröna fältet" som enda identifierare i formulärinstruktioner eller hjälptester, utan att också ange knappens synliga etikett eller fältets namn — detta bryter mot både 1.3.3 och 1.4.1.
• Att använda positionsfraser som "menyn till vänster" eller "panelen längst upp" i hjälpdokumentation eller onboarding-flöden utan att namnge menyn eller panelen, vilket gör instruktioner värdelösa efter att responsivt omflöde har kollapsat layouten till en enda kolumn.
• Att beskriva ikoner enbart med form ("klicka på den triangulära uppspelningsknappen") i stället för att använda ikonens tillgängliga namn eller etikett, som en skärmläsaranvändare faktiskt skulle kunna hitta via tangentbordsnavigering.
• Att ange obligatoriska formulärfält uteslutande genom kantfärg eller bakgrundsfärg i inline-instruktioner ("orange fält måste fyllas i") utan en symbol, etikett-suffix eller attributet aria-required='true' för att förmedla samma information programmatiskt.
• Att lägga till återkoppling enbart via ljud för interaktiva processer (filuppladdningar, formulärinlämningar, tidsgränser) utan motsvarande synlig textstatusuppdatering med role='status' eller aria-live='polite'.
• Att använda storlek som enda särskiljande signal — instruktioner som "klicka på det stora kortet för att expandera" misslyckas när användaren zoomar in, när kort renderas i identisk storlek i mindre vyer eller när en skärmläsaranvändare inte har någon uppfattning om relativa kortstorlekar i DOM:en.
• Att förlita sig på orienteringssignaler såsom "svep horisontellt för att navigera" utan att tillhandahålla en alternativ interaktionsmetod och en icke-orienteringsbaserad etikett för den karusell eller slider som beskrivs.
• Att glömma att felmeddelanden också är instruktioner — ett fel som säger "de markerade fälten nedan innehåller fel" förlitar sig på visuell markering och positionsmässig närhet, och kommer att vara värdelöst för en skärmläsaranvändare om inte varje felaktigt fält också namnges uttryckligen i felmeddelandet.
• Att anta att det räcker att lägga till alt-text för en ikon — om den löpande instruktionstexten fortfarande bara säger "klicka på den cirkulära ikonen" gör inte ikonens alt-text på bildelementet instruktionen förenlig; själva texten måste innehålla en icke-sensorisk identifierare.
• Att förbise dynamiskt injicerade instruktioner i single-page-applikationer — verktygstips, modaler och steg i guider som injiceras via JavaScript innehåller ofta sensorik-baserad vägledning som undgår QA-granskning eftersom de inte är synliga i en statisk sidgranskning.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentdekret 2025/10, publicerat i Officiella tidningen nr 32933 den 21 juni 2025, fastställer obligatoriska krav på webbtillgänglighet för ett brett spektrum av offentliga och privata aktörer verksamma i Turkiet. Cirkuläret kräver överensstämmelse med WCAG 2.1 nivå AA som baslinjestandard, och WCAG 1.3.3 — som ett kriterium på nivå A — är därför fullt obligatoriskt för alla berörda aktörer.

De aktörer som omfattas av cirkuläret inkluderar offentliga institutioner och myndigheter, e-handelsplattformar, banker och finansiella institutioner, sjukhus och vårdgivare, telekommunikationsföretag med 200,000 eller fler abonnenter, resebyråer, privata transportföretag och privatskolor auktoriserade av Ministry of National Education (MoNE). Offentliga institutioner måste uppnå full efterlevnad inom ett år från cirkulärets publiceringsdatum, medan privata aktörer ges ett tvåårigt tidsfönster.

WCAG 1.3.3 är särskilt relevant för turkiska digitala tjänster med tanke på den utbredda användningen av färgkodad formulärvägledning och ikonbaserade navigationsmönster i turkiska e-förvaltningsportaler, bankapplikationer och kassaflöden i e-handeln. Till exempel skulle ett offentligt organs onlineansökningsformulär som instruerar medborgare att "fylla i fälten markerade i rött" och skicka in genom att "trycka på knappen i det nedre högra hörnet" stå i direkt strid med 1.3.3 och utgöra ett brott mot presidentdekretet. På samma sätt skulle en banks mobila webbgränssnitt som vägleder användare genom flerstegstransaktioner enbart med positions- och färgsignaler behöva revideras före den tvååriga tidsfristen för den privata sektorn.

Bristande efterlevnad medför rykte- och rättsliga risker i takt med att Turkiets regleringsmiljö kring digital tillgänglighet mognar. Berörda aktörer bör se efterlevnad av 1.3.3 inte som en mindre redaktionell justering utan som en systematisk genomgång av all instruktionstext — inklusive hjälptester, felmeddelanden, onboarding-flöden och supportdokumentation — för att säkerställa att sensoriska referenser alltid åtföljs av stabila, programmatiska, textbaserade identifierare. Accsible:s overlay-SDK kan hjälpa till att identifiera och åtgärda många relaterade problem, men den manuella innehållsgranskning som krävs enligt 1.3.3 måste i slutändan utföras av en kvalificerad mänsklig granskare som arbetar tillsammans med automatiserade verktyg.