Lista över ARIA-roller: Bästa referenser jämfört

ARIAs fullständiga rollista består av 82 värden definierade i W3C:s WAI-ARIA 1.2-specifikation, organiserade i sex funktionella kategorier: dokumentroller, landmärkesroller, widgetroller, strukturroller, fönsterroller och abstrakta roller. Valet av lämplig referens för att konsultera dessa beror på om du behöver en snabb tabell, dokumentation med kodexempel eller en beslutsguide om när varje roll ska tillämpas.

Viktiga punkter

• WAI-ARIA 1.2-specifikationen definierar 82 roller, men endast en liten del används i det dagliga arbetet med en tillgänglig XHTML/CSS-webbplats.
• Den första ARIA-regeln gäller fortfarande: om det finns ett inbyggt HTML-element med den semantik du behöver, använd det istället för att lägga till en roll.
• Abstrakta roller (som role="widget" eller role="input") får aldrig skrivas i märkningen; de fungerar endast som en taxonomisk bas.
• En användbar referens för front-end bör inkludera rollen, dess obligatoriska ARIA-attribut, tillåtna tillstånd och ett exempel på verklig märkning.
• Landmärkes- och widgetroller är där de flesta fel som upptäcks av automatiska granskare som axe-core eller Lighthouse är koncentrerade.

Vad är en ARIA-roll och varför behöver du en pålitlig lista

En ARIA-roll är ett värde som tilldelas ett element via attributet role för att kommunicera till hjälpmedel vilken typ av komponent det representerar. Webbläsaren exponerar denna roll via tillgänglighetsträdet, och en skärmläsare som NVDA, JAWS eller VoiceOver översätter det till ett specifikt uttal: “knapp”, “flik”, “region”, “dialogruta”.

WAI-ARIA-specifikationen, som underhålls av W3C inom ARIA-arbetsgruppen, definierar varje roll tillsammans med dess tillåtna tillstånds- och egenskapsattribut. Version 1.2 är den nuvarande stabila rekommendationen, och ARIA 1.3 är under utveckling. För en utvecklare som arbetar med XHTML och CSS är rollistan inte en dekorativ katalog: varje felaktigt tillämpat värde skapar en konflikt mellan elementets inbyggda semantik och den deklarerade, och skärmläsare löser denna konflikt på olika sätt beroende på webbläsare.

Den officiella dokumentationen för ARIA-roller på MDN (Mozilla Developer Network) är den mest konsulterade tekniska referensen på spanska och engelska, men den är inte den enda. Det finns referensblad, mönsterguider och valideringsverktyg som täcker olika behov. Att jämföra dem hjälper dig att välja den som passar ditt arbetsflöde.

De sex kategorierna av ARIA-roller

Den officiella taxonomin grupperar rollerna efter funktion. Att känna till kategorierna förhindrar att man letar i fel lista.

Dokumentroller. Beskriver strukturen på en sida eller sektion: article, document, feed, heading, img, list, listitem, math, none, note, presentation, row, separator, table, term, toolbar, tooltip. Många duplicerar inbyggda HTML-element och skrivs därför sällan för hand.

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

Landmärkesroller. Definierar navigerbara regioner på sidan: banner, complementary, contentinfo, form, main, navigation, region, search. Detta är det som används mest på webbplatser med ofullständig HTML-semantik.

Widgetroller. Representerar interaktiva kontroller: button, checkbox, gridcell, link, menuitem, menuitemcheckbox, menuitemradio, option, progressbar, radio, scrollbar, searchbox, slider, spinbutton, switch, tab, tabpanel, textbox, treeitem. Kräver fokus- och tangentbordshantering.

Strukturroller. Organisationswidgetar inkluderar: application, grid, group, listbox, menu, menubar, radiogroup, tablist, tree, treegrid, rowgroup, columnheader, rowheader.

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

Fönsterroller. Hantering av överlagrat eller modalt innehåll: alertdialog, dialog.

