In veel handleidingen wordt uitgelegd hoe je een toegankelijk navigatiemenu kunt maken, maar daarbij wordt vaak voorbijgegaan aan de complexiteit van de "je bent hier"-indicatie. Hoe kunnen we de visuele markering van een "actief bovenliggend item" vertalen naar iets wat een gebruiker van een schermlezer daadwerkelijk begrijpt?
In een megamenu met meerdere subniveaus is het een standaard usability-praktijk om de bovenliggende sectie van een niveau-2 of niveau-3 pagina visueel te onderscheiden. Dit helpt de gebruiker om zich te oriënteren binnen de site-architectuur en gemakkelijk nevengeschikte of bovenliggende pagina's te vinden.
Visuele oplossing: doorgaans gebruiken ontwikkelaars een dynamische CSS-klasse zoals .active-parent.
Het probleem: deze opmaak is puur visueel en blijft onzichtbaar voor gebruikers van schermlezers, tenzij deze wordt gecombineerd met een semantisch attribuut.
Hoewel een breadcrumb technisch gezien deze visuele identificatie kan vervangen, is het geen waterdichte oplossing. Breadcrumbs worden op mobiele apparaten vaak ingekort of zelfs verborgen om ruimte te besparen. In dergelijke gevallen wordt de visuele markering van de bovenliggende sectie in de navigatie de enige manier om de hiërarchie van de site te begrijpen.
Toegankelijkheid vereist dat visuele informatie op een niet-visuele manier wordt aangeboden. Idealiter zou dit via standaard HTML moeten gebeuren. Er bestaat echter geen standaard HTML-tag om een “bovenliggende sectie” te onderscheiden van de “huidige pagina”. We zijn dus genoodzaakt om naar ARIA te kijken.
Hoewel aria-expanded ons vertelt of een menu open is, zegt het niet of deze sectie de actieve pagina bevat. Dit brengt ons bij aria-current. Volgens het W3C wordt aria-current gebruikt wanneer een element binnen een set, visueel is opgemaakt om aan te geven dat dit het huidige item is.
De meest interessante waarden van aria-current voor ons geval zijn:
aria-current=“page”: Moet strikt worden gereserveerd voor de exacte pagina waarop de gebruiker zich bevindt.aria-current=“location”: Wordt vaak gezien in breadcrumbs; schermlezers kondigen dit meestal aan als “huidige locatie”.aria-current=“true”: Een generieke status, eenvoudig aangekondigd als “huidig”.aria-current-attributen gebruiken?Het gebruik van meerdere aria-current-tags in dezelfde groep kan verwarrend zijn, omdat een blinde gebruiker dan meerdere keren “huidig” hoort. Het combineren van de waarde “page” voor de actieve link met waarden als “location” of “true” voor bovenliggende items kan inderdaad tot aanzienlijke verwarring leiden. Een gebruiker van een schermlezer kan moeite hebben om te onderscheiden welk item de daadwerkelijke bestemming is en welk item een structureel oriëntatiepunt is.
De WAI-ARIA 1.2-specificaties over aria-current stellen echter: “auteurs ZOUDEN (SHOULD) slechts één element in een reeks als actueel markeren.” Het gebruik van “ZOUDEN” (in plaats van”MOETEN”) impliceert flexibiliteit. In een megamenu met meerdere niveaus zou theoretisch elke bovenliggende pagina van de huidige pagina in theorie aria-current=“location” kunnen dragen. Dit attribuut heeft uitstekende ondersteuning in moderne schermlezers, waaronder Narrator in combinatie met Edge.
Het eigen voorbeeld van de navigatiemenubalk van het W3C biedt een andere aanpak door gebruik te maken van het title-attribuut. Door title="bevat link naar huidige pagina" toe te voegen aan het bovenliggende item wordt aanvullende informatie geboden, en aangezien title niet het zichtbare label in de toegankelijkheidsstructuur (accessibility tree) vervangt, werkt het als een handige hint.
Een andere oplossing is de sr-only-span. Hierbij wordt een visueel verborgen span binnen de link toegevoegd: <a href="...">products <span class="sr-only">(current section)</span></a>. Met deze methode zou de toegankelijke naam nog steeds beginnen met het zichtbare label, wat in overeenstemming is met de toegankelijkheidsvereisten.
Om de nuances van digitale toegankelijkheid onder de knie te krijgen, is meer nodig dan alleen het afvinken van een checklist; het vereist een balans tussen technische standaarden en de gebruikerservaring in de praktijk. De keuze tussen een ongebruikelijke ARIA-implementatie – die mogelijk te kampen heeft met inconsistente ondersteuning door ondersteunende technologie of verwarring kan veroorzaken bij gebruikers van schermlezers – en een minder semantische “oplossing” zoals een verborgen span-tag, is een complexe architecturale beslissing. Er is zelden een universeel antwoord, omdat de beste aanpak vaak afhangt van de specifieke context van de navigatie van uw site en de gebruikers ervan.
Bij Eleven ways zijn we gespecialiseerd in het oplossen van deze complexe puzzels. Wij geloven dat echte toegankelijkheid verder gaat dan enkel naleving van de regels; het gaat erom digitale producten intuïtief te maken voor iedereen. Ons team biedt de diepgaande expertise die nodig is voor audits, om te adviseren en om uw ontwikkelaars te trainen, zodat zelfs de meest complexe megamenu's inclusief zijn in hun ontwerp. Of u nu de nieuwste WAI-ARIA-specificaties doorneemt of op zoek bent naar pragmatische, in de browser geteste oplossingen voor uw gebruikers, wij staan klaar om u te helpen de kloof tussen code en bruikbaarheid te overbruggen.
Hier bij Eleven Ways krijgen we vaak de vraag naar het “correcte, toegankelijke tooltip-patroon”. Het bouwen van toegankelijke tooltips is een mijnenveld — vooral wanneer je rich content en de eigenaardigheden van screen readers toevoegt. Laten we de problemen onderzoeken en op zoek gaan naar een tooltip-patroon dat werkelijk alle behoeften dekt.
Twintig Waalse gemeenten weigeren het gemeentelijk handvest van Esenca voor de inclusie van personen met een handicap te ondertekenen. We hebben de toegankelijkheid van hun startpagina gecontroleerd.