Ontwikkelen van toegankelijke apps

Bart Simons op 25/02/2014

Smartphones en tablets die werken met Android en iOS zijn vandaag goed bruikbaar door personen met een handicap. Zie voor meer details ons eerdere artikel Mobiel surfen met een handicap. Meer en meer krijgen we dan ook de vraag om naast websites ook apps te testen op toegankelijkheid. Hier volgen een aantal zaken om rekening mee te houden en links om je als ontwikkelaar op weg te helpen. We beperken ons in dit artikel tot apps voor het Android en iOS platform.

In theorie zijn de Web Content Accessibility Guidelines technologie-onafhankelijk geformuleerd en zouden ze dus ook bruikbaar moeten zijn om apps te testen. Sommige aspecten lijken inderdaad veel op het testen van een website, vb. zijn knoppen gelabeld, links betekenisvol, tabellen lineariseerbaar en formuliervalidatie duidelijk voor wie het scherm niet kan zien.

Het is echter moeilijker om concreet te adviseren hoe gevonden problemen verholpen kunnen worden. We kunnen immers niet even in de broncode kijken zoals bij een website. Hier volgen enkele voorbeelden:

Bruikbaar met het toetsenbord

Het eerste ijkpunt van de AnySurfer checklist vraagt dat alle functionaliteit bruikbaar is met het toetsenbord. Hoe vertalen we dit naar het aanraakscherm van een smartphone of tablet?

Een blinde gebruiker gaat heel anders om met het aanraakscherm dan iemand die het scherm kan zien. Screenreaders als VoiceOver voor iOS en Talkback voor Android doen meer dan voorlezen wat er op het scherm staat. Ze bieden een heel bedieningsconcept, ook met aangepaste aanraakgebaren (bekijk een video). Met een vinger van links naar rechts vegen, verplaatst de focus naar het volgende element. U moet er als ontwikkelaar dus voor zorgen dat deze focus bij alle elementen van de app kan komen en dat dit in een logische volgorde gebeurt.

Semantiek

Gebruik zoveel mogelijk standaardcomponenten voor interactieve elementen als keuzelijsten en aankruisvakjes. Daarvoor voorzien screenreaders zelf al alternatieve bedieningsconcepten. Als u een eigen component programmeert, moet u die grondig testen met de screenreader en zelf een aantal functionaliteiten voorzien.

Afbeeldingen hebben een alt-tekst

Afbeeldingen op websites moeten een alt-tekst hebben. In apps geldt hetzelfde voor knoppen. Het concept is hetzelfde maar de terminologie zal verschillen van de ene ontwikkelomgeving tot de andere.

Als u vergeet een knop te labelen, dan wordt de bestandsnaam van de knop voorgelezen in plaats van de functie ervan. Het is veel vlotter als je "terug" hoort in plaats van "NavBarIconBackButtonSmall".

Documentatie voor ontwikkelaars

Zowel voor iOS als Android ontwikkelaars is documentatie beschikbaar over het ontwikkelen van toegankelijke apps voor deze platformen.

Daarnaast zijn er de Mobile Accessibility Guidelines van de BBC. Het artikel Accessibility for iPhone and iPad apps vertelt een concreter verhaal. Laat je niet ontmoedigen door de lange inleiding.

Andere artikels of tips kunt u vermelden in de reacties op dit artikel.

Reageer als eerste

Screenreaders om je site mee te testen

Bart Simons op 07/02/2014

Een screenreader is software die blinden en slechtzienden gebruiken om de tekst van het computerscherm te laten voorlezen en/of in braille te laten verschijnen op een brailleleesregel. Uw website testen met een screenreader kan erg interessant zijn omdat het bepaalde toegankelijkheidsproblemen aan het licht brengt die anders moeilijk op te sporen zijn. Voor iemand die niet gewend is ermee te werken, is een screenreader tamelijk complexe software dus trek wat tijd uit om de handleiding te lezen en denk niet te snel dat het onmogelijk is om met een screenreader door uw website te surfen. Het artikel How to use NVDA and Firefox to test your web pages for accessibility geeft een goede inleiding die ook nuttig is als u besluit om met een andere screenreader te testen.

