We moeten eens hebben over WCAG.

Samenvatting

In dit artikel vraag ik iedereen die betrokken is bij webtoegankelijkheid om hulp. Hulp voor site-eigenaren, programmeurs, ontwerpers en contentmanagers wereldwijd. Het is moeilijk om te voldoen aan de richtlijnen voor toegankelijkheid omdat ze zo ondoorgrondelijk zijn.

Het eerste aandachtspunt: de specificaties en documentatie online zijn ontoegankelijk, onleesbaar, gedupliceerd, verwarrend, onnodig ingewikkeld en onoverzichtelijk.

Het tweede aandachtspunt is de toevoeging van nieuwe succescriteria voordat de bestaande goed zijn begrepen, gedocumenteerd en geïmplementeerd.

Ik beschrijf wat ik “in het veld” tegenkom, als expert webtoegankelijkheid, reviewer, programmeur en onderzoeker. Ik wil hier problemen aankaarten en enkele aanbevelingen doen.

De conclusie:

• Maak de W3C-specificaties en documentatie toegankelijk voor webmakers. Maak ze eenduidig ​​en gemakkelijker te onderhouden. 
• Zorg voor training en maak in voorbeeldmateriaal gebruik van moderne technieken voor web development. Verzamel deze informatie op één plek en onderhoud in inhoud goed. 
• Stop met het toevoegen van nieuwe succescriteria voordat de huidige goed zijn gedocumenteerd, uitgelegd en beter zijn overgenomen in websites over de hele wereld.
• Met als doel webmakers zo goed mogelijk te helpen een toegankelijk web te bouwen.

Allereerst

De Web Content Accessibility Guidelines (WCAG) zijn een waardevol en essentieel instrument om wereldwijd de webtoegankelijkheid te verbeteren en te waarborgen. Door de succescriteria te gebruiken, kunnen we problemen onderzoeken en rapporteren. We kunnen hiermee programmeurs, contentmanagers en ontwerpers helpen hun werk te verbeteren.

Ook verbetering van de bestaande richtlijnen blijft noodzakelijk. Het web verandert en de richtlijnen moeten de veranderingen volgen.

In dit artikel betwist ik de noodzaak van WCAG of de noodzaak van updates niet.

Het web is stuk

In het onderzoek van WebAIM van 2021  Jaarlijkse toegankelijkheidsanalyse van de 1.000.000 startpagina’s blijkt dat 97,4% van de startpagina’s detecteerbare WCAG 2-fouten heeft! Dit was iets lager dan 98,1% in februari 2020.

Dit is de staat van het web op dit moment. Daarom concludeer ik dat de wijze waarop we WCAG en semantische HTML5 communiceren en onderwijzen aan webmakers duidelijk niet voldoende is. We kunnen zo niet doorgaan.

Dit artikel is geschreven vanuit mijn visie, als expert toegankelijkheid. Iemand die toegankelijkheid onderzoekt en webmakers helpt bij hun werk.

Ik ben geen W3C-lid, ik ben niet betrokken bij de ontwikkeling van richtlijnen of politiek; Ik werk in het veld. Laat me enkele van mijn zorgen en ideeën delen.

De informatiearchitectuur van de WCAG-documentatie moet beter

Zoals de meeste programmeurs en onderzoekers die op zoek zijn naar documentatie en specificaties, gebruik ik een zoekmachine. En dan vind ik het moeilijk om bepalen wat de status is van de W3C-pagina waar ik naar kijk en wat deze status betekent.

Is het een concept? Is het verouderd? Is het voor WCAG 2.0? Of voor WCAG 2.1? Kijk ik naar actuele, geldige en recente documentatie of specificaties?

Op de archiefpagina w3.org/TR/ staat een overzicht van alle standaarden en concepten. Elk document heeft een status:

• Candidate Recommendation (CR)s
• Group Note (Note)
• Proposed Edited Recommendation (PER)
• Proposed Recommendation (PR)
• Recommendation (REC)
• Retired (ret)
• Working Draft (WD)

En een versie: ‘Latest’, ‘Upcoming’, ‘Editor’s draft’. Er zijn pagina’s met succescriteria, uitleg (Understanding) en technieken. Al deze documenten komen tevoorschijn in Google-zoekopdrachten.

WAI Guidelines and Techniques  verschijnt als het eerste resultaat als ik zoek naar “technieken WAI”. Dit is een concept uit 2004. In plaats daarvan zou de recente en geldige pagina WAI tools and techniques als eerste naar voren moeten komen.

Sommige projecten lijken te zijn verlaten of bewaard voor intern gebruik, zoals Start with Accessibility – Education & Outreach.

