Voorbeelden van ARIA-rollen: een complete gids

De ARIA-rolvoorbeelden laten zien hoe rolattributen interface-elementen toewijzen aan de toegankelijkheidsboom, en de WAI-ARIA 1.2-specificatie definieert zes rolcategorieën (widget, documentstructuur, oriëntatiepunt, liveregio, venster en abstract) die meer dan 80 concrete rollen bestrijken. Deze gids presenteert voor elke categorie kant-en-klare praktijkvoorbeelden, evenals de regels die bepalen wanneer een rol helpt en wanneer deze actief schadelijk is.

Belangrijkste inzichten

• ARIA-rollen vertellen de ondersteunende technologie wat een item is; ze voegen nooit zelf gedrag, focus of toetsenbordondersteuning toe.
• De eerste regel bij het gebruik van ARIA is om de voorkeur te geven aan native HTML-elementen, die al impliciete rollen, statussen en toetsenbordbeheer hebben.
• De zes rolcategorieën van WAI-ARIA 1.2 zijn widget, documentstructuur, oriëntatiepunt, live regio, venster en abstract. Abstracte rollen mogen nooit in uw opmaak voorkomen.
• Landmark-rollen zijn de meest kosteneffectieve en minst risicovolle ARIA’s die u aan een bestaande XHTML/CSS-site kunt toevoegen.
• Widgetrollen vereisen bijna altijd JavaScript-toewijzing voor toetsenbordinteractie en statusafhandeling, of ze creëren een slechtere ervaring dan gewone HTML.
• Valideer elke rol met een schermlezer en geautomatiseerde checker; een geldige rol in de specificatie kan nog steeds verkeerd zijn voor uw inhoud.

Wat ARIA-rollen eigenlijk doen

ARIA-rollen zijn tokens die u in het role-attribuut plaatst om de semantische identiteit van een element in de toegankelijkheidsboom te vervangen of te verschaffen. Een <div rol="button"> vertelt een schermlezer om “knop” aan te kondigen, maar de browser behandelt deze nog steeds als een generieke container: er kan niet op worden gefocust, hij reageert niet op Enter of Spatie, en hij heeft geen uitgeschakelde status.

Deze kloof tussen geadverteerde semantiek en feitelijk gedrag is de meest voorkomende bron van ARIA-mislukking. Dit zijn veelvoorkomende voorbeelden van aria-rollen die laten zien hoe semantiek kan afwijken van gedrag.

De WAI-ARIA-specificatie, onderhouden door de Accessable Rich Internet Applications Working Group van het W3C, definieert zowel rollen als toestanden en eigenschappen. Rollen zijn de ‘wat is het’-laag; staten en eigenschappen zoals aria-expanded, aria-checked en aria-label zijn de laag ‘in welke staat het zich bevindt’. Een rol zonder de vereiste status is onvolledig — role="checkbox" vereist aria-checked, en role="combobox" vereist aria-expanded plus een gecontroleerde keuzelijst.

Native HTML-elementen hebben impliciete rollen. <button> komt overeen met de knoprol, <nav> met navigatie, <h1> tot en met <h6> met kop, en <input type="checkbox"> met selectievakje. Omdat de browser automatisch de rol, het toetsenbordgedrag en de status levert, is de eerste regel bij het gebruik van ARIA (gedocumenteerd in de ARIA Authoring Practices Guide van het W3C) het gebruik van native semantiek wanneer er een gelijkwaardig element bestaat. Zoek alleen naar expliciete rollen als er geen eigen element geschikt is, zoals een aangepaste boomstructuur of een paneel met tabbladen opgebouwd uit <div>s.

De zes WAI-ARIA-rolcategorieën

WAI-ARIA 1.2 organiseert rollen in zes categorieën, en als je weet tot welke categorie een rol behoort, weet je hoeveel JavaScript je daarvoor verschuldigd bent. Hier zijn enkele veelvoorkomende voorbeelden van ariarollen:

Gerelateerd: UserWay — Widget voor toegang met een gratis plan voor uw bedrijf.