Waar moet u rekening mee houden?

Blinde screenreadergebruikers werken nooit met een muis en doen alles met toetscombinaties. Om een correcte test uit te voeren, mag u dus geen muis gebruiken in combinatie met een screenreader. De screenreader leest alles voor wat op het scherm staat maar doet dat in een bepaalde volgorde. Een groot probleem voor blinden is gebrek aan overzicht over het scherm. Een screenreadergebruiker weet niet wat er verderop nog zal komen en wordt niet altijd geïnformeerd over paginawijzigingen. Dit is moeilijk in te beelden voor een tester die een screenreader gebruikt maar het scherm wel kan zien. Om een echt realistische test uit te voeren, zou u eigenlijk niet alleen de muis aan de kant moeten laten maar ook het scherm uit moeten schakelen. Dit is uiteraard niet evident als u dit de eerste keer doet.

Screenreaders voor Windows

NVDA

Non Visual Desktop Access (NVDA) is een gratis en opensource screenreader. Een donatie wordt erg op prijs gesteld. Bij de installatie kunt u kiezen om een draagbare versie aan te maken. U kan de screenreader dan starten vanaf een USB-stick of vanaf een map op uw harde schijf zonder dat u iets moet installeren op uw computer. Sinds onze vorige blogpost over NVDA is het programma enorm verbeterd.

De Nederlandse stem die standaard bij NVDA zit, is van mindere kwaliteit. Voor een bescheiden bedrag kunt u een pakket kwalitatieve stemmen kopen waaronder Vlaams en Nederlands. Een andere mogelijkheid is het Microsoft Speech Platform. Deze stemmen zijn gratis maar er is op dit moment geen Vlaamse stem beschikbaar. U moet eerst Microsoft Speech Platform - Runtime (Version 11), x86 installeren. Merk op dat u de x86 versie moet installeren zelfs als uw systeem 64-bit is. Vervolgens installeert u de gewenste stemmen via de pagina Microsoft Speech Platform - Runtime Languages (Version 11). Kies de bestanden met TTS in de bestandsnaam en niet die met SR. Voor de Nederlandse stem Hanna installeert u het bestand MSSpeech_TTS_nl-NL_Hanna.msi. Vervolgens herstart u de computer.

Dan moet u in NVDA aangeven dat u deze stem wilt gebruiken. Druk insert+n, kies opties en vervolgens Synthesizer. Kies uit de lijst Microsoft Speech platform. Als u meerdere stemmen heeft geïnstalleerd, kunt deze instellen via insert+n, Opties, Stem.

Window Eyes

Window Eyes is een commerciële screenreader die u gratis kunt gebruiken als u over een licentie beschikt voor Office 2010 of hoger. Deze bevat voor het Nederlands ook enkel Hanna als stem.

JAWS

JAWS is een commerciële screenreader die u 40 minuten als demoversie kunt gebruiken. Daarna moet u de computer herstarten om er verder mee te kunnen werken. Download JAWS in het Nederlands. De meest recente versie is 15. Kies een 32- of 64bit-versie overeenkomstig uw besturingssysteem.

Merk op dat veel JAWS-gebruikers niet met de meest recente versie van de software werken omdat updates betalend zijn. Voor een realistische test zou u dus eigenlijk een oudere versie moeten gebruiken.

Kwalitatief hoogstaande stemmen zijn beschikbaar. Extra stemmen zijn gratis te downloaden. Ga naar Help, Webbronnen, Vocaliser Direct downloadpagina. Als u deze stemmen installeert, zullen ze enkel binnen JAWS werken.

Er is een specifieke tutorial om te leren surfen met JAWS.

Screenreader voor Mac

