Robuust: je website werkt ook met hulptechnologie

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. Denk aan een schermlezer die de pagina voorleest, een vergrootprogramma, spraakherkenning of 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. Het oude criterium 4.1.1 is in WCAG 2.2 geschrapt.

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. 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. 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”. W3C is er duidelijk over: geen ARIA is beter dan slechte ARIA. Een rol is een belofte. 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). Denk aan “Je aanmelding is verstuurd” of “12 resultaten gevonden” na het zoeken. Geef zo’n melding in de code de rol van statusmelding. Dan kan een schermlezer hem 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. Met de Structuurcheck vind je snel knoppen zonder naam en invulvelden zonder label. Of een onderdeel echt goed werkt, merk je pas met hulptechnologie.

Zo ziet het eruit in de praktijk

Een welzijnsorganisatie koopt een wijkagenda bij een leverancier en zet die op haar website. Je kunt filteren op dag en op soort activiteit. Een vrijwilliger die blind is, probeert de agenda met zijn schermlezer. De filters hoort hij als gewone tekst, dus hij weet niet dat hij iets kan kiezen. De pijltjes voor vorige en volgende week hebben geen naam. En na het filteren verandert de lijst, maar hij hoort niets.

De communicatiemedewerker plakt de HTML van de agenda in de Structuurcheck. Die bevestigt de twee knoppen zonder naam. Ze stuurt de leverancier drie vragen. Zijn de filters echte knoppen, of zelfgebouwde onderdelen, en hebben die een naam, rol en toestand? Geeft de agenda een melding die een schermlezer voorleest als de lijst verandert, zoals “8 activiteiten op dinsdag”? En is de agenda getest met een schermlezer, en mogen we het rapport zien?

Wat zeg je tegen een collega die vindt dat de agenda er toch goed uitziet? Bijvoorbeeld: “Voor ons wel. Maar een schermlezer heeft niets aan hoe het eruitziet. Die heeft een naam en een rol in de code nodig.”

Let op

• 4.1.1 bestaat niet meer. Dit succescriterium ging over correct opgebouwde code. Volgens W3C is het niet meer nodig. 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. Nette code blijft nuttig, maar is geen eis meer voor toegankelijkheid.
• Oude checklists noemen 4.1.1 nog. Moet je volgens een regel aan WCAG 2.1 voldoen? In de bijgewerkte WCAG 2.1 staat dat 4.1.1 bij HTML altijd als gehaald geldt.
• Een onderdeel van een ander telt ook mee. WCAG kijkt naar de hele pagina, dus ook naar een agenda, chat of formulier van een leverancier. Vraag daarom vooraf hoe zo’n onderdeel is getest, en niet pas als een bezoeker vastloopt.

Meer weten

• De andere principes: waarneembaar, bedienbaar en begrijpelijk.
• Je website toegankelijk maken: de stappen voor je organisatie.
• Checklist toegankelijke website