Exempel på ARIA-roller: En komplett guide

Av Niquelao Resource Desk · Uppdaterad 28 september 2026

ARIA-rollexemplen visar hur rollattribut kartlägger gränssnittselement till tillgänglighetsträdet, och WAI-ARIA 1.2-specifikationen definierar 6 rollkategorier – widget, dokumentstruktur, landmärke, levande region, fönster och abstrakt – som täcker mer än 80 konkreta roller. Den här guiden presenterar praktiska exempel som är klara att kopiera för varje kategori, samt reglerna som avgör när en roll hjälper och när den aktivt skadar.

Viktiga punkter

ARIA-roller berättar för hjälpmedelstekniken vad ett föremål är; de lägger aldrig till beteende, fokus eller tangentbordsstöd på egen hand.
Den första regeln för att använda ARIA är att föredra inbyggda HTML-element, som redan har implicita roller, tillstånd och tangentbordshantering.
De sex WAI-ARIA 1.2-rollkategorierna är widget, dokumentstruktur, landmärke, levande region, fönster och abstrakt - abstrakta roller ska aldrig visas i din uppmärkning.
Landmärkesroller är de mest kostnadseffektiva och minst riskfyllda ARIA-roller du kan lägga till på en befintlig XHTML/CSS-webbplats.
Widgetroller kräver nästan alltid JavaScript-mappning för tangentbordsinteraktion och tillståndshantering, eller så skapar de en sämre upplevelse än vanlig HTML.
Validera varje roll med en skärmläsare och automatiserad kontrollör; en giltig roll i specifikationen kan fortfarande vara fel för ditt innehåll.

Vad ARIA-roller faktiskt gör

ARIA-roller är tokens som du placerar i “role”-attributet för att ersätta eller tillhandahålla den semantiska identiteten för ett element i tillgänglighetsträdet. En <div role="button"> säger åt en skärmläsare att meddela “knapp”, men webbläsaren behandlar den fortfarande som en generisk behållare: den är inte fokuserbar, den svarar inte på Enter eller Space, och den har inte ett avaktiverat läge.

Denna klyfta mellan annonserad semantik och faktiskt beteende är den vanligaste källan till ARIA-fel. Dessa är vanliga ariarollsexempel på hur semantik kan avvika från beteende.

WAI-ARIA-specifikationen, som underhålls av W3C:s arbetsgrupp för åtkomliga rika internetapplikationer, definierar roller såväl som tillstånd och egenskaper. Roller är “vad är det”-lagret; tillstånd och egenskaper som aria-expanderade, aria-checked och aria-label är lagret “vilket skick är det i”. En roll utan dess nödvändiga tillstånd är ofullständig – role="checkbox" kräver aria-checked och role="combobox" kräver aria-expanded plus en kontrollerad listbox.

Inbyggda HTML-element har implicita roller. <knapp> motsvarar knapprollen, <nav> till navigering, <h1> till <h6> till rubrik och <input type="checkbox"> till kryssrutan. Eftersom webbläsaren automatiskt tillhandahåller rollen, tangentbordets beteende och tillstånd, är den första regeln för att använda ARIA – dokumenterad i W3C:s ARIA Authoring Practices Guide – att använda inbyggd semantik närhelst ett likvärdigt element finns. Leta bara efter explicita roller när inget inbyggt element är lämpligt, till exempel en anpassad trädvy eller en flikpanel byggd från <div>.

De sex WAI-ARIA-rollkategorierna

WAI-ARIA 1.2 organiserar roller i sex kategorier, och att veta vilken kategori en roll tillhör talar om för dig hur mycket JavaScript du är skyldig den. Här är några vanliga exempel på ariaroller:

Relaterat: — Superposición de IA que promete cumplimiento WCAG en 48 horas.

Kategori	Syfte	Exempel roller	Behövs JavaScript?
Widget	Interaktiva kontroller	`button`, `checkbox`, `tab`, `slider`, `combobox`	Ja — tangentbord + status
Dokumentstruktur	Innehållsorganisation	`rubrik`, `lista`, `listitem`, `tabell`, `artikel`	Nej
Landmärke	Sidregioner för navigering	`banner`, `huvud`, `navigering`, `komplementär`	Nej
Levande region	Tillkännage dynamiska uppdateringar	`alert`, `status`, `logg`, `timer`	Vanligtvis — för att utlösa uppdateringar
Fönster	Underfönster och dialogrutor	`dialog`, `alertdialog`	Ja — fokushantering
Abstrakt	Superklassroller, aldrig författade	`widget`, `input`, `sektion`, `landmark`	N/A – använd inte

