NL

Robuust: je website werkt ook met hulptechnologie

  • Uitleg
  • Met je cliënt

Bijgewerkt op

Onderwerp

In het kort

Robuust is het vierde principe van WCAG. Je website moet goed samenwerken met browsers, apparaten en hulptechnologie zoals een schermlezer. Dat lukt als knoppen en meldingen in de code zeggen wat ze zijn en wat ze doen. Je leest ook welke vragen je een leverancier stelt, bijvoorbeeld over een wijkagenda.

Wat is het

Robuust is het vierde principe van WCAG. Je website moet werken in verschillende browsers, op verschillende apparaten en met hulptechnologie, nu en ook als die technologie verandert.

Hulptechnologie is software of apparatuur die mensen met een beperking helpt om het web te gebruiken. Voorbeelden zijn een schermlezer die de pagina voorleest, een vergrootprogramma, spraakherkenning en een schakelaar voor wie toetsenbord en muis niet kan gebruiken.

Het principe heeft één richtlijn: compatibel (4.1). Daaronder vallen in WCAG 2.2 maar twee succescriteria op niveau A en AA, eisen waarop je een website kunt testen: 4.1.2 en 4.1.3. Dit principe gaat over code. Zelf hoef je die niet te schrijven, maar je kunt er wel naar vragen bij je webbouwer of leverancier.

Waarom het ertoe doet

Hulptechnologie werkt alleen goed als de code klopt. Een knop die eruitziet als knop, kan voor een schermlezer gewone tekst zijn, en dan weet iemand die blind is niet dat er iets te kiezen valt. Zo loopt een cliënt vast bij het aanmelden, terwijl de pagina er voor jou goed uitziet.

Met meldingen gaat het net zo. Verschijnt “Je aanmelding is verstuurd” alleen in beeld, dan hoort iemand met een schermlezer het misschien niet, en weet diegene niet of het gelukt is. Goede code helpt trouwens ook anderen, want een browser of wachtwoordbeheerder herkent velden met een goede naam in de code beter, en kan ze dan zelf invullen.

Zo doe je het

  1. Gebruik gewone onderdelen uit HTML. HTML is de taal waarin webpagina’s worden gebouwd. Een standaardknop, link of invulveld doet vanzelf wat 4.1.2 vraagt, als je hem goed gebruikt.
  2. Geef zelfgebouwde onderdelen een naam, rol en toestand (4.1.2, niveau A). Neem een blok met veelgestelde vragen dat openklapt. De code zegt dan: dit is een knop (rol) met de vraag als naam, en hij is open of dicht (toestand).
  3. Gebruik ARIA alleen als het nodig is. ARIA (Accessible Rich Internet Applications) is een set extra codes die hulptechnologie vertelt wat iets is, bijvoorbeeld “dit is een knop” of “dit blok is open”. De vuistregel is: geen ARIA is beter dan slechte ARIA. Zeg je in de code dat iets een knop is, dan moet de webbouwer er ook voor zorgen dat hij met het toetsenbord werkt zoals een knop. Dat doet ARIA niet vanzelf.
  4. Laat meldingen voorlezen (4.1.3, AA). Meldingen zijn bijvoorbeeld “Je aanmelding is verstuurd” of “12 resultaten gevonden” na het zoeken. Geef zo’n melding in de code de rol van statusmelding, zodat een schermlezer hem kan voorlezen zonder dat de focus verspringt. De lijst met resultaten zelf is geen statusmelding, de zin met het aantal wel.
  5. Test op meer dan één manier. Probeer je website met een schermlezer, op een computer en op een telefoon. Vraag je webbouwer dit ook te doen na elke grote update. De Structuurcheck vindt knoppen zonder naam en invulvelden zonder label.

Voorbeeld: vragen bij een wijkagenda

Een welzijnsorganisatie wil een wijkagenda van een leverancier op haar website zetten. Bezoekers kunnen erin filteren op dag en op soort activiteit, en met pijltjes naar de vorige of volgende week. WCAG kijkt naar de hele pagina, dus ook naar een agenda, chat of formulier van een leverancier. Vraag de leverancier daarom vóór de koop, en niet pas als een bezoeker vastloopt:

  1. Zijn de filters en de pijltjes echte knoppen, of zelfgebouwde onderdelen? En hebben die een naam, rol en toestand?
  2. Geeft de agenda een melding die een schermlezer voorleest als de lijst verandert, zoals “8 activiteiten op dinsdag”?
  3. Is de agenda getest met een schermlezer, en mogen we het rapport zien?

Let op

  • 4.1.1 bestaat niet meer. Dit succescriterium ging over correct opgebouwde code en is in WCAG 2.2 geschrapt: browsers gaan nu beter om met fouten in de code, en hulptechnologie laat het lezen van de code over aan de browser. Veel problemen die 4.1.1 vond, vallen nu onder 1.3.1 of 4.1.2. Noemt een oude checklist of een rapport 4.1.1 nog, en moet je aan WCAG 2.1 voldoen? In de bijgewerkte WCAG 2.1 geldt 4.1.1 bij HTML altijd als gehaald.

Meer weten

Hulpmiddelen die hierbij passen

  • Websitetest

    Toetsenbordtest

    Test je eigen website met alleen het toetsenbord. Tien korte stappen, elk met de eis uit WCAG 2.2, laten zien wat werkt en wat niet, met een tip bij elk punt.

  • Generator

    Toegankelijk­heids­verklaring maken

    Zet op een rij wat je organisatie al heeft gedaan om de website toegankelijk te maken, en wat nog moet. Je krijgt een eenvoudige verklaring in gewone taal, als pdf. Voor overheden geldt een eigen, officieel model.

Bronnen

  1. Web Content Accessibility Guidelines (WCAG) 2.2 W3C
  2. Web Content Accessibility Guidelines (WCAG) 2.1 W3C
  3. Understanding Success Criterion 4.1.2: Name, Role, Value W3C Web Accessibility Initiative
  4. Understanding Success Criterion 4.1.3: Status Messages W3C Web Accessibility Initiative
  5. Understanding Success Criterion 3.3.8: Accessible Authentication (Minimum) W3C Web Accessibility Initiative
  6. Read Me First (ARIA Authoring Practices Guide) W3C Web Accessibility Initiative
  7. Tools and Techniques W3C Web Accessibility Initiative
  8. WCAG 2 FAQ W3C Web Accessibility Initiative
  9. What's New in WCAG 2.2 W3C Web Accessibility Initiative
  10. EN 301 549 en WCAG Digitoegankelijk

Meer over dit onderwerp

Samen iets bouwen?

Stuur ons een berichtje als je een idee hebt, iets mist of een hulpmiddel wilt uitproberen met je team. Vertel in een paar zinnen waar het om gaat. We lezen alles, en het verplicht je tot niets.

Stuur een berichtje [email protected]