Oszacowanie kosztów wprowadzenia poprawek dotyczących dostępności

Poprawki dotyczące dostępności nie są błędami. Są to funkcje, których zespół nie wprowadził przy pierwszym wydaniu.

Traktowanie problemu dostępności jako błędu („proszę naprawić okno modalne tak, aby zatrzymywało fokus”) ogranicza się wyłącznie do samego „pułapki”. Nie uwzględnia to jednak czynników, od których ta „pułapka” zależy: pozostałych aspektów nawigacji za pomocą klawiatury, komunikatów czytnika ekranu oraz kontrastu kolorów, który prawdopodobnie stanowi ten sam problem również w kolejnym oknie modalnym. Większość „drobnych poprawek dotyczących dostępności” stanowi punkt wyjścia do klasy problemów, które dotyczą całego komponentu.

Rzetelna ocena dotyczy klasy, a nie konkretnego egzemplarza. Wprowadzą Państwo jedną poprawkę, a w następnym sprincie będą Państwo musieli zająć się kolejną, a potem jeszcze kolejną, aż ktoś przyzna, że zadaniem jest „przegląd modelu interakcji okien modalnych” i odpowiednio oszacuje zakres prac.

O czym się mówi w tym pomieszczeniu

Frontend: „Wprowadzenie mechanizmu focus trap zajmuje pół dnia”.

Pytanie dotyczące kontroli jakości: „Czy przycisk zamykania jest odczytywany przez czytniki ekranu?”

Projektant: „Czy kontrast na przycisku drugorzędnym jest odpowiedni?”

Wstęp: „Ile jeszcze czasowników modalnych ma taki sam kształt?”

PM: „Czy zajmujemy się wszystkimi, czy tylko tym, na który klienci zgłosili skargę?”

Pytania, które warto zadać przed oddaniem głosu

• Czy jest to instancja, czy klasa? Ile istnieje podobnych komponentów?
• Zakres audytu: ten komponent, ta strona, ten produkt?
• Poziom zgodności z wytycznymi WCAG: A, AA, AAA?
• Testowanie: program „Axe”, ręczny czytnik ekranu, instrukcja obsługi wyłącznie za pomocą klawiatury?
• Zapobieganie regresji: reguła Lint, migawka historii, kontrola w ramach ciągłego wdrażania (CI)?
• Jaki jest planowany budżet na prace związane z dostępnością po wdrożeniu tego rozwiązania?

Jeśli chodzi o klasę, a nie o instancję, proszę oddzielić ten jeden komponent, z którym mają do czynienia klienci, od audytu pozostałych elementów, a następnie dostosować wielkość każdego z nich do rzeczywistych zobowiązań.

Proszę określać rozmiar klasy, a nie instancji. Jedną z pułapek, na które łatwo się natknąć, jest „pół dnia”; wzorcem leżącym u jej podstaw jest opowieść.

Podobnie jak w przypadku szacowania zmiany w systemie projektowym, poprawka na wcześniejszym etapie jest niewielka, a rzeczywistą pracą jest pokrycie zmian na późniejszych etapach. Proszę zapoznać się z innymi przykładami szacowania lub zorganizować bezpłatną sesję „planning poker” po uzgodnieniu zakresu prac.