WCAG 4.1.2: Namn, roll, värde

WCAG 4.1.2 kräver att alla användargränssnittskomponenter har ett programmatiskt fastställbart namn och en programmatiskt fastställbar roll, och att tillstånd, egenskaper och värden både kan läsas och ställas in av hjälpmedelstekniker. Detta säkerställer att skärmläsare och andra verktyg kan identifiera, beskriva och interagera korrekt med varje element på sidan.

Vad Denna Regel Innebär

WCAG 4.1.2 — Name, Role, Value är ett framgångskriterium på nivå A under principen Robust. Det kräver att följande tre saker är sanna för varje användargränssnittskomponent — inklusive formulärelement, knappar, länkar, anpassade widgets, ramar och interaktiva kontroller:

Namn: Varje komponent måste ha ett tillgängligt namn som hjälpmedelsteknik kan läsa upp eller visa via en punktskriftsskärm. Namnet kan komma från elementinnehåll (t.ex. texten inuti ett <button>), ett label-element, ett aria-label-attribut, en aria-labelledby-referens eller ett title-attribut.
Roll: Varje komponent måste ha en roll som förmedlar dess syfte till hjälpmedelsteknik. Inbyggda HTML-element har implicita roller (ett <button> har rollen button, ett <input type='checkbox'> har rollen checkbox). Anpassade widgets som byggs av generiska element som <div> eller <span> måste uttryckligen deklarera en roll med hjälp av ARIA-attributet role.
Värde (tillstånd och egenskaper): Alla aktuella tillstånd eller värden som är meningsfulla för användaren — om en kryssruta är markerad, om en disclosure-widget är expanderad, om ett fält är obligatoriskt — måste exponeras programmatiskt så att hjälpmedelsteknik kan rapportera dem och så att användare kan ändra dem där det är tillämpligt.

En komponent klarar detta kriterium när dess tillgängliga namn inte är tomt, dess roll är giltig och semantiskt lämplig, och alla relevanta tillstånd (såsom aria-checked, aria-expanded eller aria-required) är korrekt tillämpade och hålls synkroniserade med det visuella gränssnittet. En komponent underkänns när någon av dessa tre delar saknas, är felaktig eller inte är synkroniserad — till exempel en anpassad växlingsknapp som ändrar färg visuellt men aldrig uppdaterar sitt aria-pressed-tillstånd.

Det officiella WCAG-undantaget omfattar komponenter som avsiktligt inte exponeras för tillgänglighets-API:er — till exempel rent dekorativa element eller innehåll som döljs med aria-hidden='true'. Att dölja aktivt eller fokuserbart innehåll med aria-hidden (till exempel genom att tillämpa det på <body>-elementet) är dock i sig ett brott, eftersom det tar bort allt sidinnehåll från tillgänglighetsträdet.

Varför Det Är Viktigt

Enligt Världshälsoorganisationen har cirka 2,2 miljarder människor världen över någon form av synnedsättning. För blinda och synsvaga användare som förlitar sig på skärmläsare som JAWS, NVDA eller VoiceOver är det tillgängliga namnet och rollen för varje interaktiv komponent det primära — och ofta enda — sättet att förstå vad en kontroll gör och hur den används. Om en knapp saknar ett tillgängligt namn hör en skärmläsaranvändare bara ”button” utan någon indikation på dess syfte. Om en anpassad rullgardinsmeny saknar roll kan användaren inte skilja den från statisk text.

Motoriskt funktionsnedsatta användare som använder programvara via switch-styrning, röststyrningsverktyg som Dragon NaturallySpeaking eller tangentbordsnavigering är också beroende av detta kriterium. Röststyrningsprogramvara mappar talade kommandon (”click Submit”) till tillgängliga namn. Om det tillgängliga namnet på en knapp inte matchar dess synliga etikett misslyckas röstkommandon helt.

