Scalable Vector Graphics (SVG)

Gijs Veyfeyken op 13/07/2018

Scalable Vector Graphics (SVG) bieden bepaalde voordelen tegenover hun rastergebonden soortgenoten. Dankzij hun vectoriële aard kan je ze eindeloos herschalen zonder kwaliteitsverlies. Dit maakt ze gebruiksvriendelijk voor mensen die zichtproblemen hebben en vergrotingsprogramma's gebruiken.

Toch zijn SVG-bestanden niet vanzelf toegankelijk. Een aantal ingrepen zijn nodig om deze compatibel te maken met hulptechnologieën zoals schermlezers en toetsenbordnavigatie. Dit artikel bespreekt de belangrijkste aspecten van toegankelijke SVG's.

We overlopen enkele scenario's die veel voorkomen.

Decoratieve afbeelding

In dit voorbeeld is de SVG van het e-mail icoon decoratief want de informatie is ook als tekst beschikbaar.

<svg aria-hidden="true" focusable="false">...</svg>
<span>E-mail us at <a href="mailto:info@example.com">info@example.com</a></span>

Codepen svg decorative - aria-hidden

Screenshot:

e-mail icoon met tekst en link ernaast

  • We voegen aria-hidden="true" toe aan het SVG element zodat screenreaders het icoon negeren. role="presentation" is ook een optie.
  • Het focusable="false" attribuut lost een bug in Internet Explorer op.

Betekenisvolle afbeelding met SVG als source attribuut

Dit is het meest robuust en waterdicht wat betreft ondersteuning door screenreaders. Je gebruikt een normale afbeelding met een beknopte alt-tekst en verwijst naar de svg in het source attribuut. Simpel en makkelijk. Het enige nadeel is dat je geen delen van de svg kunt aanspreken. Bijvoorbeeld een deel van de afbeelding van kleur laten veranderen bij :focus en :hover.

<img src="http://label.anysurfer.be/images/label_AS_square.svg" alt="AnySurfer logo" />

Codepen svg meaningful via src

Screenshot:

AnySurfer logo

Betekenisvolle afbeelding als inline SVG

Je kan alternatieve tekst toevoegen aan inline SVG's met de combinatie van een title element, een aria-labelledby attribuut en een role img.

<svg role="img" aria-labelledby ="logo" focusable="false">
  <title id="logo">AnySurfer logo</title>
  ...
</svg>

Codepen svg meaningful - aria

Screenshot:

logo AnySurfer

  • Voeg een title element toe aan je SVG die de afbeelding beschrijft. Het titel element moet de eerste child zijn van diens parent element: deze plaats je dus meteen na je svg tag. De titel heeft in deze context een gelijkaardige functie als het alt-attribuut van een standaard img element. De schermlezer zal deze gebruiken om de SVG-code te benoemen.
  • Laat het attribuut aria-labelledby verwijzen naar je title. Zo ben je zeker dat elke browser en schermlezer de link tussen de titel en de SVG legt.
  • Dankzij de toevoeging van role="img" weet een schermlezer, en dus ook de blinde gebruiker, dat het gaat om een afbeelding. Bepaalde browsers en schermlezers beseffen niet dat SVG-code een beeldrol heeft. Door een role toe te voegen, overschrijf je de mogelijk foute rol die de browser zelf aan de SVG geeft.
  • De SVG specificatie voorziet ook een desc (description) element voor afbeeldingen die een uitgebreide beschrijving vereisen. Plaats deze onder je title element en verwijs er op dezelfde manier naar met aria-labelledby. Een desc is overbodig voor normale, eenvoudige afbeeldingen.
  • Het focusable="false" attribuut lost een bug in Internet Explorer op.

Complexe afbeelding als inline SVG

<h2>Water consumptie</h2>
<svg role="img" aria-labelledby="diag" focusable="false">
	<title id="diag">Diagram water consumptie (tekstversie hieronder)</title>
		<g aria-hidden="true">
			<g>
				<g>...</g>
				<g>...</g>
				<g>...</g>
				<g>...</g>
				<g>...</g>
			</g>
</svg>

<table>
	<caption>Water consumptie</caption>
	...
</table>

Codepen svg complex aria

Screenshot:

