Navigeren met het toetsenbord in macOS

Gijs Veyfeyken op 15/12/2010

Wanneer je met de tabtoets doorheen een website navigeert in een browser onder Windows, bijvoorbeeld Firefox, krijgt elke link of formulierelement op de pagina de focus. Diezelfde browser voor Mac gaat standaard enkel de formulierelementen focus geven. Links worden overgeslagen en niet in de tabvolgorde opgenomen. Daardoor is de website niet bruikbaar voor personen die de muis niet (kunnen) gebruiken. Apple gaat er dus vanuit dat zijn gebruikers altijd de muis hanteren en dat ze enkel met de tabtoets door formulieren willen kunnen navigeren. Logisch maar helaas ontoegankelijk uitgangspunt.

Toch is er een simpele oplossing. Onder Systeemvoorkeuren > Toetsenbord > tabblad Toetscombinaties kan je bij 'Uitgebreide toetsenbordfuncties' kiezen voor 'Alle regelaars'. Computer heropstarten vereist. Spijtig dat dit niet de standaard instelling is.

screenshot systeemvoorkeuren met optie alle regelaars aangevinkt

Ook de instellingen van Safari, Apple's eigen browser, zijn standaard niet ingesteld op toetsenbordgebruikers. Onder Safari > Voorkeuren... > tabblad Geavanceerd is er een checkbox Tab-toets markeert elk onderdeel op webpagina. Ook die moet je aanvinken. Daarna kun je met de tabtoets alle elementen bereiken in programma's en browsers onder macOS.

screenshot Safari voorkeuren met checkbox Tab-toets markeert elk onderdeel op webpagina aangevinkt

3 reacties

Nederlandse vertaling WCAG2.0 is klaar

Bart Simons op 06/12/2010

De internationale standaard voor webtoegankelijkheid (WCAG 2.0) is vertaald in het Nederlands. Het initiatief kwam van stichting Accessibility; AnySurfer heeft als reviewer meegewerkt. De Nederlandse vertaling van WCAG2.0 heet officieel Richtlijnen voor de Toegankelijkheid van Webcontent (WCAG) 2.0 . Het document werd eerder vertaald in het Frans, Duits, Spaans en andere talen. Een overzicht van vertalingen is beschikbaar. Wij zullen in onze checklist de links aanpassen om te verwijzen naar de Nederlandse vertaling. De onderliggende documenten zoals technieken, "how to meet" en "understanding WCAG" zijn nog niet vertaald.

Reageer als eerste

Cufón, de font-oplossing

Gijs Veyfeyken op 29/11/2010

Update 07/07/2011:Omdat Cufón geen ondersteuning biedt voor VoiceOver, kunnen we dit niet als toegankelijk beschouwen. Gebruik liever de CSS gebaseerde @font-face techniek.

Cufón is JavaScript dat ervoor zorgt dat je eender welk lettertype in je website kan gebruiken. Dus ook een lettertype dat niet is geïnstalleerd op de PC van de bezoeker. Het gewenste font wordt als afbeelding getoond maar ook de werkelijke tekst staat in de broncode.

Tijd voor een screenreader-testje.

logo Jaws, Window-Eyes, Supernova, NVDA

Ik heb een site waar de koppen (H1, H2, H3) met Cufón opgemaakt zijn, getest met bovenstaande screenreaders in Windows XP in combinatie met Internet Explorer 8. Lang leve virtualisatie met VMware.

  • NVDA 2009.1 leest alles mooi voor, je merkt niet eens dat het geen normale tekst is.
  • Jaws 9 idem dito. Niets op aan te merken.
  • Window-Eyes 7.11 laat een steekje vallen. Hij stopt na het lezen van het eerste woord in de H2, ik moet telkens naar het volgende element navigeren (pijltje naar beneden) om elk woord in de hoofding te laten voorlezen.
  • Supernova 12.01 leest de koppen niet voor wanneer ik met de H-toets (H van headings) van kop naar kop navigeer. Wanneer ik met de pijltjestoetsen over de pagina ga, worden ze wel voorgelezen. Net zoals bij Window-Eyes wordt elk woord in de H2 apart voorgelezen.

