Hvad er ARIA-roller? En praktisk guide til udviklere

Hvorfor ARIA-roller overhovedet eksisterer

For at forstå, hvad der er aria-roller, skal man se, at de løser et strukturelt problem, som HTML alene ikke kan løse. Native HTML-elementer har implicit semantik: en <knap> annoncerer sig selv som en knap, kan fokuseres, reagerer på Enter og mellemrumstasten og viser en trykket tilstand, når det er nødvendigt.

Når udviklere opretter brugerdefinerede widgets (en kombinationsboks, et fanepanel, en trævisning), bruger de ofte <div> og <span>, som ikke indeholder nogen semantik. ARIA-roller lukker dette hul ved at tillade forfattere eksplicit at angive manglende mening.

WAI-ARIA-specifikationen vedligeholdes af W3C’s Accessible Rich Internet Applications Working Group. Den første version, ARIA 1.0, blev en W3C-anbefaling i 2014; ARIA 1.1 fulgte i 2017, og ARIA 1.2 nåede anbefalingsstatus i 2023. Roller, tilstande og egenskaber blev tilføjet med hver revision, og hver enkelt er knyttet til et forfatterpraksisdokument, der beskriver tastaturets forventede adfærd.

En vigtig skelnen adskiller rollerne fra de to andre ARIA-kategorier. Rollerne svarer: “Hvad er det her?” Tilstande og egenskaber svarer: “Hvilken tilstand er den i?” og “Hvad er det relateret til?” Et role="checkbox" erklærer widgettypen; aria-checked="true" angiver dens aktuelle tilstand. At forveksle de to er en af ​​de mest almindelige årsager til ødelagte brugerdefinerede widgets.

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

De seks rollekategorier

For at forstå, hvad ARIA-roller er, hjælper det at vide, at ARIA-specifikationen grupperer roller i seks familier. At forstå familien giver dig mulighed for at forudsige, hvilke tilstande og egenskaber en rolle understøtter, og hvilke tastaturmønstre der gælder.

Abstrakte roller bruges kun til at organisere taksonomien. Forfattere må aldrig skrive role="widget" eller role="input" i markup; dette resulterer i udefineret adfærd og validering mislykkes. De resterende fem kategorier er dem, du rent faktisk anvender.

Implicitte roller og den første regel i ARIA

Hvert HTML-element har en implicit ARIA-funktion (som forklarer, hvad der er aria-roller), defineret af HTML Accessibility API Mapping (AAM)-specifikationen. Et <nav>-element har en implicit role="navigation". En <ul> har en implicit role="list". En <h1> til <h6> har role="heading". En <table> har role="table".

Værd at se: AudioEye — Accesibilidad gestionada: automatisering combinada con revision humana.

Den første W3C-regel om brug af ARIA siger klart: Hvis et indbygget HTML-element eller -attribut allerede formidler den nødvendige semantik og adfærd, så brug det i stedet for at genbruge et element med ARIA. Det er ikke nødvendigt at tilføje role="button" til en <button>. Endnu værre, hvis du tilføjer role="button" til en <div>, vil du få meddelelsen, men ingen adfærd: intet fokus, ingen tastaturaktivering, ingen formularindsendelse.

Redundans er ikke altid harmløst. Tilsidesættelse af en implicit rolle kan miste den semantik, som hjælpeteknologi afhænger af. At skrive role="præsentation" i en <table> eliminerer fuldstændig tabelsemantik, som nogle gange er bevidst med layouttabeller, men katastrofalt med datatabeller.

Hvordan roller interagerer med stater og ejendomme

Roller fungerer som beholdere for de stater og egenskaber, de understøtter. Specifikationen definerer, hvilke attributter der er gyldige for hvilke roller, og browsere viser kun understøttede kombinationer i tilgængelighedstræet.