Abstrakta roller. Inga element skrivs i märkningen: command, composite, input, landmark, range, roletype, section, sectionhead, select, structure, widget, window. De används för att specifikationen ska kunna ärva egenskaper mellan roller.

Jämförelse: de bästa referenserna för ARIA-roller

Följande tabell jämför de referenser som är mest använda av spansktalande utvecklare baserat på praktiska kriterier.

Referens	Typ	Språk	Kodexempel	Idealisk för
MDN Web Docs (ARIA-roller)	Officiell dokumentation	Flerspråkig (inkl. spanska)	Ja, per roll	Djup teknisk konsultation
WAI-ARIA 1.2 (W3C)	Normativ specifikation	Engelska	Nej	Verifiera exakt beteende
WAI-ARIA Authoring Practices Guide	Mönsterguide	Engelska	Ja, fullständiga mönster	Implementera widgets med tangentbord
Referensblad (cheat sheet)	Sammanfattande tabell	Engelska	Minimala	Snabb genomgång i editorn
accessibility.build (ARIA-referens)	Praktisk referens	Engelska	Ja	Lära sig med kommenterade exempel
Granskare (axe-core, Lighthouse)	Verktyg	Flerspråkig	Nej	Upptäcka ogiltiga roller

Valet beror på situationen. Under skrivandet av märkningen vinner ett kompakt referensblad i hastighet. Vid felsökning av en widget som inte uttalas korrekt är W3C-specifikationen och WAI:s mönsterguide de källor som löser tvivlet.

Hur man avgör vilken roll som ska tillämpas: praktiska kriterier

Det rätta beslutet börjar nästan alltid med att utesluta ARIA. Dessa kriterier, i ordning, förhindrar de flesta fel.

1. Finns det ett inbyggt HTML-element? En <button> har redan den implicita rollen av en button. Att lägga till role="button" är redundant och kan introducera konflikter.
2. Kräver rollen obligatoriska attribut? role="checkbox" kräver aria-checked. role="slider" kräver aria-valuenow, aria-valuemin och aria-valuemax. Om du inte kan underhålla dessa tillstånd skadar rollen mer än den hjälper.
3. Innebär rollen tangentbordshantering? Widgetroller kräver navigering med pilar, Home, End och Esc beroende på mönster. En role="tablist" utan pilhantering är värre än att inte ha den alls.
4. Är rollen abstrakt? Om den finns i listan över abstrakta roller ska den inte skrivas.
5. Är rollen föråldrad eller ur bruk? Vissa värden ändrades mellan ARIA 1.0 och 1.2. Konsultera alltid den aktuella versionen.

Den första regeln för att använda ARIA, erkänd i W3C:s teknikguide, är principen: använd inbyggd HTML när det är möjligt. ARIA är en patch för när HTML inte räcker till, inte en ersättning.

Relaterat: IAAP CPACC / WAS Certification — La certificación profesional que acredita tu experiencia and accesibilidad.

Vanliga fel vid konsultation och tillämpning av rollistan

Ett vanligt fel består i att kopiera en roll från ett referensblad utan att kontrollera dess obligatoriska attribut. role="combobox" i ARIA 1.2 ändrades jämfört med 1.0 och förväntar sig nu aria-expanded och en relation till en listbox via aria-controls. Att tillämpa den gamla versionen bryter uttalet i uppdaterade skärmläsare.

Det är också vanligt att använda role="presentation" eller role="none" för att “städa upp” semantiken utan att förstå att det eliminerar elementet från tillgänglighetsträdet, inklusive dess barn i vissa fall. Detta förekommer också ofta med role="application", vilket överför all tangentbordskontroll till widgeten och inaktiverar skärmläsarens genvägar; den är reserverad för komplexa webbapplikationer, inte för formulär.

