Wat zijn ARIA-rollen? Een praktische gids voor ontwikkelaars

Wat zijn ARIA-rollen? ARIA-rollen zijn de woordenschat van 87 gedefinieerde waarden (vanaf WAI-ARIA 1.2) die ondersteunende technologieën vertellen wat een element is en hoe het zich moet gedragen, ongeacht de HTML-tag. Een rol als button, navigation of dialog wijst een generiek <div> of <span> toe aan een bekend widgettype, zodat schermlezers dit correct aankondigen en de juiste toetsenbordinteracties weergeven.

Waarom ARIA-rollen überhaupt bestaan

Om te begrijpen wat aria-rollen zijn, moet je inzien dat ze een structureel probleem oplossen dat HTML alleen niet kan oplossen. Native HTML-elementen hebben een impliciete semantiek: een <button> kondigt zichzelf aan als een knop, kan worden gefocust, reageert op Enter en de spatiebalk, en geeft indien nodig een ingedrukte status weer.

Wanneer ontwikkelaars aangepaste widgets maken (een combobox, een tabbladpaneel, een boomstructuur), gebruiken ze vaak <div> en <span>, die geen semantiek bevatten. ARIA-rollen dichten deze kloof door auteurs in staat te stellen expliciet ontbrekende betekenis te vermelden.

De WAI-ARIA-specificatie wordt onderhouden door de Accessible Rich Internet Applications Working Group van het W3C. De eerste versie, ARIA 1.0, werd in 2014 een W3C-aanbeveling; ARIA 1.1 volgde in 2017 en ARIA 1.2 bereikte de aanbevelingsstatus in 2023. Bij elke revisie werden rollen, statussen en eigenschappen toegevoegd, en elke versie is gekoppeld aan een document met schrijfpraktijken dat het verwachte gedrag van het toetsenbord beschrijft.

Een belangrijk onderscheid scheidt de rollen van de andere twee ARIA-categorieën. De rollen antwoorden: “Wat is dit?” Statussen en eigenschappen antwoorden: “In welke staat verkeert het?” en “Waar heeft het mee te maken?” Een role="checkbox" geeft het widgettype aan; aria-checked="true" geeft de huidige status aan. Het verwarren van deze twee is een van de meest voorkomende oorzaken van kapotte aangepaste widgets.

De zes rolcategorieën

Om te begrijpen wat ARIA-rollen zijn, helpt het om te weten dat de ARIA-specificatie rollen in zes families groepeert. Als u de familie begrijpt, kunt u voorspellen welke toestanden en eigenschappen een rol ondersteunt en welke toetsenbordpatronen van toepassing zijn.

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

Categorie	Doel	Representatieve rollen
Abstract	Superklassedefinities, nooit gebruikt in opmaak	widget, input, section
Widget	Interactieve bediening	button, checkbox, slider, tab
Documentstructuur	Pagina oriëntatiepunten en regio’s	banner, main, navigation, region
Oriëntatiepunt	Navigeerbare paginagebieden (subset van structuur)	banner, complementary, contentinfo, form
Live regio	Kondig dynamische inhoudswijzigingen aan	alert, status, log, timer
Venster	Browser- of applicatievensters	dialog, alertdialog

Abstracte rollen worden alleen gebruikt om de taxonomie te organiseren. Auteurs mogen nooit role="widget" of role="input" in de opmaak schrijven; dit resulteert in ongedefinieerd gedrag en de validatie mislukt. De overige vijf categorieën zijn de categorieën die u daadwerkelijk toepast.

Impliciete rollen en de eerste regel van ARIA

Elk HTML-element heeft een impliciete ARIA-functie (die uitlegt wat aria-rollen zijn) gedefinieerd door de HTML Accessibility API Mapping (AAM)-specificatie. Een <nav> element heeft een impliciete role="navigation". Een <ul> heeft een impliciete role="list". Een <h1> tot <h6> heeft role="heading". Een <table> heeft role="table".

De eerste W3C-regel over het gebruik van ARIA stelt duidelijk: als een native HTML-element of -attribuut al de vereiste semantiek en gedrag overbrengt, gebruik dit dan in plaats van een element opnieuw te gebruiken met ARIA. Het toevoegen van role="button" aan een <button> is niet nodig. Erger nog, als je role="button" toevoegt aan een <div>, krijg je de aankondiging maar geen gedrag: geen focus, geen toetsenbordactivatie, geen formulierinzending.

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

