Digitale toegankelijkheid als eis in een aanbesteding
Als toegankelijkheid pas aan het einde van een project aandacht krijgt, zijn fouten meestal lastiger te herstellen. Denk aan componenten die opnieuw gebouwd moeten worden, formulieren die niet goed werken met het toetsenbord, pdf-processen zonder duidelijke afspraken of contentbeheer waarbij redacteurs niet weten waar ze op moeten letten.
Daarom hoort digitale toegankelijkheid al thuis in de aanbesteding of opdrachtomschrijving.
Toegankelijkheid begint niet bij de oplevering
Voor overheden en publieke organisaties is digitale toegankelijkheid geen vrijblijvende keuze. Websites, apps en digitale diensten moeten toegankelijk zijn voor iedereen. Ook voor mensen die gebruikmaken van een screenreader, toetsenbordnavigatie, vergrotingssoftware, spraakbediening of andere ondersteunende technologie.
Toch wordt toegankelijkheid in aanbestedingen vaak te algemeen omschreven. Bijvoorbeeld met zinnen als:
“De website moet voldoen aan de geldende toegankelijkheidseisen.”
Of:
“De leverancier houdt rekening met digitale toegankelijkheid.”
Dat klinkt goed, maar in de praktijk is het vaak te vaag. Want wanneer is iets dan goed genoeg? Wie controleert dit? Wat gebeurt er als er na oplevering toegankelijkheidsproblemen worden gevonden? En wie is verantwoordelijk voor het oplossen daarvan?
Door toegankelijkheid concreet op te nemen in de aanbesteding voorkom je discussie achteraf.
1. Eis WCAG 2.1 AA en EN 301 549
Leg in de aanbesteding expliciet vast aan welke norm de website, app of digitale dienst moet voldoen. Voor overheidsorganisaties is het belangrijk om te verwijzen naar WCAG 2.1 niveau A en AA en naar EN 301 549.
Een formulering kan bijvoorbeeld zijn:
“De op te leveren website, app of digitale dienst moet voldoen aan de relevante eisen uit EN 301 549, waaronder WCAG 2.1 niveau A en AA.”
Door dit concreet te benoemen, weten leveranciers vooraf waar zij aan moeten voldoen. Zij kunnen tijdens het ontwerpen en bouwen van de website rekening gehouden met de webrichtlijnen.
Spreek daarnaast af wie de bewijslast draagt. Laat de overheidsorganisatie het toegankelijkheidsonderzoek uitvoeren, of ligt dit bij de opdrachtgever?
WCAG versie 2.1 of 2.2?
Versie 2.1 van de WCAG is opgenomen in de huidig wetgeving, versie 2.2 is de huidige versie. Versie 2.2 voldoet ook aan de huidige wetgeving én is toekomstbestendiger. Daarom voert Audit House toegankelijkheidsonderzoeken uit op basis van versie 2.2 van de WCAG.
2. Vraag om aantoonbare ervaring
Niet iedere leverancier die websites of apps bouwt, heeft voldoende ervaring met digitale toegankelijkheid. Vraag daarom niet alleen of een leverancier bekend is met WCAG, maar ook hoe die kennis in de praktijk wordt toegepast.
U kunt leveranciers bijvoorbeeld vragen naar:
- eerdere projecten waarbij toegankelijkheid een duidelijke eis was;
- voorbeelden van toegankelijke componenten;
- de manier waarop toegankelijkheid wordt meegenomen in ontwerp en development;
- ervaring met toegankelijkheidsonderzoeken en hersteltrajecten;
Aantoonbare ervaring helpt om het verschil te maken tussen een leverancier die toegankelijkheid alleen noemt en een leverancier die toegankelijkheid echt meeneemt in het proces.
3. Neem toegankelijkheid op in acceptatiecriteria
Een belangrijke stap is het vertalen van toegankelijkheid naar concrete acceptatiecriteria. Daarmee beschrijf je wanneer een onderdeel wordt goedgekeurd.
Dat voorkomt dat toegankelijkheid pas achteraf als discussiepunt op tafel komt.
Voorbeelden van acceptatiecriteria zijn:
- Alle interactieve onderdelen zijn volledig met het toetsenbord te bedienen.
- De focus is altijd zichtbaar en volgt een logische volgorde.
- Formuliervelden hebben duidelijke labels.
- Foutmeldingen zijn tekstueel duidelijk en programmatisch gekoppeld aan het juiste veld.
- Knoppen en links hebben een duidelijke toegankelijke naam.
- Informatie wordt niet alleen via kleur, vorm, positie of icoon overgebracht.
- Modals, menu’s, filters en accordions zijn bruikbaar met toetsenbord en screenreader.
- Contentredacteurs kunnen pagina’s publiceren met een correcte koppenstructuur, goede linkteksten en toegankelijke afbeeldingen.
Hoe concreter de acceptatiecriteria, hoe beter toegankelijkheid tijdens het project gecontroleerd kan worden. Audit House denkt graag mee om de WCAG-criteria tot acceptatiecriteria om te zetten. Neem voor meer informatie vrijblijvend contact op.
4. Laat componenten toetsen vóór livegang
Wacht niet tot de volledige website of app klaar is. Juist veel toegankelijkheidsproblemen ontstaan in herbruikbare componenten.
Denk aan onderdelen als het hoofdmenu, mobiele navigatie, formulieren, de zoekfunctie of een cookie banner.
Als zo’n component niet toegankelijk is, komt dezelfde fout vaak op meerdere plekken terug. Een ontoegankelijk formulier of menu kan daardoor een groot deel van de website raken.
Laat belangrijke componenten daarom al toetsen tijdens ontwerp en ontwikkeling. Dan kunnen problemen worden opgelost voordat ze in tientallen pagina’s, templates of processen worden hergebruikt.
5. Leg vast wie fouten oplost na oplevering
Ook als toegankelijkheid vanaf het begin goed wordt meegenomen, kan een onafhankelijk onderzoek nog bevindingen opleveren. Daarom is het belangrijk om vooraf vast te leggen wie verantwoordelijk is voor herstel.
Bij toegankelijkheidsproblemen kunnen meerdere partijen betrokken zijn:
- de opdrachtgever;
- de webbouwer;
- een externe leverancier;
- een pluginontwikkelaar;
- het contentteam;
- de beheerorganisatie;
- een pdf-leverancier.
Zonder duidelijke afspraken ontstaat na oplevering vaak discussie. Is het een technisch probleem? Een contentprobleem? Een beperking van het CMS? Of iets dat buiten de opdracht viel?
Neem daarom in de aanbesteding en overeenkomst op hoe bevindingen worden opgepakt, binnen welke termijn herstel plaatsvindt en wie verantwoordelijk is voor de kosten.
Voorkom discussie achteraf
Door digitale toegankelijkheid goed op te nemen in de aanbesteding voorkom je veel problemen later in het project.
Je maakt vooraf duidelijk:
- aan welke norm de oplossing moet voldoen;
- welke ervaring van leveranciers verwacht wordt;
- hoe toegankelijkheid wordt getoetst;
- welke onderdelen vóór livegang gecontroleerd worden;
- wie verantwoordelijk is voor herstel;
- hoe toegankelijkheid na livegang wordt geborgd.
Dat zorgt voor betere afspraken, minder herstelwerk en een grotere kans dat de website, app of digitale dienst bij livegang echt bruikbaar is voor iedereen.