At forstå, hvad aria-roller er, hjælper med at vide, at en role="checkbox" understøtter aria-checked med værdierne true, false eller mixed. En role="slider" understøtter aria-valuenow, aria-valuemin, aria-valuemax og eventuelt aria-valuetext. En role="combobox" understøtter aria-expanded, aria-controls og aria-activedescendant. At anvende aria-checked på en role="button" er meningsløst og vil blive ignoreret eller give forvirrende resultater i nogle skærmlæsere.

De nødvendige egenskaber er også vigtige. En role="checkbox" uden aria-checked er ugyldig; staten er obligatorisk og ikke valgfri. En role="slider" uden aria-valuenow efterlader brugeren ude af stand til at bestemme den aktuelle værdi. ARIA-specifikationen mærker dem som “påkrævede tilstande og egenskaber”, og overensstemmelsestjekkere såsom axe-core og IBM Equal Access Accessibility Checker påpeger deres fravær.

Roller, tilgængelighedstræet og browsersupport

Browsere oversætter ARIA-funktioner til platformtilgængeligheds-API’er (UIA på Windows, AXAPI på macOS, ATK/AT-SPI på Linux), og skærmlæsere bruger disse API’er. En rolle, som ingen browser korrekt tildeler, er praktisk talt usynlig for brugerne.

Relateret: IAAP CPACC / WAS Certification — Den professionelle certificering que acredita tu experiencia and accessibilidad.

Support varierer efter funktion og browser. Kernefunktioner såsom “Knap”, “Link”, “Header”, “Liste” og “Navigation” er universelt understøttet. Nyere eller mere specialiserede roller (“feed”, “math”, “doc-footnote” fra Digital Publishings WAI-ARIA-modul) har mere usammenhængende understøttelse. Rollen = “switch” er understøttet i moderne browsere, men blev inkonsekvent annonceret for et årti siden.

Det er fortsat vigtigt at teste på tværs af de faktiske kombinationer, dit publikum bruger. En widget, der fungerer i NVDA med Firefox, kan opføre sig anderledes i VoiceOver med Safari, fordi de to skærmlæsere bruger forskellige platforms API’er og anvender forskellige heuristika.

skelsættende roller og sidestruktur

Landmark-roller giver skærmlæserbrugere mulighed for at hoppe direkte til områder på en side. De otte skelsættende roller er “banner”, “komplementær”, “indholdsoplysninger”, “formular”, “hoved”, “navigation”, “region” og “søgning”. Moderne HTML har indbyggede ækvivalenter for de fleste: <header> bliver til banner, <footer> bliver til contentinfo, <main> bliver main, <nav> bliver til navigation, <aside> bliver komplementær, <form> med et tilgængeligt navn bliver til form, og <section> med et tilgængeligt navn bliver til region.

Værd at se: UserWay — Accessibilidad widget med en gratis plan for empezar hoy mismo.

Brug af native elementer er at foretrække, fordi de virker, selvom CSS eller JavaScript fejler, og fordi de reducerer risikoen for rolle/attributkonflikter. Søge-varemærket har ingen indbygget HTML-ækvivalent, så role="search" er stadig det korrekte valg for søgeområdet.

En almindelig fejl er at anvende role="banner" på en <div>, der er inde i en <main> eller <artikel>. Landmark-roller skaber kun landemærker, hvis de ikke er indlejret i visse andre roller; et ‘banner’ inde i ‘main’ vil slet ikke blive vist som et vartegn. Placering i DOM er lige så vigtig som rolleværdien. For dem, der spekulerer på, hvad er arie-roller, er disse vartegn en vigtig del af specifikationen.

Live regionsroller

Når man overvejer, hvad der er arieroller, annoncerer live regionale roller indholdsændringer uden at ændre fokus. De fire live regionsfunktioner er alert, status, log og timer, såvel som det mere generelle marquee. Hver bærer en “aria-live” værdi implicit: “alert” og “log” betyder i praksis henholdsvis “assertive” og “høflig”, mens “status” betyder “høflig”.

At vælge mellem ‘alert’ og ‘status’ er en designbeslutning med reelle konsekvenser. En “alarm” stopper, hvad end skærmlæseren læser, hvilket er passende for fejl og presserende meddelelser, men skadeligt, hvis det bruges overdrevent. En status venter på en pause, som falder sammen med statusmeddelelser og bekræftelsestekster.