Kognitiv tillgänglighet är lika relevant. Konsekvent, förutsägbar märkning minskar kognitiv belastning för användare med dyslexi, minnesnedsättningar eller uppmärksamhetsrelaterade funktionsnedsättningar. När tillståndsändringar — såsom att en modal öppnas eller att ett formulärfält blir obligatoriskt — inte annonseras av hjälpmedelsteknik kan användare bli desorienterade och oförmögna att slutföra uppgifter.

Överväg ett konkret scenario från verkligheten: en turkisk e-handelsplattform visar en ”Add to Cart”-knapp byggd som en <div> med en klick-händelse och en kundvagnsikon. Visuellt ser den ut som en knapp. Men eftersom den saknar role='button', ett tillgängligt namn och tabindex='0', stöter en skärmläsaranvändare som navigerar med tangentbordet inte på någonting — elementet är fullständigt osynligt för deras hjälpmedelsteknik. De kan inte lägga produkter i sin kundvagn, vilket i praktiken utesluter dem från hela köpupplevelsen.

Utöver tillgänglighet förbättrar korrekt namngivna och strukturerade komponenter SEO eftersom sökmotorers crawlers förlitar sig på semantisk markup för att förstå sidstruktur och interaktiv avsikt. De förbättrar också testbarheten, eftersom automatiserade testverktyg mer tillförlitligt kan hitta och interagera med element som har meningsfulla roller och etiketter.

Relaterade Axe-core-regler

Följande axe-core-regler är direkt kopplade till WCAG 4.1.2. Var och en riktar in sig på en specifik kategori av fel relaterade till namn, roll eller värde:

aria-allowed-attr: Kontrollerar att ARIA-attribut som tillämpas på ett element är tillåtna för elementets roll. Att till exempel tillämpa aria-checked på ett element med role='link' är ogiltigt och flaggas, eftersom rollen link inte stöder aria-checked.
aria-command-name: Säkerställer att element med ARIA-kommandoroller (link, button, menuitem) har ett icke-tomt tillgängligt namn. En ikon-enbart-knapp utan etiketttext och utan aria-label skulle flaggas här.
aria-hidden-body: Flaggar det specifika fallet där aria-hidden='true' har tillämpats på <body>-elementet, vilket tar bort hela sidan från tillgänglighetsträdet och gör allt innehåll osynligt för skärmläsare.
aria-input-field-name: Kontrollerar att element med ARIA-inmatningsroller (textbox, searchbox, spinbutton, slider, combobox) har ett tillgängligt namn. Ett anpassat sökfält byggt med role='textbox' men utan etikett skulle flaggas.
aria-meter-name: Verifierar att element med role='meter' har ett tillgängligt namn, så att skärmläsaranvändare förstår vilken kvantitet mätaren visar (till exempel lagringsanvändning eller batterinivå).
aria-progressbar-name: Säkerställer att element med role='progressbar' har ett tillgängligt namn, så att användare vet vilken process eller vilket förlopp som pågår istället för att bara höra ”progress bar”.
aria-required-attr: Kontrollerar att element som använder en viss ARIA-roll inkluderar alla attribut som krävs av ARIA-specifikationen för den rollen. Till exempel kräver role='slider' aria-valuenow, aria-valuemin och aria-valuemax; att utelämna något av dessa flaggas.
aria-roles: Validerar att alla värden som tilldelas role-attributet är giltiga, icke-abstrakta ARIA-roller. Stavfel, påhittade roller eller abstrakta roller (som role='widget') som används direkt på element flaggas alla.
aria-tooltip-name: Kontrollerar att element med role='tooltip' har ett tillgängligt namn. Ett tomt tooltip-element ger inget värde för skärmläsaranvändare och representerar ett märkningsfel.
button-name: Verifierar att <button>-element och element med role='button' har ett icke-tomt tillgängligt namn. Detta fångar ikonknappar utan aria-label och tomma knappar som används som dekorativa triggers.
frame-title: Kräver att <iframe>- och <frame>-element har ett icke-tomt title-attribut som beskriver ramens innehåll. Utan detta kan skärmläsaranvändare inte avgöra syftet med det inbäddade innehållet och kanske inte vet om de ska gå in i eller hoppa över ramen.
input-button-name: Kontrollerar att <input>-element av typen submit, reset, button och image har ett tillgängligt namn — antingen via ett value-attribut eller, för bildinmatningar, ett alt-attribut.

