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 („należy poprawić 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 powrócą Państwo do kolejnego elementu z tej samej grupy, a potem do kolejnego, aż ktoś przyzna, że zadaniem jest „przegląd modelu interakcji z oknami modalnymi” i odpowiednio oszacuje zakres prac.

O czym się mówi w tym pomieszczeniu

Frontend: „Wprowadzenie 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 odpowiedni?”

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

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

Pytania, które warto zadać przed głosowaniem

• 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, instrukcja obsługi wyłącznie za pomocą klawiatury?
• Zapobieganie regresji: reguła Lint, migawka historii, kontrola 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ę za pomocą funkcji split oddzielić ten element, z którym mają do czynienia klienci, od pozostałych elementów poddanych audytowi, 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. Jednym z pułapek, na które warto zwrócić uwagę, 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 uzgodniony zostanie zakres prac.