Vanuit toegankelijkheidsstandpunt is er dus geen reden om Cufón links te laten liggen. Voor gebruikers van Supernova (volgens ons de meest gebruikte screenreader in België) en Window-Eyes loopt het niet echt soepel maar je kan wel aan alle informatie.

9 reacties

Lightbox: veel gebruikt, zelden voor iedereen bruikbaar

Gijs Veyfeyken op 09/11/2010

Update 27 mei 2015: er is een meer recente blogpost over de toegankelijkheid van dialoogvensters.

Wat is een lightbox?

Een Lightbox is een user interface concept dat gebruikers toelaat om afbeeldingen te vergroten in een soort venster of pop-up zonder de pagina te verlaten. Het is meestal gebaseerd op JavaScript maar bestaat ook in HTML/CSS.

screenshot jQuery Lightbox

Fotogalerijen verschijnen steeds vaker in zulke Lightboxes, maar ook video en Flash wordt zo aan de man gebracht. De rest van de pagina wordt tegelijkertijd gedimd om het vergrote element te benadrukken. Er bestaan heel wat varianten, een mooi overzicht vind je in The Lightbox Clones Matrix.

Wat is het probleem?

  • onaangekondigde pagina-wijziging
  • gebrekkige toetsenbordtoegankelijkheid
  • verwarrende lees - en tabvolgorde

Zoals met alle JavaScript functionaliteiten hoeft er geen probleem te zijn maar is het er meestal wel. Wanneer JavaScript gebruikt wordt om browsergedrag na te bootsen, in dit geval het openen van een nieuw venster of pop-up, denken de meeste ontwikkelaars enkel vanuit het visuele standpunt.

Onaangekondigde pagina-wijziging

Wanneer we op een link klikken, ook wanneer dat een afbeelding is, verwachten we dat we naar een nieuwe pagina gebracht worden die ons daar meer over verteld. We verwachten niet dat dit element uitvergroot wordt terwijl de rest van de pagina bijna onleesbaar wordt gemaakt.

Een blinde gebruiker die met een screenreader surft, heeft niet in de gaten dat er iets gebeurt en komt een link tegen die blijkbaar niet werkt. Kondig onverwacht gedrag daarom altijd aan. Voor een screenreadergebruiker is dit essentieel, voor uw andere bezoekers is het een vorm van beleefdheid.

Alt="toon vergrote weergave in een fotogalerij" lijkt me voldoende als alternatieve beschrijving. "Klik om te vergroten" als bijschrift? Hangt natuurlijk van de context af en waarvoor het wordt gebruikt.

Gebrekkige toetsenbordtoegankelijkheid

Je moet de Lightbox niet enkel met het toetsenbord kunnen openen, maar ook kunnen sluiten. De escape-toets mag hier ook aan toegewezen worden, op voorwaarde dat je dit aan de bezoeker laat weten.

Als er knoppen zijn om binnen de Lightbox tussen meerdere foto's of andere elementen te navigeren dan moeten die ook met het toetsenbord bedienbaar zijn. 'Vorige en volgende afbeelding' is kristalhelder als link tekst. De pijltjestoetsen worden vaak aan deze acties gekoppeld. Op zich geen slecht idee zolang je dat communiceert naar de gebruiker. Helaas worden de horizontale pijltjestoetsen (links en rechts) al door sommige screenreaders gebruikt om het element dat de virtuele focus heeft, te spellen. Met de verticale pijltjetoetesen (naar boven en naar onder) wordt het vorige,volgende element voorgelezen. Het is theoretisch mogelijk om dit te omzeilen maar de gemiddelde screenreadergebruiker is hier niet van op de hoogte.

Tijdens mijn zoektocht ben ik heel wat varianten tegengekomen. Omdat de ontwikkelaar bepaalt hoe de bediening werkt, is er geen standaard. Sommige tonen knoppen (pre/next) wanneer je met de muis over de linker - of rechterhelft zweeft. Andere moet je sluiten door buiten de box te klikken. Nog andere werken met de pijltjestoetsen en hebben een sluitknop (x). Welke variant je ook kiest: zorg dat het duidelijk is voor de gebruiker hoe de bediening werkt.