diagram en tabel waterconsumptie

  • We volgen dezelfde principes als bij een simpele SVG en geven de SVG een beknopte omschrijving via het title element
  • We verbergen het g element wiens kinderen tekst bevatten zodat die wordt overgeslagen door screenreaders. Zonder de visuele context zijn die cijfers verwarrend.
  • Onder de SVG voegen we een tabel toe als tekstueel alternatief voor het diagram.

SVG in een link of button

Wanneer de SVG binnen een link of button staat, mag de SVG zelf genegeerd worden door screenreaders. We kunnen als alternatief een aria-label op de link of button plaatsen. Of kiezen voor de meest robuuste techniek, verborgen tekst.

In een link met verborgen tekst:

<a href="http://www.anysurfer.be">
<span class="visuallyhidden">AnySurfer startpagina</span> 
<svg role="presentation" focusable="false">
...
</svg>
</a>
.visuallyhidden {
 position: absolute;
 width: 1px;
 height: 1px;
 margin: -1px;
 overflow: hidden;
 clip: rect(0 0 0 0);
}

Codepen svg link hidden text

Screenshot:

logo AnySurfer

In een button met een aria-label:

<button aria-label="delete">
<svg role="presentation" focusable="false">
...
</svg>

Codepen svg button aria-label

Screenshot:

vuilbak icoon

Bugs

VoiceOver (screenreader op Mac) kondigt een SVG altijd aan als een "group" (Webkit bug), wat mogelijk verwarrend is.

IE11 bevat een veel voorkomende bug. SVG's krijgen namelijk focus wanneer je door een pagina tabt, ook wanneer deze geen link zijn. Dat los je op door focusable="false" toe te voegen.

Internet Explorer 11 wordt veel gebruikt door mensen met een handicap omdat deze browser compatibel is met vele soorten assistive technology, in tegenstelling tot Edge. Het is daarom belangrijk dat je website naar behoren werkt in IE.

Bronnen

Reageer als eerste

Pleidooi van een screenreadergebruiker: overdrijf niet

Bart Simons op 11/07/2018

Semantiek is belangrijk en wij hameren er nogal op dat je voor koppen, lijsten, sections enz. de HTML-elementen gebruikt die daarvoor beschikbaar zijn. Maar als je overdrijft, gaat het effect verloren. Waar semantiek een screenreadergebruiker erg kan helpen om zich te oriënteren binnen een webpagina, kan overdaad het juist onoverzichtelijk maken. Goedbedoelende ontwikkelaars kunnen het ook op andere gebieden té goed willen doen.
Wat volgt is een persoonlijke mening. Ik wil niemand aan de schandpaal nagelen, maar met de website van het Center for Education & Rehabilitation for the Blind kan ik illustreren wat ik bedoel. Deze website claimt dat ze voldoet aan WCAG2.0 niveau AAA, maar ik vraag me toch af of hun cursisten er gemakkelijk hun weg vinden.

Skip links

Een link bovenaan in de broncode die zichtbaar wordt als hij focus krijgt en toelaat om naar de inhoud te springen, heeft zeker zijn nut. De voorbeeldwebsite heeft drie van zulke skip links: de eerste brengt je naar de inhoud zoals je mag verwachten, maar daarnaast kan je ook naar de navigatie en naar de footer springen. Ik betwijfel of iemand dat laatste zou willen. De navigatie is inderdaad een beetje moeilijk te vinden, maar dat komt voornamelijk door veel andere overbodige inhoud.

Als je skip links toevoegt, geef je de mogelijkheid om sneller naar een onderdeel van de site te tabben, maar denk er aan dat elke skip link zelf ook een extra tabstop toevoegt aan het begin van elke webpagina.

Verborgen tekst

De visuele positionering van elementen op een webpagina gaat voor blinden verloren. Het kan voor screenreadergebruikers soms interessant zijn om extra informatie toe te voegen. Je kan verborgen tekst toevoegen via de clipping-techniek of je kan met aria-labels aan de slag. Kies een van beide technieken en niet allebei zoals de voorbeeldwebsite doet.

<nav role="navigation" aria-labelledby="zf--side-menu--section-heading">
<h2 id="zf--side-menu--section-heading">Side menu</h2>

