Alle artikels

WCAG 2.2 helpt je om beter vindbare hulpfuncties aan te bieden

Geschreven door Sophie Ragas op vrijdag 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 help 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 (consistente) 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 organsaties 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 unform opgebouwd worden.

Conclusie

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

💡 Tip: abonneer je op de nieuwsbrief van Eleven Ways om onze andere artikels over WCAG 2.2 niet te missen.

Laatste artikels

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 willen ons team tijdelijk versterken met een accessibility-expert of front-end-engineer.

We willen onze nieuwe app laten testen door gebruikers met een beperking.

Gebruikers hebben opmerkingen gemaakt over de toegankelijkheid van onze website. Daar willen we mee aan de slag.

Een overheidsklant vraagt ons om te voldoen aan WCAG. Hoe pakken we dat aan?