Abstrakta roller finns bara för att organisera taxonomin. Att skriva role="input" eller role="section" i din HTML är ett valideringsfel och producerar oförutsägbara meddelanden eftersom dessa roller inte har något definierat beteende för hjälpmedel.

Landmärke rollexempel

Landmärkesroller är de säkraste och mest effektfulla exemplen på ARIA-roller som du kan lägga till på en äldre XHTML/CSS-webbplats eftersom de inte kräver något JavaScript och mappar direkt till regioner du redan har. Ett typiskt sidskelett:

<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>

Varje markörroll motsvarar ett inbyggt element - “banner” till "

Värt att titta på: — Accesibilidad gestionada: automatización combinada con revisión humana.

" på översta nivån, “main” till "

", “navigation” till "

", “komplementär” till "

", “contentinfo” till "". När du använder det inbyggda elementet är rollen underförstådd och du bör inte upprepa den. Det explicita role-attributet får sin plats endast när du har fastnat med <div>-markeringen som du inte kan ändra, vilket är vanligt i äldre mallar och CMS-utdata.

Två varningar är på sin plats här. Först måste banner, main och contentinfo visas en gång per sida; flera “huvudsakliga” landmärken stör navigeringen. För det andra, när flera landmärken av samma typ finns – säg tre <nav>-element – ge var och en en separat aria-etikett så att skärmläsare kan särskilja dem i landmärkeslistan. En omärkt “nav” annonseras på samma sätt som sina syskon, vilket motverkar syftet.

Widgetroller är där ARIA blir både kraftfull och farlig i lika stor utsträckning. Varje widgetroll har ett implicit kontrakt: specifika tangentbordstangenter, specifika tillstånd och specifikt fokusbeteende. ARIA Authoring Practices Guide publicerar hela mönstret för var och en. Dessa ariarollexempel illustrerar komplexiteten som är involverad.

En växlingsknapp behöver till exempel ‘aria-pressed’ för att kommunicera dess på/av-läge:

<button type="button" aria-pressed="false" id="mute">
  Silenciar
</button>

Elementet <button> tillhandahåller rollen, fokus och Enter/Space-hantering; JavaScript växlar bara aria-pressed mellan "false" och "true". Detta är den idealiska formen för ARIA-användning - inbyggt element, minimal ARIA, litet skript.

Ett anpassat flikgränssnitt byggt från <div>s är det motsatta fallet. Den behöver role="tablist" på behållaren, role="tab" på varje flik, role="tabpanel" på varje panel, aria-selected på den aktiva fliken, aria-kontroller som länkar fliken till panelen och piltangentens navigering mellan flikarna.

Relaterat: — La certificación profesional que acredita tu experiencia and accesibilidad.

Om du missar någon av dessa annonserar widgeten sig som flikar men beter sig som statisk text. Detsamma gäller role="slider" (kräver aria-valuenow, aria-valuemin, aria-valuemax och piltangenter), role="combobox" (kräver aria-expanded och en kontrollerad listbox) och role="tree" (kräver aria-expanded och full pil).

En användbar beslutsregel: Om det finns ett inbyggt element som gör jobbet — <knapp>, <input type="checkbox">, <select>, <details> – använd det och ignorera widgetrollen helt och hållet. Reservera anpassade widgetroller för helt nya kontroller och budgetera JavaScript för att implementera hela tangentbordsmönstret innan leverans.

Exempel på dokumentstruktur och levande region

Dokumentstrukturroller beskriver innehållsrelationer när inbyggda element inte är tillgängliga. Dessa ariarollsexempel inkluderar role="heading" med aria-level, som är den klassiska räddningen för en formaterad <div> som fungerar som en rubrik:

Värt att titta på: — Widget för accessibilidad med plan gratis för empezar Hoy Mismo.

<div role="heading" aria-level="2">Novedades del mes</div>

Attributet “aria-level” är obligatoriskt här - en rubrikroll utan nivå tillkännages utan rang, vilket bryter dokumentkonturen. På liknande sätt återställer role="list" och role="listitem" listsemantik när CSS som list-style: none eller en flexcontainer tar bort dem i vissa webbläsare och role="table", role=“row”, role="columnheader" och role="cell" bygger om en datatabell från .<div>. I praktiken kräver omstrukturering till faktiska

-,

- och