Mac-gebruikers hoeven geen screenreader te installeren, want vanaf het Lion besturingssysteem is deze ingebouwd en heet VoiceOver. Druk op command+f5 en uw computer begint te praten. Standaard praat hij Engels maar via de VoiceOver-instellingen kunt u de Nederlandse stem Ellen activeren. Lees meer over VoiceOver, de screenreader van Apple.

Tech Touch Team maakt een Nederlandstalige podcastreeks over het in gebruik nemen van een Mac als blinde gebruiker.

Reageer als eerste

Toegankelijkheid van de Vimeo HTML5 speler

Bart De Clercq op 04/02/2014

Vimeo kondigde onlangs zijn nieuwe videospeler aan. Deze nieuwe speler gebruikt niet langer Flash maar HTML5 als achterliggende technologie, en is volgens Vimeo toegankelijk. De vorige versie was niet bruikbaar met een screenreader en bevatte geen mogelijkheid om ondertiteling toe te voegen. We raadden hem dan ook altijd af. We hebben een testpagina gemaakt om na te gaan of de nieuwe speler toegankelijk is zoals beweerd wordt.

Flash nog steeds sterk aanwezig

Vimeo beweert zelf dat de HTML5 speler ingeladen wordt wanneer mogelijk. Opmerkelijk is dat de Flash speler nog relatief veel gebruikt wordt, ook in recente browsers zoals elke versie voor Internet Explorer 11, in FireFox voor Mac OS X en Opera.

Sommige bestandsformaten zullen altijd gebruik maken van de Flash speler. Bovendien, als er ondertiteling voorzien is, zal in FireFox altijd de Flash speler geladen worden.

Dit is een probleem aangezien de Flash speler absoluut niet toegankelijk is:

  • In Internet Explorer verdwijnen de bedieningsknoppen als de video enkele seconden speelt en kan je ze niet opnieuw oproepen met het toetsenbord.
  • De bedieningsknoppen in Flash zijn niet benoemd, een screenreader zal ze zelf een naam geven zoals 'knop zonder label 1', 'knop zonder label 2', enz. tot en met 'knop zonder label 14'.

Toetsenbordnavigatie

De HTML5 speler van Vimeo is niet altijd toetsenbordtoegankelijk. Reden hiervoor is dat de bedieningsknoppen verdwijnen na enkele seconden.

Met de tabtoets kom je volgende zaken tegen als je het video element overloopt: 'Play', 'Volume', 'CC', 'Full screen' en 'Vimeo'. Op het einde staan er nog enkele andere buttons: 'Like', 'Add to watchlist' en 'Share'.

De bedieningsknoppen van Vimeo HTML5 speler

Zolang de video niet gestart wordt, kan je navigeren in het video element met het toetsenbord. Zodra de video gestart wordt, verdwijnen de bedieningsknoppen. Wanneer je verder tabt, verspringt de focus naar het eerstvolgende element buiten de videospeler, bijvoorbeeld een link of button. Als je van dit volgend element terug tabt (shift+tab), hangt het gedrag af van de browser.

In Chrome, FireFox en Internet Explorer verschijnen de knoppen opnieuw als je met tab een button van de speler tegenkomt. Je moet dus op de omgekeerde manier tabben om terecht te komen waar je wilt. De bedieningsknoppen in de speler blijven zichtbaar met deze werkwijze. In Safari is dit echter niet mogelijk.

Daarenboven is de focus niet zichtbaar op de button 'Play' in FireFox. Het zou handig zijn als dit wel zo is, je kan de stijl voor :hover ook toepassen op :focus.

Toetsenbordnavigatie met een screenreader

De bedieningsknoppen in de HTML5 speler zijn gelukkig goed benoemd. Een screenreader geeft volgende output: 'Like', 'Add to watch later', 'Share', 'Play', 'Volume', 'HD' en 'Full screen'.