Mijn punt is: de enige manier om dit systeem te begrijpen is door te weten hoe alle documentatie is opgezet en wat de status betekent. Je kunt niet verwachten dat een programmeur het verschil kent tussen een CR, PER, REC of WD.

Alle programmeurs gebruiken zoekmachines om antwoorden te vinden. Het is moeilijk om alle verschillende WCAG- en W3C-documentatie te begrijpen als je geen expert toegankelijkheid bent.

En zelfs dan kost het moeite om de juiste documentatie te vinden.

De inhoud van de W3C-documentatie moet worden herzien en bijgewerkt

Graag wil ik twee voorbeelden uit de praktijk geven waar de online WCAG-documentatie programmeurs niet helpt en waar verbetering nodig is.

Eerste voorbeeld: het ‘title’ attribuut

Stel je voor, je bent programmeur en je wilt weten hoe je het title attribuut moet gebruiken volgens WCAG.

Wat doe je? Je Googlet. Bijvoorbeeld: “title attribute WCAG”.

De eerste W3C resultaten (voor mij, in Nederland, uitgelogd van Google) zijn:

• H33: Supplementing link text with the title attribute (voor WCAG 2.0)
• H65: Using the title attribute to identify form controls when the label element cannot be used (voor WCAG 2.1)
• H65: Using the title attribute to identify form controls when the label element cannot be used  (voor WCAG 2.0)

En dan:

• Kies je de eerste.
• Sla je de tekst over en ga direct naar het codevoorbeeld (programmeurs lezen niet)
• Copy/paste je het codevoorbeeld en gebruik je de code volgens het voorbeeld.

Het resultaat:

<a href=”http://example.com/WORLD/africa/kenya.elephants.ap/index.html” title=”Read more about failed elephant evacuation”>

    Evacuation Crumbles Under Jumbo load

</a>

Zelf zou ik deze code afkeuren, qua toegankelijkheid, omdat niet alle informatie voor iedereen beschikbaar is.

Op een mobiel zie je de tekst “Read more about failed elephant evacuation” niet. Uit het Deque-onderzoek Text Links: Best Practices for Screen Readers, blijkt dat schermlezers het title attribuut niet allemaal hetzelfde voorlezen.

H33 linkt ook naar een bericht uit 2004 van Brothercake over tooltips – in zowel de WCAG 2.0- als de 2.1-versie. Deze informatie is niet echt zinvol voor de moderne programmeur. Er zijn betere en modernere manieren om tooltips toe te voegen. Ja, het is een techniek en geen succescriterium. Maar vertel me eens, hoeveel mensen kennen het verschil tussen normatief en niet-normatief? Wereldwijd, buiten de experts toegankelijkheid? Meer dan 10? Als het op een W3C-pagina staat, moet het waar zijn en de juiste manier.

Tweede voorbeeld: onterechte foutmeldingen

Een klant stuurde me een e-mail met een klacht: een plugin op hun site voldoet niet aan WCAG en beschrijft een fout die Total Validator (TV) rapporteert in een geautomatiseerde toegankelijkheidsscan.

Het lijkt erop dat Total Validator het toevoegen van een label onder een tekstinvoer markeert als een fout, een overtreding. Zelfs als er een goede for/id-relatie is tussen het label en het invoerveld. Waar heeft TV dit idee vandaan?

TV meldt de fout als:
E874 [WCAG21 3.3.2 (A)] The matching <label> text must appear before/after the control Associate labels properly with their controls. See  WCAG 2.1 HTML Technique H44.

Vertaald naar het Nederlands:
E874 [WCAG21 3.3.2 (A)] De overeenkomende tekst <label> moet voor/na het invoerelement verschijnen. Koppel de labels op de juiste manier aan hun besturing. Zie WCAG 2.1 HTML-techniek H44.

Als we in H44 duiken, staat helemaal onderaan de pagina (vertaald):
“Controleer of er een label-element is dat het doel van het invoerelement identificeert vóór het invoer-, tekstgebied- of selectie-element.”

Het is dus duidelijk dat deze geautomatiseerde check-software het verschil tussen een succescriterium en een techniek ook niet kent en een afwijking van een suggestie in een techniek meldt als een overtreding.

Verouderde technieken zijn schadelijk

Programmeurs zijn copy/paste mensen. Op zijn minst moet de documentatie en vooral de voorbeeldcode en de links voor de huidige en meest gebruikte succescriteria, modern, degelijk en valide zijn. 

Een argument hiertegen is dat het veel tijd kost om het ongelooflijk aantal bestaande pagina’s over de technieken en de uitleg te controleren en bij te werken. Ze zijn erg moeilijk te onderhouden.