`-element nästan alltid mindre arbete än att underhålla en fullständig uppsättning strukturroller.

Live regionroller meddelar att innehållet ändras utan att sidan laddas om. role="alert" avbryter omedelbart skärmläsaren och tar emot felmeddelanden och brådskande meddelanden; role="status" väntar artigt och klarar sig bra med bekräftelser som “Guardado”; role="log" passar chatt- och aktivitetsflöden; role="timer" motsvarar nedräkningar. Den kritiska detaljen är att behållaren för levande region måste finnas i DOM innan innehållet ändras — att injicera ett nytt element med role="alert" och dess text samtidigt ger ofta inget meddelande, eftersom regionen inte var närvarande för att övervakas. Skapa en tom <div role="status"> vid sidladdning och uppdatera dess text senare.

Vanliga ARIA-rollmisstag

Överflödiga roller toppar listan. Dessa ariarollexempel, som <button role="button"> och <nav role="navigation">, lägger till ingenting och gör uppmärkningen belamrad; den implicita rollen finns redan. Samma redundans visas när utvecklare lägger till role="heading" till en <h2>.

Saknade obligatoriska tillstånd kommer i andra hand. role="checkbox" utan aria-checked, role="slider" utan aria-valuenow och role="combobox" utan aria-expanded producerar alla ofullständiga meddelanden som vilseleder användare. Specifikationen listar nödvändiga tillstånd och egenskaper för varje roll, och automatiska kontrollörer flaggar deras frånvaro.

Rollmissbruk på fel element är tredje. Att placera role="button" på en <a href> åsidosätter länksemantiken och bryter förväntat beteende som att öppna i en ny flik. Att placera role="presentation" eller role="none" på ett fokuserbart element tar bort dess semantik samtidigt som det lämnas i tabbordningen, vilket skapar ett fokuserbart element utan tillkännagiven identitet. Och att använda abstrakta roller som role="widget" eller role="input" är alltid ett fel.

Slutligen kan ARIA-roller inte fixa en trasig DOM. En role="tabpanel" kapslad i sin egen role="tab" producerar ett nonsensträd oavsett hur många attribut du lägger till. Fixa strukturen först, lägg sedan ARIA ovanpå.

Hur man testar ARIA-roller

Att testa ARIA-roller kräver flera metoder, eftersom automatiserade verktyg upptäcker giltighetsfel men inte semantiska felmatchningar. Börja med en tillgänglighetskontroll - ax DevTools, WAVE eller Lighthouse - för att upptäcka ogiltiga roller, saknade obligatoriska attribut och abstrakta roller i din uppmärkning. Dessa verktyg är snabba och upptäcker mekaniska fel.

Följ med ett skärmläsarpass. NVDA med Firefox på Windows, JAWS med Chrome och VoiceOver med Safari på macOS exponerar var och en för tillgänglighetsträdet på olika sätt, och en roll som tillkännager korrekt i en kanske inte i en annan. Navigera efter landmärke och genom rubrik för att bekräfta att dina strukturroller producerar den förväntade konturen, bläddra sedan igenom varje widget för att verifiera den annonserade rollen, tillståndet och tangentbordsbeteendet matchar.

Inspektera tillgänglighetsträdet direkt i Chrome eller Firefox DevTools, där panelen “Tillgänglighet” visar den beräknade rollen och namnet för ett element. Detta avslöjar gapet mellan rollen du skrev och rollen som webbläsaren faktiskt avslöjar – det snabbaste sättet att upptäcka en roll som åsidosätts av en förälder eller ignoreras helt.

Källor & vidare läsning

WAI-ARIA — Wikipedia: Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) är en teknisk specifikation publicerad av World Wide Web Consortium (W3C) som…

Vanliga frågor

Vad är ARIA-roller och hur fungerar de?

ARIA-roller är värden i “role”-attributet som definierar identiteten för ett element i tillgänglighetsträdet, så att skärmläsare meddelar det korrekt. De ändrar bara semantik, inte utseende, fokus eller tangentbordsbeteende. WAI-ARIA 1.2-specifikationen definierar sex rollkategorier och mer än 80 konkreta roller, var och en med nödvändiga tillstånd och egenskaper.

När ska jag använda ARIA-roller istället för inbyggd HTML?

Använd endast ARIA-roller när inget inbyggt HTML-element tillhandahåller den semantik du behöver. Inbyggda element som <button>, <nav> och <input type="checkbox"> har implicita roller plus inbyggt tangentbordsstöd och tillståndshantering. Den första regeln för ARIA-användning är att föredra inbyggd semantik, och att lägga till explicita roller endast för anpassade widgets eller äldre uppmärkning kan du inte omstrukturera.

Vad är skillnaden mellan ARIA-roller och ARIA-attribut?

ARIA-roller svarar “vad är det här föremålet”, medan ARIA-attribut som “aria-expanderade”, “aria-checked” och “aria-etikett” svarar “vilket tillstånd är det i” eller “vad heter det”. Rollerna och deras nödvändiga attribut fungerar tillsammans: som exempel på ariaroller är role="checkbox" ofullständig utan aria-checked, och role="combobox" behöver aria-expanded plus en kontrollerad listbox.

Kan jag använda ARIA-roller på vilket HTML-element som helst?

ARIA-roller kan tillämpas på de flesta element, men vissa kombinationer är ogiltiga eller skadliga. Abstrakta roller som “widget” och “input” bör aldrig skapas. Att ändra en länks roll till role="button" bryter det förväntade beteendet hos länken, och role="presentation" på ett fokuserbart element tar bort dess semantik samtidigt som den lämnas i tabbordning.

Fungerar ARIA-roller utan JavaScript?

Dokumentstruktur och landmärkesroller fungerar utan JavaScript eftersom de bara ändrar semantik. Widgetroller som “tab”, “slider” och “combobox” kräver JavaScript för att implementera tangentbordsinteraktion och uppdatera tillstånd - utan det annonseras elementet som en kontroll men beter sig inte som en, vilket är värre än vanlig HTML.

Hur kontrollerar jag om mina ARIA-roller är korrekta?

Kombinera automatiserad och manuell testning. Kör ax DevTools, WAVE eller Lighthouse för att upptäcka ogiltiga roller och saknade obligatoriska attribut, testa sedan med NVDA, JAWS och VoiceOver för att bekräfta uppläsningar och tangentbordsbeteende. Tillgänglighetspanelen i Chrome och Firefox DevTools visar den beräknade rollen och avslöjar alla roller som webbläsaren åsidosätter eller ignorerar.

Vanliga frågor

Vad är ARIA-roller och hur fungerar de?

ARIA-roller är värden i rollattributet som definierar identiteten för ett element i tillgänglighetsträdet, så att skärmläsare meddelar det korrekt. De ändrar bara semantik, inte utseende, fokus eller tangentbordsbeteende. WAI-ARIA 1.2-specifikationen definierar sex rollkategorier och mer än 80 konkreta roller, var och en med nödvändiga tillstånd och egenskaper.

När ska jag använda ARIA-roller istället för inbyggd HTML?

Använd endast ARIA-roller när inget inbyggt HTML-element tillhandahåller den semantik du behöver. Inbyggda element som <button>, <nav> och <input type='checkbox'> har implicita roller plus inbyggt tangentbordsstöd och tillståndshantering. Den första regeln för ARIA-användning är att föredra inbyggd semantik, och att lägga till explicita roller endast för anpassade widgets eller äldre uppmärkning kan du inte omstrukturera.

Vad är skillnaden mellan ARIA-roller och ARIA-attribut?

ARIA-roller svarar "vad är det här föremålet", medan ARIA-attribut som aria-expanderat, aria-markerat och aria-etikett svarar "vilket tillstånd är det i" eller "vad heter det". Rollerna och deras nödvändiga attribut fungerar tillsammans: som exempel på ariaroller är role='checkbox' ofullständig utan aria-markerad, och role='combobox' behöver aria-expanderad plus en kontrollerad listbox.

Kan jag använda ARIA-roller på vilket HTML-element som helst?

ARIA-roller kan tillämpas på de flesta element, men vissa kombinationer är ogiltiga eller skadliga. Abstrakta roller som widget och input bör aldrig skapas. Att ändra en länks roll till role='button' bryter det förväntade beteendet hos länken, och role='presentation' på ett fokuserbart element tar bort dess semantik samtidigt som den lämnas i tabbordning.

Fungerar ARIA-roller utan JavaScript?

Dokumentstruktur och landmärkesroller fungerar utan JavaScript eftersom de bara ändrar semantik. Widgetroller som tabb, skjutreglage och kombinationsruta kräver JavaScript för att implementera tangentbordsinteraktion och uppdateringstillstånd - utan det tillkännager elementet sig självt som en kontroll men beter sig inte som en, vilket är värre än vanlig HTML.

Hur kontrollerar jag om mina ARIA-roller är korrekta?

Kombinera automatiserad och manuell testning. Kör ax DevTools, WAVE eller Lighthouse för att upptäcka ogiltiga roller och saknade obligatoriska attribut, testa sedan med NVDA, JAWS och VoiceOver för att bekräfta meddelanden och tangentbordsbeteende. Tillgänglighetspanelen i Chrome och Firefox DevTools visar den beräknade rollen och avslöjar alla roller som webbläsaren åsidosätter eller ignorerar.

Añade accesibilidad på 5 minuter

Widget för accessibilidad med plan gratis för empezar Hoy Mismo