Duplicerade landmärkesroller skapar förvirring: två role="main" på samma sida, eller en role="banner" inuti en <article>, producerar en inkonsekvent regionnavigering. Validering med axe-core eller webbläsarens tillgänglighetsverktyg upptäcker flera av dessa fall, även om inget automatiskt verktyg ersätter testning med en riktig skärmläsare.

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

Verktyg för att validera roller i din märkning

Kontroll av roller kombinerar manuell inspektion och automatisering. DevTools i Chrome och Firefox inkluderar en tillgänglighetspanel som visar trädet precis som operativsystemet tar emot det, med den beräknade rollen för varje nod. Det är det mest direkta sättet att se om en deklarerad roll överlever eller skrivs över av den inbyggda semantiken.

axe-core, integrerat i Lighthouse och tillgängligt som tillägg, markerar ogiltiga roller, saknade obligatoriska attribut och motsägelsefulla kombinationer. Tillägget Accessibility Insights for Web, baserat på axe-regler, lägger till guidade kontroller. För tester med riktiga användare erbjuder NVDA på Windows och VoiceOver på macOS den slutgiltiga verifieringen: ingen validerare kan upptäcka om uttalet är begripligt i sitt sammanhang.

MDN:s tillgänglighetsdokumentation och W3C:s WAI-ARIA mönsterguide är de två källor man bör ha öppna under utvecklingen. Den första förklarar varje roll; den andra visar hur de kombineras i fullständiga komponenter.

Källor & vidare läsning

• WAI-ARIA — Wikipedia: Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) is a technical specification published by the World Wide Web Consortium (W3C) that…

Vanliga frågor

Hur många ARIA-roller finns det?

W3C WAI-ARIA 1.2-specifikationen definierar totalt 82 roller, uppdelade mellan dokument-, landmärkes-, widget-, struktur-, fönster- och abstrakta roller. I detta sammanhang används endast en bråkdel i vanlig utveckling: abstrakta roller skrivs aldrig och många dokumentroller duplicerar inbyggda HTML-element.

Vad är skillnaden mellan en ARIA-roll och ett ARIA-attribut?

En ARIA-roll beskriver vad ett element är, medan ARIA-attribut beskriver dess tillstånd eller egenskaper. Till exempel identifierar role="checkbox" komponenten och aria-checked="true" kommunicerar om den är markerad. Roller tilldelas med attributet role; tillstånd och egenskaper använder prefixet aria-.

Bör jag använda ARIA om jag redan använder semantisk HTML?

I de flesta fall, nej. Semantisk HTML exponerar redan implicita roller: <nav> motsvarar role="navigation" och <main> motsvarar role="main". Att lägga till rollen explicit är redundant och kan skapa konflikter. ARIA är reserverat för komponenter som HTML inte täcker, såsom flikar, träd eller komplexa menyer.

Vilka ARIA-roller får jag aldrig skriva i märkningen?

Abstrakta roller ska aldrig visas: command, composite, input, landmark, range, roletype, section, sectionhead, select, structure, widget och window. De existerar endast för att specifikationen ska kunna definiera arv av egenskaper mellan roller. Att skriva dem resulterar i en ogiltig roll som validerare flaggar.

Hur verifierar jag att en ARIA-roll fungerar korrekt?

Verifieringen kombinerar tre steg: inspektera tillgänglighetsträdet i webbläsarens DevTools för att bekräfta den beräknade rollen, köra en validerare som axe-core för att upptäcka saknade obligatoriska attribut, och testa med en riktig skärmläsare som NVDA eller VoiceOver. Endast det sista steget bekräftar att uttalet är begripligt för en person.

Ändras ARIA-roller mellan versioner av specifikationen?

Ja. ARIA 1.1 lade till roller som feed och switch, och ARIA 1.2 modifierade beteendet för combobox och konsoliderade andra värden. ARIA 1.3 är under utveckling. Att alltid konsultera den gällande versionen av specifikationen förhindrar tillämpning av föråldrade mönster som moderna skärmläsare tolkar på ett annat sätt.