• gepubliceerd
  • leestijd
    ± 6 minuten

Dit kun je verwachten van de WCAG 2.2

In dit blog vertel ik je over enkele succescriteria die worden toegevoegd aan de vernieuwde versie van de WCAG.

Afgelopen woensdag 10 maart en donderdag 11 maart was het einde­lijk tijd voor axe-con, Deque’s eigen online toeganke­lijkheidscongres. Twee dagen bomvol lezingen over de toekomst van toeganke­lijkheid, praktische tips en concrete voorbeelden. Ik keek naar de lezing WCAG 2.2 – Real World Examples Illustrating the Future of Accessibility, gegeven door Thomas Logan van Equal Entry. In dit blog vertel ik je over enkele succescriteria die worden toegevoegd aan de vernieuwde versie van de WCAG en wat je daarvan kunt verwachten!

Dichte deuren

De WCAG is altijd in ontwikkeling

De WCAG, voluit de Web Content Accessibility Guidelines, is een verzameling richtlijnen voor toeganke­lijke webcontent. Denk aan sites en apps, maar ook aan documenten als pdf’s en EPUBS. Op dit moment werken we met de WCAG 2.1. Sinds september 2020 moeten alle (semi) overheidswebsites voldoen aan de WCAG 2.1 niveau AA. De WCAG wordt samengesteld door de W3C, het World Wide Web Consortium. Het W3C ontwerpt de webstandaarden voor het internet, zoals HTML en CSS. Net zoals de HTML die we vandaag kennen niet meer de HTML van tien jaar geleden is, zo zijn ook de richtlijnen voor toeganke­lijkheid altijd in ontwikkeling. De W3C werkt momenteel aan de WCAG 2.2. Het is nog een ‘working draft’, dat wil zeggen dat de richtlijnen nog niet af zijn. Iedereen mag nog feedback geven en suggesties doen. Dat betekent ook dat het moge­lijk is dat de besproken succescriteria in dit artikel uiteinde­lijk niet in de WCAG 2.2 worden opgenomen. Vanaf wannéér de WCAG 2.2 van kracht is, is ook nog niet bekend.

Focus

Voor een deel van de gebruikers die met het toetsenbord – in plaats van met de muis – over een webpagina navigeert, is het ontzettend belangrijk dat ze ook daadwerke­lijk kunnen zien wáár die focus zich bevindt. Alle interactieve elementen, zoals knoppen en links, moeten dus zichtbaar focus krijgen. In de WCAG 2.1 gebruiken we de succescriteria 2.4.7 Focus zichtbaar en 1.4.11 Contrast van niet tekstuele content om te beoordelen of focus zichtbaar is. Maar die succescriteria beoordelen alleen óf de focusrand zichtbaar is en of het contrast tussen de kleur van de focusrand en de achtergrond hoog genoeg is. Een stippeltjesrand of een rand van maar een halve pixel breed ís in principe zichtbaar, maar laat veel te wensen over voor slechtzienden. In de WCAG 2.2 lost succescriterium 2.4.11 Focus appearance (minimum) (AA) dat op. Om aan dit succescriterium te voldoen moet een focusrand (of lijn) een bepaald aantal pixels dik zijn en het contrast tussen het element zónder en mét focus moet hoog genoeg zijn. Het verschil tussen een element zonder focus en datzelfde element mét focus moet dus goed zichtbaar zijn. Ook voor niveau AAA komt er succescriterium bij: 2.4.12 Focus appearance (enhanced) (AAA). Om aan dit criterium te voldoen moet de focus om het hele element heen staan, minimaal 2 CSS pixels breed zijn én een contrastratio van 4,5:1 hebben.

Locatie in een document

Als je een boek leest met een vergrootglas kun je er nog steeds vanuit gaan dat als iemand verwijst naar een pagina, er voor jou op die pagina precies dezelfde informatie staat. In een digitaal document, zoals een EPUB of pdf, is dat niet zo. Door in te zoomen of gebruik te maken van reflow verschuift informatie in een document. Dus wat voor mij op pagina 5 in een EPUB staat, staat voor iemand die het document moet vergroten misschien wel op pagina 38. Succescriterium 2.4.13 Fixed reference points (A) lost dit probleem op. Dit succescriterium vereist name­lijk dat een document over een ‘page list’ beschikt. Een page list verwijst naar waar in de code ‘page breaks’ zijn aangegeven. Een page break geeft aan dat er een nieuwe pagina begint. Dus ongeacht of een document is ingezoomd, kan een gebruiker via de page list naar een specifieke pagina navigeren.

Slepen