Hier voegt men een verborgen kop toe boven het navigatiemenu. Die tekst herhaalt men nog eens als label bij het navigatiegebied. JAWS-gebruikers krijgen die verborgen tekst drie keer te horen:

Side menu navigatiegebied
Kop2 side menu
Lijst met zes items
Link Home
...
Link Contact
Einde lijst
Side menu einde navigatiegebied

Benoem niet elk blok

De dubbele techniek om blokken te benoemen, heeft men op de voorbeeldwebsite overal doorgetrokken. Waar je op het scherm het Facebook-logo ziet, moet een screenreadergebruiker luisteren naar zes regels informatie:

<section aria-labelledby="zf--follow-us--section-heading">
<h2 id="zf--follow-us--section-heading">Follow us</h2>
<ul>
<li><a href="">
<span class="visually-hidden">KEAT - Facebook</span>
<span aria-hidden="true" class="zf--zhong-icon zf--zhong-icon-facebook"></span>
</a>
</li>
</ul>
</section>

Vertaald door JAWS geeft dit:

Follow us gebied
Kop2 Follow us
Lijst met 1 items
Link Keat - Facebook
Einde lijst
Follow us einde gebied

Hetzelfde gebeurt voor het Accessibility panel. Ook die knop zit in een lijst van 1 item, wordt voorafgegaan door een onzichtbare kop met de tekst Toolbox en die wordt herhaald bij het aan- en afkondigen van het navigatiegebied. Ik zou zeggen dat Accessibility panel helemaal duidelijk maakt waar die knop voor dient. Het voegt echt niets toe als je die knop in een lijst en in een blok met de naam Toolbox stopt.

De link English en Greek staan ook in een navigatiegebied met als label "Language options" en met dezelfde tekst als verborgen kop erboven. Als je aan de ziende bezoeker niet vertelt dat Grieks en Engels taalkeuzes zijn, waarom zou je dat dan aan blinde bezoekers uitleggen?

Waar een verborgen kop of een aria-label wel nuttig is, is rond het kruimelpad. Al is het niet eenvoudig om daarvoor een term te verzinnen die bezoekers begrijpen. Deze website kiest voor "Location path". Bij wie doet dat een belletje rinkelen?

Oh ja, onderaan de pagina staat een blok met als verborgen kop "Complementary content (lower)".
Waar het helemaal hilarisch wordt, is bij het zoekveld:

<section role="search" aria-labelledby="zf--search--section-heading">
<h2 id="zf--search--section-heading">Search</h2>

Als je role="search" gebruikt, dan maak je van het blok een Zoekgebied. Dat is prima, maar het is dan echt niet nodig om er nog een label Search aan te hangen.

Koppen

Screenreaders bieden de mogelijkheid om van kop naar kop te navigeren of een dialoogvenster te openen met alle koppen binnen de pagina. Deze homepage heeft een prima kopniveau 1 met de tekst Home. Doordat elk blok een onzichtbare kop heeft gekregen, krijgen we een outline die helemaal niet meer overzichtelijk is en is deze navigatietechniek in de praktijk bijna onbruikbaar:

Kop2 Quick access menu
Kop2 Location path
Kop2 Toolbox
Kop2 Language options
kop2 Follow us
kop2 Search
Kop1 Center for Education & Rehabilitation for the Blind
Kop2 Side menu
Kop1 Main content
Kop1 Home
Kop2 Center for Education & Rehabilitation for the Blind
Kop2 Complementary content (lower)
Kop3 Administration and Content
Kop3 Design and Development
Kop2 Footer

Of, hoe je van een eenvoudige homepage een onbegrijpelijk kluwen kunt maken.

Live region

Als je het accessibility panel opent, dan klapt een blok uit met een aantal opties. De ontwikkelaar heeft dat blok als live region gemarkeerd: een screenreader krijgt de opdracht om de gewijzigde informatie voor te lezen. Dat moet je letterlijk nemen. Jaws ratelt:

Accessibility options Font Size: Bigger. Increase font size. Smaller. Decrease font size. Theme: Low brightness Dark Font: Sans serif Serif Bold Layout: Large print. This layout is suitable for people with low vision

