In de verwarrende wereld van webtoepassingen kan ARIA de toegankelijkheid en het gebruiksgemak van uw creaties verbeteren. HTML kan niet veel typen relaties tussen elementen op de pagina verwerken, maar ARIA is ideaal voor vrijwel elke soort installatie die u kunt bedenken. Laten we eens kijken wat ARIA is, hoe het van toepassing kan zijn op uw webapp en enkele snelle recepten die u kunt gebruiken voor uw eigen sites..
ARIA, ook wel WAI-ARIA genoemd, staat voor de webtoegankelijkheidsinitiatief-toegankelijke rijke internettoepassingen. Dit initiatief, bijgewerkt door het W3C, heeft tot doel ontwikkelaars een nieuwe reeks schema's en attributen te geven om hun creaties toegankelijker te maken. Het heeft specifiek tot doel om de inherente hiaten te overbruggen die HTML achterlaat. Als u niet bekend bent met wat het al doet, moet u onze primer op ARIA bekijken. Mogelijk bent u ook geïnteresseerd in onze artikelen op ARIA voor de startpagina en ARIA voor eCommerce.
Kort samengevat, ARIA heeft drie belangrijke functies waarop we ons zullen concentreren:
aria-Live
attribuut geeft schermlezers en andere apparaten een luisteraar voor wanneer de inhoud op de pagina verandert. Dit zorgt voor eenvoudiger communicatie van wanneer inhoudsveranderingen op het scherm plaatsvinden.We hebben eerder gekeken naar het toevoegen van ARIA aan de algemene elementen van eCommerce-pagina's en startpagina's van sites. Met web-apps verschillen ze echter allemaal drastisch van de vorige. Formulieren en functies schakelen tussen elke app en vaak zelfs tussen versies van dezelfde app. Daarom behandelen we onze implementaties hier als recepten in een kookboek in plaats van een groothandelconversie van een pagina.
Als het gaat om webapps, is de intentie van een gebruiker moeilijker te onderscheiden in algemene zin. Met eCommerce, het maakt niet uit op welke site u zich bevindt, is het aannemelijk dat de bezoekers op zoek zijn naar een product of dienst. Web-apps dienen verschillende doeleinden, dus in plaats daarvan zullen we ons concentreren op het creëren van genuanceerde besturingselementen die toegankelijk en gebruiksvriendelijk zijn.
Laten we een paar van deze besturingstypen bekijken.
Het eerste besturingselement dat we gaan bekijken, is een weergegeven waarde die wordt bijgewerkt met een druk op de knop. Dit soort besturingselementen wordt meestal gezien als een element een hoeveelheid weergeeft die kan worden aangepast met knoppen met het label '+'en'-', maar kan vele vormen aannemen, zoals pijlknoppen waarmee u door vooraf gedefinieerde statussen kunt bladeren.
Een standaardimplementatie kan enkele hiaten in het begrip voor de gebruiker achterlaten. Het is onduidelijk welke elementen de knoppen beïnvloeden, hoe ze deze beïnvloeden en wanneer de waarde van het element verandert.
Hieronder gebruiken we ARIA om een verbinding tot stand te brengen tussen de knoppen en het waardeweergave-element met behulp van de aria-controles
attribuut. Vervolgens maken we het gebruik van de knoppen duidelijk door te gebruiken aria-label
en HTML . Eindelijk, we zullen de aria gebruiken
alarm
rol en de aria-Live
attribuut om onze gebruiker te laten weten wanneer de waarde wordt bijgewerkt.
Laten we eens kijken naar hoe die code eruit ziet:
Bij het afbouwen van een site met ARIA is het gebruikelijk om "progressieve toegankelijkheid" te gebruiken. Het idee achter deze term is dat het nemen van een site of web-app van de basisvorm naar volledig toegankelijk een ontmoedigende taak is. Om dit op een manier aan te pakken die nog steeds vooruit beweegt, kunt u geleidelijk nieuwe en nieuwe functies implementeren.
Voor een tooltip met een verwante pop-up of modaal betekent dit dat we het probleem in twee stappen kunnen doorbreken en zo nodig kunnen uitrollen. In dit geval is de tooltip waar we het over hebben het algemene beeld van een klein vraagteken dat aanvullende informatie opent wanneer er overheen wordt zweeft.
Om gebruikers te laten weten dat de afbeelding van het vraagteken eigenlijk een tooltip is, hebben we dit gedefinieerd door een geschikte rol te gebruiken, zoals deze:
Er zijn echter een paar problemen met deze implementatie. Gebruikers zijn zich er mogelijk nog steeds niet van bewust dat het zweven boven de tooltip een popup met meer informatie initieert. Hier is hoe we dat kunnen toevoegen aan onze code:
In plaats van een hover-gebaseerde tooltip, is het ook gebruikelijk dat een webapp formulieren gebruikt waarbij elke invoer zijn eigen bijbehorende tooltip heeft.
Zonder aanvullende ARIA-opmaak, kan het moeilijk zijn om te bepalen welke knopinfo van toepassing is op welke invoer voor een gebruiker. Als deze relatie niet aanwezig is, kan uw Help-tekst in sommige gevallen nutteloos worden.
Om dit te corrigeren, verpakken we onze tooltips in hun eigen elementen. Elk van deze kan worden genest in de buurt van hun gerelateerde invoer, hun relaties worden vastgelegd met ARIA en kunnen vervolgens worden geactiveerd met JavaScript (of alleen CSS als je handig bent).
Hier ziet u hoe dat eruit zou kunnen zien:
"Onze service is momenteel niet beschikbaar", "Uw account is opgeschort" en gerelateerde statusmeldingen worden vaak gebruikt door web-apps en geven belangrijke informatie weer voor gebruikers. Zonder ARIA kunnen ze worden begraven binnen de informatie op een pagina en een verscheidenheid aan problemen veroorzaken.
Gebruik maken van de ARIA alarm
rol en de aria-Live
kenmerk, kunnen we ervoor zorgen dat onze gebruikers snel op de hoogte zijn van eventuele problemen zodra ze op een pagina aankomen.
We kunnen dit type statuswaarschuwing als volgt instellen:
Het systeem is offline!
Laten we tot slot eens kijken naar een ander gemeenschappelijk besturingselement dat wordt gebruikt in web-apps: de werkbalk. Voor onze doeleinden markeren we een werkbalk die op deze manier werkt: onze web-app toont een grote hoeveelheid gegevens, georiënteerd in een tabel. Boven deze tabel heeft onze werkbalk meerdere knoppen waarmee gebruikers de tabel op verschillende manieren kunnen sorteren. Deze knoppen bevatten klassieke sorteeropties zoals A tot Z en Z tot A.
Relatief gezien laten deze enkele problemen met betrekking tot toegankelijkheid. Ten eerste is het niet duidelijk dat die knoppen van invloed zijn op de tabel. We lossen dit op met behulp van de aria-controles
attribuut. Het is ook niet duidelijk dat de knoppen aan elkaar zijn gekoppeld, wat een nuttige informatie voor onze gebruikers kan zijn. Om dit te definiëren, gebruiken we de toolbar
rol. Ten slotte weet een gebruiker niet noodzakelijk welke knop als laatste werd ingedrukt. Om dit te corrigeren, gebruiken we de aria geperst
attribuut.
Bij gebruik van de aria geperst
attribuut, het is belangrijk om op te merken dat u deze elementen moet bijwerken als de gebruiker met hen communiceert. Hiervoor moeten waarschijnlijk de kenmerken worden gewijzigd via JavaScript of jQuery.
Dit is hoe onze werkbalkcode eruitziet:
Met dit handvol nieuwe besturingsschema's en relaties onder uw riem bent u goed op weg om uw eigen webapp volledig toegankelijk te maken! Nadat u deze nieuwe markeringen hebt toegevoegd, moet u bedenken hoe u deze kenmerken kunt toepassen op andere delen van uw gebruikersinterface om de bruikbaarheid van uw creatie te maximaliseren..
Zijn er kenmerken, rollen of andere functies van ARIA waarover u meer wilt weten? Of heeft u misschien vragen over uw eigen implementaties of correcties voor dit artikel? Neem contact op met behulp van de onderstaande opmerking of door kylejspeaker te taggen op Twitter!