Ekspert dostępności
na Waszym czacie.
Macie audyt, lecz nie ma w nim informacji jak wprowadzić poprawkę w Waszym frameworku, ani jak sprawdzić, czy przejdzie retest? Wchodzimy na Waszego Slacka, Teams albo Google Chat i odpowiadamy na pytania, kiedy potrzebujecie naszej pomocy.
Zamów wsparcie eksperta
Wpisujemy się w Wasz sposób pracy.
Slack, Teams, Google Chat albo spotkanie, kiedy wątek nie wystarcza. Programista wkleja komponent i to, co odczytał czytnik ekranu, i dostaje odpowiedź od kogoś, kto naprawiał dokładnie ten wzorzec na produkcji.
Trudne pytanie trafia do eksperta, zanim zamieni się w obciążający ticket, który przechodzi do kolejnego sprintu po raz trzeci.
Sam raport z audytu często nie wystarcza
Raport z audytu odpowiada na pytania, które tester miał podczas testów. Przy pracy nad kodem programiści trafiają na nowe.
-
Ostatnie tickety kosztują najwięcej
Brakująca etykieta to pięć minut roboty. Zagnieżdżony modal z pułapką fokusu, wirtualizowana tabela albo własny combobox może zająć kilka dni albo nawet tygodni. Właśnie takie tickety stoją w miejscu, a raport może je tylko opisać.
-
Pętla, która zjada sprint
Programista czyta kryterium WCAG, znajduje trzy sprzeczne odpowiedzi na Stack Overflow, wdraża najbardziej prawdopodobną i dalej nie wie, czy to spełnia kryterium. Ticket wraca po reteście.
Co daje ekspert dostępności w zespole
Odpowiedzi na czacie zespołu
Programiści pytają na kanale, wklejają komponent i dostają techniczną odpowiedź, zanim wybiorą rozwiązanie, którego nie są pewni.
Sprawdzenie poprawki, zanim ją wdrożycie
Wysyłacie nam komponent, a my sprawdzamy obsługę klawiatury, wsparcie czytników ekranu i zachowanie przy dynamicznych zmianach. Wyłapanie niepoprawnego zachowania kosztuje teraz jedną wiadomość. Wyłapanie jej w reteście kosztuje kolejny sprint.
Trudne komponenty rozwiązane porządnie
Dodanie atrybutu ARIA to często za mało. Rozkładamy problem na czynniki pierwsze i proponujemy poprawki, które przetrwają Wasze refaktory.
Makiety sprawdzone, zanim trafią do sprintu
Wiele problemów zaczyna się jeszcze w fazie projektowej. Przyślijcie makiety, a wskażemy wzorce, które drogo będzie zbudować w dostępny sposób. Na tym etapie zmiana to jedna poprawka w projekcie. Gdy komponent jest już zbudowany, ta sama zmiana oznacza jego przeróbkę.
Jak wygląda współpraca?
Poznajemy produkt.
Sprawdzamy Wasz stack, procesy i wcześniejszy audyt, jeśli już go macie.
Wchodzimy na Wasz kanał.
Jeden wspólny kanał na Slacku, w Teamsach albo w Google Chacie. Wystarczy, że zaprosicie nas jako gości.
Wy pytacie, my odpowiadamy.
Pytanie trafia na kanał i wraca z uzasadnieniem, a poprawkę wdrażacie sami. Jedne zespoły pytają dwa razy na sprint, inne dwa razy dziennie.
Przestajecie nas potrzebować.
Pytań jest coraz mniej, a zespół wyrabia pewność siebie. O to właśnie chodzi. Wolimy być Waszym ekspertem, kiedy naprawdę tego potrzebujecie.
Jak na co dzień wygląda wsparcie wdrożeniowe
Jak ustalacie zakres i cenę wsparcia wdrożeniowego?
Zakres i cenę wsparcia wdrożeniowego ustalamy przed startem, w jednym z trzech wariantów. Jednorazowa konsultacja dotyczy jednego trudnego komponentu. Wsparcie przez sprint obejmuje czas, w którym zamykacie zgłoszenia z audytu. Przy stałej współpracy Wasi programiści mogą pytać na bieżąco, w rytmie, który ustalamy na początku. Najlepiej zacząć od jednego komponentu.
Jak szybko odpowiadacie naszym programistom?
Programista wrzuca na kanał komponent razem z tym, co odczytuje czytnik ekranu, i dostaje techniczną odpowiedź tego samego dnia roboczego. Jeśli najlepszym rozwiązaniem jest przebudowa komponentu, mówimy to wprost i podajemy powód. Kiedy wątek przestaje wystarczać, umawiamy krótką rozmowę i udostępniamy ekran, bo niektóre błędy fokusu szybciej pokazać, niż opisać.
Potrzebujecie dostępu do naszego repozytorium?
Nie. Pracujemy bez dostępu do repozytorium, na tym, co programiści udostępniają na kanale: komponent, wyrenderowany HTML, zrzut ekranu, odczyt czytnika ekranu. Jeśli po Waszej stronie łatwiej podesłać branch albo link do Storybooka, to też się sprawdzi. Pierwsze pytanie zespół może zadać już w dniu startu.
Piszecie poprawkę, czy tylko ją opisujecie?
Poprawkę przekazujemy jako wzorzec z uzasadnieniem, a commit robi Wasz programista. Taka poprawka musi żyć w Waszym repozytorium, trzymać się przyjętych u Was konwencji i przetrwać kolejny refaktor. Kod zrzucony z zewnątrz rzadko spełnia wszystkie trzy warunki. Dostajecie strukturę HTML, ARIA, obsługę fokusu i uzasadnienie każdego elementu, tak szczegółowo, żeby dało się to przejrzeć w pull requeście.
Czy możecie przejrzeć projekty, zanim trafią do developmentu?
Tak. Wyślijcie makiety, zanim trafią do sprintu, a zaznaczymy, co nie przejdzie: tekst poniżej wymaganego kontrastu, stan fokusu, którego nikt nie narysował, błąd sygnalizowany samym kolorem, układ, który rozpada się przy szerokości 320 px. Poprawka w makiecie kosztuje mniej niż ponowne otwieranie zmergowanego komponentu.
Z jakimi frameworkami pracujecie?
React, Vue, Angular i zwykłe szablony. Trudna część dostępnego komponentu i tak jest niezależna od frameworka: zarządzanie fokusem, semantyka i to, co czytnik odczytuje przy zmianie stanu. Combobox psuje się tak samo w każdym stacku, a poprawka różni się tylko składnią. Powiedzcie, na czym pracujecie, a odpowiemy w tej technologii.
Mamy raport od innego dostawcy. Da się na nim pracować?
Tak, i to częsty początek współpracy. Przyślijcie raport, a my go przejrzymy: co jest realną blokadą, co fałszywym alarmem ze skanera, a co opisano tak, że zespół nie wie, co z tym zrobić. Potem pracujemy nad zgłoszeniami razem z Waszymi programistami.
Odkryj swój pełny potencjał
Masz produkt do zbudowania. Nie masz czasu, aby stać się ekspertem WCAG. Pozwól nam zająć się technikaliami, aby Twój zespół mógł wrócić do tego, co robi najlepiej.
Omówmy Twój projekt