Accessibility testen is niet ingewikkeld. Het wordt gewoon vaak overgeslagen.

95,9% van de meest bezochte websites ter wereld heeft minstens één detecteerbare toegankelijkheidsfout. En dat cijfer gaat al jaren niet vooruit.

Niet omdat de tools ontbreken. Wel omdat een toegankelijkheidscheck zelden een vast onderdeel is van het proces vóór iets live gaat. Het staat op de takenlijst als "later nog eens bekijken", en dat later komt zelden.

De twee problemen die je het vaakst tegenkomt

Geen van beide is complex om te fixen. Het probleem zit niet in de moeilijkheidsgraad, het zit erin dat niemand er structureel naar kijkt.

Wat je automatiseert, en wat niet

Dit is het goede nieuws: een groot deel van deze problemen laat zich vangen zonder dat er een mens naar hoeft te kijken. Tools zoals axe-core of Lighthouse CI checken contrast, ontbrekende alt-teksten en labels automatisch, en dat kan gewoon in je bestaande pipeline.

Toetsenbordnavigatie en de werkelijke ervaring van iemand die een schermlezer gebruikt, test je er bewust bovenop. Dat blijft mensenwerk. Maar de basis, de dingen die je bij elke build zou moeten controleren, hoort in je pipeline en nergens anders.

Zo'n check ziet er in de praktijk uit als een paar regels bovenop je bestaande Playwright-tests:

// draait bij elke build mee, faalt de test bij een overtreding
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('checkout-pagina voldoet aan WCAG 2.1 AA', async ({ page }) => {
  await page.goto('/checkout');

  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa'])
    .analyze();

  expect(results.violations).toEqual([]);
});

Faalt de build omdat een knop te weinig contrast heeft? Dan zie je dat meteen in de pull request, niet pas wanneer een gebruiker het meldt.

Waar je begint

Zet axe-core of Lighthouse CI in je pipeline en laat hem draaien bij elke build, niet alleen bij een jaarlijkse audit. Begin met contrast en alt-teksten, dat zijn de twee met de grootste impact voor de kleinste inspanning. Bouw van daaruit een gewoonte op: een handmatige toetsenbordtest bij elke nieuwe feature die interactie toevoegt.

Toegankelijkheid testen is niet ingewikkeld. Het wordt gewoon vaak overgeslagen, en dat is precies het probleem dat je met een paar regels in je CI kan oplossen.

// Ook als carrousel

Dit artikel verscheen eerder als carrousel op LinkedIn.

Bekijk op LinkedIn