Nu toevoegen van nieuwe succescriteria is contraproductief

Het toevoegen van nieuwe succescriteria voordat de huidige goed zijn begrepen en geïmplementeerd, is contraproductief. Nieuwe succescriteria toevoegen terwijl de oude door zoveel websites worden genegeerd lijkt mij een hopeloze zaak.

Daarnaast zijn sommige nieuwe succescriteria erg moeilijk te implementeren.

Bijvoorbeeld: autocomplete

Met de release van WCAG 2.1 zijn er nieuwe succescriteria toegevoegd. Eén daarvan heeft grote gevolgen voor webformulieren: 1.3.5 Identificeer het doel van de input.

Sommige invoervelden moeten nu een autocomplete attribuut hebben. Dit heeft wereldwijd geleid tot veel onbegrip. De implementatie kost veel extra tijd en is dus kostbaar.

Programmeurs van plugins moeten de optie voor een juiste autocomplete toevoegen en daarnaast dit zo begrijpelijk mogelijk uitleggen aan contentmanagers.

De autocomplete-waarden zijn erg veramerikaniseerd. In Europa kunnen namen heel anders worden samengesteld.

Er is ook een voortdurend intern debat tussen reviewers over wat wel en niet goed te keuren. Ze  maken daarom hun eigen set van criteria(!) om hiermee om te kunnen gaan.

Programmeurs beheersen geen HTML5, laat staan ​​WCAG

De meeste programmeurs zweren bij divs en spans en doen geen moeite om HTML5 te leren. Dit verbaast me altijd en ik heb er geen goede verklaring voor, behalve dat programmeurs graag kopiëren/plakken van, niet altijd de beste, bronnen. En, als het voor hen werkt, dan is het goed.

Code, gevonden in het wild, voor een knop om naar de volgende afbeelding in een carrousel te gaan:

<li data-target=”#carousel-2986″ data-slide-to=”1″ class=”carousel-indicator” role=”button” title=”Mijn kat”><span class=”sr-only”>Mijn kat</span> </li>

Deze structuur schendt semantische HTML5 en ook WCAG. Maar dit is het soort code die reviewers dagelijks zien. Dit is de staat van het web op dit moment.

Er is een enorme kloof tussen wat de meeste programmeurs weten en wat HTML5 en WCAG vereisen.

De meeste frontend-programmeurs moeten nog steeds worden verteld om een ​​label met een for/id-verbinding toe te voegen aan een invoerveld; dat een tijdelijke aanduiding niet hetzelfde is als een label. Laat staan dat ze ​​weten wat een toegankelijke naam is, of hoe om te gaan met feedback van schermlezers over dynamische veranderingen.

Bijna geen enkele programmeur kent het verschil tussen een richtlijn, succescriterium, uitleg, techniek of wat er nieuw is in 2.1. Maar we verwachten dat ze dat wel weten.

Wat kunnen we verbeteren?

We moeten inzetten op onderwijs en goede documentatie. Maak beide zo gemakkelijk en onbetwistbaar mogelijk.

Verbeter de informatiestructuur en leesbaarheid op de W3C-website

Het zou al heel veel schelen als de documentatie toegankelijk was voor webmakers, eenduidig ​​en gemakkelijker te onderhouden.

Voeg bovenaan elke pagina een duidelijke melding toe wanneer deze pagina verouderd is.

Voeg een link toe naar de huidige aanbeveling in het artikel en ook naar de WAI-website. Een paar pagina’s hebben al een bericht geïmplementeerd, zoals de Accessible Rich Internet Applications (WAI-ARIA) 1.2 Working Draft. Dit kan voor veel meer documentatie.

Focus op hoe een webmaker naar informatie zoekt. Optimaliseer voor zoekmachines. Geef verouderde documenten een “noindex”, voeg de status en WCAG-versie duidelijk toe aan de HTML-titel.

Overweeg of er een manier is om de pagina’s over succescriteria en de pagina’s met uitleg en technieken te combineren tot één pagina om meerdere pagina’s in meerdere versies over één onderwerp te vermijden?

Wat betreft de informatie zelf: technieken zijn schadelijk als ze niet worden onderhouden of als verouderde webtechnieken bevatten. Omdat er nu zoveel pagina’s zijn, is er een ander systeem nodig, een systeem van makkelijker te onderhouden content.

Gebruik de WAI-website voor onderwijs en tutorials

Breid de WAI-website uit, onderhoud en actualiseer de tutorials. Eén plek om naartoe te gaan in plaats van talloze moeilijk leesbare pagina’s met verouderde informatie en gebroken links.

