Standarder · WCAG 2.2

SC 4.1.2 Niveau A WCAG 2.0

Navn, rolle, værdi

Enhver UI-komponent skal programmatisk eksponere et navn, en rolle og — hvor relevant — en værdi og tilstand. Uden dette kan skærmlæsere, stemmestyring og kontaktkontrolenheder ikke identificere eller betjene kontrolelementet.

Hvad det kræver

Enhver interaktiv ting på siden — knapper, links, formularfelter, faner, skydere, brugerdefinerede widgets — skal eksponere tre oplysninger til hjælpeteknologi:

  • Navn — hvad hedder dette kontrolelement? („Send“, „Luk dialog“, „Lydstyrke“)
  • Rolle — hvilken type kontrolelement er det? (knap, link, afkrydsningsfelt, fane, skyder)
  • Værdi / tilstand — for komponenter, der har en: er den trykket, udvidet, afkrydset, valgt? Hvad er den aktuelle værdi?

Eksponeringen skal være programmatisk — angivet i DOM’en, ikke malet på med CSS. Skærmlæsere, brailledisplays, stemmestyringssoftware og kontaktscannere læser alle tilgængelighedstræet, ikke pixels.

Sådan opfyldes det

  • Brug det native HTML-element, når et sådant findes. <button> leveres med den rigtige rolle, fokus, tastaturhåndtering og et tilgængeligt navn fra sit tekstindhold — gratis.
  • For ikoner-kun-knapper: tilføj aria-label (eller visuelt skjult tekst). <button aria-label="Luk">×</button>.
  • For formularinput: knyt et <label for> til inputtets id. Eller pak inputtet ind i <label>. Pladsholdertekst er ikke en etiket.
  • Når du nødvendigvis skal bygge en brugerdefineret widget ud af <div> og <span>: tilføj role="…", administrer tabindex, håndter Enter og Space, og afspejl tilstand med aria-pressed, aria-expanded, aria-checked, aria-selected, aria-valuenow.
  • Kør den gengivne side gennem browserens tilgængelighedstræinspektor (Chrome DevTools → Elementer → Tilgængelighed) og læs hvert kontrolelement: alle skal annonceres som navn + rolle + tilstand.

Hyppige fejl

  • <div onclick="…"> stilet som en knap — ingen rolle, intet tastatur, intet navn. Skærmlæsere springer det over. Stemmestyring kan ikke sige „klik Gem“.
  • <div role="button"> uden tabindex="0", uden Enter/Space-handler — ser tilgængeligt ud, er det ikke.
  • Ikoner-kun-knapper (<button><svg /></button>) uden aria-label, aria-labelledby eller visuelt skjult tekst. Annonceres som bare „knap“.
  • Brugerdefinerede dropdowns bygget med <div> og JavaScript, der mangler role="combobox", aria-expanded, aria-controls og rollerne listbox/option underneden.
  • Skifteknapper (lydløs, favorit, følg), der ændrer tilstand visuelt, men aldrig opdaterer aria-pressed. Seende brugere ser ændringen; brugere af skærmlæser hører ingen forskel.
  • Formularinput med en visuel etiket ved siden af, men uden for/id-forbindelse eller indpakkende <label>.
  • Brugerdefinerede afkrydsningsfelter tegnet med <svg> og et skjult native input, der aldrig afspejler :checked i det synlige UI — skærmlæserens og den visuelle tilstand drifter fra hinanden.

Hvorfor det er vigtigt

Dette er det hyppigst citerede succeskriterium i specifikationen. Næsten enhver klage om „dette site er ubrugeligt med en skærmlæser“ kan føres tilbage til en 4.1.2-fejl et sted — typisk en <div> forklædt som en knap, eller en ikonknap uden navn. Det er også her, omkostningen ved at bygge brugerdefinerede widgets viser sig: ethvert native HTML-kontrolelement består allerede 4.1.2; enhver håndlavet <div>-widget skal tjene det linje for linje. Den hurtigste 4.1.2-audit er at navigere med Tab gennem siden med en skærmlæser og lytte — alt, der annonceres som „blank“ eller blot „knap“, er et fund.