Het is jammer dat de 'Play' button op de vierde plaats komt, bij het tabben staat hij namelijk op de eerste plaats. Dit verschil in gedrag is te wijten aan het gebruik van tabindex. De buttons staan in de broncode in een onlogische volgorde, er wordt gebruik gemaakt van tabindex om dit recht te zetten en de tabvolgorde wel correct te laten verlopen. Een screenreader gebruiker die de pagina lineair afloopt door pijltje omhoog en pijltje omlaag, heeft geen voordeel van deze aanpassing. Het is beter om de buttons in een logische volgorde in de broncode te plaatsen, dan achteraf de volgorde te wijzigen met tabindex.

Opnieuw is het verdwijnen van de bedieningsknoppen een groot probleem. Na enkele seconden verdwijnen deze en is het onmogelijk om ze opnieuw op te roepen. Ze worden verborgen op een specifieke manier dat ook screenreader gebruikers de bedieningsknoppen niet meer kunnen terug vinden. Een oplossing zou zijn om ze offscreen te plaatsen zodat ze zichtbaar blijven voor screenreader gebruikers.

Ondertiteling

Het is mogelijk om ondertiteling toe te voegen aan een video filmpje. De volgende ondertitelingsformaten zijn ondersteund: SRT, WebVTT, DFXP/TTML, SCC en SAMI.

Als je ondertiteling toevoegt bij een video fragment, kan je aanduiden of het ondertiteling is voor doven en slechthorenden (CC) of normale ondertiteling (Subtitles).

Instellingen voor ondertiteling bij een video fragment

Wanneer de video is voorzien van ondertiteling, zal er automatisch een button CC bijkomen in de bedieningsknoppen van de HTML5 speler. Door er op te klikken, komt er een menu tevoorschijn met de beschikbare versies. Ondertiteling voor doven en slechthorenden wordt extra gemarkeerd met CC.

Menu om ondertiteling te kiezen.

Vimeo voorziet geen automatische ondertiteling, je moet het bestand zelf aanmaken en uploaden bij het filmpje.

Besluit

De nieuwe HTML5 speler van Vimeo is in meerdere opzichten een verbetering tegenover de oude Flash speler:

  • Je kan ondertiteling toevoegen.
  • Je kan met het toetsenbord navigeren.
  • De bedieningsknoppen zijn benoemd.

Ondanks deze vele aanpassingen, is de speler niet voor iedereen bruikbaar. We raden aan om momenteel de HTML5 video speler niet te gebruiken, en wel om deze redenen:

  • In veel situaties wordt nog een ontoegankelijke Flash speler geladen.
  • Het verdwijnen van de bedieningsknoppen is een groot probleem voor screenreader gebruikers.

Als je Vimeo toegankelijk wil maken, moet je zelf bedieningsknoppen voorzien door gebruik te maken van de JavaScript API, of de Vimeo speler in een andere toegankelijke speler opnemen, zoals bijvoorbeeld de Nomensa speler.

Reageer als eerste

Online bankieren toegankelijk?

Bart Simons op 22/01/2014

Is het in België mogelijk om als persoon met een visuele handicap zelfstandig je bankzaken online te verrichten? In opdracht van het Slechtzienden- en Blindenplatform Vlaanderen onderzochten we de online banktoepassingen van vier grote Belgische banken: Belfius, BNP Paribas, ING en KBC.

logo Belfius, BNP Paribas, ING en KBC

Het is snel duidelijk dat geen van deze websites ontworpen is om toegankelijk te zijn voor iedereen. Er zijn talloze opmerkingen op de toegankelijkheid van elk van de vier websites. Op de ene site zijn ze al meer blokkerend dan op de andere.

Om online te kunnen bankieren, moet men zich eerst aanmelden. We onderzochten dus eerst de toegankelijkheid van het inlogmechanisme en daarna van de banktoepassing zelf.

Aanmelden met een kaartlezer

Om te kunnen aanmelden, moet eerst en vooral de kaartlezer toegankelijk zijn voor iedereen.

5 kleine kaartlezers en een grote