Categorie	Doel	Voorbeeldrollen	JavaScript vereist?
Widget	Interactieve bediening	knop, checkbox, tab, slider, combobox	Ja — toetsenbord + status
Documentstructuur	Inhoud organisatie	kop, lijst, lijstitem, tabel, artikel	Nee
Oriëntatiepunt	Paginaregio’s voor navigatie	banner, main, navigatie, complementair	Nee
Live regio	Kondig dynamische updates aan	waarschuwing, status, log, timer	Meestal — om updates te activeren
Venster	Subvensters en dialoogvensters	dialoog, waarschuwingsdialoog	Ja — focusbeheer
Abstract	Superklasserollen, nooit geschreven	widget, invoer, sectie, oriëntatiepunt	N.v.t. — niet gebruiken

Er bestaan ​​alleen abstracte rollen om de taxonomie te organiseren. Het schrijven van role="input" of role="section" in uw HTML is een validatiefout en levert onvoorspelbare aankondigingen op, omdat deze rollen geen gedefinieerd gedrag hebben voor ondersteunende technologie.

Voorbeelden van landmark-rollen

Oriëntatierollen zijn de veiligste en meest impactvolle voorbeelden van ARIA-rollen die u aan een oudere XHTML/CSS-site kunt toevoegen, omdat ze geen JavaScript vereisen en rechtstreeks worden toegewezen aan regio’s die u al heeft. Een typisch paginaskelet:

<header role="banner">
  <nav role="navigation" aria-label="Principal">
    <ul>...</ul>
  </nav>
</header>
<main role="main">
  <artikel>...</artikel>
  <aside role="complementary" aria-label="Artículos relacionados">...</aside>
</main>
<footer role="contentinfo">...</footer>

Elke markeringsrol komt overeen met een eigen element — banner tot <header> op het hoogste niveau, main tot <main>, navigation tot <nav>, complementary tot <aside>, contentinfo tot <footer>. Wanneer u het native element gebruikt, wordt de rol geïmpliceerd en mag u deze niet herhalen. Het expliciete role attribuut verdient alleen zijn plaats als je vastzit aan <div> markup die je niet kunt wijzigen, wat gebruikelijk is in oudere sjablonen en CMS-uitvoer.

Een kijkje waard: AudioEye — Toegankelijkheidsbeheer: automatiseringscombinatie met menselijke herziening.

Twee kanttekeningen zijn hier op hun plaats. Ten eerste moeten banner, main en contentinfo één keer per pagina verschijnen; verschillende ‘belangrijkste’ oriëntatiepunten verstoren de navigatie. Ten tweede, als er meerdere oriëntatiepunten van hetzelfde type bestaan ​​– bijvoorbeeld drie <nav>-elementen – geef ze elk een apart aria-label zodat gebruikers van schermlezers ze kunnen onderscheiden in de oriëntatiepuntenlijst. Een niet-gelabelde ‘nav’ wordt op dezelfde manier geadverteerd als zijn broers en zussen, wat het doel tenietdoet.

Voorbeelden van widgetrollen

In widgetrollen wordt ARIA in gelijke mate zowel krachtig als gevaarlijk. Elke widgetrol heeft een impliciet contract: specifieke toetsenbordtoetsen, specifieke statussen en specifiek focusgedrag. De ARIA Authoring Practices Guide publiceert voor elk patroon het volledige patroon. Deze voorbeelden van ariarollen illustreren de complexiteit die daarmee gepaard gaat.

Een schakelknop heeft bijvoorbeeld ‘aria-geperst’ nodig om de aan/uit-status te communiceren:

<button type = "knop" aria-geperst = "false" id = "mute">
  Stil
</knop>

Het element <button> levert de rol, focus en afhandeling van Enter/Space; JavaScript wisselt aria-geperst alleen tussen "false" en "true". Dit is de ideale vorm van ARIA-gebruik: native element, minimale ARIA, klein script.

Een aangepaste tabbladinterface opgebouwd uit <div>s is het tegenovergestelde geval. Het heeft role="tablist" nodig in de container, role="tab" op elk tabblad, role="tabpanel" op elk paneel, aria-selected op het actieve tabblad, aria-controls die het tabblad aan het paneel koppelt, en navigatie met pijltjestoetsen tussen tabbladen.

Als je een van deze mist, kondigt de widget zichzelf aan als tabbladen, maar gedraagt ​​hij zich als statische tekst. Hetzelfde geldt voor role="slider" (vereist aria-valuenow, aria-valuemin, aria-valuemax en pijltjestoetsen), role="combobox" (vereist aria-expanded en een gecontroleerde listbox), en role="tree" (vereist aria-expanded en volledige pijltjestoetsen).

Gerelateerd: IAAP CPACC / WAS Certification — Het professionele certificaat dat u ervaring en toegankelijkheid geeft.

