Spampreventie met Google's reCAPTCHA v2

Gijs Veyfeyken op 18/01/2017

Dit principe van spampreventie is simpel. Je moet een checkbox aanvinken om te bewijzen dat je een mens bent. En die checkbox is prima toegankelijk. Ook met het toetsenbord of een screenreader.

reCAPTCHA checkbox met label I'm not a robot

Maar soms is het aanvinken van de checkbox niet voldoende en vraagt Google om een extra handeling. Je krijgt een foto te zien die is opgedeeld in vierkantjes en je moet elk vak aanklikken dat een bepaald element bevat. Bijvoorbeeld alle vakken in de foto die een straatbord bevatten.

foto met 4 vakken die een verkeersbord voor fietsers en wandelaars bevatten

Dat is voor een slechtziende niet evident en voor een blinde onmogelijk. Daarom kan je ook voor een audiocaptcha kiezen via het icoontje van een koptelefoon.

De audiocaptcha zelf is altijd in het Engels. Je moet 5 cijfers in een invoerveld typen.

press play and enter the numbers you hear

Maar je mag er eigenlijk niet van uitgaan dat al je bezoekers Engelse cijfers makkelijk begrijpen. De taal van de interface past zich wel aan (aan de taal van de browser?).

De audiocaptcha start onmiddellijk na het activeren van de play-knop. Een screenreadergebruiker mist daardoor meestal het eerste cijfer omdat de screenreader dan nog aan het spreken is.

In onze testen moesten we meerdere en verschillende audiocaptcha's achter elkaar correct oplossen om geverifieerd te raken. Dit doet de slaagkans enorm dalen en neemt veel tijd in beslag. Het is ook verwarrend want je zou denken dat één audiocaptcha correct oplossen voldoende is.

Je krijgt de melding "Er zijn meerdere juiste oplossingen vereist - geef meer oplossingen op." De gebruiker denkt daardoor misschien dat hij meer dan 5 cijfers moet ingeven maar dat is niet het geval. De cijfers worden ook met verschillende stemmen voorgelezen, sommige met sterke vervorming. Voor slechthorenden zijn die moeilijk of onmogelijk te verstaan.

Google's ReCAPTCHA v2 is dus helaas zeer ongebruiksvriendelijk voor een screenreadergebruiker. Maar met het nodige doorzettingsvermogen geraakt een power-user er wel voorbij.

Iemand die slecht ziet en slecht hoort, zit wel volledig vast.

Tot slot is er nog de onvoorspelbaarheid op langere termijn. Je hebt geen controle over de code. Google kan dit morgen aanpassen in positieve of negatieve zin.

Is Google's reCAPTCHA technisch toegankelijk?

Ja, behalve voor mensen met een combinatie van een visuele en auditieve beperking.

Is het gebruiksvriendelijk?

Neen. Voor sommige gebruikers is het zeer moeilijk en omslachtig.

Is er een alternatief?

We zijn grote voorstander van spampreventie waar de bezoeker niets van merkt zoals werken met een honeypot of tijdsanalyse.

2 reacties

EU-richtlijn over toegankelijkheid overheidswebsites treedt in werking

Bart Simons op 23/12/2016

Champagne!
We klinken niet enkel op het naderend eindejaar, maar speciaal op de inwerkingtreding van de Europese richtlijn over toegankelijkheid van overheidswebsites.

Vier jaar geleden deed de Europese Commissie een eerste voorstel. Dat werd uitvoerig geamendeerd door het Europese Parlement en vervolgens stevig bediscussieerd in de telecom-raad. Onder het Nederlandse voorzitterschap vond men een compromis begin mei 2016. Maar we moesten nog wachten op de goedkeuring door het parlement op 26 oktober 2016. Vervolgens verscheen de tekst op 2 december in het Publicatieblad van de Europese Unie (zoiets als het Staatsblad). Dan was het enkel nog 20 dagen wachten op de inwerkingtreding.

Maar hier is hij dan: Richtlijn (EU) 2016/2102 van het Europees Parlement en de Raad inzake de toegankelijkheid van de websites en mobiele applicaties van overheidsinstanties

Na de champagne volgt er nog een hoop werk maar de inwerkingtreding van deze richtlijn is een belangrijke stap. Eindelijk hebben mensen met een beperking een poot om op te staan als websites en apps van de overheid niet toegankelijk zijn.

