En utviklerveiledning til ARIA-etiketter som faktisk hjelper

ARIA-etiketter er for navn, ikke unnskyldninger

ARIA er nyttig, men brukes ofte som en lapp på uklart HTML. Det er der team får problemer.

Det vanligste eksempelet er aria-label. Det virker harmløst: legg til en tekststreng, tilfredsstill en linter, gå videre. Men et tilgjengelig navn er ikke pynt. Det er navnet mange hjelpemiddelteknologier viser til brukere når de navigerer etter knapper, lenker, skjemafelt, overskrifter, landemerker og kontroller.

Hvis navnet er vagt, duplisert, utdatert eller forskjellig fra den synlige etiketten, blir grensesnittet vanskeligere å bruke. Noen ganger verre: aria-label kan overstyre bedre tekst som allerede finnes i DOM-en.

Målet er ikke å legge til mer ARIA. Målet er å gjøre navn, rolle, tilstand og formål for hvert grensesnittelement tydelig.

Det tilgjengelige navnet, på vanlig norsk

De fleste interaktive elementer har et tilgjengelig navn. Skjermlesere bruker dette navnet til å kunngjøre hva elementet er.

For eksempel:

<button>Save changes</button>

En skjermleser kan kunngjøre noe slikt som: «Save changes, button.» Rollen kommer fra det innebygde button-elementet. Navnet kommer fra teksten inni det.

Det er idealsituasjonen: synlig tekst og tilgjengelig navn samsvarer.

ARIA-attributter for etiketter blir nyttige når det synlige grensesnittet ikke gir et fullstendig navn, eller når navnet må komme fra et annet element. Hovedattributtene er:

• aria-label: gir en tekststreng direkte på elementet.
• aria-labelledby: peker til ett eller flere elementer hvis tekst blir navnet.
• aria-describedby: peker til støttende beskrivelsestekst, ikke hovednavnet.

Disse tre henger sammen, men kan ikke brukes om hverandre.

Første regel: foretrekk innebygd HTML og synlige etiketter

Hvis du kan plassere synlig tekst på kontrollen, gjør det først.

Dette er bedre:

<button>Delete invoice</button>

Enn dette:

<button aria-label="Delete invoice">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Det andre mønsteret er gyldig for en knapp som bare består av et ikon. Men hvis designet tåler synlig tekst, hjelper synlig tekst alle: skjermleserbrukere, brukere av talegjenkjenning, personer med høy kognitiv belastning, personer som skanner raskt, og personer som bruker oversettelsesverktøy.

Dette er et tilbakevendende tema i tilgjengelighetsarbeid. Innebygd HTML og synlige handlingssignaler løser flere problemer enn skjulte metadata. Det samme prinsippet gjelder knappesemantikk mer generelt; hvis teamet ditt reviderer UI-kontroller, er vår sjekkliste for tilgjengelige webknapper et godt supplement til denne veiledningen.

Når aria-label er riktig verktøy

Bruk aria-label når et element trenger et tilgjengelig navn og det ikke finnes egnet synlig tekst å referere til.

Det klassiske tilfellet er en knapp som bare består av et ikon:

<button aria-label="Search">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
    <!-- icon -->
  </svg>
</button>

Dette er fornuftig. Det synlige ikonet antyder søk, men selve SVG-banen gir ikke et pålitelig navn. aria-label leverer et.

Andre gode tilfeller inkluderer:

• En lukkeknapp som bare er representert med en «X».
• Et navigasjonslandemerke som trenger et mer spesifikt navn, for eksempel aria-label="Product".
• En gjentatt kontroll der synlig kontekst ikke er en del av knappeteksten.

For eksempel:

<nav aria-label="Primary">
  ...
</nav>

<nav aria-label="Footer">
  ...
</nav>

Begge er navigasjonslandemerker, men etikettene hjelper brukere å skille dem fra hverandre når de beveger seg etter landemerker.

Når aria-label er feil verktøy

Ikke legg til aria-label bare fordi en test sier at et element trenger en etikett. Rett opp markupen først.

Dårlig:

<div role="button" tabindex="0" aria-label="Submit">Submit</div>

