Home > Digitale toegankelijkheid in jouw organisatie > Ontwikkelaar of tester

Ontwikkelaar of tester

Dit is een kopie van een pagina uit het boekje Digitale toegankelijkheid in jouw organisatie: wie doet wat?

Als ontwikkelaar of tester ben je verantwoordelijk voor code, ontwerpen en systemen die geen toegankelijkheidsproblemen opwerpen, maar de toegankelijkheid juist verbeteren. Er is veel gedocumenteerd over toegankelijk bouwen en het testen hierop. In dit overzicht vind je een aantal belangrijke aandachtspunten.

Wat moet je doen als ontwikkelaar of tester?

  • Zorg dat toegankelijkheid een vast onderdeel is bij het ontwikkelen en testen van software en systemen.
  • Zorg dat je begrijpt hoe mensen met een functiebeperking digitale informatie en diensten gebruiken. Gebruik regelmatig het toetsenbord om te navigeren, in plaats van een muis of touchscreen. Leer met een screenreader werken. Gebruik hulpapparatuur en bevraag mensen met een functiebeperking. Weet dat de gemiddelde gebruiker niet bestaat.
  • Initieer een inventarisatieproject of neem hieraan deel. Hierin wordt een overzicht gemaakt van alle digitale diensten en producten, verwachte levensduur, toegankelijkheidsstatus en maatregelen die al genomen zijn.
  • Zorg dat je de technische standaard WCAG 2.1 goed kent. Er wordt veel over toegankelijkheid geschreven, maar dit document is het uitgangspunt voor toegankelijkheid voor een hele brede groep mensen met een functiebeperking. Volg een training, bezoek bijeenkomsten, vergroot - en deel - je kennis.
  • Gebruik HTML-elementen en -attributen conform de HTML-specificatie. Gebruik ze waarvoor ze bedoeld zijn, dan komt toegankelijkheid vanzelf mee. Dus een a-element voor een link, een button voor een knop en niet een span of div die zich deels zo gedragen maar voor toegankelijkheidsproblemen zorgen. Gebruik de specificaties voor CSS, SVG et cetera.
  • Gebruik ARIA alleen als het echt nodig is en met mate.
  • Onderzoek bestaande frameworks als React, Angular en bootstrap. Hierin wordt ARIA vaak verkeerd gebruikt en worden toegankelijkheidsproblemen gecreëerd. Controleer met behulp van de specificatie en repareer. Vaak is het gebruik van ARIA onnodig en kun je beter standaard-HTML gebruiken.
  • Als je met een componentenlibrary werkt, zorg dan dat deze uitgebreid getoetst en verbeterd is. Deze componenten zijn je bouwstenen.
  • Tools kunnen helpen met testen, maar als je alleen met tools test heb je geen goed en volledig beeld van de mate van toegankelijkheid. Met tools meet je slechts een deel van de eisen en kennis is nodig voor interpretatie.
    Valkuil is dat je optimaliseert om een tool tevreden te stellen in plaats van de toegankelijkheid te verbeteren. Test ook handmatig en op alle succescriteria en zorg voor de kennis om dit goed te kunnen doen.
  • Zorg voor een goed ingericht testproces. Test in het hele ontwikkelproces. Repareren is altijd duurder dan voorkomen en leidt bovendien tot frustratie bij betrokkenen.
  • Test een dienst of product met de evaluatiemethode WCAG-EM (of een gelijkwaardige gedocumenteerde evaluatiemethode voor de toegankelijkheidsstandaard WCAG 2.1). Gebruik deze standaard in het testproces of schakel experts in. Een toets op basis van deze methode is geschikt als onderbouwing voor de verplichte toegankelijkheidsverklaring.
  • Documenteer wanneer niet voldaan wordt aan een succescriterium van WCAG 2.1 AA en wat de reden is. Benoem wat de impact is voor verschillende mensen met een functiebeperking, welke maatregelen je organisatie neemt, welke alternatieven er zijn en wanneer het probleem is opgelost. Ook deze informatie moet in de toegankelijkheidsverklaring staan.
  • Zorg dat toegankelijkheid onderdeel is van de ‘definition of done’ en onderdeel is van het besluit of live gegaan wordt.
  • Ontwikkel alleen toegankelijke apps en test - of laat testen - op toegankelijkheid.

Nuttige links