Webtoegankelijkheid voor gevorderden – deel 2

Braille displayVeel webmasters en developers zijn inmiddels wel bekend met de 16 toegankelijkheidsrichtlijnen van het W3C, in Nederland beter bekend als het waarmerk Drempelvrij. Derek Featherstone, een autoriteit op het gebied van webtoegankelijkheid, gaf vorige maand op de IA Summit 2007 een workshop voor ‘gevorderden’.

In deel 1 van dit artikel ben ik ingegaan op wat algemene tips en specifieke aanbevelingen om formulieren gebruiksvriendelijker te maken voor met name mensen met een visuele beperking.

In dit tweede deel komen toegankelijk zoeken en navigeren aan de orde. En daarnaast nog wat specifieke aandacht voor het toegankelijk(er) maken van Rich Internet Applications (RIA), in het bijzonder AJAX.

Zoeken

Voorbeeld 6

Voorbeeld van een typische zoek-interface

Deze layout komen we nog wel eens tegen. Een gebruikelijke vertaling naar html is dit:

<div>
    Label
    Zoekveld
    Zoekknop
</div>
<div>
    Radiobuttons
</div>

Visueel heel logisch, maar niet voor blinden. Die komen in deze volgorde namelijk nooit de radiobuttons tegen. Een betere oplossing is deze:

<div>
    Label
    Zoekveld
    <div>
        Radiobuttons
    </div>

    Zoekknop
</div>

De tabvolgorde is nu voor iedereen logisch. En visueel kun je nog steeds de radiobuttons onder het zoekveld positioneren met CSS.

Voorbeeld 7

Voorbeeld van een zoekinterface met het zoekresultaat op dezelfde pagina

Het is niet ongebruikelijk om het zoekresultaat op dezelfde pagina te tonen als het zoekformulier. Maar na het klikken op de submit-button ga je meestal naar bovenaan de pagina, en daar zit het probleem. Een screenreader-gebruiker ziet op die manier weer dezelfde titel en hetzelfde zoekformulier en weet dus niet dat daaronder het zoekresultaat te vinden is.

Oplossing:

Voorbeeld van een goede flow in een zoekresultaat-interface

Begin de pagina met het aantal resultaten, maak dat een link naar de resultatenlijst. Plaats onderaan de zoekresultaten een “zoek opnieuw”-link die de focus op het zoekformulier zet.

Geavanceerd zoeken

Veel ‘Geavanceerd zoeken’ pagina’s laten twee zoekvelden zien: één die er altijd staat, het standaardzoekveld rechtsbovenaan, en het zoekveld van het geavanceerde zoekformulier. Visueel is er weinig verwarring. Maar een screenreader ziet enkel twee dezelfde velden achter elkaar op de pagina staan (vooral in formuliermodus). Wel verwarrend dus. De oplossing ligt voor de hand, maar kan technisch soms iets lastiger zijn: verberg de standaardzoekfunctie op de geavanceerde zoekpagina. Zo houd je maar één zoekveld over op de pagina.

Hoe vind je de zoekfunctie?

Meestal staat op een website de zoekbox in de rechterbovenhoek. Maar hoe vinden screenreader-gebruikers de zoekfunctie op de pagina? Meestal heeft de zoekfunctie geen vaste plaats in de broncode. Hier wat tips:

  • Plaats de zoekfunctie bovenin de code of plaats een link naar de zoekfunctie bovenin de code.
  • Koppel expliciet een label “Zoek” aan het zoekveld. Dan kan de gebruiker ook bij in de formuliermodus van de screenreader eenvoudig het zoekveld vinden. Net als bij formulieren kun je er met CSS voor zorgen dat dit label in de grafische weergave niet zichtbaar is door het label buiten het scherm (b.v. -900em) te positioneren.
  • Maar let op: Gebruik geen JavaScript om bij het laden de cursor direct naar het zoekveld te brengen, want dan kan de gebruiker niet de backspace-toets gebruiken om terug te gaan naar de vorige pagina.

Navigatie

Dat JavaScript-uitklapmenu’s vaak problemen opleveren, is bekend. Maar net als bij formulieren zijn er ook vaak structuurproblemen met navigatie.

Voorbeeld 9

Voorbeeld van een site-navigatie

In screenreaders ziet bovenstaande navigatie er vaak zo uit:

Nieuws
Producten
Service
Home
Contact
Over ons

Camera’s | Printers | Scanners

Paginatitel

 

Een betere opzet is deze:

Direct naar content

Hoofdmenu:

  • Nieuws
  • Producten
    • Camera’s
    • Printers
    • Scanners
  • Service

Globale links:

  • Home
  • Contact
  • Over ons

#Content

Paginatitel

 

Gebruik dus het liefst lijsten. Structureer ze zo dat ze zonder stylesheet een logische leesvolgorde hebben. Gebruik bij voorkeur headers speciaal voor screenreaders (verberg ze voor de gewone layout buiten het scherm). En voorzie altijd in een zogenaamde ‘skip navigation’ link. Overigens: de hierboven getoonde opzet is niet de enige goede opzet. Er zijn meerdere goede alternatieven.

