Eksempler på ARIA-roller: En komplet vejledning
ARIA-rolleeksemplerne viser, hvordan rolleattributter kortlægger grænsefladeelementer til tilgængelighedstræet, og WAI-ARIA 1.2-specifikationen definerer 6 rollekategorier – widget, dokumentstruktur, vartegn, levende region, vindue og abstrakt – der dækker mere end 80 konkrete roller. Denne vejledning præsenterer praktiske eksempler, der er klar til kopiering for hver kategori, samt reglerne, der bestemmer, hvornår en rolle hjælper, og hvornår den aktivt skader.
Vigtigste pointer
- ARIA-roller fortæller hjælpeteknologien, hvad en genstand er; de tilføjer aldrig adfærd, fokus eller tastaturstøtte alene.
- Den første regel ved at bruge ARIA er at foretrække native HTML-elementer, som allerede har implicitte roller, tilstande og tastaturstyring.
- De seks WAI-ARIA 1.2-rollekategorier er widget, dokumentstruktur, vartegn, levende region, vindue og abstrakt - abstrakte roller bør aldrig vises i din markering.
- Landmark-roller er de mest omkostningseffektive og laveste risiko-ARIA’er, du kan tilføje til et eksisterende XHTML/CSS-websted.
- Widget-roller kræver næsten altid JavaScript-mapping til tastaturinteraktion og tilstandshåndtering, eller de skaber en dårligere oplevelse end almindelig HTML.
- Validere hver rolle med en skærmlæser og automatiseret kontrol; en gyldig rolle i specifikationen kan stadig være forkert for dit indhold.
Hvad ARIA-roller faktisk gør
ARIA-roller er tokens, som du placerer i “role”-attributten for at erstatte eller give den semantiske identitet af et element i tilgængelighedstræet. En <div role="button"> fortæller en skærmlæser om at annoncere “knap”, men browseren behandler den stadig som en generisk beholder: den kan ikke fokuseres, den reagerer ikke på Enter eller Space, og den har ikke en deaktiveret tilstand.
Denne kløft mellem annonceret semantik og faktisk adfærd er den mest almindelige kilde til ARIA-fejl. Disse er almindelige eksempler på ARIA-roller på, hvordan semantik kan afvige fra adfærd.
WAI-ARIA-specifikationen, der vedligeholdes af W3C’s Accessible Rich Internet Applications Working Group, definerer roller såvel som tilstande og egenskaber. Roller er “hvad er det” laget; tilstande og egenskaber som aria-udvidet, aria-checked og aria-label er laget “hvilken tilstand er den i”. En rolle uden dens påkrævede tilstande er ufuldstændig - role="checkbox" kræver aria-checked, og role="combobox" kræver aria-expanded plus en kontrolleret listeboks.
Native HTML-elementer har implicitte roller. <knap> svarer til knappens rolle, <nav> til navigation, <h1> gennem <h6> til overskriften og <input type="checkbox"> til afkrydsningsfeltet. Fordi browseren automatisk giver rollen, tastaturadfærden og tilstanden, er den første regel for at bruge ARIA – dokumenteret i W3C’s ARIA Authoring Practices Guide – at bruge indbygget semantik, når der findes et tilsvarende element. Søg kun efter eksplicitte roller, når intet indbygget element er egnet, såsom en tilpasset trævisning eller et fanepanel bygget fra <div>er.
De seks WAI-ARIA-rollekategorier
WAI-ARIA 1.2 organiserer roller i seks kategorier, og at vide, hvilken kategori en rolle tilhører, fortæller dig, hvor meget JavaScript du skylder den. Her er nogle almindelige eksempler på arieroller:
Relateret: — Superposición de IA que promete cumplimiento WCAG en 48 timer.
| Kategori | Formål | Eksempelroller | JavaScript påkrævet? |
|---|---|---|---|
| Widget | Interaktive kontroller | button, checkbox, tab, slider, combobox | Ja — tastatur + tilstand |
| Dokumentstruktur | Organisering af indhold | ”heading, list, listitem, table, article” | Nej |
| Landmærke | Sideområder til navigation | banner, main, navigation, komplementær | Nej |
| Levende region | Annoncer dynamiske opdateringer | alert, status, log, timer | Normalt — for at udløse opdateringer |
| vindue | Undervinduer og dialogbokse | dialog, alertdialog | Ja — fokusstyring |
| Abstrakt | Superklasseroller, aldrig forfattet | widget, input, sektion, vartegn | N/A — brug ikke |
Abstrakte roller eksisterer kun for at organisere taksonomien. At skrive role="input" eller role="section" i din HTML er en valideringsfejl og producerer uforudsigelige meddelelser, fordi disse roller ikke har nogen defineret adfærd for hjælpeteknologi.
Eksempler på vartegnsroller
Landmark-roller er de sikreste og mest virkningsfulde eksempler på ARIA-roller, du kan føje til et ældre XHTML/CSS-websted, fordi de ikke kræver JavaScript og kortlægges direkte til regioner, du allerede har. Et typisk sideskelet:
<header role="banner">
<nav role="navigation" aria-label="Principal">
<ul>...</ul>
</nav>
</header>
<main role="main">
<article>...</article>
<aside role="complementary" aria-label="Artículos relacionados">...</aside>
</main>
<footer role="contentinfo">...</footer>Hver markørrolle svarer til et indbygget element - banner til <header> på øverste niveau, main til <main>, navigation til <nav>, complementary til <aside>, contentinfo til <footer>. Når du bruger det native element, er rollen underforstået, og du bør ikke gentage den. Den eksplicitte “rolle”-attribut fortjener kun sin plads, når du sidder fast med "
Værd at se: — Accesibilidad gestionada: automatisering combinada con revision humana.
To forbehold er i orden her. For det første skal banner, main og contentinfo vises én gang pr. side; flere “vigtigste” vartegn forstyrrer navigationen. For det andet, når der findes flere vartegn af samme type – for eksempel tre <nav>-elementer – giv hver en separat aria-label, så skærmlæserbrugere kan skelne dem i listen over landemærker. En umærket “nav” annonceres på samme måde som dens søskende, hvilket besejrer formålet.
Widget-rolleeksempler
Widget-roller er, hvor ARIA bliver både kraftfuld og farlig i lige grad. Hver widgetrolle har en implicit kontrakt: specifikke tastaturtaster, specifikke tilstande og specifik fokusadfærd. ARIA Authoring Practices Guide udgiver det fulde mønster for hver. Disse eksempler på arieroller illustrerer kompleksiteten.
En skifteknap skal f.eks. have “aria-pressed” for at kommunikere dens tænd/sluk-tilstand:
<button type="button" aria-pressed="false" id="mute">
Silenciar
</button><knap>-elementet leverer rollen, fokus og Enter/Space-håndtering; JavaScript vender kun aria-presset mellem "false" og "sand". Dette er den ideelle form for ARIA-brug - native element, minimal ARIA, lille script.
En brugerdefineret fanegrænseflade bygget fra <div>s er det modsatte tilfælde. Den skal bruge role="tablist" på beholderen, role="tab" på hver fane, role="tabpanel" på hvert panel, aria-selected på den aktive fane, aria-controls, der forbinder fanen til panelet, og piletastnavigation mellem faner.
Relateret: — Den professionelle certificering que acredita tu experiencia and accessibilidad.
Hvis du savner nogen af disse, annoncerer widgetten sig selv som faner, men opfører sig som statisk tekst. Det samme gælder for role="slider" (kræver aria-valuenow, aria-valuemin, aria-valuemax og piletaster), role="combobox" (kræver aria-udvidet og en kontrolleret listeboks) og role="træ" (kræver aria-udvidet piletaster og fuld pil).
En nyttig beslutningsregel: Hvis der er et indbygget element, der udfører jobbet - <button>, <input type="checkbox">, <select>, <details> – brug det og ignorer widgetrollen helt. Reserver tilpassede widget-roller til helt nye kontroller, og budgetter JavaScript for at implementere det fulde tastaturmønster inden forsendelse.
Eksempler på dokumentstruktur og levende region
Dokumentstrukturroller beskriver indholdsrelationer, når native elementer ikke er tilgængelige. Disse eksempler på aria-roller inkluderer role="heading" med aria-level, som er den klassiske redning for en stylet <div>, der fungerer som en overskrift:
<div role="heading" aria-level="2">Novedades del mes</div>Attributten “aria-level” er obligatorisk her - en overskriftsrolle uden et niveau annonceres uden en rang, hvilket bryder dokumentets omrids. På samme måde gendanner role="list" og role="listitem" listesemantik, når CSS såsom list-style: none eller en flex container fjerner dem i nogle browsere, og role="table", `role="row"`, `role="columnheader"` og `role="cell"` genopbygger en datatabellen fra
. I praksis kræver omstrukturering til faktiske - WAI-ARIA — Wikipedia: Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) er en teknisk specifikation udgivet af World Wide Web Consortium (W3C), der…
-, - og `-elementer næsten altid mindre arbejde end at opretholde et komplet sæt strukturroller.
Live regionsroller annoncerer ændret indhold uden en genindlæsning af siden. role="alert" afbryder øjeblikkeligt skærmlæseren og imødekommer fejlmeddelelser og presserende meddelelser; role="status" venter høfligt og har det fint med bekræftelser som “Guardado”; role="log" passer til chat- og aktivitetsfeeds; role="timer" svarer til nedtællinger. Den kritiske detalje er, at den levende region-beholder skal eksistere i DOM før indholdet ændres — indsprøjtning af et nyt element med role="alert" og dets tekst på samme tid producerer ofte ingen meddelelse, fordi regionen ikke var til stede for at blive overvåget. Opret en tom <div role="status"> ved sideindlæsning og opdater dens tekst senere.
Almindelige ARIA-rollefejl
Overflødige roller topper listen. Disse eksempler på ariaroller, såsom <button role="button"> og <nav role="navigation">, tilføjer intet og roder opmærkningen; den implicitte rolle eksisterer allerede. Den samme redundans vises, når udviklere tilføjer role="heading" til en <h2>.
Manglende nødvendige tilstande kommer i anden række. role="checkbox" uden aria-checked, role="slider" uden aria-valuenow og role="combobox" uden aria-expanded producerer alle ufuldstændige meddelelser, der vildleder brugere. Specifikationen viser påkrævede tilstande og egenskaber for hver rolle, og automatiske kontrolfunktioner markerer deres fravær.
Rollemisbrug på det forkerte element er tredje. At sætte role="button" på en <a href> tilsidesætter link-semantikken og bryder forventet adfærd som at åbne i en ny fane. Ved at sætte role="præsentation" eller role="none" på et fokuserbart element fjernes dets semantik, mens det efterlades i tabulatorrækkefølgen, hvilket skaber et fokuserbart element uden annonceret identitet. Og at bruge abstrakte roller såsom role="widget" eller role="input" er altid en fejl.
Endelig kan ARIA-roller ikke rette en ødelagt DOM. Et role="tabpanel" indlejret i sin egen role="tab" producerer et nonsenstræ, uanset hvor mange attributter du tilføjer. Fix strukturen først, og læg derefter ARIA ovenpå.
Sådan testes ARIA-roller
Test af ARIA-roller kræver flere metoder, da automatiserede værktøjer registrerer validitetsfejl, men ikke semantiske uoverensstemmelser. Start med en tilgængelighedskontrol - ax DevTools, WAVE eller Lighthouse - for at opdage ugyldige roller, manglende påkrævede attributter og abstrakte roller i din opmærkning. Disse værktøjer er hurtige og registrerer mekaniske fejl.
Følg med et skærmlæserpas. NVDA med Firefox på Windows, JAWS med Chrome og VoiceOver med Safari på macOS eksponerer hver især tilgængelighedstræet forskelligt, og en rolle, der annoncerer korrekt i den ene, er muligvis ikke i en anden. Naviger efter vartegn og ved at gå til for at bekræfte, at dine strukturroller producerer den forventede omrids, og tabuler derefter gennem hver widget for at bekræfte den annoncerede rolle, tilstand og tastaturadfærdsmatch.
Undersøg tilgængelighedstræet direkte i Chrome eller Firefox DevTools, hvor panelet “Tilgængelighed” viser den beregnede rolle og navn på ethvert element. Dette afslører kløften mellem den rolle, du skrev, og den rolle, som browseren faktisk afslører - den hurtigste måde at opdage en rolle, der er tilsidesat af en forælder eller ignoreret fuldstændigt.
Kilder og yderligere læsning
Ofte stillede spørgsmål
Hvad er ARIA-roller, og hvordan fungerer de?
ARIA-roller er værdier i “rolle”-attributten, der definerer identiteten af et element i tilgængelighedstræet, så skærmlæsere annoncerer det korrekt. De ændrer kun semantik, ikke udseende, fokus eller tastaturadfærd. WAI-ARIA 1.2-specifikationen definerer seks rollekategorier og mere end 80 konkrete roller, hver med påkrævede tilstande og egenskaber.
Hvornår skal jeg bruge ARIA-roller i stedet for indbygget HTML?
Brug kun ARIA-roller, når intet native HTML-element giver den semantik, du har brug for. Indbyggede elementer som <button>, <nav> og <input type="checkbox"> har implicitte roller plus indbygget tastaturunderstøttelse og tilstandsstyring. Den første regel for ARIA-brug er at foretrække indbygget semantik, og kun at tilføje eksplicitte roller for brugerdefinerede widgets eller ældre markup, kan du ikke omstrukturere.
Hvad er forskellen mellem ARIA-roller og ARIA-attributter?
ARIA-roller svarer “hvad er denne vare”, mens ARIA-attributter såsom aria-udvidet, aria-checked og aria-label svarer “hvilken tilstand er den i” eller “hvad hedder den”. Rollerne og deres påkrævede attributter arbejder sammen: Som eksempler på ariaroller er role="checkbox" ufuldstændig uden aria-checked, og role="combobox" skal have aria-udvidet plus en kontrolleret listeboks.
Kan jeg bruge ARIA-roller på ethvert HTML-element?
ARIA-roller kan anvendes på de fleste elementer, men nogle kombinationer er ugyldige eller skadelige. Abstrakte roller som “widget” og “input” bør aldrig forfattes. Ændring af et links rolle til role="button" bryder den forventede adfærd af linket, og role="præsentation" på et fokuserbart element fjerner dets semantik, mens det efterlades i tabulatorrækkefølge.
Fungerer ARIA-roller uden JavaScript?
Dokumentstruktur og landmark-roller fungerer uden JavaScript, fordi de kun ændrer semantik. Widget-roller som ‘tab’, ‘slider’ og ‘combobox’ kræver JavaScript for at implementere tastaturinteraktion og opdatere tilstande - uden det annonceres elementet som en kontrol, men opfører sig ikke som en, hvilket er værre end almindelig HTML.
Hvordan kontrollerer jeg, om mine ARIA-roller er korrekte?
Kombiner automatiseret og manuel test. Kør axe DevTools, WAVE eller Lighthouse for at opdage ugyldige roller og manglende påkrævede attributter, og test derefter med NVDA, JAWS og VoiceOver for at bekræfte oplysninger og tastaturadfærd. Tilgængelighedspanelet i Chrome og Firefox DevTools viser den beregnede rolle og afslører alle roller, som browseren tilsidesætter eller ignorerer.
Ofte stillede spørgsmål
Hvad er ARIA-roller, og hvordan fungerer de?
ARIA-roller er værdier i rolleattributten, der definerer identiteten af et element i tilgængelighedstræet, så skærmlæsere annoncerer det korrekt. De ændrer kun semantik, ikke udseende, fokus eller tastaturadfærd. WAI-ARIA 1.2-specifikationen definerer seks rollekategorier og mere end 80 konkrete roller, hver med påkrævede tilstande og egenskaber.
Hvornår skal jeg bruge ARIA-roller i stedet for indbygget HTML?
Brug kun ARIA-roller, når intet native HTML-element giver den semantik, du har brug for. Indbyggede elementer som <button>, <nav> og <input type='checkbox'> har implicitte roller plus indbygget tastaturunderstøttelse og tilstandsstyring. Den første regel for ARIA-brug er at foretrække indbygget semantik, og kun at tilføje eksplicitte roller for brugerdefinerede widgets eller ældre markup, kan du ikke omstrukturere.
Hvad er forskellen mellem ARIA-roller og ARIA-attributter?
ARIA-roller svarer 'hvad er dette element', mens ARIA-attributter såsom aria-udvidet, aria-markeret og aria-label svarer 'hvilken tilstand er det i' eller 'hvad hedder det'. Rollerne og deres påkrævede attributter arbejder sammen: Som eksempler på ariaroller er role='checkbox' ufuldstændig uden aria-markeret, og role='combobox' skal udvides med aria plus en kontrolleret listeboks.
Kan jeg bruge ARIA-roller på ethvert HTML-element?
ARIA-roller kan anvendes på de fleste elementer, men nogle kombinationer er ugyldige eller skadelige. Abstrakte roller som widget og input bør aldrig forfattes. Ændring af et links rolle til role='button' bryder den forventede adfærd af linket, og role='præsentation' på et fokuserbart element fjerner dets semantik, mens det efterlades i tabulatorrækkefølge.
Fungerer ARIA-roller uden JavaScript?
Dokumentstruktur og skelsættende roller fungerer uden JavaScript, fordi de kun ændrer semantik. Widget-roller som tab, skyder og combobox kræver JavaScript for at implementere tastaturinteraktion og opdateringstilstande - uden det annoncerer elementet sig selv som en kontrol, men opfører sig ikke som en, hvilket er værre end almindelig HTML.
Hvordan kontrollerer jeg, om mine ARIA-roller er korrekte?
Kombiner automatiseret og manuel test. Kør ax DevTools, WAVE eller Lighthouse for at opdage ugyldige roller og manglende påkrævede attributter, og test derefter med NVDA, JAWS og VoiceOver for at bekræfte meddelelser og tastaturadfærd. Tilgængelighedspanelet i Chrome og Firefox DevTools viser den beregnede rolle og afslører alle roller, som browseren tilsidesætter eller ignorerer.
Adgang på 5 minutter
Accessibilidad widget med en gratis plan for empezar hoy mismo