Det är viktigt att notera att även om automatiserade verktyg fångar många fel relaterade till namn, roll och värde kräver vissa överträdelser manuell testning. Automatiska skannrar kan inte verifiera om ett tillgängligt namn är meningsfullt — en knapp märkt ”click here” klarar tekniskt sett den automatiska kontrollen för att ha ett namn, men misslyckas med att kommunicera sitt faktiska syfte. På samma sätt kan det bara bekräftas genom praktisk testning med skärmläsare om tillståndsändringar (som att aria-expanded växlar när en meny öppnas) annonseras korrekt under interaktion i realtid.

Hur Man Testar

Automatisk skanning med axe DevTools eller Lighthouse: Installera webbläsartillägget axe DevTools (Chrome eller Firefox) eller kör en Lighthouse-granskning i Chrome DevTools under fliken Accessibility. Aktivera skanning av hela sidan och filtrera resultaten efter taggen WCAG 4.1.2. Leta specifikt efter överträdelser av button-name, frame-title, aria-required-attr, aria-roles och aria-input-field-name. Varje träff innehåller det felande elementet, en beskrivning av felet och ett föreslaget åtgärdsförslag. Exportera resultaten och prioritera först poster med allvarlighetsgrad Critical och Serious.
Tangentbordsnavigeringstest: Koppla bort musen och navigera hela sidan med Tab-tangenten. Bekräfta att varje fokuserbart element får synlig fokus, att webbläsarens inbyggda fokusindikator (eller en anpassad) är tydligt synlig och att du kan aktivera alla kontroller med Enter eller mellanslag. Alla element du når som du inte kan identifiera enbart utifrån sammanhang — utan att titta på skärmen — indikerar sannolikt ett fel i det tillgängliga namnet.
Testning med skärmläsaren NVDA och Firefox: Öppna NVDA (Windows, gratis), starta Firefox och navigera på sidan med Tab för att gå igenom interaktiva element och NVDA Elements List (Insert+F7) för att bläddra bland alla knappar, länkar och formulärfält. Lyssna på vad NVDA annonserar för varje interaktivt element. Den ska läsa upp elementets namn, roll och relevanta tillstånd (t.ex. ”Subscribe, button” eller ”Email address, required, edit text”). Flagga alla element som annonseras utan namn eller med felaktig roll.
Testning med skärmläsaren VoiceOver och Safari (macOS/iOS): Aktivera VoiceOver (Command+F5 på macOS), öppna Safari och använd VO+Högerpil för att navigera mellan element. Använd VoiceOver Rotor (VO+U) för att lista alla formulärkontroller och knappar. Verifiera att namn är beskrivande, roller är lämpliga och att tillstånd uppdateras dynamiskt när du interagerar (till exempel ska växling av ett anpassat dragspel göra att VoiceOver annonserar ”expanded” eller ”collapsed”).
Testning med skärmläsaren JAWS och Chrome: Starta JAWS och öppna Chrome. Använd Tab-tangenten för att navigera mellan interaktiva element och JAWS Virtual Cursor (Insert+F3 för en lista över formulärfält) för att granska etiketter. Var särskilt uppmärksam på anpassade widgets byggda med ARIA — bekräfta att tillståndsändringar som utlöses av tangentbordsinteraktion återspeglas i vad JAWS annonserar i realtid.
Verifiering av tillstånd för anpassade widgets: För alla anpassade widgets (dragspel, flikpanel, combobox, modal), interagera fullt ut med dem enbart med tangentbordet. Verifiera vid varje steg att skärmläsaren annonserar korrekt tillståndsuppdatering — till exempel ska öppning av en disclosure-widget utlösa en annonsering av ”expanded”, och stängning ska annonsera ”collapsed”. Om det visuella tillståndet ändras men skärmläsaren är tyst saknas aria-expanded eller så växlas det inte programmatiskt.

Hur Man Åtgärdar

