WCAG 3.2.4: Konsekvent identifiering

Vad den här regeln innebär

WCAG:s framgångskriterium 3.2.4 — Konsekvent identifiering — anger att komponenter som har samma funktion inom en uppsättning webbsidor måste identifieras konsekvent. Detta innebär att när ett interaktivt element eller en bild utför samma funktion, ska det ha samma tillgängliga namn eller etikett varje gång det förekommer på webbplatsen.

Termen ”identifieras” i detta sammanhang syftar på hur en komponent presenteras för hjälpmedelstekniker och användare. Detta inkluderar den synliga etiketttexten, attributen aria-label eller aria-labelledby, alt-texten på en bild, attributet title eller det tillgängliga namn som beräknas av webbläsarens tillgänglighetsträd. Om en sökknapp visas på varje sida på en webbplats måste den alltid kallas ”Search” — inte ”Search” på startsidan, ”Find” på produktsidan och ”Go” på kassasidan.

Detta kriterium gäller för en uppsättning webbsidor, vilket WCAG definierar som en samling sidor som delar ett gemensamt syfte och produceras av samma upphovsperson. Detta omfattar en hel webbplats, en webbapplikation eller ett flerstegsformulär som sträcker sig över flera URL:er. Komponenter som bara är visuellt lika men tjänar olika funktioner behöver inte ha samma namn — kravet är specifikt kopplat till identisk funktionalitet.

Vad som räknas som godkänt: En navigationsikon som öppnar en hamburgermeny är konsekvent märkt ”Open navigation menu” (eller motsvarande) på alla sidor. En kundvagnsikon har alltid alt-texten eller det tillgängliga namnet ”Shopping cart”. En utloggningsknapp är alltid märkt ”Log out”. Variation i formulering för samma funktion utgör ett fel.

Vad som räknas som underkänt: En skicka-knapp märkt ”Submit” i registreringsformuläret men märkt ”Send” i kontaktformuläret när båda knapparna har samma funktionella syfte att skicka användarens inmatade data. En ikonknapp med ett förstoringsglas märkt ”Search” på de flesta sidor men ”Ara” på en enskild översatt undersida utan en konsekvent språkstrategi.

Officiellt undantag: WCAG anger uttryckligen att det är acceptabelt att ha två komponenter med samma tillgängliga namn om de utför olika funktioner — i så fall är den olika funktionen i sig tillräcklig för att skilja dem åt. Kriteriet utlöses bara när funktionen är identisk men namngivningen är inkonsekvent.

Varför det är viktigt

Inkonsekvent identifiering skapar en oproportionerlig börda för användare som förlitar sig på icke-visuell eller mönsterbaserad navigering. De grupper som drabbas hårdast inkluderar skärmläsaranvändare, användare med kognitiva funktionsnedsättningar och användare med motoriska funktionsnedsättningar som använder röststyrningsprogram.

Skärmläsaranvändare bygger upp en mental modell av en webbplats genom att lyssna på elementnamn när de tabbar sig fram eller bläddrar efter landmärken. När en knapp som utförde samma funktion på föregående sida nu har ett annat namn, måste användaren stanna upp, undersöka och orientera om sig — en tidskrävande och frustrerande upplevelse. Enligt Världshälsoorganisationen har cirka 2,2 miljarder människor globalt någon form av synnedsättning. Även om bara en bråkdel av den populationen interagerar med en inkonsekvent märkt webbplats kommer de att möta betydande hinder.

Användare med kognitiva funktionsnedsättningar, inklusive personer med dyslexi, uppmärksamhetsstörningar eller minnesnedsättningar, är starkt beroende av förutsägbar namngivning för att minska den kognitiva belastningen. Att möta en välbekant ikon eller kontroll under ett annat namn tvingar fram inlärning på nytt och orsakar oro. Konsekvent märkning minskar ansträngningen som krävs för att bygga upp procedurminne vid regelbunden användning av en webbplats.

Röststyrningsanvändare (som använder verktyg som Dragon NaturallySpeaking eller Apples Voice Control) uttalar namnet på en kontroll för att aktivera den. Om det tillgängliga namnet på en knapp skiljer sig från vad de förväntar sig baserat på tidigare erfarenheter av webbplatsen, kommer deras talade kommando att misslyckas tyst — programvaran hittar helt enkelt ingen matchning. Detta gör gränssnittet i praktiken oanvändbart i det ögonblicket.

Ett konkret scenario från verkligheten: Tänk dig en turkisk e-handelsplattform som säljer kläder. På produktsidan med rutnät har varje artikel en knapp med en hjärtikon vars tillgängliga namn är ”Add to favourites”. På produktsidan med detaljer är samma hjärtikons tillgängliga namn ”Kaydet” (turkiska för ”Spara”). En skärmläsaranvändare som lärt sig att aktivera hjärtknappen med namn på rutnätssidan kan nu inte hitta motsvarande kontroll på detaljsidan utan omfattande utforskning. De kan överge webbplatsen helt.