Dit is geen goede toepassing van een live region. Dat er nieuwe info is verschenen, is voldoende duidelijk dankzij aria-expanded dat de waarde "true" krijgt als ik de knop activeer. Laat mij vervolgens maar rustig de opties verkennen met de pijltjes, de tabtoets of andere navigatiemogelijkheden.

Conclusie

  • Hou het simpel: bouw je template logisch op met een header, main en footer. Denk even na over de outline van de pagina en markeer de koppen met heading-elementen van het juiste niveau. Gebruik lijsten voor opsommingen (d.w.z. minstens 2 items).
  • Reserveer nav voor het hoofdmenu en eventueel een doormat. Als je het aantal navigatiegebieden beperkt, is het ook niet nodig om allerlei labels te verzinnen om ze van elkaar te onderscheiden.
  • Verborgen tekst of aria-labels toevoegen of tekst verbergen voor screenreaders, is enkel aan te raden in uitzonderlijke gevallen. Als je zelf test met een screenreader zorg dan dat je vertrouwd bent met het verwachtingspatroon van de dagelijkse gebruiker van dit hulpmiddel. Of check het even met enkele gebruikers of vraag het aan AnySurfer.
  • Als de basis goed is, zijn veel specifieke toegankelijkheidsopties niet nodig en zoals we hierboven zagen: overdaad schaadt. Ik kan het niet beter samenvatten dan met de eerste zin van dit artikel van het Mozilla Developer Network: A great deal of web content can be made accessible just by making sure the correct HTML elements are used for the correct purpose at all times
Reageer als eerste

Omzetting EU-richtlijn: stand van zaken

Bart Simons op 23/05/2018

Binnen vier maanden moet de Europese richtlijn over toegankelijkheid van overheidswebsites omgezet zijn in de Belgische wetgeving. Wat weten we over de stand van zaken?

Federaal

Op een schriftelijke vraag in de Kamer antwoordt de Vice-eersteminister van Digitale Agenda en Telecommunicatie "De verschillende gefedereerde entiteiten zijn momenteel bezig met de omzetting van de richtlijn". AnySurfer wordt in het antwoord met naam genoemd. Daarom willen we een belangrijke nuance aanbrengen:

1. Sinds 2011 worden alle sites die door de FOD Beleid en Ondersteuning (FOD BOSA) (ex-Fedict) worden gehost en onderhouden onderworpen aan een AnySurfer-audit bij hun ontwikkeling. [...] De door BOSA gehoste sites zijn dus AnySurfer compliant.

Reactie: men kan onmogelijk besluiten dat een website compliant is omdat een audit werd uitgevoerd. Een audit is een onderzoek van de mate van toegankelijkheid van een website. De uitkomst van een audit is helaas nooit dat een website volledig compliant is. De audit is de start van een verbetertraject. Enkel als men na de aanpassingen een nieuwe validatie uitvoert, kan men vaststellen of de website compliant is.

Terug naar de omzetting van de richtlijn: op 30 maart bleek uit een persbericht dat de ministerraad een voorontwerp van wet heeft goedgekeurd. Het voorontwerp wordt voor advies overgemaakt aan de Raad van State, maar de tekst van het voorontwerp zelf is van hieruit niet te vinden.

In zijn eigen persbericht kondigt minister De Croo een tool aan "die de toegankelijkheid van overheidswebsites in kaart brengt". Die kan inderdaad een steentje bijdragen, maar vergeet niet dat je mensen nodig hebt om de uitkomsten van een dergelijke tool te interpreteren en aan te vullen.

Vlaanderen

Uit een schriftelijke vraag in het Vlaams Parlement blijkt dat de richtlijn verwerkt wordt in een bestuursdecreet.

Brussel (Update van 11 juni)

Op de ministerraad van 31 mei werd het ontwerp van ordonnantie inzake de toegankelijkheid van de websites en mobiele applicaties van de gewestelijke overheidsdiensten goedgekeurd.

Andere overheden

Van de andere overheden konden we geen informatie vinden. Wij zijn zelf zeker geen experts in wetgeving en politiek. We hopen in de reacties hieronder aanvullingen en correcties te ontvangen die we kunnen verwerken in dit bericht.

1 reactie

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é

Update 30 mei 2018: links toegevoegd naar de draft implementing acts van de Europese Commissie. Feedback mogelijk tot 15 juni.

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:

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