Bedre:

<button>Submit</button>

Det første eksempelet skaper unødvendig arbeid. Nå må du gjenskape tastaturatferd, deaktiverte tilstander, skjemaatferd og forventninger som innebygde knapper allerede gir.

Unngå også å bruke aria-label til å gi synlig tekst et nytt navn på en måte som endrer betydningen.

<button aria-label="Delete invoice">Remove</button>

Dette ser lite ut, men det kan forvirre brukere som er avhengige av taleinndata. Hvis en synlig knapp sier «Remove», men det tilgjengelige navnet er «Delete invoice», kan det hende at en bruker som prøver å si «click Remove», ikke får forventet resultat. WCAGs krav om «label in name» finnes nettopp av denne grunnen: synlig tekst bør vanligvis være inkludert i det tilgjengelige navnet.

En bedre versjon:

<button aria-label="Remove invoice">Remove</button>

Ofte enda bedre:

<button>Remove invoice</button>

Bruk aria-labelledby når synlig tekst allerede finnes

Hvis etiketteksten allerede finnes på siden, er aria-labelledby som regel bedre enn aria-label.

Eksempel:

<h2 id="billing-title">Billing address</h2>
<section aria-labelledby="billing-title">
  ...
</section>

Seksjonens tilgjengelige navn kommer nå fra den synlige overskriften. Du unngår å duplisere tekststrenger, noe som reduserer oversettelsesfeil og utdaterte etiketter.

Dette er spesielt nyttig for skjemagrupper:

<fieldset aria-labelledby="shipping-speed-title">
  <legend id="shipping-speed-title">Shipping speed</legend>

  <label>
    <input type="radio" name="shipping" value="standard">
    Standard
  </label>

  <label>
    <input type="radio" name="shipping" value="express">
    Express
  </label>
</fieldset>

I mange tilfeller er den innebygde legend nok uten ARIA. Poenget er at synlige etiketter bør lede an. ARIA bør koble sammen eksisterende mening, ikke skape en egen privat versjon av den.

Bruk aria-describedby for hjelpetekst, ikke navnet

En beskrivelse er ikke en etikett.

Tenk på dette feltet:

<label for="password">Password</label>
<input id="password" type="password" aria-describedby="password-help">
<p id="password-help">Use at least 12 characters.</p>

Det tilgjengelige navnet er «Password». Beskrivelsen er «Use at least 12 characters.» En skjermleser kan kunngjøre begge, men de tjener ulike formål.

Ikke gjør dette:

<input type="password" aria-label="Use at least 12 characters">

Da får feltet navn etter instruksjonen, ikke etter konseptet. En bruker som navigerer i et skjema, vil først vite hva feltet er, og deretter hvilke begrensninger som gjelder.

Dette skillet er også viktig i feiltilstander:

<label for="email">Email</label>
<input
  id="email"
  type="email"
  aria-invalid="true"
  aria-describedby="email-error"
>
<p id="email-error">Enter an email address in the format [email protected].</p>

Etiketten forblir stabil. Feilmeldingen blir støttende kontekst.

Gjentatte kontroller trenger unike navn

Lister og kort er steder der ARIA-etiketter ofte blir nødvendige.

Dårlig:

<button>Delete</button>
<button>Delete</button>
<button>Delete</button>

En skjermleserbruker som navigerer etter knapper, kan høre «Delete, button» tre ganger uten kontekst.

Bra:

<button aria-label="Delete report: Q4 revenue">Delete</button>
<button aria-label="Delete report: Hiring plan">Delete</button>
<button aria-label="Delete report: Vendor list">Delete</button>

Dette er en legitim bruk av aria-label: den synlige teksten forblir kort, mens det tilgjengelige navnet inkluderer objektet.

Men bruk dette mønsteret med forsiktighet. Hvis objektnavnet er synlig i nærheten, kan aria-labelledby være mer vedlikeholdbart:

<article>
  <h3 id="report-q4">Q4 revenue</h3>
  <button aria-labelledby="delete-q4 report-q4" id="delete-q4">Delete</button>
</article>