Live-regioner skal eksistere i DOM, før indholdet ændres. Indsættelse af et role="alert"-element og dets tekst på samme tid resulterer ofte i ingen meddelelse, fordi regionen ikke eksisterede på tidspunktet for ændringen. Det pålidelige mønster er at gengive en tom live-region ved sideindlæsning og opdatere dets tekstindhold senere.

Hvornår man IKKE skal bruge ARIA-roller

Den anden regel for at bruge ARIA er, at forfattere ikke bør ændre den oprindelige semantik, medmindre de virkelig har brug for det. Den femte regel siger, at hvert interaktivt element, uanset dets funktion, skal være tilgængeligt og kan fokuseres via tastaturet.

Tilføjelse af en rolle tilføjer ikke adfærd. role="button" på en <div> får den til ikke at fokusere, ikke reagere på input eller mellemrumstasten og ikke indsende formularen. Du skal tilføje tabindex="0", en tastetrykshåndtering til input og plads, og ofte “rolle-passende” tilstandsstyring. På dette tidspunkt kræver brug af en rigtig "" mindre kode og færre fejl.

Nogle roller er aktivt skadelige, når de anvendes forkert. role="præsentation" og role="ingen" fjerner semantik fra et element og, i nogle implementeringer, fra dets påkrævede efterkommere. Anvendelse af role="application" skifter skærmlæsere til en tilstand, hvor de stopper med at opsnappe tastetryk, hvilket kan fange brugere, hvis den brugerdefinerede tastaturhåndtering er ufuldstændig.

En beslutningsramme for valg af roller

At arbejde gennem en kort sekvens forhindrer de fleste ARIA-rollefejl. Følg disse trin for at forstå, hvad ARIA-roller er, og hvordan du bruger dem:

1. Identificer widgetten eller regionen. Navngiv, hvad elementet faktisk er, i almindeligt sprog.
2. Se efter en indbygget HTML-ækvivalent. Se HTML-AAM-tilknytningen. Hvis <knap>, <vælg>, <detaljer> eller <dialog> passer, skal du bruge det.
3. Hvis intet indbygget element passer, skal du vælge den nærmeste ARIA-rolle. Bekræft, at den findes i den aktuelle specifikation og ikke er abstrakt.
4. Tilføj påkrævede tilstande og egenskaber. Tjek rollens definition for obligatoriske attributter.
5. Implementer tastaturinteraktionsmønsteret. Følg WAI-ARIA Authoring Practices Guide for widgettypen.
6. Test med mindst to skærmlæser- og browserkombinationer. Bekræft meddelelser, tilstande og tastaturflow.

Trin tre til seks er, hvor de fleste brugerdefinerede widgetfejl opstår. Hvis du springer tastaturmønsteret over i trin fem, opretter du en widget, der annoncerer korrekt, men som ikke kan bruges, hvilket uden tvivl er værre end at have ingen ARIA overhovedet.

Test- og valideringsværktøjer

Automatiserede værktøjer registrerer strukturelle fejl: ugyldige rolleværdier, manglende påkrævede egenskaber og roller anvendt på elementer, der ikke understøtter dem. axe-core, motoren bag mange browserudvidelser, kontrollerer et defineret undersæt af ARIA-regler. IBM Equal Access Accessibility Checker og W3C’s egen Nu HTML Checker viser også rollemisbrug.

Automatiserede værktøjer kan ikke bekræfte, om en rolle producerer den korrekte meddelelse, eller om tastaturinteraktion fungerer. Manuel test med NVDA og Firefox, JAWS og Chrome eller VoiceOver og Safari er stadig påkrævet. Accessibility Insights for Web-udvidelsen kombinerer automatiske kontroller med en guidet manuel vurdering, der inkluderer tastatur- og skærmlæserbekræftelse.