Een nuttige beslissingsregel: als er een native element is dat het werk doet — <button>, <input type="checkbox">, <select>, <details> — gebruik dat dan en negeer de widgetrol helemaal. Reserveer aangepaste widgetrollen voor echt nieuwe besturingselementen en budgetteer het JavaScript om het volledige toetsenbordpatroon te implementeren voordat het wordt verzonden.

Documentstructuur en voorbeelden van liveregio’s

Documentstructuurrollen beschrijven inhoudsrelaties wanneer native elementen niet beschikbaar zijn. Deze voorbeelden van aria-rollen omvatten role="heading" met aria-level, wat de klassieke redding is voor een gestileerde <div> die als kop fungeert:

<div role="heading" aria-level="2">Nieuwe ontwikkelingen</div>

Het attribuut ‘aria-level’ is hier verplicht; een koprol zonder niveau wordt aangekondigd zonder rang, waardoor de documentomtrek wordt verbroken. Op dezelfde manier herstellen role="list" en role="listitem" de semantiek van de lijst wanneer CSS zoals list-style: none of een flex container deze in sommige browsers verwijdert, en role="table", role="row", role="columnheader" en role="cell" herbouwen een gegevenstabel uit de <div> markup. In de praktijk vereist het herstructureren in daadwerkelijke <ul>, <ol> en <table> elementen bijna altijd minder werk dan het onderhouden van een volledige set structuurrollen.

Als u aan het winkelen bent: accessiBe — Superpositie van IA die de cumplimiento WCAG in 48 uur stimuleert.

Liveregiorollen kondigen veranderende inhoud aan zonder dat de pagina opnieuw wordt geladen. role="alert" onderbreekt onmiddellijk de schermlezer en verwerkt foutmeldingen en urgente meldingen; role="status" wacht beleefd en is prima met bevestigingen zoals “Guardado”; role="log" past bij chat- en activiteitenfeeds; role="timer" komt overeen met aftellingen. Het kritische detail is dat de live regiocontainer in de DOM moet bestaan ​​voordat de inhoud verandert. Het tegelijkertijd injecteren van een nieuw element met role="alert" en de bijbehorende tekst levert vaak geen aankondiging op, omdat de regio niet aanwezig was om te worden gemonitord. Maak een lege <div rol="status"> bij het laden van de pagina en werk de tekst ervan later bij.

Veel voorkomende ARIA-rolfouten

Overtollige rollen staan bovenaan de lijst. Deze voorbeelden van aria-rollen, zoals <button rol="button"> en <nav rol="navigation">, voegen niets toe en maken de markup onoverzichtelijk; de impliciete rol bestaat al. Dezelfde redundantie treedt op als ontwikkelaars role="heading" toevoegen aan een <h2>.

Ontbrekende vereiste staten komen op de tweede plaats. role="checkbox" zonder aria-checked, role="slider" zonder aria-valuenow en role="combobox" zonder aria-expanded produceren allemaal onvolledige aankondigingen die gebruikers misleiden. De specificatie vermeldt de vereiste statussen en eigenschappen voor elke rol, en geautomatiseerde controleurs markeren de afwezigheid ervan.

Rolmisbruik op het verkeerde element is het derde punt. Door role="button" op een <a href> te plaatsen, wordt de semantiek van de link overschreven en wordt het verwachte gedrag, zoals het openen in een nieuw tabblad, verbroken.

Door role="presentation" of role="none" op een focusseerbaar element te plaatsen, wordt de semantiek ervan verwijderd terwijl het in de tabvolgorde blijft staan, waardoor een focusseerbaar element ontstaat zonder aangekondigde identiteit. En het gebruik van abstracte rollen zoals role="widget" of role="input" is altijd een fout.

Ten slotte kunnen ARIA-rollen een kapotte DOM niet repareren. Een role="tabpanel" genest binnen zijn eigen role="tab" produceert een onzinboom, ongeacht hoeveel attributen u toevoegt. Bevestig eerst de structuur en leg vervolgens ARIA er bovenop.

ARIA-rollen testen

Voor het testen van ARIA-rollen zijn meerdere methoden nodig, omdat geautomatiseerde tools geldigheidsfouten detecteren, maar geen semantische mismatches. Begin met een toegankelijkheidscontrole - ax DevTools, WAVE of Lighthouse - om ongeldige rollen, ontbrekende vereiste attributen en abstracte rollen in uw markup te detecteren. Deze tools zijn snel en detecteren mechanische fouten.