Endast ikon-knapp utan tillgängligt namn — Felaktig

<!-- Icon button with no accessible name: screen readers announce only "button" -->
<button>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

Endast ikon-knapp utan tillgängligt namn — Korrekt

<!-- aria-label provides the accessible name when no visible text is present -->
<button aria-label='Search'>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

Anpassad växlingswidget utan roll eller tillstånd — Felaktig

<!-- A div used as a toggle: no role, no state, not keyboard accessible -->
<div class='toggle' onclick='toggleDarkMode()'>
  Dark Mode
</div>

Anpassad växlingswidget utan roll eller tillstånd — Korrekt

<!-- role='switch' communicates purpose; aria-checked reflects current state;
     tabindex='0' makes it keyboard reachable; keydown handler enables Space/Enter -->
<div
  role='switch'
  aria-checked='false'
  tabindex='0'
  onclick='toggleDarkMode(this)'
  onkeydown='if(event.key==="Enter"||event.key===" "){toggleDarkMode(this);event.preventDefault();}'
>
  Dark Mode
</div>

<script>
function toggleDarkMode(el) {
  const isOn = el.getAttribute('aria-checked') === 'true';
  el.setAttribute('aria-checked', String(!isOn));
  document.body.classList.toggle('dark-mode', !isOn);
}
</script>

Omarkerad iframe — Felaktig

<!-- iframe with no title: screen reader users cannot determine what is inside -->
<iframe src='https://maps.example.com/embed?q=istanbul'></iframe>

Omarkerad iframe — Korrekt

<!-- title describes the frame's content so users can decide whether to enter it -->
<iframe
  src='https://maps.example.com/embed?q=istanbul'
  title='Interactive map showing our Istanbul office location'
></iframe>

Anpassad förloppsindikator utan nödvändiga ARIA-attribut — Felaktig

<!-- role='progressbar' without aria-valuenow, aria-valuemin, aria-valuemax:
     screen readers cannot determine the current progress -->
<div role='progressbar' style='width:60%'></div>

Anpassad förloppsindikator utan nödvändiga ARIA-attribut — Korrekt

<!-- All required attributes present; aria-label provides the accessible name -->
<div
  role='progressbar'
  aria-valuenow='60'
  aria-valuemin='0'
  aria-valuemax='100'
  aria-label='File upload progress'
>
  60%
</div>

Vanliga Misstag

Att använda role='button' på en <div> utan att lägga till tabindex='0' — elementet annonseras som en knapp av skärmläsare men förblir onåbart via tangentbordets Tab-navigering, vilket gör det oanvändbart för användare som enbart använder tangentbord.
Att tillämpa aria-label på ett icke-interaktivt element — att lägga till aria-label på en <div> eller <span> utan roll har ingen effekt; etiketten ignoreras av de flesta webbläsare eftersom elementet saknar roll som den kan namnge.
Att lämna aria-expanded statiskt efter att ha implementerat en disclosure-widget — att sätta aria-expanded='false' i HTML och aldrig växla det med JavaScript innebär att attributet alltid är fel efter första klicket och annonserar motsatt tillstånd för skärmläsaranvändare.
Att använda aria-hidden='true' på en behållare som innehåller fokuserbara element — detta döljer behållaren från tillgänglighetsträdet men inte från tangentbordsfokus, så skärmläsaranvändare kan tabba in i element de inte kan höra, vilket orsakar extrem förvirring.
Att använda en placeholder som den enda etiketten för ett <input> — placeholder-text försvinner vid inmatning, annonseras inte tillförlitligt som etikett av alla skärmläsare och uppfyller inte kravet på tillgängligt namn för formulärfält.
Att använda en ogiltig eller abstrakt ARIA-roll som role='widget' eller role='structure' — dessa är basroller i ARIA-specifikationen och är inte avsedda att användas direkt; de ger ingen meningsfull semantisk information och kan ignoreras eller orsaka fel i hjälpmedelsteknik.
Att referera till ett icke-existerande element-ID i aria-labelledby — om ID:t som pekas ut av aria-labelledby inte finns i DOM:en misslyckas beräkningen av det tillgängliga namnet och elementet lämnas utan namn.
Att använda value istället för aria-label för <input type='image'> — bildinmatningsknappar kräver ett alt-attribut för sitt tillgängliga namn; value-attributet ignoreras vid namnbestämning för bildinmatningar.
Att utelämna title-attributet på <iframe>-element som laddar tredjepartsinnehåll — utvecklare antar ofta att välkända inbäddningar (kartor, betalwidgets, videospelare) är självbeskrivande, men skärmläsaranvändare måste få veta ramens syfte innan de kan avgöra om de ska gå in i den.
Att glömma att uppdatera tillgängliga namn dynamiskt när innehåll ändras — om en knapps etikett ändras visuellt från ”Play” till ”Pause” men aria-label förblir ”Play” får skärmläsaranvändare felaktig information om aktuellt tillstånd och åtgärd.