Selve ARIA-specifikationen, WAI-ARIA Authoring Practices Guide og HTML-AAM-kortlægningsdokumentet er de autoritative referencer for, hvad der er aria-roller. MDN Web Docs ARIA Reference er en praktisk og velvalgt sekundær kilde, der refererer til specifikationen for hver rolle.

Key Takeaways

• ARIA-roller erklærer, hvad et element er; WAI-ARIA 1.2 definerer 87 roller i seks kategorier, og abstrakte roller vises muligvis aldrig i markeringen.
• Native HTML-elementer har implicitte roller og indbygget adfærd, så den første regel, når du bruger ARIA, er at foretrække dem frem for “div” plus “rolle”.
• Roller kræver deres understøttede tilstande og egenskaber: et role="checkbox" uden aria-checked er ugyldigt og kan ikke bruges.
• Tilføjelse af en rolle tilføjer aldrig tastaturadfærd eller fokuserbarhed; disse skal implementeres og testes separat.
• Landmark og Live Region roller har placering og timing regler, der bestemmer, om de fungerer eller ej.
• Automatiserede inspektører opdager kun strukturelle fejl; test af skærmlæsere til forskellige browserkombinationer er stadig påkrævet.

For at forstå, hvad ARIA-roller er, skal du huske, at de definerer formålet med et element til hjælpeteknologi.

Kilder og yderligere læsning

• WAI-ARIA — Wikipedia: Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) er en teknisk specifikation udgivet af World Wide Web Consortium (W3C), der…

Ofte stillede spørgsmål

Hvad er ARIA-roller i enkle vendinger?

ARIA-roller er etiketter, du knytter til HTML-elementer for at fortælle hjælpeteknologi, hvad elementet repræsenterer. En <div role="button"> annonceres som en knap i stedet for som generisk tekst. Roller leverer, hvilket betyder, at det underliggende tag ikke giver, men de tilføjer ikke nogen adfærd, fokushåndtering eller tastaturunderstøttelse alene.

Hvad er forskellen mellem ARIA-roller og ARIA-attributter?

Roller beskriver typen af ​​et element, mens attributter beskriver dets tilstand, værdi eller relationer. role="slider" identificerer en skyder; aria-valuenow="50" rapporterer sin nuværende position og aria-labelledby peger på sin etiket. Roller og attributter bruges sammen, og hver rolle definerer, hvilke attributter den understøtter.

Hvor mange ARIA-roller er der?

WAI-ARIA 1.2 definerer 87 roller grupperet i seks kategorier: abstrakt, widget, dokumentstruktur, landmark, live region og vindue. Abstrakte roller som “widget” og “input” eksisterer kun for specifikationens interne taksonomi og bør aldrig skrives i HTML. Antallet vokser med hver specifikationsrevision.

Skal jeg bruge ARIA-roller i stedet for semantisk HTML?

Nej. Den første regel for ARIA-brug siger, at man foretrækker et indbygget HTML-element, når der findes et med den nødvendige semantik og adfærd. Brug <button> i stedet for <div role="button">, og <nav> i stedet for <div role="navigation">. ARIA-roller er en reserve for tilfælde, hvor der ikke findes et passende indbygget element.

Fungerer ARIA-roller i alle browsere og skærmlæsere?

Kerneroller som button, link, heading og navigation understøttes pålideligt af moderne browsere og skærmlæsere. Nyere eller mere specialiserede roller, herunder dem i Digital Publishing-modulet, giver mere variabel support. Kun ved at teste med de specifikke browser- og skærmlæserkombinationer, som dit publikum bruger, kan du være sikker.

Kan tilføjelse af en ARIA-rolle bryde tilgængelighed?

Ja. Tilsidesættelse af en implicit rolle kan miste nyttig semantik, såsom når role="presentation" anvendes på en datatabel. Anvendelse af role="application" kan blokere brugere, hvis tilpasset tastaturhåndtering er ufuldstændig. Redundante roller i indbyggede elementer skaber unødvendig støj og fører lejlighedsvis til modstridende meddelelser.