Hva er ARIA-roller? En praktisk veiledning for utviklere

WAI-ARIA-spesifikasjonen vedlikeholdes av W3Cs arbeidsgruppe for tilgjengelige rike internettapplikasjoner. Den første versjonen, ARIA 1.0, ble en W3C-anbefaling i 2014; ARIA 1.1 fulgte i 2017, og ARIA 1.2 nådde anbefalingsstatus i 2023. Roller, tilstander og egenskaper ble lagt til med hver revisjon, og hver av dem er koblet til et dokument for forfatterpraksis som beskriver den forventede oppførselen til tastaturet.

Relatert: accessiBe — Superposición de IA que promete cumplimiento WCAG en 48 timer.

Et nøkkelskille skiller rollene fra de to andre ARIA-kategoriene. Rollene svarer: “Hva er dette?” Tilstander og egenskaper svarer: “Hvilken tilstand er den i?” og “Hva er det relatert til?” En role="checkbox" erklærer widgettypen; aria-checked="true" indikerer gjeldende tilstand. Å forvirre de to er en av de vanligste årsakene til ødelagte egendefinerte widgets.

De seks rollekategoriene

For å forstå hva ARIA-roller er, hjelper det å vite at ARIA-spesifikasjonen grupperer roller i seks familier. Å forstå familien lar deg forutsi hvilke tilstander og egenskaper en rolle støtter og hvilke tastaturmønstre som gjelder.

Abstrakte roller brukes kun til å organisere taksonomien. Forfattere må aldri skrive role="widget" eller role="input" i markup; dette resulterer i udefinert oppførsel og validering mislykkes. De resterende fem kategoriene er de du faktisk bruker.

Verdt en titt: UserWay — Tilgjengelighetswidget med gratis plan for empezar Hoy Mismo.

Implisitte roller og den første regelen for ARIA

Hvert HTML-element har en implisitt ARIA-funksjon (som forklarer hva som er aria-roller) definert av HTML Accessibility API Mapping (AAM)-spesifikasjonen. Et <nav>-element har en implisitt role="navigation". En <ul> har en implisitt role="list". En <h1> til <h6> har role="heading". En <tabell> har role="table".

Den første W3C-regelen om bruk av ARIA sier tydelig: Hvis et naturlig HTML-element eller -attributt allerede formidler nødvendig semantikk og atferd, bruk det i stedet for å gjenbruke et element med ARIA. Det er ikke nødvendig å legge til role="button" til en <button>. Enda verre, hvis du legger til role="button" til en <div>, vil du få kunngjøringen, men ingen atferd: ingen fokus, ingen tastaturaktivering, ingen skjemainnsending.

Redundans er ikke alltid ufarlig. Å overstyre en implisitt rolle kan miste semantikken som hjelpemiddelteknologi er avhengig av. Å skrive role="presentation" i en <tabell> eliminerer fullstendig tabellsemantikk, som noen ganger er tilsiktet med layouttabeller, men katastrofalt med datatabeller.

Hvordan roller samhandler med stater og eiendommer

Roller fungerer som beholdere for tilstandene og egenskapene de støtter. Spesifikasjonen definerer hvilke attributter som er gyldige for hvilke roller, og nettlesere viser kun støttede kombinasjoner i tilgjengelighetstreet. Å forstå hva som er aria-roller hjelper å vite at en role="checkbox" støtter aria-checked med verdiene true, false eller mixed.

En role="slider" støtter aria-valuenow, aria-valuemin, aria-valuemax og eventuelt aria-valuetext. En role="combobox" støtter aria-expanded, aria-controls og aria-activedescendant. Å bruke aria-checked på en role="button" er meningsløst og vil bli ignorert eller gi forvirrende resultater i enkelte skjermlesere.

De nødvendige egenskapene er også viktige. En role="checkbox" uten aria-checked er ugyldig; staten er obligatorisk og ikke valgfri. En role="slider" uten aria-valuenow gjør at brukeren ikke kan bestemme gjeldende verdi. ARIA-spesifikasjonen merker dem som “påkrevde tilstander og egenskaper”, og samsvarskontrollere som axe-core og IBM Equal Access Accessibility Checker påpeker deres fravær.

Relatert: Deque axe DevTools Pro — El estándar de la industria para testear accesibilidad durante el desarrollo.

Roller, tilgjengelighetstreet og nettleserstøtte

Nettlesere oversetter ARIA-funksjoner til API-er for plattformtilgjengelighet (UIA på Windows, AXAPI på macOS, ATK/AT-SPI på Linux), og skjermlesere bruker disse API-ene. En rolle som ingen nettlesere tildeler riktig er praktisk talt usynlig for brukere.

Støtte varierer etter funksjon og nettleser. Kjernefunksjoner som “Button”, “Link”, “Header”, “List” og “Navigation” støttes universelt. Nyere eller mer spesialiserte roller (“feed”, “math”, “doc-footnote” fra Digital Publishings WAI-ARIA-modul) har mer ujevn støtte. Rolle=“switch” støttes i moderne nettlesere, men ble inkonsekvent annonsert for et tiår siden.