Eén plaats om alles te onderhouden, in plaats van honderden techniek-pagina’s. Dit zal op den duur een stuk minder werk zijn en zal resulteren in informatie die beter vindbaar is en van betere kwaliteit voor ontwikkelaars.

De WAI-website is zo waardevol dat ik er mensen naartoe kan sturen voor leesbare informatie. Het is duidelijk, goed gestructureerd. Het heeft een leesbare en aantrekkelijke lay-out en vormgeving. Het nodigt uit tot lezen.

De WCAG Quickref-pagina is fantastisch, duidelijk en goed opgezet. Alle informatie verzameld op één pagina. Het is een consistente link, betrouwbaar. Ik kan er mensen naartoe sturen. Dit is het startpunt voor het ontsluiten van alle andere specificaties en documentatie over de richtlijnen.

Helaas is de Quick Reference sinds november 2019 niet meer bijgewerkt. Er ontbreken dus nogal wat toevoegingen aan de technieken en ook verwijderingen zoals de Silverlight- en Flash-technieken.

Ik hoop dat de WAI Web Accessibility Tutorials zullen worden gemoderniseerd, uitgebreid en onderhouden als dé plek voor webmakers. Het zou de perfecte plek zijn om direct een programmeur naar toe te sturen als vervanging voor de technieken. Maar ook hiervoor zijn er op dit moment meer dan 60 openstaande issues op GitHub. Dat is zo jammer.

Gebruik de WAI-pagina’s als de plek om naartoe te gaan voor webmakers en optimaliseer ze voor zoekmachines.

Laten we een stapje terug doen

We moeten een stapje terug doen en kijken naar wat we nu hebben. Voor de meeste programmeurs is semantische HTML5 en webtoegankelijkheid onbekend terrein. Maar we eisen wel dat ze de specificaties kennen en hoe ze moeten testen.

Het is zo belangrijk dat ze dit weten, omdat het een wettelijke vereiste is; omdat meer dan 20% van alle bezoekers er baat bij heeft; omdat site-eigenaren geen klanten willen verliezen of aangeklaagd willen worden.

Mijn punt is: focus eerst op het onderwijs en op het toegankelijk, begrijpelijk, vindbaar en onbetwistbaar maken van de richtlijnen. Wacht met de uitrol van WCAG 2.2. Eerst moeten we webmakers alle hulp geven die ze nodig hebben. Want hulp hebben ze overduidelijk nodig.

Aanbeveling en discussie

We kunnen zo niet doorgaan. Naar mijn mening moet iedereen die betrokken is bij webtoegankelijkheid wereldwijd het W3C helpen.

Maak de specificaties en documentatie toegankelijk voor webmakers, eenduidig ​​en gemakkelijker te onderhouden.

Focus op hoe een webmaker naar informatie zoekt. Optimaliseer voor zoekmachines. Voeg de status en WCAG-versie duidelijk toe aan de HTML-titel.

Zorg voor training, voorbeeldmateriaal met behulp van moderne webtechnieken en geef links naar bronnen. Publiceer dit op één plek, op de WAI-website. Zorg voor informatie die aantrekkelijk, leesbaar en goed onderhouden is.

Werk samen aan de MDN Web Docs, door te reviewen wat er nu is en door toegankelijke codevoorbeelden te voegen. Voor de programmeurs om te kopiëren/plakken.

Verwijder de technieken, omdat ze moeilijk te onderhouden en schadelijk zijn. Richt je in plaats daarvan op Web Accessibility Initiative (WAI)-site, als dé website voor technieken en tutorials en houd dat allemaal op één plek en up-to-date. Als verwijderen een brug te ver is, review en update dan in ieder geval de bestaande inhoud.

Focus eerst op onderwijs en documentatie, in plaats van nieuwe specificaties te schrijven. Stop met het toevoegen van nieuwe succescriteria voordat de huidige goed zijn gedocumenteerd en uitgelegd en beter zijn overgenomen op websites over de hele wereld. Wacht met de uitrol van WCAG 2.2.

En vooral: verplaats je in een webmaker, want zij zijn degenen die het web bouwen. Kan ik hier zeggen: gebruikers eerst?

Veel dank aan Adrian, Eric, Hidde, Jules en Taeke voor het proeflezen en voor hun waardevolle feedback en discussies over de conceptversies van dit artikel.

Op de W3C/WCAG Github-repository heb ik een issue geopend: Comment on WCAG 2.2 Draft: please delay adding of new Success Criteria before the current documentation is improved. Ik nodig je graag uit om aan de discussie deel te nemen.