Vad är ARIA-roller? En praktisk guide för utvecklare

Varför ARIA-roller överhuvudtaget finns

För att förstå vad som är ariaroller måste man se att de löser ett strukturellt problem som HTML ensam inte kan lösa. Inbyggda HTML-element har implicit semantik: en <knapp> tillkännager sig själv som en knapp, kan fokuseras, svarar på Enter och mellanslagstangenten och visar ett nedtryckt läge när det behövs.

När utvecklare skapar anpassade widgets (en kombinationsruta, en flikpanel, en trädvy) använder de ofta <div> och <span>, som inte innehåller någon semantik. ARIA-roller täpper till denna lucka genom att tillåta författare att uttryckligen ange saknad semantik.

WAI-ARIA-specifikationen underhålls av W3C:s arbetsgrupp för åtkomliga rika internetapplikationer. Den första versionen, ARIA 1.0, blev en W3C-rekommendation 2014; ARIA 1.1 följde 2017, och ARIA 1.2 nådde status som rekommendation 2023. Roller, tillstånd och egenskaper lades till med varje revision, och var och en är länkad till ett dokument för författarpraxis som beskriver tangentbordets förväntade beteende.

En nyckelskillnad skiljer rollerna från de andra två ARIA-kategorierna. Rollerna svarar: “Vad är det här?” Tillstånd och egenskaper svarar: “I vilket skick är den?” och “Vad är det relaterat till?” En role="checkbox" deklarerar widgettypen; aria-checked="true" indikerar dess nuvarande tillstånd. Att blanda ihop de två är en av de vanligaste orsakerna till trasiga anpassade widgets.

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

De sex rollkategorierna

För att förstå vad ARIA-roller är, hjälper det att veta att ARIA-specifikationen grupperar roller i sex familjer. Genom att förstå familjen kan du förutsäga vilka tillstånd och egenskaper en roll stöder och vilka tangentbordsmönster som gäller.

Abstrakta roller används bara för att organisera taxonomin. Författare får aldrig skriva role="widget" eller role="input" i uppmärkning; detta resulterar i odefinierat beteende och validering misslyckas. De återstående fem kategorierna är de som du faktiskt tillämpar.

Implicita roller och den första regeln för ARIA

Varje HTML-element har en implicit ARIA-funktion (som förklarar vad som är aria-roller) definierad av HTML Accessibility API Mapping (AAM)-specifikationen. Ett <nav>-element har en implicit role="navigation". En <ul> har en implicit role="list". En <h1> till <h6> har role="heading". En <tabell> har role="table".

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

Den första W3C-regeln om att använda ARIA säger tydligt: ​​Om ett inbyggt HTML-element eller -attribut redan förmedlar den nödvändiga semantiken och beteendet, använd det istället för att återanvända ett element med ARIA. Det är inte nödvändigt att lägga till role="button" till en <button>. Ännu värre, om du lägger till role="button" till en <div> får du meddelandet men inget beteende: inget fokus, ingen tangentbordsaktivering, ingen formulärinlämning.

Redundans är inte alltid ofarligt. Att åsidosätta en implicit roll kan förlora den semantik som hjälpmedel är beroende av. Att skriva role="presentation" i en <tabell> eliminerar helt tabellsemantik, vilket ibland är avsiktligt med layouttabeller men katastrofalt med datatabeller.

Hur roller interagerar med stater och egenskaper

Roller fungerar som behållare för de tillstånd och egenskaper som de stöder. Specifikationen definierar vilka attribut som är giltiga för vilka roller, och webbläsare visar endast stödda kombinationer i tillgänglighetsträdet.

Att förstå vad som är ariaroller hjälper till att veta att en role="checkbox" stöder aria-checked med värdena true, false eller mixed. En role="slider" stöder aria-valuenow, aria-valuemin, aria-valuemax och eventuellt aria-valuetext. En role="combobox" stöder aria-expanded, aria-controls och aria-activedescendant. Att använda aria-checked på en role="button" är meningslöst och kommer att ignoreras eller ge förvirrande resultat i vissa skärmläsare.

De egenskaper som krävs är också viktiga. En role="checkbox" utan aria-checked är ogiltig; staten är obligatorisk och inte frivillig. En role="slider" utan aria-valuenow gör att användaren inte kan bestämma det aktuella värdet. ARIA-specifikationen etiketterar dem som “obligatoriska tillstånd och egenskaper”, och överensstämmelsekontroller som axe-core och IBM Equal Access Accessibility Checker påpekar att de saknas.

Roller, tillgänglighetsträdet och webbläsarstöd

Webbläsare översätter ARIA-funktioner till API:er för plattformstillgänglighet (UIA på Windows, AXAPI på macOS, ATK/AT-SPI på Linux), och skärmläsare använder dessa API:er. En roll som ingen webbläsare korrekt tilldelar är praktiskt taget osynlig för användarna.

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

