ARIA-rollen en -kenmerken: beste keuzes vergeleken

De ARIA-rollen en -attributen van de specifieke WAI-ARIA 1.2-specificatie van W3C tellen in de honderden, hoewel een handvol de meeste toegankelijkheidsproblemen in XHTML- en CSS-widgets oplost. Een rol definieert wat een element is en een attribuut de status of relaties, maar ARIA wijzigt het browsergedrag niet: elke toegevoegde rol vereist de implementatie van interactie met JavaScript.

Toegankelijke Rich Internet Applications (ARIA) is een W3C-specificatie die semantiek toevoegt aan HTML-elementen die deze niet in de oorspronkelijke vorm hebben. Een rol beschrijft wat een element is (een knop, een tab, een dialoog), terwijl een attribuut zijn status of zijn relaties beschrijft (aria-expanded, aria-controls, aria-labelledby). De eerste regel van ARIA, gepubliceerd door het W3C in ARIA gebruiken, is bot: als er een native HTML-element is dat al zijn werk doet, gebruik dat dan en voeg geen ARIA toe.

De reden is dat ARIA het browsergedrag niet wijzigt. Een <div role="button"> krijgt geen focus met Tab, reageert niet op de Enter-toets of spatie, en wordt niet samen met een formulier verzonden.

Het verandert alleen wat de ondersteunende technologie aankondigt. Alle interactie moet met JavaScript worden geïmplementeerd en zorgvuldig worden beheerd. In XHTML/CSS-projecten waar de HTML statisch is en de JS minimaal, betekent dit dat elk van de aria-rollen en attributen die worden toegevoegd een belofte is die uw code moet waarmaken.

De tweede regel van ARIA vraagt ​​om de oorspronkelijke semantiek niet te veranderen, tenzij dit onontbeerlijk is. Een <h2 role="tab"> doorbreekt de structuur van koppen en brengt schermlezers die per regio navigeren in verwarring. De derde regel vereist dat alle ARIA-bedieningselementen met een toetsenbord kunnen worden bediend. De vierde vraagt ​​om aria-hidden="true" niet te gebruiken op elementen die focus krijgen. De vijfde, en meest vergeten, herinnert ons eraan dat elk interactief element een toegankelijke naam vereist: een rol zonder label is een mute-knop.

Hoe te kiezen: criteria vóór de lijst

Het kiezen van een rol of attribuut is geen kwestie van smaak. Deze criteria, in volgorde toegepast, vermijden de meeste fouten met betrekking tot ariarollen en attributen:

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

1. Is er een native HTML-element? Zo ja, gebruik dit dan. <button>, <details>, <dialog>, <input type="checkbox"> omvatten meer cases dan mensen denken.
2. Heeft de widget dynamische statussen nodig? Als deze verandert tussen open/gesloten, geselecteerd/niet geselecteerd of uitgevouwen/samengevouwen, heeft u statusattributen nodig (aria-expanded, aria-selected, aria-pressed).
3. Heeft het relaties tussen elementen nodig? Relatieattributen (aria-controls, aria-labelledby, aria-describedby, aria-owns) verbinden stukken die de toegankelijkheidsboom niet uit de DOM kan afleiden.
4. Heeft het live aankondigingen nodig? Live regio’s (aria-live, role="status", role="alert") lossen updates op zonder de focus te verplaatsen.
5. Kan ik het onderhouden? Een complex ARIA-patroon zonder toetsenbord- of schermlezertests is erger dan niets hebben.

De onderhoudskosten zijn het meest genegeerde criterium. Een goed gemaakte role="tablist" vereist pijlsleutelbeheer, roterende tabindex, synchronisatie van aria-selected en aria-controls, en het correct verbergen van inactieve panelen. Als het team dat niet aankan, is een setje koppelingen met ankers toegankelijker en goedkoper.

Vergelijking van de meest nuttige ARIA-rollen

De volgende tabel vat de rollen samen die telkens terugkomen in echte audits, met hun native equivalent indien beschikbaar en de meest voorkomende valkuil.