Utöver tillgänglighet gynnar konsekvent märkning SEO. Sökmotorer tolkar tillgängliga namn och länktexter för att förstå sidinnehåll. Inkonsekvent märkning för funktionellt identiska länkar (t.ex. ”Read more”, ”Continue reading”, ”Learn more” som alla leder till artikeldetaljsidor) försvagar nyckelordssignaler och gör det svårare för sökrobotar att förstå webbplatsens struktur.

Relaterade Axe-core-regler

WCAG 3.2.4 kräver manuell testning eftersom automatiserade verktyg inte kan avgöra semantiskt syfte över flera sidor eller veta att två komponenter med olika namn utför samma funktion. Ingen axe-core-regel motsvarar direkt detta kriterium. Här är varför automatisering inte räcker och vad testare måste göra i stället:

• Manuell testning krävs — konsekvens mellan sidor: Axe-core utvärderar en enskild sida isolerat. Det har ingen mekanism för att jämföra det tillgängliga namnet på en ”Search”-knapp på startsidan med en ”Find”-knapp på en produktsida, eftersom det inte upprätthåller ett sidöverskridande register över komponentnamn. En mänsklig testare måste katalogisera återkommande funktionella element och verifiera att deras namngivning är enhetlig på alla sidor där de förekommer.
• Manuell testning krävs — konsekvent alt-text för ikoner och bilder: Automatiserade verktyg kan upptäcka saknad alt-text (via regeln image-alt) men kan inte avgöra om två bilder som tjänar samma syfte har samma alt-text på olika sidor. Till exempel kan en skrivarikons på en kvittosida och samma skrivarikons på en fakturasida båda ha alt-text — men om den ena lyder ”Print” och den andra ”Print this page” måste en människa bedöma om detta utgör en inkonsekvens enligt 3.2.4.
• Manuell testning krävs — konsekventa ARIA-etiketter: Axe-core kontrollerar att ARIA-etiketter finns och inte är tomma, men granskar inte om aria-label-värden för samma komponenttyp är konsekventa över hela uppsättningen sidor. En testare måste inspektera tillgänglighetsträdet på flera sidor och jämföra namn för funktionellt identiska kontroller.
• Manuell testning krävs — formulärkontrolletiketter: Automatiska regler som label verifierar att inmatningsfält är kopplade till etiketter, men de kontrollerar inte om ett ”Username”-fält på inloggningssidan också är märkt ”Username” (snarare än ”Email” eller ”User ID”) på sidan för kontorecovery när båda fälten accepterar samma typ av indata och har samma funktionella roll.

Hur man testar

1. Automatisk förskanning: Kör axe DevTools eller Lighthouse på varje sida för att identifiera relaterade överträdelser som saknade tillgängliga namn (image-alt, button-name, link-name). Åtgärda dessa först — du kan inte bedöma namngivningskonsekvens om namn saknas. Notera de tillgängliga namn som rapporteras för återkommande komponenter i dina skanningsresultat.
2. Skapa en komponentinventering: Lista manuellt alla funktionella komponenter som återkommer på flera sidor — navigationsmenyer, sökfält, skicka-knappar, ikonknappar, brödsmulslänkar, länkar till sociala medier, skriv-/dela-knappar och pagineringskontroller. Registrera det tillgängliga namnet för varje instans med hjälp av webbläsarens panel för tillgänglighet (Chrome DevTools > Elements > Accessibility eller Firefox Accessibility Inspector).
3. Jämför namn mellan sidor: För varje komponenttyp i din inventering, verifiera att varje instans har samma tillgängliga namn. Flagga alla avvikelser. Var särskilt uppmärksam på komponenter som visas i sidhuvuden, sidfötter och sidopaneler, eftersom dessa oftast är inkonsekvent märkta mellan olika mallar.
4. Skärmläsartestning med NVDA + Firefox: Navigera till startsidan och använd sedan NVDAs elementlista (Insert + F7) för att öppna listan över knappar och länkar. Notera namnen på återkommande kontroller. Navigera sedan till tre eller fyra andra representativa sidor och upprepa. Lyssna efter variationer i namn på funktionellt identiska kontroller.
5. Skärmläsartestning med VoiceOver + Safari (macOS/iOS): Använd Rotor (VO + U) för att visa listan över knappar eller länkar på varje sida. Jämför namnen på återkommande element. På iOS, svep genom interaktiva element på motsvarande sidor och notera eventuella skillnader i namngivning.
6. Skärmläsartestning med JAWS + Chrome: Använd JAWS virtuella markör och listan över formulärfält (Insert + F5) och länkar (Insert + F7) på flera sidor. Bekräfta att identiska kontroller har identiska namn på hela webbplatsen.
7. Röststyrningstest: Använd Windows Voice Access eller Dragon NaturallySpeaking och uttala namnet på en återkommande kontroll på en sida (t.ex. ”Click Search”). Navigera till en annan sida och uttala samma kommando. Om det misslyckas är namnen inkonsekventa ur ett funktionellt perspektiv.