Vergeet zeker geen focus-state te definiëren. Dit geldt trouwens voor de hele website. Als je over de pagina 'tabt' maar niet kan zien welk element de focus heeft, wordt de site onbruikbaar met het toetsenbord. Eén regel CSS kan dit oplossen. Bijvoorbeeld:

a:focus {outline: 1px solid red;} 

Verwarrende lees - en tabvolgorde

Een Lightbox is een div-element onderaan in de broncode die met CSS is verborgen en bij activatie zichtbaar wordt gemaakt. Hierdoor heeft de broncode geen logische volgorde. Problematisch, aangezien screenreaders de broncode volgen om de leesvolgorde te bepalen. Dit wordt duidelijk wanneer je een Lightbox opent en met de tabtoets verder over de pagina navigeert. Je zal eerst over de volledige pagina-inhoud moeten tabben, die zich visueel achter de lightbox bevindt. Pas helemaal op het einde van de pagina komt de focus in het div-element van de Lightbox terecht.

Om de lees - en tabvolgorde logisch en begrijpelijk te houden, zorg je ervoor dat na het openen, de focus op het eerste element in de Lightbox komt te liggen. Bij het sluiten, wordt de focus terug op het element gelegd waar je vandaan komt.

Dit is een zeldzaam voorbeeld waar een 'keyboard-trap' wel wenselijk is. De gebruiker zou niet buiten de Lightbox mogen kunnen tabben. De box moet eerst gesloten worden, zoals een klassieke JavaScript pop-up, vooraleer men verder kan. Op die manier is er geen verwarring mogelijk.

In de praktijk

Tot nu toe heb ik nog geen implementatie van het Lightbox-principe gevonden die aan alle toegankelijkheidsvereisten voldoet zoals hierboven beschreven. Moest je er ééntje kennen, laat het me zeker weten. Ik kan er hier wel één aanbevelen die zeer dicht in de buurt komt. De jQuery-Accessible-RIA Lightbox van Felix Nagels. Ik heb de demoversie niet in alle mogelijke combinaties van browser, screenreader en besturingssystemen getest. Maar wat de combinatie Windows XP, Internet Explorer 8 en Jaws 9 betreft, zit het goed. Het enige minpunt is dat je buiten de Lightbox kan tabben.

4 reacties

Site-eigenaars contacteren om ontoegankelijkheid aan te kaarten

Bart Simons op 23/04/2010

AnySurfer ziet het niet als haar taak om de ontoegankelijkheid van specifieke sites aan te kaarten. We benaderen zelf geen organisaties of bedrijven om hen erop te wijzen dat hun website niet of onvoldoende toegankelijk is. Deze rol is meer weggelegd voor de organisaties die gebruikers vertegenwoordigen. AnySurfer moedigt deze organisaties, maar ook individuen uiteraard aan om contact op te nemen met de eigenaars van ontoegankelijke websites. We zijn beschikbaar als technische partner, maar we willen niet overkomen als marketeers die er op uit trekken om audits te verkopen.

Om u te helpen met het aanschrijven van ontoegankelijke websites heeft het WAI een mogelijke werkwijze voorbereid, inclusief een aantal standaardmails. Dit document is momenteel in het Engels, maar misschien wil iemand wel helpen met de vertaling? Hiermee kunnen de belangenbehartigers VeBeS, Fevlado en anderen dus aan de slag. Maar we moedigen zeker ook individuele bezoekers aan om actie te ondernemen. Ervaringen van (potentiële) klanten kunnen soms zeer overtuigend werken voor een bedrijf. Als een gemeente nooit een klacht krijgt van een inwoner met een handicap die haar website niet kan gebruiken, zal ze zich ook niet bewust zijn van het probleem. Sterker nog, veel website-eigenaars realiseren zich niet dat mensen met een handicap vandaag prima een computer kunnen gebruiken en websites willen bezoeken.

Maar, niet alleen klagen kan helpen. Vertel een webmaster ook eens dat hij een prima site heeft gemaakt en al goed heeft rekening gehouden met uw beperkingen. Vraag hem dan of hij nog dit en dit kan aanpassen want dat zou het voor u nog een stuk handiger maken.

5 reacties