Even rondkijken op een kaart, een bestand uploaden door het vanuit je map naar de button te slepen of even een kolom verschuiven, het zijn allemaal handigheidjes waar muis-gebruikers maar al te graag gebruik van maken. Maar het wordt vervelend als mensen die geen muis kúnnen gebruiken geen andere optie aangeboden krijgen. Om aan het nieuwe succescriterium 2.5.7 Dragging (AA) moet je er dus voor zorgen dat slepen niet de énige optie is om een functionaliteit te gebruiken. Bijvoorbeeld door knoppen met pijlen aan te bieden om over een map te navigeren of met een knop een menu te openen waar de gebruiker zelf een nieuwe locatie voor een kolom kan kiezen.

Genoeg ruimte

Ik denk dat iédereen wel eens een situatie heeft meegemaakt waar dit nieuwe succescriterium van pas was gekomen. Je bekijkt een webpagina op je mobiele telefoon en wil op een knop tikken, maar je tikt per ongeluk op de knop er naast. Argh! Succescriterium 2.5.8 Pointer target spacing (AA) maakt hier een einde aan. Om aan dit succescriterium te voldoen moet het klikbare gebied van een interactief element voldoende groot zijn én mag het niet overlappen met het klikbare gebied van een naastgelegen element. Dit klikbare gebied moet tenminste 44 CSS pixels breed én hoog zijn.

Hulp op iedere pagina

Heb je je ook wel eens rot gezocht naar contactgegevens, of kon je een taak op een pagina niet voltooien maar moest je naar een ándere pagina om daar hulp bij te krijgen? Dat is natuur­lijk niet handig. Succescriterium 3.2.6 Findable help (A) zorgt er voor dat gebruikers op iedere pagina van een website (of webapps van één pagina) altijd toegang hebben tot een vorm van hulp. Bijvoorbeeld contactgegevens om een medewerker te bereiken (telefonisch of via mail), een chatfunctie of een AI-oplossing. Om de hulpvorm goed vindbaar te maken, moet deze op iedere pagina op dezelfde plek worden aangeboden.

Toeganke­lijke toegang

We zijn inmiddels allemaal overtuigd van het belang van veilige inlogmethodes. Twee-factor-authenticatie, wachtwoorden vol speciale tekens en getallen, DigiD, noem het maar op. Een manier waarop veel websites het veiliger proberen te maken om in te loggen, is door te voorkomen dat gebruikers autocomplete kunnen gebruiken of door gebruikers een reeks cijfers en letters te laten overtypen met CAPTCHA. Voor mensen met cognitieve functiestoornissen kan het ontzettend moei­lijk zijn om op die manier in te loggen. Succescriterium 3.3.7 Accessible authentication (A) vereist dat er ofwel een alternatieve inlogmethode wordt geboden óf dat er een mechanisme aanwezig is dat de gebruiker helpt met het inloggen. Een alternatieve vorm van inloggen is bijvoorbeeld een tijde­lijke inloglink per mail. Bij een hulpmechanisme kan je denken aan de autocomplete functie of het kunnen kopiëren en plakken van inloggegevens.

Zichtbare bedieningselementen

Ben jij ook regelmatig in Word aan het zoeken naar de juiste button of aan het stoeien in Outlook met de opmaak van je e-mail? Denk je dan eens in hoe frustrerend het zou zijn als de knoppen die je nodig hebt alleen zichtbaar zouden zijn als je er met je muis overheen gaat, of verstopt zitten onder een andere knop. Om dat te voorkomen is succescriterium 3.2.7 Hidden controls (AA) in het leven geroepen. Om aan dit succescriterium te voldoen moeten alle bedieningselementen die nodig zijn om een taak uit te voeren zichtbaar zijn op het moment dat je die taak uit moet voeren óf er moet een manier zijn om de bedieningselementen permanent zichtbaar te maken.

Nooit meer dubbel invoeren

Ook dit succescriterium zal veel mensen aanspreken. Niets zo frustrerend als meerdere keren je e-mailadres, leveringsadres of klantnummer te moeten invoeren tijdens een bestelproces of het invullen van een webformulier. Succescriterium 3.3.8 Redundant Entry (A) vereist dat formuliervelden waar informatie wordt gevraagd die eerder in het proces (en tijdens dezelfde sessie) al eens ingevoerd is, automatisch diezelfde informatie kopiëren en invullen óf dat gebruikers eerder ingevoerde informatie kunnen selecteren uit een keuzelijst. Het moet natuur­lijk altijd wél moge­lijk blijven dat de gebruiker die informatie kan aanpassen als het niet klopt.

En, in hoeverre voldoet jouw website al aan deze nieuwe succescriteria? Geen zorgen, het duurt nog wel even voor de WCAG 2.2 van kracht is en het is ook nog niet zeker dat al deze succescriteria onderdeel worden van de nieuwe WCAG. Maar niets houd je natuur­lijk tegen om al aan de slag te gaan en je website WCAG 2.1.-overstijgend toeganke­lijk te maken!