Relation till Turkiets Tillgänglighetsreglering

Turkiets Presidential Circular 2025/10, publicerad i Official Gazette nr 32933 den 21 juni 2025, fastställer obligatoriska krav på digital tillgänglighet i linje med WCAG 2.2. WCAG 4.1.2 — Name, Role, Value är ett kriterium på nivå A, vilket innebär att det ligger på den mest grundläggande nivån av överensstämmelse. Enligt cirkuläret är överensstämmelse på nivå A inte valfri — det är den basnivå som alla omfattade aktörer måste uppnå.

Cirkuläret gäller för ett brett spektrum av aktörstyper som är verksamma i Turkiet. Offentliga institutioner — inklusive ministerier, kommuner och statliga myndigheter — måste uppnå överensstämmelse inom ett år från cirkulärets publiceringsdatum. Privata aktörer — inklusive e-handelsplattformar, banker och finansiella institutioner, sjukhus och privata vårdgivare, telekommunikationsföretag med 200,000 eller fler abonnenter, resebyråer, privata transportföretag och privatskolor auktoriserade av Ministry of National Education (MoNE) — måste uppnå överensstämmelse inom två år.

WCAG 4.1.2 är särskilt betydelsefull för turkiska organisationer eftersom så många moderna turkiska webbplatser förlitar sig på specialbyggda interaktiva komponenter — produktkaruseller, FAQ-dragspel, stegvisa checkout-flöden och bankdashboards — som ofta implementeras utan korrekta ARIA-roller, namn eller tillståndshantering. En anpassad checkout-knapp som saknar tillgängligt namn, eller en lånekalkylatorslider som saknar aria-valuenow, är inte bara en dålig användarupplevelse: enligt cirkuläret utgör det ett juridiskt övertramp mot efterlevnadskraven.

För banker och e-handelsplattformar som omfattas av cirkuläret är WCAG 4.1.2-överträdelser i transaktionskritiska flöden — betalningsformulär, autentiseringsmodals, kontodashboards — särskilt riskfyllda. En visuellt stylad anpassad combobox för att välja bankkontor som saknar korrekt ARIA-markup kan helt hindra en skärmläsaranvändare från att slutföra en transaktion, vilket utsätter institutionen för både tillsynsåtgärder och diskrimineringsanspråk.

Organisationer som använder Accsible overlay SDK kan dra nytta av automatiserad upptäckt och åtgärd i realtid av många Name, Role, Value-överträdelser — inklusive att injicera saknade tillgängliga namn, korrigera ogiltiga ARIA-roller på kända widgetmönster och synkronisera tillståndsattribut på interaktiva komponenter. Organisationer bör dock se automatiserat overlay-stöd som ett komplement till, inte en ersättning för, korrekt semantisk HTML-utveckling, särskilt för komplexa anpassade widgets där programmatisk tillståndshantering måste byggas in i applikationslogiken från början.

Källor och referenser

Relaterade artiklar

AWCAG 1.1.1: Icke-textinnehåll AWCAG 1.2.1: Endast ljud och endast video (förinspelat)AWCAG 1.2.2: Textning (förinspelat)