Naar inhoud springen Eleven Ways (Home)

Alle artikels

WCAG 2.2 helpt je om beter vindbare hulpfuncties aan te bieden

Geschreven door Sophie Ragas op 15 oktober 2021 (Gemiddelde leestijd: 2 minuten)

WCAG versie 2.2 zal een nieuw succescriterium brengen over hulpfuncties. Wij helpen je om te voldoen aan het nieuwe criterium 3.3.5 Help.

Eind 2022 wil het W3C de nieuwe versie van de Richtlijnen voor Toegankelijkheid van Webcontent uitbrengen. WCAG 2.2 wordt de nieuwe standaard voor het testen van websites en apps op een vlotte toegankelijkheid voor mensen met een beperking. WCAG is ook het normdocument waar websites van overheden en publieke organisaties aan moeten voldoen.

WCAG 2.2 brengt ons wellicht negen nieuwe succescriteria. In dit tweede artikel van de reeks, zoomen we in op het nieuwe criterium over het aanbieden van hulp- en ondersteuningsfuncties. Verder in deze reeks:

  1. Veilig inloggen voor iedereen dankzij WCAG 2.2
  2. Maak je controls zichtbaar voor bezoekers
  3. Laat gebruikers dezelfde informatie maar één keer invullen
  4. Help bezoekers naar de juiste pagina springen (met WCAG 2.2)
  5. You can touch this! Zijn de target sizes in jouw UI wel groot genoeg?
  6. Geef je bezoekers focus
  7. Je bezoekers verdienen een meeslepende ervaring!

Noot vooraf: verwar dit criterium niet met 3.3.5 Help (niveau AAA) dat helemaal gericht is op het voorkomen van invoerfouten.

Wat zijn “helpfuncties”?

WCAG hanteert een vrij brede definitie van wat een helpfunctie is. In de praktijk gaat het om deze vormen:

  • Alle mogelijkheden om contact met mensen op te nemen. Denk aan een contactformulier, een live chat en integraties met social-mediakanalen.
  • Zelfhulp-opties, zoals een lijst met veelgestelde vragen, een handleidingen of een kennisdatabanken.
  • Automatische contactsystemen, zoals AI-gestuurde chatbots.
  • Algemene contactgegevens (denk aan adresgegevens, telefoonnummer, e-mailadres, openingsuren).

Wordt het aanbieden van dergelijke helpfuncties verplicht?

Nee. Het nieuwe criterium verplicht de aanwezigheid van helpfuncties niet. Echter, als er een helpfunctie aangeboden wordt, moet ze wel steeds op dezelfde (logische) plek terug te vinden te zijn. Dat is in essentie waar dit criterium om draait.

Als je vandaag nog weinig helpfuncties hebt op je website, is het wel een goed idee om dat aanbod uit te breiden. Voor grote organisaties is het een effectieve manier om de druk op helpdesk-medewerkers te verminderen.

Praktijkvoorbeelden

Het nieuwe succescriterium vereist dat als er een of meer van de bovengenoemde helpfuncties beschikbaar zijn op je website, ze gemakkelijk terug te vinden moeten zijn. Enkele voorbeelden:

  • Als er een knop voor een chatbot in een hoekje van de pagina staat, moet deze op alle andere pagina’s op dezelfde plaats te vinden zijn.
  • Als openingsuren in de footer staan, moet dat op alle pagina’s het geval zijn.
  • Een lijst met veelgestelde vragen moet uniform opgebouwd worden.

Conclusie

Op zich is het een erg logisch criterium. Als de informatiearchitectuur van je website of app al goed in elkaar zit, voldoe je er misschien automatisch aan. Bevat je website echter nog heel veel versnipperde en moeilijk te vinden hulp- en ondersteuningsopties, dan is het een goed idee om even orde op zaken te stellen.

Haalbare accessibility-tips in je mailbox

Met onze praktische tips leer je hoe je de website of app van jouw organisatie (of klant) voor iedereen toegankelijk maakt.

Je kunt je met één klik uitschrijven.

Waarmee kunnen we jouw organisatie helpen?

Alle contactgegevens

We moeten wettelijk voldoen aan WCAG. Wat is de omvang van het project?

We willen onze teams trainen in toegankelijkheid. Wie moet worden opgeleid?

We hebben externe expertise nodig. Een tijdelijke versterking, kan dat?

We willen onze applicatie testen met gebruikers met een handicap. Hoe het te organiseren?