En wat betreft mouseover uitklapmenu’s: Featherstone’s advies is om het submenu standaard op display:none te zetten en het te tonen onMouseover en onFocus. Op die manier werkt het menu beter met toetsenbordbediening.

Voorbeeld 10

Voorbeeld van een tagcloud

Een populaire nieuwe vorm van navigatie is de tagcloud. De tagcloud is van zichzelf een hele visuele vorm van navigatie. Tagclouds kunnen gesorteerd zijn op alfabet of op populariteit. Vaak geeft de tekstgrootte de relatieve verhoudingen in populariteit aan. Ze kunnen verschillende kleuren bevatten, b.v. voor gedeelde en niet-gedeelde tags. Er zit dus nogal wat visuele informatie in een tagcloud. Hoe maken we die semantisch voor screenreaders? Ten eerste: maak het mogelijk de tagcloud te sorteren op alfabet en op populariteit. Verder kan het helpen om de relatieve populariteit te kwantificeren, dus door het aantal items gekoppeld aan de tag te vermelden.

RIA en AJAX

Dit is een lastig onderwerp. Ik zit zelf al jaren niet meer genoeg met mijn handen in de html/css/javascript om goed te kunnen experimenteren met AJAX en screenreaders, dus heb ik Featherstone twee keer om feedback gevraagd over de juistheid van onderstaande tekst. Helaas heb ik nog niets van hem gehoord. Toch wil ik mijn workshop-aantekeningen over dit onderwerp wel plaatsen. Dus…als u onjuistheden vindt, dan hoor ik dat graag.

Veel Rich Internet Applications (RIA’s) gaan net als traditionele webpagina’s gewoon over interactieflows: als ik hier op klik, dan gebeurt er dat. Het grote verschil is echter dat er bij een RIA meer mogelijk is dan klikken (denk b.v. aan slepen) en dat er veel meer op één en dezelfde pagina gebeurt. En met wat grotere RIA’s is er een goede kans dat je kriskras over de pagina zwerft. Visueel zijn RIA’s niet allemaal even lineair. Maar de grootste ‘truc’ om RIA’s toegankelijk te maken, zit in het onderkennen dat je in essentie gewoon te maken hebt met een logische flow van events.

Eerst even twee punten van aandacht: Het eerste is dat RIA’s bijna altijd worden gemaakt met Flash of AJAX. En Flash is Flash en AJAX betekent JavaScript. Hoe kun je RIA’s toegankelijk maken als je interface afhankelijk is van JavaScript? Als je naar de richtlijnen kijkt, lijkt dat inderdaad heel lastig te realiseren. Maar in praktijk kun je volgens Featherstone AJAX-applicaties redelijk goed toegankelijk maken, omdat veel screenreaders tegenwoordig met JavaScript kunnen omgaan. En met Flash! Flash heeft nog altijd een negatieve reputatie wat betreft toegankelijkheid, maar zonder er in de sessie verder op in te gaan, zegt Featherstone dat – mits je bewust ontwikkelt – Flash prima toegankelijk is. Natuurlijk is wel vereist dat je de plugin geïnstalleerd hebt.

Het tweede punt is dat er bij RIA’s dikwijls al dingen gebeuren voordat de gebruiker ergens op geklikt heeft, namelijk automatisch (b.v. informatie die periodiek ververst wordt) of bij mouseover (b.v. als de gebruiker zijn muis over een tekstblok beweegt en vervolgens “Klik hier om deze tekst te bewerken” te zien krijgt). Dit zijn op dit moment nog zaken die moeilijk toegankelijk te maken zijn.

Terug naar de flows. Als we het JavaScript issue even laten voor wat het is, dan is vaak één van de grootste problemen van AJAX-applicaties dat een actie resulteert in een verandering elders op de pagina, maar dat de focus van de cursor blijft staan. Op deze manier weet een screenreader-gebruiker dus niet waar er iets gebeurd is en waar hij naartoe moet voor de volgende actie. Oplossing: zet bij iedere handeling de cursor naar de volgende plaats van handeling.

Verder: zorg ervoor dat de applicatie volledig met het toetsenbord te bedienen is, ook b.v. het doorbladeren van items in een lijst. En dat is gemakkelijker gezegd dan gedaan. Zeker de eerste keren zal er waarschijnlijk veel tijd gaan zitten in experimenteren en testen.

Op internet wordt er veel geblogd over AJAX en toegankelijkheid. Het houdt veel mensen bezig. Helaas betekent dit dat er blijkbaar nog geen pasklaar antwoord is. Het goede nieuws is echter dat veel mensen er serieus mee aan de slag zijn gegaan. Zo is er de Hijax methodologie ontwikkeld dat uitgaat van ‘progressive enhancement’, wat toegankelijkheid zou moeten waarborgen. En het W3C werkt aan standaarden voor Accessible Rich Internet Applications (ARIA). Ik ben heel benieuwd naar de ontwikkelingen op dit gebied.

Geef een reactie

Deze website gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.