Hur man åtgärdar

Sökknapp med inkonsekventa etiketter — Felaktigt

<!-- Homepage -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Product listing page -->
<button type='submit' aria-label='Find products'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Blog page -->
<button type='submit' aria-label='Go'>
  <svg aria-hidden='true'>...</svg>
</button>

Sökknapp med inkonsekventa etiketter — Korrekt

<!-- Homepage, product listing page, and blog page all use the same label -->
<!-- Consistent aria-label across all pages ensures assistive technologies
     always announce the same name for this functionally identical button -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

Ikonbild som används för samma åtgärd med olika alt-text — Felaktigt

<!-- Order history page -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print order' />
</a>

<!-- Invoice page -->
<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print this document' />
</a>

<!-- Receipt page -->
<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Yazdir' />
</a>

Ikonbild som används för samma åtgärd med olika alt-text — Korrekt

<!-- All print links across the site share the same alt text.
     The destination URL differentiates which document is printed;
     the control's accessible name remains consistent. -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Print' />
</a>

Stängknapp för navigation inkonsekvent namngiven — Felaktigt

<!-- Mobile menu on homepage -->
<button aria-label='Close menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Mobile menu on product page (different developer implemented it) -->
<button aria-label='Dismiss navigation' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Stängknapp för navigation inkonsekvent namngiven — Korrekt

<!-- A shared component/template ensures the label is identical everywhere.
     Using a single reusable component or design token for the label
     eliminates the risk of developer-introduced inconsistencies. -->
<button aria-label='Close navigation menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Länkar för delning i sociala medier med varierande namn — Felaktigt

<!-- Article page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

<!-- Video page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Tweet this'>
  <svg aria-hidden='true'>...</svg>
</a>

Länkar för delning i sociala medier med varierande namn — Korrekt

<!-- Both pages use the same accessible name for the functionally
     identical sharing action. The URL parameter carries the context;
     the control name stays uniform. -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

Vanliga misstag