Reageer als eerste

Screenreaders om je site mee te testen

Bart Simons op 23/09/2016

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. Testen met een screenreader is noodzakelijk als u ARIA gebruikt.

Er zijn geen statistieken voor België over welke screenreaders het meest worden gebruikt. Het is dus moeilijk om te beslissen met welke screenreader(s) je moet testen om zo dicht mogelijk aan te sluiten bij de situatie van de gebruikers.

Software die de tekst van het scherm voorleest, dat klinkt simpel maar is het niet. Op het scherm staat tekst meestal in meerdere kolommen en wordt hij afgewisseld met afbeeldingen, links, formulieren en eventueel bewegende informatie. Dit artikel beschrijft hoe screenreaders erin slagen zoveel mogelijk informatie van het scherm voor te lezen.

Waar moet u rekening mee houden?

Een screenreader is complexe software, dus trek wat tijd uit om ermee te leren werken. Denk niet te snel dat surfen op internet voor blinden onmogelijk is.

  • 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 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.
  • De screenreader doet meer dan voorlezen wat er op het scherm staat. Bij het surfen, zit de screenreader tussen de gebruiker en de browser. Sommige toetsaanslagen hebben een ander effect als de screenreader actief is. Er zijn bovendien meerdere interactiemodi, bijvoorbeeld bij het invullen van een formulier. Dit artikel beschrijft drie verschillende interactiemodi. U moet zich hiervan bewust zijn als u een formulier of een widget test.

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 en WebAIM heeft een artikel Using VoiceOver to Evaluate Web Accessibility.

Screenreaders voor Windows

NVDA

Non Visual Desktop Access (NVDA) is een open source 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.

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. Zie verder het WebAIM-artikel Using NVDA to Evaluate Web Accessibility

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 verschillende talen. De meest recente versie is 18. 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 best ook een oudere versie moeten gebruiken.

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

Er is een specifieke tutorial om te leren surfen met JAWS en WebAIM heeft een artikel Using JAWS to Evaluate Web Accessibility.

Supernova

In artikels over toegankelijkheid lees je er nooit over en in de Screen Reader User Survey van WebAIM komt hij enkel voor in de categorie "overige", maar deze commerciële screenreader wordt in België nog veel gebruikt. Deze screenreader gaat helaas niet goed om met paginawijzigingen. Als je met Supernova test, moet je je dus bewust zijn van deze tekortkoming.

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.

Smartphones en tablets

Op apparaten met een aanraakscherm doet een screenreader nog veel meer dan voorlezen wat er op het scherm staat. Hij moet ook hulp bieden bij het navigeren en er is dan ook een heel ander bedienginsconcept uitgedacht voor tablets en smartphones. Zie het artikel mobiel surfen met een handicap.

1 reactie

Het HTML5 outline algoritme werkt niet

Bart Simons op 03/06/2016

Dit is een geactualiseerde versie van een artikel dat werd gepubliceerd in juni 2013. Cet article en français: HTML5 outline n'est pas supporté

In het kort

  • Gebruik altijd een logische en hiërarchische volgorde van kopniveaus <h1>, <h2>, <h3> om pagina's te structureren.
  • Vertrouw niet op het HTML5 outline algoritme om automatisch de koppenstructuur te berekenen op basis van de "sectioning content" (<section>, <nav>,<aside> en <article>).

Structuur

Mensen die geen overzicht van het scherm hebben, zoals blinden en slechtzienden, kunnen software gebruiken die alles voorleest wat op het scherm staat. Die software, ook screenreader genoemd, doet meer dan alles letterlijk voorlezen. Zo worden ook lijsten, tabellen en titels (koppen) aangekondigd. Wanneer een kop wordt voorgelezen, vermeldt een screenreader ook het niveau van de kop. Bijvoorbeeld op onze pagina over captcha's leest een screenreader de kop <h1>Spam vermijden zonder captcha</h1> als volgt voor: "Spam vermijden zonder captcha - kopniveau 1". De subtitel "geen captcha" iets verderop wordt aangekondigd met kopniveau 2. En zo verder.

kopniveaus artikel captcha

Dit is cruciale informatie voor wie het scherm niet (of nauwelijks) ziet. Aan de hand van de kopniveaus kan men de structuur van een pagina beter begrijpen. Men kan ook "koppen springen" door middel van een sneltoets (h van heading) of een overzicht (outline) van alle koppen op een pagina oproepen. Onderstaande screenshot is de "headings outline" van de screenreader VoiceOver op Mac.

Lijst van headings met VoiceOver

Daarom vragen toegankelijkheidsrichtlijnen om een hiërarchische en logische volgorde van koppen te hanteren. Het is essentieel voor bezoekers met een visuele beperking en het helpt bij zoekmachine-optimalisatie (SEO).

HTML5 heeft verschillende nieuwe elementen geïntroduceerd die het mogelijk maken om pagina's beter te structureren. Elementen zoals <section>, <nav>,<aside> en <article>, ook "sectioning content" genoemd.

In HTML4 moest u zelf het niveau van koppen aanduiden. De titel van de pagina is h1, een subtitel een h2 enzoverder. Als u de nieuwe HTML5 elementen gebruikt, mag u (maar moet niet) altijd h1 gebruiken. Het HTML5 outline algorithm zal automatisch het kopniveau bepalen. Voor elk niveau van nesting wordt een kopniveau bijgeteld. Een h1 binnen een section die zelf binnen section staat, wordt zo automatisch een h2. Wanneer u een h1 gebruikt binnnen een element dat 3 niveaus diep is genest, wordt dat automatisch een h3. Enzoverder.

Theorie

Hieronder een voorbeeld (bron: W3C) met een normale, hiërarchische volgorde van koppen.

<body>
 <h1>Apples</h1>
 <p>Apples are fruit.</p>
 <section>
  <h2>Taste</h2>
  <p>They taste lovely.</p>
  <section>
   <h3>Sweet</h3>
   <p>Red apples are sweeter than green ones.</p>
  </section>
 </section>
 <section>
  <h2>Color</h2>
  <p>Apples come in various colors.</p>
 </section>
</body>

De outline van koppen wordt dan:

<h1>Apples</h1>
<h2>Taste</h2>
<h3>Sweet</h3>
<h2>Color</h2>

Volgens de HTML5 specificatie mag u nu ook enkel h1's gebruiken:

<body>
 <h1>Apples</h1>
 <p>Apples are fruit.</p>
 <section>
  <h1>Taste</h1>
  <p>They taste lovely.</p>
  <section>
   <h1>Sweet</h1>
   <p>Red apples are sweeter than green ones.</p>
  </section>
 </section>
 <section>
  <h1>Color</h1>
  <p>Apples come in various colors.</p>
 </section>
</body>

Dit wordt omwille van de sections automatisch omgevormd tot de onderstaande identieke outline van koppen:

<h1>Apples</h1>
<h2>Taste</h2>
<h3>Sweet</h3>
<h2>Color</h2>

In theorie maakt dit outline algoritm het dus makkelijker voor de developer zolang hij een logische structuur van sections (en andere "sectioning content" zoals <nav>, <aside> en <article>) hanteert. Maar kunnen screenreaders hier wel mee overweg? Krijgen blinde en slechtziende gebruikers nog steeds het juiste kopniveau te horen?

Praktijk

Het voorbeeldje van "apples" met <section>'s en enkel h1's levert de volgende resultaten op met de meest gebruikte screenreaders.

logo NVDA NVDA versie 2016.1 met IE11 en Firefox 46: geen ondersteuning, leest enkel h1's
logo Supernova Supernova versie 13.59 met Internet Explorer 11: geen ondersteuning, leest enkel h1's
logo VoiceOver VoiceOver OS X 10.11.5 (El Capitan) met Safari 9.1.1: geen ondersteuning, leest enkel h1's
logo Jaws Jaws versies 15, 16 en 17 met IE11 en Firefox 46: geen ondersteuning, leest enkel h1's

Conclusie van de test:

Er is duidelijk geen ondersteuning voor het HTML5 outline algorithm onder screenreaders. Als u "sectioning content" (<section>, <nav>,<aside> en <article>) met daarbinnen enkel h1's gebruikt, verdwijnt alle structuur van de pagina's voor screenreadergebruikers. Daarom raden we deze techniek op dit moment af. We volgen daarmee de HTML5.1 specificatie:

There are currently no known implementations of the outline algorithm in graphical browsers or assistive technology user agents, although the algorithm is implemented in other software such as conformance checkers. Therefore the outline algorithm cannot be relied upon to convey document structure to users. Authors are advised to use heading rank (h1-h6) to convey document structure.
4 reacties

Nieuwe voorwaarden erkende bouwers

Gijs Veyfeyken op 26/05/2016

Cet article en français: Nouvelles conditions pour les prestataires reconnus

Webbedrijven zijn onze belangrijkste partner om het internet toegankelijker te maken. Daarom belonen we bedrijven met bewezen ervaring in toegankelijkheid als erkende bouwer. Er staan vandaag 12 erkende bouwers op de lijst. Je kan op hen vertrouwen als je een toegankelijke website wilt laten bouwen.

We willen enerzijds de lijst zien groeien en anderzijds een betere band opbouwen met de Belgische webbouwers. We hebben ideeën om de voorwaarden voor erkende bouwers te wijzigen. We horen graag jullie mening over dit voorstel.

Huidige voorwaarden

Er zijn nu 4 voorwaarden om erkende bouwer te worden:

  • Een technische opleiding volgen bij AnySurfer
  • Het AnySurferlabel behalen voor eigen website
  • Het AnySurferlabel behalen voor een website van een klant
  • Een CMS aanbieden dat toelaat om toegankelijke inhoud te publiceren

Om erkende bouwer te blijven:

  • Elk jaar een website labelen
  • Elke twee jaar opleiding volgen

Van sommige ontwikkelaars horen we dat de drempel om in te stappen te hoog is. Anderen vinden het moeilijk om elk jaar een gelabelde website te produceren. Daarom hebben we die laatste voorwaarde tot nu toe niet strikt opgevolgd.

Voorstel nieuwe voorwaarden

Het basisidee blijft hetzelfde: een webbouwer krijgt erkenning wanneer die aantoonbare kennis en ervaring in toegankelijkheid heeft.

We verlagen de drempel om erkende bouwer te worden:

  • Een technische opleiding volgen is de basis en blijft verplicht.
  • De webbouwer verdient het AnySurferlabel voor zijn eigen website of de website van een klant. Dit is één traject minder dan met de huidige voorwaarden.
  • De webbouwer documenteert voor zijn klant hoe hij met zijn specifiek CMS inhoud op een toegankelijke manier toevoegt.

Om erkende bouwer te blijven, vragen we de webbouwer om zijn expertise te onderhouden. Dat kan op verschillende manieren :

  • Het AnySurferlabel behalen voor een website van een klant
  • Een website bouwen die voldoet aan toegankelijkheidsrichtlijnen op de redactionele punten na, die vallen onder de verantwoordelijkheid van de klant. Bijvoorbeeld documenten toegankelijk maken, videos ondertitelen of andere inhoudelijke punten.
  • Nieuwe collega's de opleiding laten volgen
  • Kennis delen:
    • Talks, meetup's, blogposts, etc. waarbij toegankelijkheid aan bod komt
    • Code delen, bijvoorbeeld een toegankelijke widget voor tabs in Drupal
    • ...

Wat krijg je terug?

De lijst van erkende bouwers op onze website is nu een alfabetische opsomming van links. We willen de erkende bouwers meer in de kijker zetten. Net als een gelabelde website geven we een erkende bouwer ook een statuspagina. Zo hebben jullie potentiële klanten meer informatie:

  • Wat voor projecten doen jullie? Grote commerciële websites of kleine sites voor bijvoorbeeld een vereniging of kmo?
  • Wat is jullie specialisatie?
  • Met welk CMS werken jullie?
  • Wat is jullie bijdrage tot een toegankelijker internet? Gelabelde websites gebouwd, widgets toegankelijk gemaakt, toegankelijkheidsbugs opgelost in open source toepassingen, presentaties gegeven of artikels geschreven ...

Benieuwd naar jullie mening

Wat vinden jullie van de nieuwe voorwaarden? Wat houdt jullie tegen om erkende bouwer te worden? Wat zou het aantrekkelijker maken? Laat je mening achter in de comments of stuur een mailtje naar info@anysurfer.be.

1 reactie