Redundantie is niet altijd onschadelijk. Het overschrijven van een impliciete rol kan de semantiek waar ondersteunende technologie van afhankelijk is, verliezen. Het schrijven van role="presentation" in een <table> elimineert de tabelsemantiek volledig, wat soms opzettelijk is bij opmaaktabellen, maar rampzalig bij datatabellen.

Hoe rollen interageren met staten en eigenschappen

Rollen fungeren als containers voor de staten en eigenschappen die ze ondersteunen. De specificatie definieert welke attributen geldig zijn voor welke rollen, en browsers geven alleen ondersteunde combinaties weer in de toegankelijkheidsboom.

Als u begrijpt wat aria-rollen zijn, weet u dat een role="checkbox" aria-checked ondersteunt met de waarden true, false of mixed. Een role="slider" ondersteunt aria-valuenow, aria-valuemin, aria-valuemax en optioneel aria-valuetext. Een role="combobox" ondersteunt aria-expanded, aria-controls en aria-activedescendant. Het toepassen van aria-checked op een role="button" is zinloos en zal in sommige schermlezers worden genegeerd of verwarrende resultaten opleveren.

Ook de benodigde eigenschappen zijn van belang. Een role="checkbox" zonder aria-checked is ongeldig; de staat is verplicht en niet optioneel. Een role="slider" zonder aria-valuenow zorgt ervoor dat de gebruiker de huidige waarde niet kan bepalen. De ARIA-specificatie bestempelt ze als ‘vereiste toestanden en eigenschappen’, en conformiteitscontroleurs zoals axe-core en IBM Equal Access Accessibility Checker wijzen op hun afwezigheid.

Rollen, de toegankelijkheidsstructuur en browserondersteuning

Browsers vertalen ARIA-functies naar API’s voor platformtoegankelijkheid (UIA op Windows, AXAPI op macOS, ATK/AT-SPI op Linux) en schermlezers gebruiken deze API’s. Een rol die geen enkele browser correct toewijst, is vrijwel onzichtbaar voor gebruikers.

Ondersteuning varieert per functie en browser. Kernfuncties zoals “Knop”, “Link”, “Header”, “Lijst” en “Navigatie” worden universeel ondersteund. Nieuwere of meer gespecialiseerde rollen (“feed”, “wiskunde”, “doc-voetnoot” uit de WAI-ARIA-module van Digital Publishing) hebben meer fragmentarische ondersteuning. De rol = “switch” wordt ondersteund in moderne browsers, maar werd tien jaar geleden op inconsistente wijze aangekondigd.

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

Het testen van de daadwerkelijke combinaties die uw doelgroep gebruikt, blijft essentieel. Een widget die in NVDA met Firefox werkt, gedraagt ​​zich mogelijk anders in VoiceOver met Safari, omdat de twee schermlezers verschillende platform-API’s gebruiken en verschillende heuristieken toepassen.

Oriëntatierollen en paginastructuur

Met oriëntatiepuntrollen kunnen gebruikers van schermlezers rechtstreeks naar delen van een pagina springen. De acht oriëntatierollen zijn ‘banner’, ‘complementair’, ‘contentinfo’, ‘formulier’, ‘hoofd’, ‘navigatie’, ‘regio’ en ‘zoeken’. Moderne HTML heeft voor de meeste native equivalenten: <header> wordt banner, <footer> wordt contentinfo, <main> wordt main, <nav> wordt navigation, <aside> wordt complementary, <form> met een toegankelijke naam wordt form, en <section> met een toegankelijke naam wordt regio.

Het gebruik van native elementen verdient de voorkeur omdat deze zelfs werken als CSS of JavaScript faalt en omdat ze het risico op rol-/attribuutconflicten verkleinen. Het search-oriëntatiepunt heeft geen native HTML-equivalent, dus role="search" is nog steeds de juiste keuze voor het zoekgebied.

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

Een veelgemaakte fout is om role="banner" toe te passen op een <div> die zich in een <main> of <article> bevindt. Oriëntatiepuntrollen creëren alleen oriëntatiepunten als ze niet binnen bepaalde andere rollen zijn genest; een banner binnen main zal helemaal niet als oriëntatiepunt worden weergegeven. Locatie in het DOM is net zo belangrijk als de rolwaarde. Voor degenen die zich afvragen wat ariarollen zijn: deze oriëntatiepunten vormen een belangrijk onderdeel van de specificatie.

Live regiorollen