Rol	Doel	Native alternatief	Veelvoorkomende valkuil
knop	Bedieningselement dat een actie uitvoert	<knop>	Voer geen Enter/Spacio-bewerking uit in tabindex="0"
link	Navigeer naar een andere URL	<a href>	Gebruiken voor acties die niet navigeren
dialoog	Modaal of niet-modaal venster	<dialoog>	Focus niet vastleggen of niet teruggeven bij het sluiten
tablijst / tab / tabpaneel	Tab-interface	Geen direct alternatief	aria-selected niet synchroniseren met het zichtbare paneel
menu / menuitem	Applicatiemenu	<select> of lijst met links	Gebruiken voor webnavigatiemenu’s
waarschuwing	Dringend en onmiddellijk bericht	role="status" voor geen urgentie	Overmatig gebruik waardoor de schermlezer overbelast raakt
status	Informatieve update	<uitvoer>	Voeg geen tekst in de DOM in vóór de actualisatie
voortgangsbalk	Voortgang van een taak	<voortgang>	aria-valuenow niet bijwerken
tooltip	Tooltip-beschrijving	titel (limitado)	Niet koppelen met aria-describedby
combobox	Veld met suggestielijst	<datalijst> (beperkt)	Aantal resultaten niet aankondigen

De keuze tussen role="alert" en role="status" is een goed voorbeeld van een beslissing met nuances met betrekking tot ariarollen en attributen. alert onderbreekt de huidige schermlezerlezing; status wacht tot de gebruiker klaar is. Voor een formuliervalidatiefout is alert geschikt. Voor “3 resultaten gevonden”, terwijl de gebruiker schrijft, is status correct en resulteert alert in opdringerig te zijn.

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

Onmisbare ARIA-attributen en hoe ze gecombineerd worden

De attributen worden geassocieerd met vier families, en elk lost een specifiek probleem op.

Labeling. aria-label geeft een naam als er geen zichtbare tekst is. aria-labelledby verwijst naar de id van een ander element en heeft de voorkeur als de tekst al op het scherm bestaat, omdat het één enkele bron van waarheid behoudt. aria-describedby voegt een langere beschrijving toe, zoals de helptekst van een veld. Het verschil is van belang: de naam is wat de gebruiker hoort bij het scherpstellen; de beschrijving is aanvullende context die kan worden onderbroken.

Statussen. aria-expanded (waar/onwaar) voor accordeons en vervolgkeuzemenu’s. aria-selected voor tabbladen en opties. aria-checked voor aangepaste selectievakjes, met de waarde mixed voor driestatenstaten. aria-pressed voor schakelknoppen. aria-disabled wanneer het element nog steeds kan worden gefocust maar niet kan worden gebruikt, in tegenstelling tot het oorspronkelijke attribuut disabled, dat het uit de tabvolgorde verwijdert.

Relaties. aria-controls geeft aan welk element een knop bestuurt. aria-owns reorganiseert de toegankelijkheidsboom wanneer de DOM de visuele relatie niet weerspiegelt. Met ‘aria-activedescendant’ kunt u de focus op een container behouden terwijl deze het actieve element aankondigt, een gebruikelijk patroon in comboboxen.

Live Regio’s. aria-live="polite" of "assertive" definiëren urgentie. aria-atomic="true" zorgt ervoor dat het hele blok wordt aangekondigd in plaats van alleen het gewijzigde deel. aria-relevant filters waarvan de wijzigingen worden aangekondigd.

Een detail dat vaak over het hoofd wordt gezien: ARIA-attributen werken alleen op elementen met een geldige rol. aria-expanded op een <div> zonder rol wordt niet aangekondigd. En ARIA Booleaanse waarden zijn tekstreeksen ("true", "false"), geen JavaScript Booleaanse waarden; het schrijven van aria-expanded="false" als een booleaanse eigenschap zal inconsistente resultaten opleveren.

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