Det tilgjengelige navnet blir «Delete Q4 revenue.» Dette unngår å duplisere rapporttittelen i et attributt.

Ikke gi etikett til alt

Ikke alle elementer trenger en ARIA-etikett.

Statisk tekst gjør vanligvis ikke det. Dekorative ikoner gjør ikke det. Beholdere gjør ikke det, med mindre de har en meningsfull landemerke- eller widgetrolle. Overmerking kan gjøre en side støyende og vanskeligere å navigere.

For bilder bør du bruke den bildespesifikke modellen: meningsfulle bilder trenger nyttig alt; dekorative bilder trenger tom alt="". Ikke bruk ARIA-etiketter som erstatning for god bildetekst. Hvis teamet ditt blander disse konseptene, gå tilbake til pragmatisk alt-tekst for bilder og skill bildealternativer fra kontrollnavn.

En vanlig feil er å gi hver SVG en aria-label. Hvis SVG-en er inni en knapp og knappen allerede har et navn, bør ikonet vanligvis skjules for hjelpemiddelteknologi:

<button aria-label="Open menu">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Ellers kan brukeren høre overflødige eller merkelige kunngjøringer, avhengig av kombinasjonen av nettleser og hjelpemiddelteknologi.

Sjekk det beregnede navnet, ikke bare koden

Tilgjengelighetsfeil overlever ofte kodegjennomgang fordi markupen ser plausibel ut.

Moderne utviklerverktøy i nettlesere kan vise det beregnede tilgjengelighetstreet. I Chrome, Edge, Firefox og Safari kan du inspisere elementet og se etter tilgjengelighetsinformasjon som rolle, navn og beskrivelse. Du sjekker tre ting:

1. Er rollen det du forventer?
2. Er det tilgjengelige navnet klart og spesifikt?
3. Er beskrivelsen nyttig uten å erstatte navnet?

Test deretter noen flyter med en ekte skjermleser. Du trenger ikke å bli en heltids ekspert på hjelpemiddelteknologi for å fange opp det grunnleggende. På macOS er VoiceOver innebygd. På Windows er NVDA mye brukt og gratis. På mobil bør du teste med VoiceOver på iOS og TalkBack på Android der det er relevant.

Automatiserte verktøy er nyttige, men de kan ikke pålitelig avgjøre om «Open», «Read more» eller «Delete» har nok kontekst. Behandle automatisering som et nett, ikke en dommer. Dette ligner ytelsesrevisjon: en rapport kan peke deg mot mistenkelige områder, men du må fortsatt tolke påvirkningen. Den samme rolige tilnærmingen vi anbefaler for å lese en Lighthouse-rapport uten panikk, gjelder her.

En praktisk sjekkliste for gjennomgang

Før du lanserer ARIA-etiketter, spør:

• Kunne dette vært innebygd HTML i stedet?
• Finnes det synlig tekst som bør brukes som etikett?
• Hvis synlig tekst finnes, inkluderer det tilgjengelige navnet den?
• Er gjentatte kontroller unike når de navigeres uten visuell kontekst?
• Er hjelpetekst koblet til med aria-describedby, ikke presset inn i etiketten?
• Er dekorative ikoner skjult for hjelpemiddelteknologi?
• Har noen sjekket det beregnede tilgjengelighetsnavnet i nettleserens utviklerverktøy?
• Er det gjort minst én gjennomgang med ekte skjermleser for den kritiske flyten?

Denne sjekklisten fanger opp de fleste etikettproblemer før de blir brukerproblemer.

Den stille disiplinen i god ARIA

Godt ARIA-arbeid er sjelden dramatisk. Det handler mest om tilbakeholdenhet.

Bruk ekte knapper. Bruk ekte etiketter. Hold synlige og tilgjengelige navn på linje. Legg til aria-label bare når det ikke finnes en bedre synlig kilde. Bruk aria-labelledby når siden allerede inneholder riktig tekst. Bruk aria-describedby for støttende instruksjoner og feil.

Webplattformen gir utviklere mye gratis når vi bruker den direkte. ARIA er der for hullene. Ferdigheten er å vite når det faktisk finnes et hull.