Oplossingen op het gebied van toegankelijkheid zijn geen fouten. Het zijn functies die het team de eerste keer niet heeft geïmplementeerd.

Door een toegankelijkheidsprobleem als een bug te behandelen („zorg ervoor dat het modaalvenster de focus vasthoudt”), wordt alleen de „val” zelf aangepakt. Er wordt geen aandacht besteed aan de factoren waarvan deze „val” afhankelijk is: de rest van de toetsenbordnavigatie, de uitspraken van de schermlezer en het kleurcontrast, dat waarschijnlijk ook in het volgende modaalvenster hetzelfde probleem vertoont. De meeste „kleine toegankelijkheidsaanpassingen“ vormen de ingang tot een categorie problemen die zich door de gehele component heen uitstrekt.

De realistische schatting heeft betrekking op de klasse, niet op het exemplaar. Als u één oplossing implementeert, bent u de volgende sprint weer terug voor de zusterklasse, en de zusterklasse daarvan, totdat iemand toegeeft dat het werk neerkomt op „het controleren van het modale interactiemodel” en de omvang ervan op die manier vaststelt.

Wat er in de kamer wordt gezegd

Frontend: “Het toevoegen van de focus trap kost een halve dag.”

Vraag: “Wordt de knop ‘Sluiten’ door schermlezers aangekondigd?”

Ontwerper: “Is het contrast op de secundaire knop voldoende?”

Inleiding: “Hoeveel andere modale werkwoorden hebben dezelfde vorm?”

PM: “Gaan we ze allemaal aanpakken, of alleen die waarover klanten hebben geklaagd?”

Vragen die het waard zijn om te stellen voordat u gaat stemmen

  • Is dit een instantie of een klasse? Hoeveel soortgelijke componenten zijn er?
  • Reikwijdte van de controle: dit onderdeel, deze pagina, dit product?
  • WCAG-doelstelling: A, AA, AAA?
  • Testen: axe, handmatige schermlezer, doorloop met uitsluitend het toetsenbord?
  • Voorkomen van regressies: Lint-regel, story-snapshot, CI-controle?
  • Hoeveel bedraagt het budget voor toegankelijkheidswerkzaamheden nadat dit project is afgerond?

Als het om een klasse gaat in plaats van een instantie, scheidt u met split het onderdeel waarmee klanten in aanraking komen van de rest van de controle, en toetst u elk onderdeel aan wat u daadwerkelijk toezegt.

Bepaal de omvang van de les, niet van de lesonderdeel. Een veelvoorkomende valkuil is een halve dag; het patroon dat hierachter schuilgaat, is het verhaal.

Net als bij het inschatten van een wijziging in het ontwerpsysteem is de aanpassing stroomopwaarts klein en vormt de dekking stroomafwaarts het eigenlijke werk. Bekijk de andere praktijkvoorbeelden van schattingen, of start een gratis planning poker-sessie zodra er overeenstemming is bereikt over de omvang van het project.