Fouten die de toegankelijkheid van een widget verpesten

De kostbaarste fout is het gebruik van ARIA om een slecht gestructureerde HTML te repareren. Voeg role="navigation" toe aan een <div> wanneer er al een <nav> beschikbaar was, dupliceert dit de regio’s en verwart het de navigatie via landmarks.

De tweede fout is de focus. Een modale widget die de focus niet verplaatst wanneer deze wordt geopend, deze niet vasthoudt terwijl deze open is en deze bij het sluiten niet terugstuurt naar de trigger, zorgt ervoor dat de toetsenbordgebruiker door onzichtbare inhoud navigeert. Het native <dialog>-element lost dit gedeeltelijk op, maar niet alles: het terugbrengen van de focus is nog steeds de verantwoordelijkheid van de ontwikkelaar.

De derde fout is het verbergen van elementen met aria-hidden die nog steeds focusbaar zijn. Een menu met aria-hidden="true" zonder display: none of visibility: hidden behoudt deze zijn links in de tabvolgorde, waardoor de gebruiker elementen focust die hij niet kan zien. De juiste combinatie is een visueel én in de toegankelijkheidsboom tegelijkertijd te verbergen.

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

De vierde fout is de ontbrekende toegankelijke naam. Een <knop> met een enkel SVG-pictogram vereist een aria-label of een <span class="visually-hidden"> met tekst. Een decoratieve SVG vereist aria-hidden="true" en focusable="false", dus Internet Explorer en sommige oudere browsers nemen dit niet op in de tabvolgorde.

Tools voor het testen van ARIA-rollen en -attributen

Er is geen tool in plaats van testen met een echte schermlezer, maar de combinatie van verschillende tools detecteert de meeste fouten in aria-rollen en -attributen.

Statische validatie. De W3C ARIA-validator (onderdeel van Nu HTML Checker) detecteert niet-bestaande rollen, slecht geschreven attributen en verboden combinaties. ax DevTools en Lighthouse wijzen op rollen zonder toegankelijke namen en ontbrekende verplichte attributen.

Toegankelijkheidsboominspectie. Met Chrome en Firefox DevTools kunt u de toegankelijkheidsboom precies zien zoals deze wordt ontvangen door ondersteunende technologie. Het is de snelste manier om te controleren of een rol daadwerkelijk is toegepast en welke toegankelijke naam de browser heeft berekend.

Handmatig testen. Navigeer alleen door de hele widget met het toetsenbord (Tab, Shift+Tab, pijlen, Enter, Spatie, Escape) en vervolgens met NVDA op Windows, JAWS indien beschikbaar, of VoiceOver op macOS en iOS. De combinatie van een desktoplezer en een mobiele lezer dekt de meeste echte gevallen.

Referentiedocumentatie. De W3C ARIA Authoring Practices Guide (APG) bevat uitgebreide patronen met toetsenbord- en codevoorbeelden. Dit is de bron die geraadpleegd moet worden voordat een nieuw patroon wordt bedacht.

Hoe te beslissen in een echt XHTML/CSS-project

Op XHTML-sites met lichtgewicht CSS en JavaScript is de meest kosteneffectieve strategie om te beginnen met native HTML en alleen ARIA toe te voegen waar native niet reikt. Een formulier met correcte <label>, <fieldset> en <legend> vereist zeer weinig ARIA. Een gegevenstabel met <th scope> doet dat ook niet. ARIA-rollen komen binnen wanneer patronen verschijnen die HTML niet dekt: tabbladen, accordeons, comboboxen met filtering, modale dialogen en dynamische meldingen.

Het is raadzaam om elk gebruik van ARIA-rollen en -attributen in de code zelf te documenteren met een opmerking waarin wordt uitgelegd waarom deze daar is. Wanneer iemand de component zes maanden later opnieuw instelt, weet hij of de aria-controls nog steeds nodig zijn of verweesd zijn geworden. Verweesde ARIA-attributen (die verwijzen naar ID’s die niet langer bestaan) zijn een stille bron van fouten die geen enkele validator betrouwbaar kan detecteren.

