Vacature junior medewerk(st)er webtoegankelijkheid

Bart Simons op 16/10/2017

AnySurfer, het kenniscentrum voor digitale toegankelijkheid, streeft ernaar dat websites, apps en digitale documenten vlot bruikbaar zijn voor iedereen, ook voor mensen met een handicap. We promoten webstandaarden, testen op toegankelijkheidscriteria, geven opleiding en sensibiliseren het brede publiek.

Jij

  • Je hebt ervaring met front-end ontwikkeling (HTML/CSS/JavaScript). Ervaring met app-ontwikkeling in iOS of Android is een pluspunt.
  • Je leert graag bij en blijft op de hoogte van technische ontwikkelingen.
  • Nederlands en Engels spreek je vlot en schrijf je foutloos. Als dat ook voor je Frans geldt, dan is dat een meerwaarde.
  • Je teksten zijn logisch opgebouwd, aangepast aan het doelpubliek en in klare taal geschreven.
  • Je spreekt graag voor publiek en je enthousiasme werkt aanstekelijk. Je stijl is aangepast aan je doelpubliek.
  • Je staat 100% achter 'accessibility'.
  • Als je zelf een handicap hebt, kan dat een troef zijn.

De job

  • Je test wireframes, designs, templates, documenten, apps en complete websites volgens de Web Content Accessibility Guidelines (WCAG). Je rapport beschrijft niet alleen de problemen maar suggereert ook verbeteringen.
  • Je geeft sensibiliserende presentaties en praktische opleidingen. One on one, in kleine groepjes of voor een bomvolle aula.
  • Je test vanuit het standpunt van een gebruiker met een beperking en publiceert je bevindingen in artikels op onze site.
  • Net als de rest van het team ben je het aanspreekpunt voor iedereen die vragen heeft over toegankelijkheid. Vragen komen zowel telefonisch als via e-mail.

Praktisch

  • Voltijds (38 uur/week)
  • Onbepaalde duur
  • Kantoor op 10 minuten van station Brussel-Centraal, op lange termijn is werken vanuit een ander kantoor van onze vzw bespreekbaar.
  • Een marktconform salaris, laptop, groepsverzekering, maaltijdcheques en een hospitalisatieverzekering maken deel uit van je verloning.

Een week uit het leven van onze toekomstige collega

Als jij onze nieuwe collega wordt en enkele maanden bent opgeleid en ingewerkt, kan je week er ongeveer zo uitzien:

  • Er komt een auditaanvraag binnen voor een website van een overheidsdienst. Je noteert alle gegevens in onze online CRM applicatie en maakt een offerte op.

  • Een klant heeft een bedrijfsvideo laten maken en wil weten hoe ze die best op hun site kunnen plaatsen. Je verwijst naar bronnen voor toegankelijke videospelers.

  • Er belt een klant met vragen over de toegankelijkheid van een pdf-document dat hij op zijn website wil publiceren. Je test het document en geeft feedback.

  • Je maakt een testpagina met verschillende manieren om afbeeldingen als een SVG te implementeren. Je test de pagina met combinaties van browsers, screenreaders en andere hulpmiddelen. Je schrijft je conclusies uit in een samenvattend artikel op onze site.

  • Je legt de laatste hand aan het auditrapport voor een nieuw museum. Je leest het nog eens na, overlegt een aantal zaken met je collega's en verstuurt het naar de klant.

  • Een blinde bezoeker van een website met het AnySurferlabel klaagt dat hij een formulier niet kan verzenden omdat er onlangs een CAPTCHA is toegevoegd. Je verwittigt de contactpersoon van de site en stelt alternatieven voor waarbij de gebruiker geen visuele CAPTCHA moet invullen.

  • Volgende week geef je een technische opleiding aan een team ontwikkelaars. Om de opleiding te personaliseren, zoek je nog wat voorbeelden op sites die zij hebben gebouwd.

Stel jezelf voor via info@anysurfer.be, ter attentie van Gijs Veyfeyken. Specifieke vragen over de job? Bel 02-210 61 49.

AnySurfer is een project van Blindenzorg Licht en Liefde vzw.

Reageer als eerste

ARIA live regions

Bart Simons op 13/09/2017

Paginawijzigingen zijn een probleem voor blinden en al wie geen overzicht heeft over het scherm. De wijziging kan het gevolg zijn van een actie: een foutmelding verschijnt wanneer je een formulier verzendt. Of de wijziging kan automatisch zijn: de koers van een beursaandeel wordt om de 30 seconden bijgewerkt. De screenreader synchroniseert continu met het DOM en pikt de wijziging dus wel op, maar de gebruiker wordt hier standaard niet van geïnformeerd. Wie het scherm niet ziet, weet daardoor niet dat er iets is gewijzigd. De focus van een screenreader kan maar op 1 plaats tegelijk zijn. In sommige gevallen kan een ARIA live region hierbij helpen.

Enkele goede voorbeelden

  • Je boekt een vlucht met Brussels Airlines en krijgt een overzicht van de mogelijkheden. Via radio buttons selecteer je een vlucht. Telkens je een andere vlucht aanvinkt, verandert de totale prijs van de reis. Om die gewijzigde prijs te bekijken, moet een screenreadergebruiker er naartoe navigeren. Als hij een andere keuze wil maken, moet hij terugkeren naar het overzicht enz. De prijs is hier echter een live region en wordt daardoor automatisch uitgesproken van zodra hij verandert.

  • Als je een tweet opstelt in de Twitter-website verschijnt een teller in beeld van zodra er nog maar 20 karakters beschikbaar zijn. Een blinde zal die niet opmerken, maar dankzij de live region hoor je deze informatie toch.
  • De zoekresultatenpagina van Gov.uk bevat een filter. Telkesn je een optie aan- of uitvinkt, verandert het aantal gevonden resultaten. Ook dit blokje is een live region waardoor de screenreader het nieuwe aantal resultaten uitspreekt.

