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 uwzględnił w pierwszej wersji.

Traktowanie problemu dostępności jako błędu — „należy poprawić okno modalne tak, by 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.

Rzetelne oszacowanie 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 nakład pracy.

O czym się mówi w tym pomieszczeniu

Frontend: „Dodanie mechanizmu przechwytywania fokusu zajmie pół dnia”.

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

Projektant: „Czy kontrast na przycisku drugorzędnym jest wystarczający?”

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?
• Testy: axe, ręczny czytnik ekranu, przewodnik dotyczący obsługi wyłącznie za pomocą klawiatury?
• Zapobieganie regresji: reguła Lint, migawka historii, kontrola w ramach ciągłego wdrażania?
• 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ę za pomocą funkcji split oddzielić ten jeden element, z którym mają do czynienia klienci, od pozostałych elementów objętych audytem — a następnie porównać wielkość każdego z nich z tym, do czego faktycznie się Państwo zobowiązują.

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 w górnej części łańcucha jest niewielka, a rzeczywistą pracą jest pokrycie zmian w dalszej części łańcucha. Proszę zapoznać się z innymi przykładami szacowania lub rozpocząć bezpłatną sesję planowania pokerowego, gdy tylko zakres prac zostanie uzgodniony.