Tot voor kort was het meest gebruikte aanmeldsysteem een kaartlezer met toetsen 'm1' en 'm2' en een numeriek toetsenbord. Het toestelletje toont op een klein schermpje telkens een andere code die je moet overtypen op de webpagina. Blinden en slechtzienden kunnen deze code niet aflezen en mensen met een motorische beperking hebben moeite met de kleine knopjes. Van deze kaartlezer bestaat daarom een versie die toegankelijk is voor blinden en slechtzienden: de sprekende kaartlezer geeft gesproken instructies en leest de challenge-code voor die je in de website moet ingeven. Deze heeft ook grotere toetsen en die zijn daardoor ook beter leesbaar.

Dit toegankelijke systeem is beschikbaar bij Belfius, BNP Paribas, en KBC maar niet meer bij ING.

ING is overgestapt op een ander soort kaartlezer en voor zover wij konden nagaan bestaat er van hun kaartlezer geen toegankelijke versie. Blinden en slechtzienden kunnen zich dus niet aanmelden op de online banktoepassing van ING.

Ook KBC introduceerde een nieuwe kaartlezer die niet toegankelijk is voor mensen met een visuele of een motorische handicap: het is een apparaatje dat je onbeweeglijk tegen het scherm moet houden om een knipperende streepjescode te scannen. Gelukkig kan men zich ook nog aanmelden met de sprekende kaartlezer.

Het aanmeldscherm van KBC met keuze uit twee kaartlezers en de knipperende streepjescode om te scannen

In deze fase van ons onderzoek naar toegankelijkheid van bankwebsites is ING dus al afgevallen want een persoon met een handicap kan zich niet aanmelden op de site. De andere drie banken stellen een sprekende kaartlezer ter beschikking die essentieel is voor deze doelgroep. Als die mogelijkheid ooit zou wegvallen, zullen klanten met een handicap zich niet meer kunnen aanmelden en dus niet meer online kunnen bankieren. In de volgende fase onderzoeken we de toegankelijkheid van de online banktoepassing zelf.

Bankverrichtingen uitvoeren via de website

Bij Belfius ondervinden we onoverkomelijke problemen. Bij KBC en BNP Paribas zijn er ook toegankelijkheidsproblemen maar mits wat oefening kunnen blinden en slechtzienden de site wel leren gebruiken.

Laten we beginnen bij Belfius. De knop om aan te melden is gemakkelijk te vinden op de homepage en ook het aanmelden is mogelijk, maar in de website zijn er grote problemen met foute implementatie van formulieren. Een element ziet er bijvoorbeeld wel uit als een selectievakje, een knop of een keuzelijst maar eigenlijk is het gewoon tekst in plaats van bekende formulierelementen. De meeste formuliervelden zijn ook niet verbonden met hun label. Een blinde weet dus niet waar elk veld voor dient en hij kan het ook niet invullen of bedienen.

Het is vooral jammer dat de vorige versie van de banktoepassing van Belfius wel goed toegankelijk was wat zeker een aantal klanten met een handicap heeft aangetrokken. Dexia Directnet behaalde als enige Belgische bank het AnySurferlabel. De toegankelijkheid is volledig vergeten bij de vernieuwing van de site.

Bij KBC moet men over veel doorzettingsvermogen beschikken om de knop te vinden die je naar het aanmeldscherm brengt. Visueel is deze knop gemakkelijk te vinden omdat hij in de rechterbovenhoek staat. In de broncode daarentegen staat er eerst een heel lang menu en de knop volgt pas op lijn 323 van de screenreaderoutput. Die leest de elementen van een pagina immers in de volgorde waarin ze in de broncode staan. Iemand die het toetsenbord gebruikt, moet om dezelfde reden ruim 200 keer op de tabtoets drukken om de knop te bereiken. Een ander probleem zijn betekenisloze paginatitels zoals 'KBC-Online dy540A-dy54001TransferOtherAccountScreen'. In de uitleg bij het aanmeldscherm hebben de afbeeldingen van de knoppen 'm1' en 'OK' lege alt-attributen wat de uitleg nutteloos maakt.

Bij BNP Paribas komen ook afbeeldingen voor zonder betekenisvolle alt-tekst en sommige formuliervelden zijn niet correct verbonden met hun label. Dit bemoeilijkt het gebruik maar een ervaren gebruiker zal er wel mee kunnen werken.