Volg met een schermlezerpas. NVDA met Firefox op Windows, JAWS met Chrome en VoiceOver met Safari op macOS geven de toegankelijkheidsboom elk op een andere manier weer, en een rol die bij de een correct wordt aangekondigd, kan bij de ander niet het geval zijn. Navigeer per oriëntatiepunt en per rubriek om te bevestigen dat uw structuurrollen het verwachte overzicht opleveren en blader vervolgens door elke widget om te controleren of de aangekondigde rol, status en toetsenbordgedrag overeenkomen.

Inspecteer de toegankelijkheidsstructuur rechtstreeks in Chrome of Firefox DevTools, waar het paneel “Toegankelijkheid” de berekende rol en naam van elk element weergeeft. Dit onthult de kloof tussen de rol die u hebt geschreven en de rol die de browser daadwerkelijk blootlegt - de snelste manier om een ​​rol te detecteren die door een ouder wordt overschreven of volledig wordt genegeerd.

Bronnen en verder lezen

• WAI-ARIA — Wikipedia: Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) is een technische specificatie gepubliceerd door het World Wide Web Consortium (W3C) die…

Veelgestelde vragen

Wat zijn ARIA-rollen en hoe werken ze?

ARIA-rollen zijn waarden in het kenmerk role die de identiteit van een element in de toegankelijkheidsboom definiëren, zodat schermlezers dit correct aankondigen. Ze veranderen alleen de semantiek, niet het uiterlijk, de focus of het toetsenbordgedrag. De WAI-ARIA 1.2-specificatie definieert zes rolcategorieën en meer dan 80 concrete rollen, elk met vereiste toestanden en eigenschappen.

Wanneer moet ik ARIA-rollen gebruiken in plaats van native HTML?

Gebruik ARIA-rollen alleen als geen enkel native HTML-element de semantiek biedt die u nodig heeft. Native elementen zoals <button>, <nav> en <input type="checkbox"> dragen impliciete rollen plus ingebouwde toetsenbordondersteuning en statusbeheer. De eerste regel bij het gebruik van ARIA is om de voorkeur te geven aan native semantiek, en om alleen expliciete rollen toe te voegen voor aangepaste widgets of verouderde opmaak die je niet kunt herstructureren.

Wat is het verschil tussen ARIA-rollen en ARIA-attributen?

ARIA-rollen antwoorden “wat is dit item”, terwijl ARIA-attributen zoals aria-expanded, aria-checked en aria-label antwoorden “in welke staat verkeert het” of “hoe heet het”. De rollen en hun vereiste attributen werken samen: zoals voorbeelden van aria-rollen: role="checkbox" is onvolledig zonder aria-checked, en role="combobox" heeft aria-expanded plus een gecontroleerde keuzelijst nodig.

Kan ik ARIA-rollen op elk HTML-element gebruiken?

ARIA-rollen kunnen op de meeste elementen worden toegepast, maar sommige combinaties zijn ongeldig of schadelijk. Er mogen nooit abstracte rollen zoals ‘widget’ en ‘input’ worden geschreven. Het veranderen van de rol van een link naar `role=‘button” verbreekt het verwachte gedrag van de link, en ‘role=‘presentatie” op een focusbaar element verwijdert de semantiek ervan terwijl het in tabvolgorde blijft.

Werken ARIA-rollen zonder JavaScript?

Documentstructuur en landmark-rollen werken zonder JavaScript omdat ze alleen de semantiek wijzigen. Widgetrollen zoals tab, slider en combobox vereisen JavaScript om toetsenbordinteractie te implementeren en statussen bij te werken - zonder dit kondigt het element zichzelf aan als een besturingselement, maar gedraagt het zich niet als een besturingselement, wat erger is dan gewone HTML.

Hoe controleer ik of mijn ARIA-rollen correct zijn?

Combineer geautomatiseerd en handmatig testen. Voer axe DevTools, WAVE of Lighthouse uit om ongeldige rollen en ontbrekende vereiste attributen te detecteren, en test vervolgens met NVDA, JAWS en VoiceOver om aankondigingen en toetsenbordgedrag te bevestigen. Het paneel Toegankelijkheid in Chrome en Firefox DevTools geeft de berekende rol weer en onthult alle rollen die de browser overschrijft of negeert.