Behandel toegankelijkheid ten slotte als onderdeel van de definitie van het onderdeel van ‘klaar’, en niet als een daaropvolgende audit. Een widget met ARIA-rollen die vanaf de eerste commit met het toetsenbord en de schermlezer is getest, kost veel minder dan een widget die na de audit is gerepareerd.

Belangrijkste conclusies

• ARIA-rollen en -attributen voegen geen gedrag toe: een rol zonder toetsenbord- en focusmanagement is erger dan niets hebben.
• De eerste regel van ARIA is om native HTML te gebruiken wanneer deze bestaat; <button>, <dialog> en <details> bestrijken meer cases dan je zou denken.
• Attributen zijn gegroepeerd in labels, statussen, relaties en live-regio’s; elk gezin lost een ander probleem op.
• role="alert" onderbreekt en role="status" wacht: een onjuiste keuze verzadigt de gebruiker van de schermlezer.
• ARIA Booleaanse waarden zijn strings (“true”/”false”`), en attributen werken alleen op elementen met een geldige rol.
• Testen met een toetsenbord en een echte schermlezer is verplicht; validators detecteren slechts een deel van de fouten.

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 is het verschil tussen een ARIA-rol en een ARIA-attribuut?

Een rol definieert wat een element is voor ondersteunende technologie, zoals role="tab" of role="dialog". Een attribuut beschrijft de staat of relaties ervan, zoals ‘aria-expanded’ of ‘aria-labelledby’. Rollen worden toegepast op het element dat de component vertegenwoordigt; attributen worden meestal toegepast op hetzelfde element of op de elementen die daaraan gerelateerd zijn.

Wanneer moet ik ARIA gebruiken in plaats van native HTML?

Alleen als er geen HTML-element is dat het patroon bedekt. De eerste regel van W3C ARIA is expliciet: als er een native element is, gebruik dat dan. ARIA-rollen zijn nodig voor tabbladen, accordeons, comboboxen met filtering en modale dialogen, naast andere patronen die HTML niet zelfstandig kan implementeren.

Wat betekent het dat een element een toegankelijke naam heeft?

Een toegankelijke naam is de tekst die de schermlezer aankondigt wanneer de focus op het element wordt gelegd. Het wordt berekend op basis van de inhoud, op basis van aria-label, op basis van aria-labelledby of op basis van een bijbehorend <label>, in een volgorde van prioriteit die is gedefinieerd door de specificatie. Een interactieve rol zonder toegankelijke naam is een besturingselement dat de gebruiker niet kan identificeren.

Waarom reageert mijn role="button" niet op het toetsenbord?

Omdat ARIA geen gedrag toevoegt. Een <div role="button"> heeft tabindex="0" nodig om focus te ontvangen en keydown-handlers voor Enter en Space. De eenvoudigste en meest robuuste oplossing is om het oorspronkelijke <button>-element te gebruiken, dat al focus, toetsenbordactivatie en formulierinzending omvat.

Is het slecht om aria-hidden="true" te gebruiken?

Het is correct om decoratieve of dubbele inhoud te verbergen in de toegankelijkheidsboom, maar dit mag nooit worden toegepast op elementen die focus krijgen. Als een focusbaar element overblijft met aria-hidden="true", kan de toetsenbordgebruiker iets focusseren dat de schermlezer niet aankondigt. Combineer het altijd met daadwerkelijk visueel verbergen.

Welke tools valideren ARIA-rollen en -attributen?

De W3C Nu HTML Checker omvat validatie van ARIA-rollen en -attributen en detecteert niet-bestaande rollen of verboden combinaties. axe DevTools en Lighthouse wijzen op rollen zonder een toegankelijke naam en ontbrekende verplichte attributen. Om het eindresultaat te verifiëren, laat de toegankelijkheidsboominspecteur in de browser DevTools precies zien wat de ondersteunende technologie ontvangt.