Sklepy zmieniają platformy częściej, niż mogłoby się wydawać. Wyrośnięcie z abonamentowego rozwiązania, koniec wsparcia dla starej wersji, fuzja, wejście na rynki zagraniczne. Przy każdej takiej rozmowie pada w końcu pytanie o dostępność: badać stary sklep, którego za rok nie będzie, czy poczekać na nowy. Odpowiedź brzmi: i jedno, i drugie, tylko w różnym zakresie i po co innego.
Po co dotykać sklepu, który idzie do kosza
Pełny audyt starego serwisu na miesiąc przed migracją rzeczywiście bywa wyrzuconym budżetem. Przegląd, który ma sens, jest węższy i służy przyszłości. Chodzi o zebranie wiedzy, której nie odtworzy żaden brief: które procesy klienci faktycznie wykonują, gdzie utykają dziś, które komponenty generują zgłoszenia. Z tego przeglądu powstaje lista wymagań wejściowych dla nowej platformy, a nie raport naprawczy dla starej.
Bez tego etapu wymagania dostępności w specyfikacji sprowadzają się do jednego zdania o zgodności z WCAG 2.1 AA. Takie zdanie brzmi solidnie i nie znaczy prawie nic, bo nie mówi wykonawcy, które przepływy są krytyczne ani jak odbierzecie efekt.
Co musi znaleźć się w umowie z wykonawcą
Największą dźwignię ma kilka zapisów, o które mało kto pyta. Wymaganie zgodności z WCAG 2.1 AA dla wskazanych z nazwy procesów, od karty produktu po potwierdzenie zamówienia. Kryteria odbioru per komponent, w tym test samą klawiaturą i test czytnikiem ekranu dla checkoutu. Zasada, że gotowe motywy i wtyczki podlegają tym samym wymaganiom co kod pisany na zamówienie. Wreszcie odpowiedzialność za poprawki barier wykrytych w audycie odbiorowym w ramach wynagrodzenia, a nie jako zlecenie dodatkowe.
Wykonawcy różnie reagują na takie zapisy i to też jest informacja. Software house, który przy negocjacjach potrafi opowiedzieć, jak testuje dostępność, zwykle rzeczywiście to robi.
Audyt właściwy: po stabilizacji, przed szczytem
Pełne badanie nowego sklepu planujemy po ustabilizowaniu wdrożenia, gdy zniknie codzienny strumień hotfixów, ale zanim zacznie się sezon wysokiego ruchu. Audyt odbiorowy weryfikuje umowne kryteria i daje twardy argument w rozliczeniu z wykonawcą. Dopiero po nim wchodzi tryb utrzymaniowy: kontrola zmian po kolejnych wdrożeniach, żeby nowa platforma nie powtórzyła losu starej.
Czego nie odkładać na później
Jeśli budżet zmusza do wyboru, priorytet ma checkout i szablony bazowe, z których dziedziczy cała reszta serwisu. Błąd w pojedynczym banerze naprawia się w godzinę. Błąd w szablonie strony produktu powiela się na dziesiątki tysięcy podstron i potrafi czekać na naprawę do następnej migracji.