Det er fortsatt viktig å teste de faktiske kombinasjonene publikum bruker. En widget som fungerer i NVDA med Firefox kan oppføre seg annerledes i VoiceOver med Safari, fordi de to skjermleserne bruker forskjellige plattform-APIer og bruker forskjellige heuristikk.

Hvis du handler: IAAP CPACC / WAS Certification — Den profesjonelle sertifiseringen er godkjenning for å oppleve og få tilgang.

Landemerke-roller og sidestruktur

Landemerke-roller lar brukere av skjermlesere hoppe direkte til områder på en side. De åtte landemerkerollene er “banner”, “komplementær”, “innholdsinformasjon”, “skjema”, “hoved”, “navigasjon”, “region” og “søk”. Moderne HTML har innebygde ekvivalenter for de fleste: <header> blir banner, <footer> blir contentinfo, <main> blir main, <nav> blir navigasjon, <aside> blir komplementær, <form> med et tilgjengelig navn blir form, og <section> med et tilgjengelig navn blir region.

Å bruke native elementer er å foretrekke fordi de fungerer selv om CSS eller JavaScript feiler og fordi de reduserer risikoen for rolle/attributtkonflikter. Landemerket for “søk” har ingen naturlig HTML-ekvivalent, så “role=“search"" er fortsatt det riktige valget for søkeområdet.

En vanlig feil er å bruke role="banner" på en <div> som er inne i en <main> eller <article>. Landemerke-roller oppretter bare landemerker hvis de ikke er nestet innenfor visse andre roller; et “banner” inne i “main” vil ikke vises som et landemerke i det hele tatt. Plassering i DOM er like viktig som rolleverdien. For de som lurer på hva som er arieroller, er disse landemerkene en sentral del av spesifikasjonen.

Live Region Roller

Når man vurderer hva som er arieroller, kunngjør live regionale roller innholdsendringer uten å endre fokus. De fire live region-funksjonene er “varsling”, “status”, “logg” og “timer”, så vel som den mer generelle “marquee”. Hver har en “aria-live”-verdi implisitt: “alert” og “log” antyder i praksis henholdsvis “assertive” og “høflig”, mens “status” betyr “høflig”.

Å velge mellom ‘varsling’ og ‘status’ er en designbeslutning med reelle konsekvenser. Et varsel stopper det skjermleseren leser, noe som er passende for feil og hastevarsler, men skadelig hvis det brukes overdrevent. En status venter på en pause, som sammenfaller med fremdriftsmeldinger og bekreftelsestekster.

Live-regioner må eksistere i DOM før innholdet endres. Å sette inn et role="alert"-element og dets tekst samtidig resulterer ofte i ingen kunngjøring fordi regionen ikke eksisterte på tidspunktet for endringen. Det pålitelige mønsteret er å gjengi en tom live-region ved sideinnlasting og oppdatere tekstinnholdet senere.

Når man IKKE skal bruke ARIA-roller

Den andre regelen for bruk av ARIA er at forfattere ikke bør endre den opprinnelige semantikken med mindre de virkelig trenger det. Den femte regelen sier at hvert interaktivt element, uansett funksjon, må være tilgjengelig og fokuserbart via tastaturet.

Å legge til en rolle legger ikke til atferd. role="button" på en <div> fører til at den ikke klarer å fokusere, ikke svare på inndata eller mellomromstasten og ikke sende inn skjemaet. Du må legge til tabindex="0", en tastetrykkbehandling for input og plass, og ofte “rollepassende” tilstandsadministrasjon. På dette tidspunktet krever bruk av en ekte "" mindre kode og færre feil.

Noen roller er aktivt skadelige når de brukes feil. role="presentation" og role="none" fjerner semantikk fra et element og, i noen implementeringer, fra dets nødvendige etterkommere. Ved å bruke role="application" skifter skjermlesere til en modus der de slutter å avskjære tastetrykk, noe som kan fange brukere hvis den tilpassede tastaturhåndteringen er ufullstendig.

Et beslutningsrammeverk for valg av roller

Å jobbe gjennom en kort sekvens forhindrer de fleste ARIA-rollefeil. Følg disse trinnene for å forstå hva ARIA-roller er og hvordan du bruker dem:

1. Identifiser widgeten eller regionen. Nevn hva elementet faktisk er på vanlig språk.
2. Se etter en innebygd HTML-ekvivalent. Se HTML-AAM-tilordningen. Hvis <knapp>, <select>, <details> eller <dialog> passer, bruk den.
3. Hvis ingen innfødt element passer, velg den nærmeste ARIA-rollen. Bekreft at den finnes i gjeldende spesifikasjon og ikke er abstrakt.
4. Legg til nødvendige tilstander og egenskaper. Sjekk rollens definisjon for obligatoriske attributter.
5. Implementer tastaturinteraksjonsmønsteret. Følg WAI-ARIA Authoring Practices Guide for widgettypen.
6. Test med minst to skjermleser- og nettleserkombinasjoner. Bekreft kunngjøringer, tilstander og tastaturflyt.