• Att använda olika aria-label-värden i olika mallar för samma komponent: När olika utvecklare bygger sidmallar oberoende av varandra utan ett gemensamt komponentbibliotek får ikonknappar som stäng, sök och kundvagn ofta ad hoc-etiketter. Etablera en designsystem-token eller en delad komponent för varje återkommande interaktivt element så att det tillgängliga namnet definieras en gång och återanvänds överallt.
• Att översätta tillgängliga namn inkonsekvent på flerspråkiga sidor: En webbplats kan korrekt märka en sökknapp ”Search” på engelska men sedan använda en inkonsekvent turkisk motsvarighet — ibland ”Ara”, ibland ”Arama Yap” — beroende på vilken sidmall som lokaliserades först. Behåll en enda översättningsnyckel per komponentetikett och tillämpa den i alla språkfiler.
• Att lägga till kontextspecifika suffix till i övrigt identiska kontroller: Att märka knappar ”Add to cart — Blue T-Shirt”, ”Add to cart — Red Dress” etc. när kärnfunktionen (lägg i kundvagn) är densamma är inte automatiskt ett brott mot 3.2.4 — WCAG tillåter förtydligande — men att göra detta inkonsekvent (ibland med suffix, ibland utan) skapar förvirring. Välj ett mönster och tillämpa det konsekvent.
• Att förlita sig på den synliga textetiketten för konsekvens medan aria-label-överskrivningar skiljer sig åt: När en knapp visuellt visar ”Search” men en mall lägger till aria-label='Search the site' och en annan inte har något aria-label (så att det tillgängliga namnet härleds enbart från den synliga texten), kommer skärmläsare att läsa upp olika namn även om knappen ser likadan ut. Granska hela beräkningen av det tillgängliga namnet, inte bara den synliga etiketten.
• Att låta CMS-redaktörer fritt ändra knapptexter utan styrning kring tillgänglighet: Innehållshanteringssystem som exponerar knappetiketter som redigerbara fält gör det möjligt för redaktörer att byta ”Submit” mot ”Send” eller ”Gönder” baserat på personlig preferens. Begränsa möjligheten att redigera etiketter för funktionella UI-komponenter eller lägg till validering som varnar redaktörer när en föreslagen etikett avviker från den etablerade standarden.
• Att inte granska tredjepartswidgets eller inbäddade komponenter: Chattwidgets, samtyckesbanners för cookies och betalnings-iframes som injiceras av tredje part innehåller ofta knappar som är märkta på ett annat sätt än värdwebbplatsens konventioner. Granska och, där det är möjligt, konfigurera tredjeparts tillgängliga namn så att de stämmer överens med dina namngivningskonventioner, eller dokumentera avvikelsen som ett känt undantag.
• Att använda tooltip-text (title-attributet) som det enda tillgängliga namnet i vissa instanser men aria-label i andra: Attributet title läses inte upp pålitligt av alla hjälpmedelstekniker och betraktas som en svag källa för tillgängliga namn. Om vissa instanser av en återkommande komponent använder title och andra använder aria-label kan de beräknade namnen skilja sig åt på grund av skillnader i hur webbläsare och skärmläsare hanterar dem.
• Att anta att pagineringskontroller är undantagna eftersom deras nummer skiljer sig åt: Kontrollerna ”Next page” och ”Previous page”, även när de innehåller ett sidnummer i etiketten (t.ex. ”Go to page 3”), måste följa ett konsekvent mönster. Att blanda ”Next” på vissa sidor med ”Next page” eller ”İleri” på andra för samma pagineringskontroll bryter mot 3.2.4.
• Att inte testa sidhuvuds- och sidfotskomponenter i varje distinkt sidmall: Webbplatser har ofta flera sidmallar (startsida, kategorisida, artikelsida, kassa). Sidhuvuds- och sidfotskomponenter kan återges något olika i olika mallar. Testare som bara kontrollerar en eller två mallar kan missa inkonsekvenser som introducerats genom mallspecifika överskrivningar.
• Att förväxla 3.2.4 med 3.2.3 (Konsekvent navigering): Team tror ibland att om navigeringsordningen är konsekvent (3.2.3) måste namngivningen också vara det — men detta är separata krav. En navigationsrad på samma plats på varje sida (överensstämmelse med 3.2.3) kan fortfarande bryta mot 3.2.4 om dess länkar är märkta olika på olika sidor. Hantera båda kriterierna uttryckligen i er QA-process.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentdekret 2025/10, publicerat i den officiella tidningen nr 32933 den 21 juni 2025, fastställer bindande tillgänglighetskrav för ett brett spektrum av offentliga och privata digitala tjänster. Dekretet kräver överensstämmelse med internationellt erkända tillgänglighetsstandarder — i praktiken i linje med WCAG 2.2 nivå AA — och kopplar denna överensstämmelse till tillgänglighetslogotypen (Erişilebilirlik Logosu) som utfärdas av familje- och socialministeriet (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 3.2.4 Konsekvent identifiering är ett kriterium på nivå AA, vilket innebär att det är ett obligatoriskt krav — inte en rådgivande rekommendation — för organisationer som vill erhålla eller behålla Erişilebilirlik Logosu. Underlåtenhet att implementera konsekvent identifiering i en digital tjänst kommer att förhindra full överensstämmelse med nivå AA och därmed berättigande till logotypen.

Dekretet omfattar uttryckligen följande typer av aktörer, som alla måste hantera WCAG 3.2.4 i sina webb- och mobilgränssnitt: offentliga institutioner och myndigheter; banker och finansiella tjänsteleverantörer; sjukhus och vårdplattformar; teleoperatörer med 200,000 eller fler abonnenter; e-handelsplattformar; resebyråer och bokningstjänster; privata transportföretag; och privatskolor som auktoriserats av utbildningsministeriet (Milli Eğitim Bakanlığı).

För dessa organisationer är den praktiska konsekvensen betydande. Stora institutionella webbplatser — såsom en banks internetbankportal, ett sjukhus bokningssystem för tider eller ett universitets studentinformationssystem — omfattar vanligtvis hundratals sidor och byggs av flera utvecklingsteam under många år. Inkonsekvent märkning av återkommande kontroller (knappar för kontoåtgärder, sökfält, navigationsikoner) på dessa sidor är ett vanligt och lätt förbisett fel. Efterlevnadsprogram måste inkludera sidöverskridande konsekvensgranskningar som en särskild testfas, inte bara automatiska skanningar av enskilda sidor.

Turkiska organisationer som eftersträvar Erişilebilirlik Logosu bör integrera kontroller av WCAG 3.2.4 i sin styrning av designsystem, arbetsflöden för innehållshantering och QA-processer. Särskilt bör varje återanvändbar UI-komponent ha sitt tillgängliga namn definierat som en icke-redigerbar konstant på designsystemnivå, med översättningsnycklar som hanteras centralt för att säkerställa att turkiska och andra språkvarianter förblir konsekventa på alla sidor och i alla mallar där komponenten förekommer.