Bij ING kan een blinde gebruiker geen overschrijving uitvoeren, zelfs als er een oplossing zou komen om aan te kunnen melden. De procedure voor het ondertekenen van een overschrijving vraagt een code over te typen op de kaartlezer, maar deze code wordt enkel weergegeven in een afbeelding, zonder tekstueel alternatief, als ware het een captcha.

Conclusie

Slechts twee van de vier onderzochte online banktoepassingen (KBC en BNP Paribas) zijn bruikbaar door personen met een visuele handicap. Dit is naast commerciële overwegingen een belangrijk aspect om rekening mee te houden bij het kiezen voor een bepaalde bank.

Wat zouden banken moeten doen?

  • Aan alle (bestaande en potentiële) klanten denken bij het ontwikkelen van de bankwebsite, maar ook de aanmeldprocedure en de kaartlezer.
  • Van hun (interne en externe) programmeurs eisen dat ze bij het ontwikkelen van websites en -toepassingen de toegankelijkheidscriteria van de AnySurfer checklist toepassen.
  • Toegankelijkheid niet vergeten bij het vernieuwen van websites en kaartlezers.

Tot slot

  • Dit onderzoek is uitgevoerd in december 2013. De hierboven beschreven situatie kan ondertussen gewijzigd zijn.
  • We hebben ons in dit onderzoek beperkt tot de websites. Elk van deze banken heeft ook apps voor smartphones en tablets. Het zou een interessant vervolg zijn om die ook eens te testen op toegankelijkheid want je kan ook prima mobiel surfen met een handicap op voorwaarde dat de apps toegankelijk zijn.
  • Banken kunnen behalve een toegankelijke online banktoepassing nog meer doen om het blinde en slechtziende klanten gemakkelijker te maken zoals uittreksels in braille of grootletterdruk, sprekende geldautomaten, behulpzaam personeel enz. Ook dit kunnen criteria zijn bij de keuze voor een bepaalde bank.
  • AnySurfer helpt alle banken graag verder om de toegankelijkheid te verbeteren van hun online banktoepassingen: neem gerust contact op.
  • Veel dank aan het Slechtzienden- en Blindenplatform Vlaanderen en de blinde en slechtziende testers die ons enorm geholpen hebben om dit onderzoek uit te voeren.
3 reacties

Skip links die voor iedereen werken

Bart Simons op 07/01/2014

Links binnen een pagina werken niet in alle browsers zoals verwacht. We hebben het over links van het type <a href="#inhoud">Ga naar de inhoud</a> die we bijvoorbeeld gebruiken als skip link.

Skip link 'ga naar de inhoud' op een pagina van dd AnySurfer-website

Skip links zijn nuttig voor personen die zonder muis surfen omdat ze toelaten direct naar de inhoud te gaan. Zonder skip link moet men eerst alle links van de navigatie doorlopen met de tabtoets van het toetsenbord, voordat men de inhoudelijke links bereikt.

Links binnen een pagina worden ook gebruikt om een inhoudsopgave te maken op een wat langere pagina (zoals deze handleiding over de toegankelijkheid van Word-documenten), of in mini-sites waar alle inhoud zich bevindt op één lange pagina.

Dit soort links is het meest nuttig voor toetsenbordgebruikers (zonder muis). Helaas is het ook voor deze gebruikers dat deze links niet altijd werken. Gelukkig is de oplossing niet moeilijk.

Voorbeelden

Hier volgen twee links naar twee paragrafen die zich lager op de pagina bevinden:

Naar het vervolg van voorbeeld (1)

Naar het vervolg van voorbeeld (2)

Als men deze links gebruikt, hetzij met het toetsenbord hetzij met de muis, dan moeten er twee dingen gebeuren: de pagina scrollt zodat de paragraaf in kwestie verschijnt en de focus verplaatst zich naar deze paragraaf.