Supporten varierar beroende på funktion och webbläsare. Kärnfunktioner som “Button”, “Link”, “Header”, “List” och “Navigation” stöds universellt. Nyare eller mer specialiserade roller (“flöde”, “matte”, “doc-fotnot” från Digital Publishings WAI-ARIA-modul) har mer ojämnt stöd. role=“switch” stöds i moderna webbläsare, men tillkännagavs inkonsekvent för ett decennium sedan.

Det är fortfarande viktigt att testa de faktiska kombinationer som din publik använder. En widget som fungerar i NVDA med Firefox kan bete sig annorlunda i VoiceOver med Safari, eftersom de två skärmläsarna använder olika plattforms-API:er och tillämpar olika heuristik.

Landmärkesroller och sidstruktur

Landmärkesroller gör att skärmläsare kan hoppa direkt till områden på en sida. De åtta landmärkesrollerna är “banner”, “komplementär”, “innehållsinformation”, “form”, “huvud”, “navigering”, “region” och “sökning”. Modern HTML har inbyggda motsvarigheter för de flesta: <header> blir banner, <sidfot> blir contentinfo, <main> blir main, <navigering> blir navigation, <aside> blir komplementär, <form> med ett tillgängligt namn blir form, och <section> med ett tillgängligt namn blir region.

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

Att använda inbyggda element är att föredra eftersom de fungerar även om CSS eller JavaScript misslyckas och eftersom de minskar risken för roll-/attributkonflikter. Landmärket Sök har ingen inbyggd HTML-motsvarighet, så role="search" är fortfarande det korrekta valet för sökregionen.

Ett vanligt misstag är att tillämpa role="banner" på en <div> som finns inuti en <main> eller <artikel>. Landmärkesroller skapar bara landmärken om de inte är kapslade i vissa andra roller; en “banner” inuti “main” kommer inte att visas som ett landmärke alls. Platsen i DOM är lika viktig som rollvärdet. För de som undrar vad som är ariaroller är dessa landmärken en viktig del av specifikationen.

Live Region Roller

När man överväger vad som är ariaroller tillkännager live regionala roller innehållsförändringar utan att ändra fokus. De fyra liveregionfunktionerna är alert, status, log och timer, såväl som den mer allmänna marquee. Var och en har ett “aria-live”-värde implicit: “alert” och “log” antyder i praktiken “assertive” respektive “polite”, medan “status” antyder “polite”.

Att välja mellan “varning” och “status” är ett designbeslut med verkliga konsekvenser. En “varning” stoppar allt som skärmläsaren läser, vilket är lämpligt för fel och brådskande meddelanden, men skadligt om det används överdrivet. En status väntar på en paus, som sammanfaller med förloppsmeddelanden och bekräftelsetexter.

Liveregioner måste finnas i DOM innan innehållet ändras. Att infoga ett role="alert"-element och dess text samtidigt resulterar ofta i inget meddelande eftersom regionen inte fanns vid tidpunkten för ändringen. Det tillförlitliga mönstret är att rendera en tom live-region vid sidladdning och uppdatera dess textinnehåll senare.

När man INTE ska använda ARIA-roller

Den andra regeln för att använda ARIA är att författare inte bör ändra den ursprungliga semantiken om de inte verkligen behöver det. Den femte regeln säger att varje interaktivt element, oavsett dess funktion, måste vara tillgängligt och fokuserbart via tangentbordet.

Att lägga till en roll lägger inte till beteende. role="button" på en <div> gör att den inte fokuserar, inte svarar på inmatning eller mellanslag och inte skickar formuläret. Du måste lägga till tabindex="0", en tangenttryckningshanterare för inmatning och utrymme, och ofta “roll-lämplig” tillståndshantering. Vid denna tidpunkt kräver användning av en riktig "" mindre kod och färre fel.

Vissa roller är aktivt skadliga när de används felaktigt. role="presentation" och role="none" tar bort semantik från ett element och, i vissa implementeringar, från dess nödvändiga avkomlingar. Genom att använda role="application" växlar skärmläsare till ett läge där de slutar fånga upp tangenttryckningar, vilket kan fånga användare om den anpassade tangentbordshanteringen är ofullständig.

Ett beslutsramverk för val av roller

Att arbeta igenom en kort sekvens förhindrar de flesta ARIA-rollfel. Följ dessa steg för att förstå vad ARIA-roller är och hur man använder dem:

1. Identifiera widgeten eller regionen. Namnge vad elementet faktiskt är på vanligt språk.
2. Sök efter en inbyggd HTML-motsvarighet. Se HTML-AAM-mappningen. Om <knapp>, <välj>, <detaljer> eller <dialog> passar, använd den.
3. Om inget inbyggt element passar, välj den närmaste ARIA-rollen. Verifiera att den finns i den aktuella specifikationen och inte är abstrakt.
4. Lägg till obligatoriska tillstånd och egenskaper. Kontrollera rollens definition för obligatoriska attribut.
5. Implementera tangentbordsinteraktionsmönstret. Följ WAI-ARIA Authoring Practices Guide för widgettypen.
6. Testa med minst två kombinationer av skärmläsare och webbläsare. Verifiera meddelanden, tillstånd och tangentbordsflöde.