Bij het overwegen van wat ariarollen zijn, kondigen live regionale rollen inhoudswijzigingen aan zonder de focus te veranderen. De vier liveregiofuncties zijn alert, status, log en timer, evenals de meer algemene marquee. Elk heeft impliciet een ‘aria-live’-waarde: ‘alert’ en ‘log’ impliceren in de praktijk respectievelijk ‘assertief’ en ‘beleefd’, terwijl ‘status’ ‘beleefd’ impliceert.

Kiezen tussen ‘alert’ en ‘status’ is een ontwerpbeslissing met reële gevolgen. Een ‘waarschuwing’ stopt alles wat de schermlezer leest, wat geschikt is voor fouten en urgente meldingen, maar schadelijk als het overmatig wordt gebruikt. Een status wacht op een pauze, die samenvalt met voortgangsberichten en bevestigingsteksten.

Live-regio’s moeten in de DOM bestaan ​​voordat de inhoud verandert. Het tegelijkertijd invoegen van een role="alert" element en de bijbehorende tekst resulteert vaak in geen aankondiging, omdat de regio niet bestond op het moment van de wijziging. Het betrouwbare patroon is om een ​​leeg livegebied weer te geven bij het laden van de pagina en de tekstinhoud later bij te werken.

Wanneer u ARIA-rollen NIET gebruikt

De tweede regel bij het gebruik van ARIA is dat auteurs de oorspronkelijke semantiek niet mogen veranderen tenzij dit echt nodig is. De vijfde regel stelt dat elk interactief element, ongeacht zijn functie, toegankelijk en focusseerbaar moet zijn via het toetsenbord.

Het toevoegen van een rol voegt geen gedrag toe. role="button" op een <div> zorgt ervoor dat deze niet kan focussen, niet reageert op invoer of spatiebalk en het formulier niet verzendt. U moet tabindex="0" toevoegen, een toetsaanslaghandler voor invoer en spatie, en vaak “rolgeschikt” statusbeheer. Op dit moment vereist het gebruik van een echte “” minder code en minder fouten.

Sommige rollen zijn actief schadelijk als ze verkeerd worden toegepast. role="presentation" en role="none" verwijderen de semantiek van een element en, in sommige implementaties, van de vereiste afstammelingen ervan. Door role="application" toe te passen, worden schermlezers in een modus gezet waarin ze stoppen met het onderscheppen van toetsaanslagen, waardoor gebruikers in de val kunnen lopen als de aangepaste toetsenbordbediening onvolledig is.

Een beslissingskader voor het kiezen van rollen

Door een korte reeks te doorlopen, worden de meeste ARIA-rolfouten voorkomen. Volg deze stappen om te begrijpen wat ARIA-rollen zijn en hoe u deze kunt gebruiken:

1. Identificeer de widget of regio. Noem in gewone taal wat het element eigenlijk is.
2. Controleer of er een native HTML-equivalent is. Raadpleeg de HTML-AAM-toewijzing. Als <knop>, <select>, <details> of <dialoog> past, gebruik deze dan.
3. Als er geen native element past, selecteer dan de dichtstbijzijnde ARIA-rol. Controleer of dit bestaat in de huidige specificatie en niet abstract is.
4. Voeg de vereiste staten en eigenschappen toe. Controleer de definitie van de rol op verplichte attributen.
5. Implementeer het toetsenbordinteractiepatroon. Volg de WAI-ARIA Authoring Practices Guide voor het widgettype.
6. Test met minimaal twee schermlezer- en browsercombinaties. Controleer aankondigingen, statussen en toetsenbordverloop.

In de stappen drie tot en met zes treden de meeste aangepaste widgetfouten op. Als u het toetsenbordpatroon in stap vijf overslaat, ontstaat er een widget die correct adverteert, maar niet werkt, wat aantoonbaar erger is dan helemaal geen ARIA.

Test- en validatietools

Geautomatiseerde tools detecteren structurele fouten: ongeldige rolwaarden, ontbrekende vereiste eigenschappen en rollen die worden toegepast op elementen die deze niet ondersteunen. axe-core, de motor achter veel browserextensies, controleert een gedefinieerde subset van ARIA-regels. Ook de IBM Equal Access Accessibility Checker en de eigen Nu HTML Checker van het W3C laten rolmisbruik zien.