Hoe werkt het?

Met het attribuut aria-live maakt u van een blok een live region. In dit voorbeeld wijzigt de tekst bovenaan als je op één van de steden klikt. De gewijzigde tekst zit in een live region en screenreaders zullen die dan automatisch uitspreken.

<div id="result" aria-live="polite">U hebt Brussel gekozen.</div>

screenshot aria-live demopagina

Mogelijke waarden voor aria-live zijn:

  • aria-live="assertive": de screenreader spreekt de gewijzigde tekst onmiddellijk uit. Als hij bezig was andere tekst uit te spreken, wordt die onderbroken.
  • aria-live="polite": de screenreader zal de gewijzigde tekst uitspreken van zodra daar ruimte voor is. Dit is de meest geschikte waarde voor een live region.
  • aria-live="off": dit zorgt ervoor dat een blok (tijdelijk) geen live region is.

Standaard zal een screenreader enkel de gewijzigde tekst binnen een live region voorlezen. Als een chat-venster een live region is, zal je dus telkens enkel de laatst toegevoegde boodschap horen en niet alle berichten die al in het blok stonden. Wilt u daarvan afwijken en toch altijd het hele blok laten voorlezen, voeg dan aria-atomic="true" toe. Een mogelijk voorbeeld is de playlist op een radiowebsite: zonder aria-atomic of met aria-atomic="false" zal anneer een nieuw nummer start, enkel de naam van de artist en de naam van het volgend nummer worden uitgesproken. De tekst "Volgend nummer" is ongewijzigd en wordt niet voorgelezen.

<p aria-live="polite">
Volgend nummer: <span id="nextsong">Als ze lacht - Yevgueni</span></p>

Door aria-atomic="true" toe te voegen, wordt de volledige inhoud voorgelezen, inclusief de ongewijzigde inhoud "Volgend nummer". Op die manier is er geen verwarring met het nummer dat speelt.

<p aria-live="polite" aria-atomic="true">
Volgend nummer: <span id="nextsong">Als ze lacht - Yevgueni</span></p>

Wil je nog meer controle over welke onderdelen binnen de live region de screenreader uitspreekt? Voeg dan aria-relevant toe. In dit voorbeeld zal de screenreader enkel de toevoegingen aan de live region uitspreken. Een mogelijke toepassing is de deelnemerslijst van een webinar:

<ul id="participants"
aria-live="polite" aria-relevant="additions">
<li>Pierre Jourdain</li>
<li>Gijs Veyfeyken</li>
</ul>

Als in een live region zeer veel wijzigt, kan je die tijdelijk aria-busy="true" geven. Dit onderdrukt de meldingen maar de screenreader verzamelt wel alle wijzigingen. Als u het attribuut daarna verwijdert of wijzigt naar aria-busy="false", leest de screenreader alle wijzigingen achter elkaar voor.

Impliciete live regions

Enkele ARIA roles maken van een blok impliciet een live region. De meest bekende is role="alert". Het blok met deze role wordt impliciet een assertieve live region. De screenreader zal deze informatie dus onmiddellijk voorlezen. Voorbeeld:

<div role="alert">
Het maximum aantal is bereikt.
</div>

Beperkingen

Het enige wat er met een live region gebeurt, is dat een screenreader wijzigingen binnen het blok voorleest. De focus verplaatst zich niet. Dus als de nieuw verschenen informatie interactie van de gebruiker verwacht, dan is focusmanagement een beter idee dan een live region.

De screenreadergebruiker heeft geen controle over de uitgesproken informatie. Als hij (per ongeluk) een toets aanraakt, wordt de aankondiging onderbroken en is er geen manier om de informatie opnieuw te beluisteren.

Het kan erg frustrerend zijn voor een screenreadergebruiker dat de website-ontwikkelaar de controle over de screenreader overneemt en allerlei meldingen forceert. We zagen ooit een slideshow die als live region was gemarkeerd. Die pagina is in de praktijk onbruikbaar voor screenreadergebruikers omdat elke 3 seconden nieuwe informatie wordt voorgelezen zonder dat je daarom vroeg en je kunt het niet uitschakelen.

Tips voor het gebruik

  • Het element waarop aria-live staat, moet aanwezig zijn voor de wijziging gebeurt. Bijvoorbeeld de lege div <div aria-live="polite"></div>. Als de div pas aangemaakt wordt op het moment van de wijziging, werkt het niet.
  • Wees erg spaarzaam met live regions. Gebruik ze enkel voor paginawijzigingen die relevant zijn voor een screenreadergebruiker.
  • Gebruik ze enkel voor korte teksten.
  • Geef anderzijds wel genoeg context: in het voorbeeld van Brussels Airlines: niet enkel de gewijzigde prijs laten uitspreken maar erbij zeggen dat het om de totale prijs gaat.
  • Bij formuliervalidatie: ok om te zeggen dat er foutmeldingen zijn, maar focusmanagement is nog steeds nodig om naar het veld te springen om het probleem op te lossen

Bronnen

Reageer als eerste

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.

4 reacties

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