5 redenen waarom toegankelijkheid een plaats verdient in uw communicatiestrategie

Gijs Veyfeyken op 30/04/2014

Deze tekst is geschreven als gastblogpost voor Toecomst, Logboek van het project Visie en strategie Vlaamse overheidscommunicatie 2014-2020

1. Omdat Europa het verplicht

Er zit nieuwe Europese wetgeving in de pijplijn die de toegankelijkheid van overheidsinformatie en diensten op het web, e-government, verplicht onder de lidstaten. Europa hanteert de Web Content Accessibility Guidelines (WCAG) als norm. Deze internationaal erkende ISO-standaard bevat 3 niveau’s van toegankelijkheid.

  • WCAG level A: basisniveau, de norm om het AnySurfer label te behalen.
  • WCAG level AA: gemiddeld niveau, de norm die Europa oplegt
  • WCAG level AAA: strengste niveau, in de praktijk nauwelijks haalbaar

Bekijk de toespraak van Neelie Kroes van de Europese Commissie op Youtube: Making the web accessible for people with a disability.

2. Omdat 15% van de Vlamingen een beperking heeft

  • mensen met een motorische handicap, die het moeilijk hebben met een muis of toetsenbord
  • blinden, die spraaksoftware gebruiken om naar een website te luisteren
  • slechtzienden, die vergroting gebruiken en nood hebben aan hoge contrasten
  • slechthorenden, waarvoor ondertiteling essentieel is.
  • doven, bij wie gebarentaal de moedertaal is en het Nederlands een vreemde taal is.
  • dyslectici, personen met een concentratiestoornis of andere cognitieve stoornissen.

Vergeet de vergrijzing van de bevolking niet. Dit cijfer zal enkel stijgen.

3. Omdat 15% van de Vlamingen de taal van de overheid niet spreekt

“In Vlaanderen is 15% van de volwassenen laaggeletterd. Dit betekent dat meer dan een half miljoen Vlamingen (580.470) kampt met een duidelijk geletterdheidsprobleem.”

Bron Vakgroep Onderwijskunde Universiteit Gent

Het gemiddeld taalniveau ligt op B1 of B2 van het Europees referentiekader. Het merendeel van overheidscommunicatie is geschreven op niveau C1, te moeilijk voor het grootste deel van de bevolking.

Iedereen leest graag klare taal.

4. Omdat vanaf het begin rekening houden met toegankelijkheid, tijd, moeite en middelen bespaart

Vergelijk het met het bouwen van een huis. Als de architect rekening houdt met toegankelijkheid in het ontwerp, blijft de meerkost beperkt en is het huis bij oplevering meteen bruikbaar. Wanneer toegankelijkheid pas achteraf ter sprake komt, zijn verbouwingen noodzakelijk. Dit kost nodeloos tijd, geld en moeite.

  • Kies voor een erkende webbouwer met bewezen ervaring en expertise
  • Neem toegankelijkheid op als vereiste in de aanbesteding van nieuwe websites en controleer bij oplevering

5. Omdat Google en mobiele gebruikers steeds belangrijker worden

  • Search Engine Optimisation (SEO): Google is blind en leest uw website op gelijkaardige wijze als een blinde met een screenreader dat doet. Toegankelijkheidsrichtlijnen helpen u beter scoren in Google.
  • Mobile: mobiele gebruikers zijn ook “gehandicapt”. Ze kunnen geen muisfuncties uitvoeren en lezen op een klein scherm, vaak in een omgeving met zonlicht, waardoor hoge contrasten wenselijk zijn.

Hoe staat de Vlaamse overheid er momenteel voor?

AnySurfer onderzoekt jaarlijks de toegankelijkheid van het Belgische internetlandschap. Daarbij wordt ook een steekproef van Vlaamse overheidssites gescreend op vraag van de dienst Emancipatiezaken.

  • 14% van Belgische websites voldoet aan minimale toegankelijkheidsvereisten
  • 64% van Vlaamse overheidswebsites

Opgelet, dat wil niet zeggen dat 64% van de Vlaamse overheid voldoet aan de norm die Europa oplegt (WCAG level AA). Slechts 11% draagt het AnySurfer label (= WCAG level A). Het aantal websites dat voldoet aan WCAG level AA zal nog lager liggen.

Wat zijn de grootste uitdagingen?

  • Bewustwording: op vlak van fysieke toegankelijkheid, bijvoorbeeld van openbare gebouwen, is er een maatschappelijk draagvlak. Het is een evidentie. Bij digitale toegankelijkheid is dat nauwelijks het geval.
  • Word en PDF: er worden anno 2014 nog steeds massaal ontoegankelijke documenten online gezet om te communiceren met de burger. 90% van die documenten zouden beter als webpagina’s gepubliceerd worden. Dat is voor iedereen toegankelijker en gebruiksvriendelijker. Hetzelfde geldt voor interactie met de burger: formulieren.
1 reactie

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.

Jonathan Mosen toont in deze video wat de meerwaarde is van een smartphone en waarom het loont om apps toegankelijk te maken.

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.

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.
5 reacties

Skip links die voor iedereen werken

Bart Simons op 07/01/2014

Update op 22 september 2016 : het probleem is nu opgelost in de meeste browsers maar bestaat nog in Edge en IE11.

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 de 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 Nielsen Norman Group artikel gaat uitgebreid in op de afwegingen om al dan niet zulke "binnen pagina links" te gebruiken.

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.

In dit voorbeeld staan twee links naar twee paragrafen die zich lager op de pagina bevinden:

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

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.

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