Geautomatiseerde tools kunnen niet verifiëren of een rol de juiste aankondiging oplevert en of toetsenbordinteractie werkt. Handmatig testen met NVDA en Firefox, JAWS en Chrome, of VoiceOver en Safari is nog steeds vereist. De Accessibility Insights for Web-extensie combineert geautomatiseerde controles met een begeleide handmatige beoordeling, inclusief toetsenbord- en schermlezerverificatie.

De ARIA-specificatie zelf, de WAI-ARIA Authoring Practices Guide en het HTML-AAM mapping-document zijn de gezaghebbende referenties voor wat aria-rollen zijn. De MDN Web Docs ARIA Reference is een handige en goed geselecteerde secundaire bron die voor elke rol naar de specificatie verwijst.

Belangrijkste conclusies

• ARIA-rollen verklaren wat een element is; WAI-ARIA 1.2 definieert 87 rollen in zes categorieën en abstracte rollen verschijnen mogelijk nooit in de opmaak.
• Native HTML-elementen hebben impliciete rollen en ingebouwd gedrag, dus de eerste regel bij het gebruik van ARIA is om ze te verkiezen boven div plus role.
• Rollen vereisen hun ondersteunde statussen en eigenschappen: een role="checkbox" zonder aria-checked is ongeldig en kan niet worden gebruikt.
• Het toevoegen van een rol voegt nooit toetsenbordgedrag of focusbaarheid toe; deze moeten afzonderlijk worden geïmplementeerd en getest.
• De rollen Landmark en Live Region hebben locatie- en timingregels die bepalen of ze werken of niet.
• Geautomatiseerde inspecteurs ontdekken alleen structurele fouten; het testen van schermlezers voor verschillende browsercombinaties is nog steeds vereist.

Om te begrijpen wat ARIA-rollen zijn, moet u er rekening mee houden dat ze het doel van een element voor ondersteunende technologie definiëren.

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 in eenvoudige bewoordingen?

ARIA-rollen zijn labels die u aan HTML-elementen koppelt om ondersteunende technologie te vertellen wat het element vertegenwoordigt. Een <div role="button"> wordt aangekondigd als een knop in plaats van als algemene tekst. Rollen leveren wat betekent dat de onderliggende tag niet voorziet, maar ze voegen op zichzelf geen gedrag, focusafhandeling of toetsenbordondersteuning toe.

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

Rollen beschrijven het type van een element, terwijl attributen de staat, waarde of relaties ervan beschrijven. role="slider" identificeert een schuifregelaar; aria-valuenow="50" rapporteert zijn huidige positie en aria-labelledby verwijst naar zijn label. Rollen en attributen worden samen gebruikt en elke rol definieert welke attributen deze ondersteunt.

Hoeveel ARIA-rollen zijn er?

WAI-ARIA 1.2 definieert 87 rollen gegroepeerd in zes categorieën: abstract, widget, documentstructuur, oriëntatiepunt, liveregio en venster. Abstracte rollen zoals ‘widget’ en ‘input’ bestaan alleen voor de interne taxonomie van de specificatie en mogen nooit in HTML worden geschreven. Het aantal groeit met elke specificatieherziening.

Moet ik ARIA-rollen gebruiken in plaats van semantische HTML?

Nee. De eerste regel voor het gebruik van ARIA zegt dat je de voorkeur geeft aan een native HTML-element wanneer er een bestaat met de vereiste semantiek en gedrag. Gebruik <button> in plaats van <div role="button">, en <nav> in plaats van <div role="navigation">. ARIA-rollen zijn een fallback voor gevallen waarin geen geschikt native element bestaat.

Werken ARIA-rollen in alle browsers en schermlezers?

Kernrollen zoals button, link, heading en navigation worden betrouwbaar ondersteund door moderne browsers en schermlezers. Nieuwere of meer gespecialiseerde rollen, waaronder die in de Digital Publishing-module, bieden meer variabele ondersteuning. Alleen door te testen met de specifieke browser- en schermlezercombinaties die uw doelgroep gebruikt, kunt u er zeker van zijn.

Kan het toevoegen van een ARIA-rol de toegankelijkheid verstoren?

Ja. Als u een impliciete rol overschrijft, kan nuttige semantiek verloren gaan, bijvoorbeeld wanneer role="presentation" wordt toegepast op een gegevenstabel. Het toepassen van role="application" kan gebruikers blokkeren als de aangepaste toetsenbordbediening onvolledig is. Overtollige rollen in native elementen zorgen voor onnodige ruis en leiden soms tot tegenstrijdige aankondigingen.