Steg tre till sex är där de flesta anpassade widgetfel uppstår. Om du hoppar över tangentbordsmönstret i steg fem skapas en widget som annonserar korrekt men som inte fungerar, vilket utan tvekan är värre än att inte ha någon ARIA alls.

Test- och valideringsverktyg

Automatiserade verktyg upptäcker strukturella fel: ogiltiga rollvärden, saknade nödvändiga egenskaper och roller som tillämpas på element som inte stöder dem. axe-core, motorn bakom många webbläsartillägg, kontrollerar en definierad delmängd av ARIA-regler. IBM Equal Access Accessibility Checker och W3C:s egen Nu HTML Checker visar också rollmissbruk.

Automatiserade verktyg kan inte verifiera om en roll ger rätt meddelande eller om tangentbordsinteraktion fungerar. Manuell testning med NVDA och Firefox, JAWS och Chrome, eller VoiceOver och Safari krävs fortfarande. Tillägget Accessibility Insights for Web kombinerar automatiska kontroller med en guidad manuell utvärdering som inkluderar verifiering av tangentbord och skärmläsare.

Själva ARIA-specifikationen, WAI-ARIA Authoring Practices Guide och HTML-AAM-mappningsdokumentet är auktoritativa referenser för vad som är ariaroller. MDN Web Docs ARIA Reference är en bekväm och väl vald sekundär källa som refererar till specifikationen för varje roll.

Viktiga punkter

• ARIA-roller deklarerar vad ett element är; WAI-ARIA 1.2 definierar 87 roller i sex kategorier och abstrakta roller kanske aldrig visas i uppmärkningen.
• Inbyggda HTML-element har implicita roller och inbyggda beteenden, så den första regeln när du använder ARIA är att föredra dem framför “div” plus “roll”.
• Roller kräver deras tillstånd och egenskaper som stöds: en role="checkbox" utan aria-checked är ogiltig och kan inte användas.
• Att lägga till en roll lägger aldrig till tangentbordsbeteende eller fokuserbarhet; dessa måste implementeras och testas separat. – Rollerna Landmark och Live Region har plats- och tidsregler som avgör om de fungerar eller inte.
• Automatiserade inspektörer upptäcker endast strukturella fel; testning av skärmläsare för olika webbläsarkombinationer krävs fortfarande.

För att förstå vad som är ARIA-roller, kom ihåg att de definierar syftet med ett element för hjälpmedel.

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 i enkla termer?

ARIA-roller är etiketter som du fäster på HTML-element för att tala om för hjälpmedelsteknik vad elementet representerar. En <div role="button"> annonseras som en knapp snarare än som allmän text. Roller tillhandahåller mening som den underliggande taggen inte tillhandahåller, men de lägger inte till något beteende, fokushantering eller tangentbordsstöd på egen hand.

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

Roller beskriver typen av ett element, medan attribut beskriver dess tillstånd, värde eller relationer. role="slider" identifierar ett reglage; aria-valuenow="50" rapporterar sin nuvarande position och aria-labelledby pekar på sin etikett. Roller och attribut används tillsammans och varje roll definierar vilka attribut den stöder.

Hur många ARIA-roller finns det?

WAI-ARIA 1.2 definierar 87 roller grupperade i sex kategorier: abstrakt, widget, dokumentstruktur, landmärke, live region och fönster. Abstrakta roller som “widget” och “input” finns bara för specifikationens interna taxonomi och bör aldrig skrivas i HTML. Antalet växer med varje specifikationsrevidering.

Ska jag använda ARIA-roller istället för semantisk HTML?

Nej. Den första regeln för ARIA-användning säger att man föredrar ett inbyggt HTML-element närhelst det finns med den nödvändiga semantiken och beteendet. Använd <button> istället för <div role="button">, och <nav> snarare än <div role="navigation">. ARIA-roller är en reserv för fall där det inte finns något lämpligt inbyggt element.

Fungerar ARIA-roller i alla webbläsare och skärmläsare?

Kärnroller som button, link, heading och navigation stöds tillförlitligt av moderna webbläsare och skärmläsare. Nyare eller mer specialiserade roller, inklusive de i Digital Publishing-modulen, ger mer variabelt stöd. Bara genom att testa med den specifika kombinationen av webbläsare och skärmläsare som din publik använder kan du vara säker.

Kan tillägget av en ARIA-roll bryta tillgängligheten?

Ja. Att åsidosätta en implicit roll kan förlora användbar semantik, till exempel när role="presentation" tillämpas på en datatabell. Att använda role="application" kan blockera användare om anpassad tangentbordshantering är ofullständig. Redundanta roller i inbyggda element skapar onödigt brus och leder ibland till motstridiga meddelanden.