Wilt u uw website beter toegankelijk maken? Wil je de eerste in de rij zijn als nieuwe online interfaces op de markt komen? Zoek niet verder dan ARIA.
Deze reeks standaarden die door het W3C (World Wide Web Consortium) wordt onderhouden, biedt u het beste van beide werelden door een aantal kenmerken toe te voegen waarmee HTML op zinvolle wijze kan worden uitgebreid. Hier zullen we doorlopen wat ARIA is, kijken hoe het kan profiteren van een informatieve website en stap voor stap door een use-case gaan met codevoorbeelden. Laten we beginnen!
ARIA (of soms WAI-ARIA) is het acroniem voor een reeks toegankelijkheidsnormen, de Web Accessibility Initiative-Accessible Rich Internet Applications. Je kunt meer lezen over de basis van ARIA in mijn vorige artikel, maar laten we nu een paar van de pijlers ervan bespreken.
Een meerderheid van websites wordt gebouwd met behulp van HTML, die voornamelijk elementen aan elkaar koppelt op een hiërarchische manier via relaties tussen ouders en kinderen. Deze structuur is geweldig voor het definiëren van inhoud, maar schiet tekort als het gaat om het definiëren van gebruikersinterfaces. In veel sites en webtoepassingen wordt een inhoudsgebied bijvoorbeeld beheerd door knoppen binnen een broer of zus-de broers en zussen hebben hetzelfde bovenliggende element, maar in HTML hebben ze geen directe relatie met elkaar. Hierdoor wordt het moeilijk om te definiëren welke gebruikersinterface-elementen (UI) bepalen welke inhoudstypen bij het gebruik van ondersteunende technologieën.
Dit gaat ook door naar nieuwere interfaces. Als u bijvoorbeeld probeert een website te navigeren via een slim apparaat, wordt het moeilijk wanneer elementwijzigingen niet zichtbaar zijn.
Met ARIA kunt u HTML-elementen aan elkaar koppelen met behulp van aanvullende kenmerken om dit soort besturingselementen weer te geven.
Een andere tekortkoming van HTML is het onvermogen om de structuur van de intentie te scheiden.
U wilt bijvoorbeeld een afbeeldingselement maken in een klikbare knop. HTML definieert dat beeld echter nog steeds grotendeels als alleen een afbeelding, en alles daarbuiten gebeurt elders.
Met ARIA kan de intentie worden gescheiden van een element, waardoor afbeeldingen kunnen worden gemarkeerd als knoppen of een koppeling kan worden gedefinieerd als een tooltip. Dit geeft de ontwikkelaar meer controle over de gebruikersinterface en creëert duidelijker ingestelde relaties.
Naast het markeren van elementen in de gebruikersinterface, geeft ARIA ook toegang tot het rolkenmerk-gebruikt om gebieden van een pagina te definiëren. U kunt bijvoorbeeld uw hoofdmenu markeren als navigatie en het inhoudsgebied van uw artikel als hoofdinhoud. Dit maakt het gemakkelijker voor gebruikers om zich door de belangrijke delen van uw site te verplaatsen en kan verwarring voorkomen voor mensen met ongewone of complexe sitelay-outs.
Om wat ervaring op te doen met het toevoegen van ARIA aan een site, nemen we een wireframe van een site die mogelijk door een klein bedrijf wordt gebruikt en implementeren onze kenmerken stapsgewijs.
Het pagina-wireframe dat we gaan markerenVoor de duidelijkheid, de code waar we mee werken is uitgekleed, met CSS-klassen en alle functionaliteit van een CMS verwijderd.
Het eerste dat we willen doen, is ons draadframe in delen opdelen om het toevoegen aan ARIA eenvoudiger te maken. In de onderstaande afbeelding ziet u dat ik de site heb onderverdeeld in vijf hoofdonderdelen:
In ons geval ziet het er zo uit:
De secties waar we mee gaan werkenWanneer u uw site opslaat in dit soort gebieden, zijn we op zoek naar twee dingen. De eerste is voor belangrijke elementen die kunnen worden gedefinieerd door een ARIA-herkenningspunt: banner, navigatie, hoofd-, aanvullende, inhoudsinformatie, zoeken en formulier. Deze vertegenwoordigen de noodzakelijke delen van onze site en alles dat niet nodig is om het te gebruiken, wordt niet gemarkeerd als een oriëntatiepunt (bijvoorbeeld advertenties).
Het tweede ding om te zoeken naar specifieke elementen die moeten worden verduidelijkt met ARIA. In de meeste gevallen is dit vrij eenvoudig (zoals het markeren van een afbeelding als afbeelding), maar voor sommige UI-elementen kan het een beetje lastig worden.
Als we eenmaal weten op welke gebieden ARIA geïmplementeerd moet worden, kunnen we er systematisch doorheen gaan. Laten we aan de slag gaan met de navigatie van de site.
In ons voorbeeld merk je dat we een paar navigatietypen hebben. De eerste is een menu zoals te zien op de meeste sites, met enkele pagina's voor de site. Direct hieronder is een kleiner menu dat opties voor gebruikers bevat.
We willen deze markeren met de role = "navigation"
attribuut zodat ze gemakkelijk kunnen worden gekozen als menu's van de site. Dit leidt tot de vraag: moeten ze worden gegroepeerd in een enkel navigatie-oriëntatiepunt, of worden gemarkeerd als twee afzonderlijke oriëntatiepunten?
Om deze vraag in uw eigen projecten te beantwoorden, kunt u zich normaal gesproken twee vragen stellen:
Is de bedoeling van deze menu's anders? In ons voorbeeld navigeert het bovenste menu de pijlerpagina's van de site, terwijl het kleinere menu zich richt op dingen die een ingelogde gebruiker mogelijk nodig heeft. Deze intenties zijn verschillend, dus het is logisch ze te scheiden.
Bevinden de menu's zich binnen hetzelfde bovenliggende element? Ik weet dat dit contra-intuïtief lijkt aangezien ARIA is ontworpen om ons te helpen dit soort relatiebeperkingen te overwinnen, maar in dit geval gaat het minder om wat mogelijk is en meer om wat goed is voor de gebruiker. Als een enkel menu wordt gedefinieerd, maar met de helft op een locatie en de andere helft ergens anders, wordt navigatie moeilijker.
Voor ons geval gaan we onze navigatie behandelen als twee afzonderlijke oriëntatiepunten. Dus we zullen enkele wijzigingen in de code aanbrengen. Om te beginnen hebben we gewoon onze eenvoudige HTML:
- Huis
- Wat betreft
- Diensten
- Plaats
- Neem contact met ons op
- Log in
- Account
- instellingen
Nu zullen we het annoteren met enkele oriëntatiepunten.
De volgende stap bij het definiëren van deze herkenningspunten is om de gebruiker een hint te geven over wat de bedoeling van elk menu is. Als we ze allebei als navigatie achterlaten zonder verdere informatie, maakt het de zaken alleen maar moeilijker te interpreteren. Laten we daarom zinvolle labels toevoegen met behulp van de aria-label
attribuut:
Daarnaast willen we extra rolmarkering aan ons menu toevoegen om gebruikers te laten weten dat dit een menu is en elke link binnen een menu-item markeren:
Nu naar het inhoudsgebied. Hier markeren we de container die de volledige inhoud van onze hoofdinhoud bevat role =”main”
. Nogmaals, ter vergelijking, hier is onze startercode.
Lorem ... scelerisque ...
En hier is hoe het eruit ziet nadat we de "hoofd"
mijlpaal.
Lorem ... scelerisque ...
Binnen die inhoud gaan we elk element zoeken dat een intentie heeft die niet overeenkomt met de HTML-definitie.
Eerst zorgen we ervoor dat het beeld als een knop fungeert door het toe te voegen "knop"
rol:
Deze link activeert een modaal is een beetje lastiger, omdat het afhangt van wat zich in het modale zelf bevindt. Voor ons gaan we zeggen dat het een tooltip is:
scelerisque
Binnen onze hoofdinhoud hebben we ook een zoekformulier. Dit heeft een extra laag van complexiteit, omdat het een zoekformulier is dat HTML-elementen gebruikt en het ook als een oriëntatiepunt van een zoekvak kwalificeert. We zouden het als volgt markeren:
Verder kunt u elk element met de juiste ARIA-tag definiëren. Voor de meeste sites kan dit een te grote tijdsdruk zijn op het ontwikkelingsproces, hoewel het in de meeste CMS's kan worden geautomatiseerd. In gevallen waar dit niet kan, als de HTML-definitie van een element overeenkomt met de gebruiksintentie, kan het als lage prioriteit worden beschouwd bij het maken van ARIA-implementaties. Dit is hoe het hoofdinhoudsgebied eruitziet na het maken van al deze wijzigingen:
Lorem ... scelerisque ...
De zijbalk van een site kan vele vormen aannemen. In ons geval biedt het aanvullende inhoud met betrekking tot de site, met een lijst met gerelateerde berichten onderaan.
Dit is de startnotering voor de zijbalk:
Om de inhoud te definiëren, willen we deze geven "Complementair"
rol, door gebruikers te laten weten dat de informatie in de zijbalk aanvullende inhoud is die gerelateerd is aan de hoofdinhoud. Dat kan er als volgt uitzien:
Meer over ons
Lorem ...
De gerelateerde berichten hieronder kunnen als een vorm van navigatie worden beschouwd, zodat gebruikers de posts van de site verder kunnen verkennen. We willen het markeren met een "navigatie"
rol en geef het een geschikt label, zoals:
De zijbalk van elke site is anders en vereist mogelijk een andere combinatie van rollen en oriëntatiepunten. Als uw zijbalk een advertentie heeft, kunt u dit element beter niet markeren. Als er een zoekformulier in uw zijbalk staat, markeert u dit ook met de juiste rol. Alle menu's die in een zijbalk verschijnen, moeten hetzelfde patroon volgen als we in het navigatiegedeelte hebben besproken:
"navigatie"
mijlpaal"menu"
rol voor de menubox"menu onderdeel"
voor elk van de geneste itemsDit is wat onze laatste zijbalk eruit ziet:
Tot slot, onderaan onze pagina staat een call-to-action-formulier met de naam van de gebruiker en e-mail, met een standaard verzendknop hieronder. Als het gaat om formulieren, zijn er drie onderdelen om in gedachten te houden:
Geef de vorm de historische rol van "het formulier"
: aangezien het formulier een belangrijk deel van de site is, moeten we het gebruikers gemakkelijk maken om erbij te komen. We doen dit door het een mijlpaal te geven
Wijs matching-rollen toe aan elementen. Formulieren zijn een gemeenschappelijk gebied voor intentie en HTML-definities die niet overeenkomen. Voeg waar nodig ARIA-rollen toe, vooral als het gaat om selectievakjes, schuifregelaars, tooltips en andere elementen die op meerdere manieren kunnen worden geïmplementeerd.
Zorg dat de labels overeenkomen met de juiste elementen. HTML verwerkt dit op een eenvoudige manier, zodat je de element om een label aan een invoer te koppelen. Formulieren kunnen gemakkelijk een complexere structuur hebben die voorkomt dat ze werken; gelukkig kunnen we dat oplossen met de
aria-labelledby
attribuut.
Laten we eens kijken naar hoe onze bijgewerkte code eruitziet: