Europese richtlijn: wie doet wat?

Bart Simons op 31/01/2017

Cet article en français: La directive Européenne relative à l'accessibilité des sites web - résumé

Onze vorige blogpost over de Europese richtlijn inzake de toegankelijkheid van de websites en mobiele applicaties van overheidsinstanties sloot af met de bedenking dat er nog heel wat werk te doen staat. Hier doen we een poging om de tekst van de richtlijn samen te vatten en te groeperen waar de verantwoordelijkheden liggen.

Overheidsinstanties

Het belangrijkste is natuurlijk dat staats-, regionale en lokale overheidsinstanties en publiekrechtelijke instellingen enkel nog toegankelijke websites en apps maken. Dit omvat zowel tekst als andere informatie, downloadbare documenten en formulieren, en interactie, zoals authenticatie , het verwerken van digitale formulieren en online betalingen.

Dit is verplicht voor nieuwe websites die online gaan vanaf 23 september 2018. Bestaande websites, gebouwd voor 22 september 2018, moeten toegankelijk zijn tegen 23 september 2020.

Dit is ook verplicht voor kantoorbestandsformaten die gepubliceerd zijn voor 23 september 2018 als ze nodig zijn voor actieve administratieve processen.

Dit is ook verplicht voor de apps die ze publiceren vanaf 22 juni 2021.

Om toegankelijk te zijn, moet een website of app voldoen aan de Web Content Accessibility Guidelines versie 2.0 niveau AA.

Elke website zal een toegankelijkheidsverklaring bevatten. De Commissie zal hiervoor een template uitwerken. De toegankelijkheidsverklaring moet in elk geval een feedbackmechanisme bevatten zodat bezoekers toegankelijkheidsproblemen kunnen melden. Er moet ook een link vorzien zijn naar de instantie die kan optreden als de overheidsinstantie niet (voldoende) op klachten reageert. De toegankelijkheidsverklaring kan toelichten welke inhoud niet toegankelijk is, maar moet dan ook de redenen daarvoor geven en toegankelijke alternatieven aanreiken.

De Belgische overheden

Ten laatste op 23 september 2018 moeten de lidstaten, dus ook de Belgische overheden:

  • De richtlijn omzetten in Belgische wetgeving en de Commissie informeren als dat is gebeurd. De overheid mag bij de omzetting strengere normen kiezen of het toepassingsgebied uitbreiden, en vrijstellinen schrappen voor uitgesloten content.
  • Aan de Commissie melden welke instantie voor de handhaving van deze richtlijn verantwoordelijk is.
  • Aan de Commissie melden welke instantie toezicht zal houden en zal rapporteren.

Op 23 december 2021 en dan elke drie jaar, moet België een monotoringverslag bezorgen aan de Commissie.

Europese Commissie

De Commissie zal ten laatste op 23 december 2018 deze vier zaken publiceren:

  • Technische specificaties voor mobiele apps
  • Template voor toegankelijkheidsverklaring
  • Methodologie om de conformiteit te monitoren
  • Modaliteiten voor de driejaarlijkse rapportage

Ten laatste op 23 juni 2022 toetst de Commissie de toepassing van deze richtlijn en publiceert ze haar bevindingen in een toegankelijk formaat. Bij deze toetsing houdt ze rekening met de rapporten van de lidstaten over de resultaten van het toezicht en het gebruik van de handhavingsprocedure. Ze zal voor de uitgesloten content ook evalueren of dit nog steeds terecht is.

Vrijstellingen

De Europese richtlijn voorziet een aantal vrijstellingen. Bij het omzetten in nationale wetgeving kan een overheid er uiteraard voor kiezen om er hiervan enkele te laten vallen:

  • De websites en apps van publieke radio- en televisieomroepen. De richtlijn gaat er van uit dat er sectorspecifieke wetgeving komt die toegankelijkheid niet enkel aan de openbare maar ook aan de commerciële omroepen zal opleggen.
  • De websites en apps van NGO's die diensten verlenen die niet essentieel zijn voor het publiek, of diensten die niet specifiek zijn gericht op de behoeften van personen met een beperking
  • Websites en apps van scholen, kinderdagverblijven of crèches behalve essentiële online administratieve functies.
  • Live audio en video
  • Online kaarten; maar er moet wel een toegankelijk digitaal alternatief zijn voor de essentiële informatie
  • Third party content waarvoor de overheidsinstantie niet betaalt, die ze niet zelf heeft ontwikkeld en waarover ze geen controle heeft
  • Reproducties van stukken uit erfgoedcollecties
  • Content van extra- en intranetten die is gepubliceerd vóór 23 september 2019, tot dergelijke websites een ingrijpende herziening ondergaan
  • Kantoorbestandsformaten die zijn gepubliceerd vóór 23 september 2018, tenzij ze nodig zijn voor actieve administratieve processen
  • Video en audio, gepubliceerd vóór 23 september 2020
  • Gearchiveerde content die niet noodzakelijk is voor actieve administratieve processen

Websitebezoekers met een handicap kunnen via het feedbackmechanisme wel een aanvraag doen om uitgesloten inhoud (zoals kantoorbestandsformaten, video of gearchiveerde content) op te vragen in een toegankelijk formaat. De betrokken overheidsinstantie moet naar aanleiding van een legitiem en redelijk verzoek, binnen een redelijke termijn op adequate en passende wijze informatie verstrekken.

Conclusie

Vanaf 23/9/2018 moeten de documenten en websites die overheidsinstanties publiceren, voldoen aan WCAG2.0 niveau AA. Vanaf 23/9/2020 geldt hetzelfde voor websites die eerder werden gepubliceerd (uitgezonderd gearchiveerde documenten). Video's die vanaf deze datum worden gepubliceerd, moeten eveneens toegankelijk zijn. Vanaf 23/6/2021 is het de beurt aan mobiele apps.

Het lijkt misschien dat u als overheidsinstantie nog wat tijd krijgt, maar wacht niet tot september volgend jaar om de toegankelijkheidseisen toe te passen. Ooit zal ook de inhoud die u vandaag publiceert immers toegankelijk moeten zijn. Als u nog niet op de hoogte bent van digitale toegankelijkheid is het moment aangebroken om daar werk van te maken. Iedereen in de overheidssector en hun leveranciers zullen hiermee te maken krijgen. Enkele suggesties:

  • Sensibiliseer uw collega's en zorg dat ze opgeleid zijn.
  • Specifieer toegankelijkheid in het lastenboek voor elke nieuwe website, app, video, digitale brochure of andere digitale toepassing.
  • Check (of laat checken) bij oplevering ervan dat aan de toegankelijkheidscriteria uit het lastenboek is voldaan.
  • Kies leveranciers die ervaring met toegankelijkheid kunnen aantonen.

Als u vragen heeft, laat het ons weten.

1 reactie

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.

4 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.

Lees het vervolg: Europese richtlijn: wie doet wat?

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 deze tutorial om NVDA te leren gebruikenen 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

Supernova is een andere commerciële screenreader die in België veel wordt gebruikt. Deze software gaat helaas niet goed om met paginawijzigingen. Als je met Supernova test, moet je je dus bewust zijn van deze tekortkoming.

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