Trinn tre til seks er der de fleste tilpassede widget-feil oppstår. Hvis du hopper over tastaturmønsteret i trinn fem, opprettes en widget som annonserer riktig, men som ikke kan brukes, noe som uten tvil er verre enn å ikke ha noen ARIA i det hele tatt.

Test- og valideringsverktøy

Automatiserte verktøy oppdager strukturelle feil: ugyldige rolleverdier, manglende nødvendige egenskaper og roller brukt på elementer som ikke støtter dem. axe-core, motoren bak mange nettleserutvidelser, sjekker et definert delsett av ARIA-regler. IBM Equal Access Accessibility Checker og W3Cs egen Nu HTML Checker viser også rollemisbruk.

Automatiserte verktøy kan ikke bekrefte om en rolle produserer riktig kunngjøring eller om tastaturinteraksjon fungerer. Manuell testing med NVDA og Firefox, JAWS og Chrome, eller VoiceOver og Safari er fortsatt nødvendig. Accessibility Insights for Web-utvidelsen kombinerer automatiserte kontroller med en guidet manuell vurdering som inkluderer tastatur- og skjermleserverifisering.

Selve ARIA-spesifikasjonen, WAI-ARIA Authoring Practices Guide og HTML-AAM-kartleggingsdokumentet er de autoritative referansene for hva som er ariaroller. MDN Web Docs ARIA Reference er en praktisk og velvalgt sekundærkilde som refererer til spesifikasjonen for hver rolle.

Viktige takeaways

• ARIA-roller erklærer hva et element er; WAI-ARIA 1.2 definerer 87 roller i seks kategorier, og abstrakte roller kan aldri vises i markup.
• Innfødte HTML-elementer har implisitte roller og innebygd atferd, så den første regelen når du bruker ARIA er å foretrekke dem fremfor “div” pluss “rolle”.
• Roller krever deres støttede tilstander og egenskaper: en role="checkbox" uten aria-checked er ugyldig og kan ikke brukes.
• Å legge til en rolle gir aldri tastaturadferd eller fokuserbarhet; disse må implementeres og testes separat.
• Landmark og Live Region-roller har plassering og tidsregler som bestemmer om de fungerer eller ikke.
• Automatiserte inspektører oppdager kun strukturelle feil; testing av skjermlesere for ulike nettleserkombinasjoner er fortsatt nødvendig.

For å forstå hva som er ARIA-roller, husk at de definerer formålet med et element for hjelpeteknologi.

Kilder og videre lesing

• WAI-ARIA — Wikipedia: Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) er en teknisk spesifikasjon utgitt av World Wide Web Consortium (W3C) som…

Vanlige spørsmål

Hva er ARIA-roller på en enkel måte?

ARIA-roller er etiketter du fester til HTML-elementer for å fortelle hjelpeteknologi hva elementet representerer. En <div role="button"> annonseres som en knapp i stedet for som generisk tekst. Roller gir noe som betyr at den underliggende taggen ikke gir, men de legger ikke til noen atferd, fokushåndtering eller tastaturstøtte alene.

Hva er forskjellen mellom ARIA-roller og ARIA-attributter?

Roller beskriver typen til et element, mens attributter beskriver dets tilstand, verdi eller relasjoner. role="slider" identifiserer en skyvebryter; aria-valuenow="50" rapporterer sin nåværende posisjon og aria-labelledby peker på etiketten. Roller og attributter brukes sammen og hver rolle definerer hvilke attributter den støtter.

Hvor mange ARIA-roller er det?

WAI-ARIA 1.2 definerer 87 roller gruppert i seks kategorier: abstrakt, widget, dokumentstruktur, landemerke, live-region og vindu. Abstrakte roller som “widget” og “input” eksisterer bare for den interne taksonomien til spesifikasjonen og bør aldri skrives i HTML. Antallet vokser med hver spesifikasjonsrevisjon.

Bør jeg bruke ARIA-roller i stedet for semantisk HTML?

Nei. Den første regelen for ARIA-bruk sier å foretrekke et innebygd HTML-element når det eksisterer med nødvendig semantikk og oppførsel. Bruk <button> i stedet for <div role="button">, og <nav> i stedet for <div role="navigation">. ARIA-roller er en reserve for tilfeller der det ikke finnes noe passende innebygd element.

Fungerer ARIA-roller i alle nettlesere og skjermlesere?

Kjerneroller som button, link, heading og navigation støttes pålitelig av moderne nettlesere og skjermlesere. Nyere eller mer spesialiserte roller, inkludert de i Digital Publishing-modulen, gir mer variabel støtte. Bare ved å teste med de spesifikke nettleser- og skjermleserkombinasjonene publikum bruker kan du være sikker.

Kan det å legge til en ARIA-rolle bryte tilgjengelighet?

Ja. Overstyring av en implisitt rolle kan miste nyttig semantikk, for eksempel når role="presentation" brukes på en datatabell. Å bruke role="application" kan blokkere brukere hvis tilpasset tastaturhåndtering er ufullstendig. Redundante roller i innebygde elementer skaper unødvendig støy og fører av og til til motstridende kunngjøringer.