Als u Firefox gebruikt, gedragen deze twee links zich op dezelfde manier. Als u een andere browser gebruikt, gedraagt de eerste link zich niet zoals verwacht.

Om het verschil te zien, drukt u op de tabtoets tot u de link 'Naar het vervolg van voorbeeld (1)' bereikt en dan drukt u 'ENTER'. De pagina scrollt en de paragraaf 'Voorbeeld (vervolg 1)' verschijnt. Druk vervolgens nogmaals TAB waardoor u de link 'link' die zich in deze paragraaf bevindt zou moeten bereiken. In Firefox gebeurt dit inderdaad. In andere browsers keert u terug naar de link 'Naar het vervolg van voorbeeld (2)' die zich hierboven bevindt.

Als u Enter drukt op de link 'Naar het vervolg van voorbeeld (2)' scrollt de pagina en verschijnt de paragraaf 'Voorbeeld (vervolg 2)'. Ook verplaatst de focus zich naar het begin van deze paragraaf. De volgende TAB brengt u dus naar de eerste link van deze paragraaf ('andere link'). Dit is het verwachte gedrag.

Code

Wat is het verschil tussen de twee links? Dit is de code van de eerste link, die niet overal goed werkt:

<a href="#vervolg">Naar het vervolg van voorbeeld (1)</a>

De bestemming van de link is een titel van niveau 2 met id="vervolg":

<h2 id="vervolg">Voorbeeld (vervolg 1)</h2>

Wat hebben we gedaan om de tweede link zich zoals gewenst te laten gedragen?

  • Voeg een attribuut tabindex="-1" toe aan het element dat als bestemming dient voor de link:

    <h2 id="vervolg" tabindex="-1">Voorbeeld (vervolg 2)</h2>

    De waarde "-1" van het tabindex-attribuut zorgt ervoor dat het element (hier h2) niet voorkomt in de tabvolgorde, maar het wordt wel mogelijk om er de focus naartoe te brengen.

    Het louter toevoegen van dit tabindex-attribuut volstaat voor Chrome, Opera, Internet Explorer en Safari (voor Mac), in elk geval voor hun recente versies.

  • Verwijs naar de Jquery bibliotheken en voeg een script toe dat de focus() functie gebruikt:

    <script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
    
    <script>
      $(document).ready(function() {
        // voeg een 'click handler' toe voor alle links
        // waarvan het doel zich bevindt op dezelfde pagina (href="#...")		
        $("a[href^='#']").click(function() {
          // vindt het attribuut href van de link,
          // en verwijder het eerste karakter (#)
          // wat de waarde geeft van het id-attribuut van het doel
          $("#"+$(this).attr("href").slice(1)+"")
            // geef de focus aan het element met dit id (voor die browsers die dit zelf niet doen)
            .focus();
        });
      });
    </script>

    Het toevoegen van Javascript is noodzakelijk om het te laten werken in Safari voor Windows.

Zie het zeer volledige artikel van Terril Thomson over skip links (in het Engels) waarin we deze techniek hebben gevonden. Hij beschrijft daarin ook technieken om de focus en de verplaatsing ervan te benadrukken.

Opmerking over screenreaders

  • Met JAWS en NVDA werken de links binnen een pagina standaard correct: de focus verplaatst zich naar de bestemming van de link. Het lezen gaat verder op deze plaats en als men op TAB drukt, is er ook geen probleem.
  • Met Voiceover stelt zich hetzelfde probleem voor de focus van het toetsenbord, maar de voorgestelde oplossing werkt ook hier.

Voorbeeld (vervolg 1)

Een beetje tekst met een link.

Voorbeeld (vervolg 2)

Een beetje tekst met een andere link.

Conclusie

Links binnen een pagina werken niet altijd correct met het toetsenbord. Om ze overal te laten werken moet u het attribuut tabindex="-1" gebruiken op de bestemming van de link, en een beetje Javascript toevoegen. Dit is heel belangrijk voor wie zonder muis surft. Denk hier dus aan als u een inhoudsopgave of skip links maakt.

6 reacties