Opis ilustracji: projektantka przy biurku stojącym widziana od tyłu, dwa monitory pokazujące bibliotekę komponentów systemu projektowego ze stanami fokusa — wizualny znacznik profilu projektantki dostępności w skali.

Czas czytania: 10 minut

Nota od redakcji. Projektantka opisana w tym artykule jest postacią zbiorową. „Maya Okafor“ nie jest jedną prawdziwą osobą; biografia składa się z wywiadów na żywo z pięcioma starszymi kierownikami ds. projektowania dostępności, którzy w latach 2019–2025 prowadzili wielokwartalne programy dostępności w firmach internetowych dla konsumentów z bazami użytkowników rzędu ok. 80–300 milionów. Każda liczba, każdy artefakt, każda porażka w poniższej osi czasu jest prawdziwa i pochodzi od jednej z pięciu praktyków; synteza — łuk jednej kariery przez jeden program — jest redakcyjną swobodą.

Produkt jest również zakamuflowany. To, co nazywamy precyzyjnie, to jego skala (ok. 200 milionów miesięcznych aktywnych użytkowników na początku, ok. 240 milionów na koniec), jego stos (frontend React + TypeScript z natywnymi aplikacjami iOS i Android współdzielącymi ten sam język projektowania) oraz obszar powierzchni systemu projektowego odziedziczony przez Mayę (ok. 410 komponentów, z czego ok. 90 „podstawowych“). To są zmienne, które decydują o trudności pracy.

Ten poniedziałek, w którym weszła

Maya Okafor dołączyła do firmy w deszczowy poniedziałek pod koniec stycznia 2022 r. jako Staff Product Designer w zespole Design Systems. Miała trzydzieści cztery lata. Poprzednie sześć lat spędziła w cyfrowym ramieniu dużego wydawcy, gdzie — niemal przypadkowo — stała się tą osobą, która wiedziała, jak powinien wyglądać pierścień fokusa i dlaczego wymuszony przez markę współczynnik kontrastu 2,6:1 na przyciskach trzeciorzędnych był — faktycznie — nieakceptowalny. Nie miała formalnych certyfikatów dostępności. Zawsze mówiła, że nauczyła się wszystkiego przez działanie: będąc projektantką biorącą udział w rozmowie, gdy użytkownik czytnika ekranu zgłosił zgłoszenie do supportu i nikt inny nie wiedział, jak odtworzyć problem.

W nowej firmie nie było mandatu dostępności. Nie było zespołu ds. dostępności. Była Accessibility Working Group, która spotykała się co drugi wtorek o 16:00 czasu pacyficznego i która w pierwszy wtorek Mayi liczyła sześciu uczestników. Miała stronę w Confluence, ostatnio aktualizowaną w 2020 r., kanał Slack z ok. 140 członkami i trzema wiadomościami tygodniowo, a — Maya zdała sobie z tego sprawę później — dokładnie jeden punkt dźwigni: zaległość czterdziestu jeden otwartych zgłoszeń supportu związanych z dostępnością, z których siedem pochodziło od jednej organizacji praw osób z niepełnosprawnościami, która wysyłała do firmy e-maile co kwartał od 2019 r.

„Pierwszą rzeczą, którą zrobiłam, było przeczytanie każdego z tych czterdziestu jeden zgłoszeń. Drugą było wydrukowanie ich i umieszczenie w segregatorze. Nie dlatego, że ktokolwiek potrzebował segregatora — dlatego, że potrzebowałam fizycznego obiektu, który za trzy miesiące, gdy rozmowa stanie się trudna, można postawić na biurku wiceprezesa.“

Maya Okafor, postać zbiorcza, o swoim pierwszym miesiącu

Budowanie argumentacji: wolumen skarg, ryzyko prawne, udział w rynku

Pierwsze trzy miesiące to nie była praca projektowa. To była praca śledcza. Maya robiła trzy rzeczy równolegle.

Skwantyfikowała potok skarg. Współpracując z Supportem, wyciągnęła każde zgłoszenie z ostatnich dwudziestu czterech miesięcy zawierające dowolne z kilkunastu wyrażeń flagowych — „screen reader“, VoiceOver, TalkBack, JAWS, NVDA, „contrast“, „keyboard only“, WCAG, ADA, EAA, „I can’t read“. Znalazła ok. 1 470 odrębnych skarg, z czego ok. 280 pozostawało nierozwiązanych dłużej niż dziewięćdziesiąt dni. Zmapowała je na powierzchnie produktu: ok. 38% dotyczyło kasy, ok. 22% — wiadomości, ok. 14% — tworzenia profilu, ok. 9% — odtwarzacza wideo. Ten rozkład zdecyduje sześć miesięcy później, które komponenty zostaną przepisane jako pierwsze.

Skwantyfikowała ryzyko prawne. Firma była wymieniana w dwóch pozwach ADA Title III w ciągu poprzednich osiemnastu miesięcy, oba zakończone ugodą. Maya nie mogła zobaczyć kwot ugód — Dział Prawny odmówił ich udostępnienia — ale mogła zobaczyć krzywą częstości postępowań sądowych w publicznym wykazie dla swojego sektora. Stworzyła arkusz kalkulacyjny, który uwzględniał powierzchnię ekspozycji firmy i generował szacunkowy zakres oczekiwanego rocznego kosztu ugody + usunięcia barier na trajektorii „nie robimy nic“. Punkt środkowy tego zakresu wynosił kilka milionów dolarów rocznie.

Skwantyfikowała szansę rynkową. To była linia, która zmieniła atmosferę w sali. Maya uzupełniła dane badań użytkowników firmy o ankietę użytkowników czytników ekranu WebAIM, statystyki niepełnosprawności CDC i dane Eurostat dotyczące występowania niepełnosprawności na rynkach UE, które obsługiwał produkt. Opracowała jeden slajd: spośród ok. 200 milionów miesięcznych użytkowników firmy szacunkowo 14–22 miliony korzystało z produktu z jakąś formą technologii wspomagającej lub niestandardowymi ustawieniami. Analityka pokazała, że ten segment odpływał w tempie ok. 1,8-krotnie wyższym niż ogólna baza. Gdyby retencja tego segmentu mogła zostać zrównana z resztą bazy, roczny wpływ na przychody byłby liczbą rozpoznawalną dla Finansów.

„Nigdy nie pokazywałam liczby Działu Prawnego Działowi Marketingu i nigdy nie pokazywałam liczby Działu Marketingu Działowi Prawnemu. Każdemu z nich pokazywałam tę liczbę, która miała dla nich znaczenie. Dyrektorowi Finansowemu pokazałam obie — na jednym slajdzie, obok siebie. To było spotkanie, na którym program otrzymał finansowanie.“

Maya Okafor, postać zbiorcza, o argumentacji finansowej

Program został zatwierdzony pod koniec Q2 2022 r. Obsada: siedem osób, narastając do jedenastu przez dwanaście miesięcy — troje projektantów, czterech inżynierów, dwóch specjalistów QA, jeden kierownik programu, jeden badacz z doświadczeniem w rekrutacji ze środowisk osób z niepełnosprawnościami. Budżet na zewnętrzne partnerstwa testowe: sześciocyfrowa roczna pozycja. Uprawnienia: zatwierdzenie każdego nowego komponentu systemu projektowego, z prawem weta dla komponentów, które nie przeszły listy kontrolnej dostępności. Ta ostatnia klauzula — weto — była tą, którą Maya negocjowała najtwardziej. To była różnica między programem a ćwiczeniem polegającym na proszeniu o pozwolenie.

Przebudowa systemu projektowego: tokeny, fokus, ruch

Prace techniczne rozpoczęły się w Q3 2022 r. i trwały przez kolejne czternaście miesięcy. Maya podzieliła je na trzy transze, które nazywała — na slajdach i podczas stand-upów — Fundamenty, Komponenty, Wzorce. Dyscyplina tej kolejności była — jak często mówiła — najważniejszą architektoniczną decyzją programu.

Transza 1 — Fundamenty

Pierwsze sześć miesięcy przebudowało tokeny projektowe. Starszy system miał ok. 84 tokeny kolorów bez semantycznego nazewnictwa — „Blue/600“, „Grey/400“, „Brand/Primary“ — i bez metadanych kontrastu. Zespół Mayi zastąpił je semantyczną paletą ok. 40 tokenów zorganizowaną funkcjonalnie: content-primary, content-secondary, surface-base, border-default, plus drabinka interaktywna (action-primary, action-primary-hover, action-primary-pressed) i drabinka statusu. Każdy token zawierał w metadanych współczynnik kontrastu względem powierzchni, na której był zatwierdzony do użycia, oraz flagę dla poziomu zgodności WCAG. Narzędzia to egzekwowały: projektant nie mógł przypisać content-tertiary na tle surface-base w Figma bez otrzymania ostrzeżenia od lintera.

Ta sama transza ustandaryzowała pierścień fokusa. Starsze komponenty miały — Maya policzyła — ok. siedemnastu różnych stylów pierścienia fokusa, od 1-pikselowego zarys w kropki, który znikał na jasnych tłach, po 2-pikselowy solidny niebieski pierścień, który łamał układ w gęsto ustawionych listach. Nowy pierścień był jednym tokenem: 2-pikselowy zarys odsunięty o 2-pikselową przezroczystą szczelinę od krawędzi komponentu, tak by pierścień był widoczny na każdej powierzchni. Każdy interaktywny komponent pobierał go domyślnie; nie było możliwości wyłączenia.

Preferencje ruchu były trzecim fundamentem. Starszy system honorował prefers-reduced-motion w ok. jednym miejscu — jednej animacji onboardingowej — a natywne aplikacje nie honorowały go nigdzie. Nowy fundament uczynił ruch tokenem, z trzema wartościami (brak, zredukowany, pełny) przeprowadzonymi przez każdy prymityw animacji. Projektant, który próbował nadpisać preferencję, musiał dołączyć pisemne uzasadnienie, które przeglądał kierownik programu.

Transza 2 — Komponenty

Po ustabilizowaniu fundamentów zespół przystąpił do ok. 90 komponentów podstawowych. Lista była uszeregowana według danych potoku skarg, które Maya zebrała w pierwszym miesiącu: najpierw kasa, potem wiadomości, potem profil, potem wideo. Każdy komponent przeszedł przez ustandaryzowaną przebudowę: mapa nawigacji klawiaturą, semantyka czytnika ekranu, kolejność fokusa, weryfikacja kontrastu w każdym stanie, wariant zredukowanego ruchu, wariant RTL i — na insystencję Mayi — udokumentowany osprzęt testowy, który zespół QA mógł uruchamiać przy każdym wydaniu.

Pole do wpisywania numeru karty kredytowej w starej formie było jednym <input> z automatycznym formatowaniem JavaScript, które łamało ogłoszenie przez czytnik ekranu wpisywanych znaków; przebudowa użyła czterech oddzielnych inputów z jawnymi etykietami, błędami powiązanymi przez aria-describedby i inline walidacją ogłaszaną przez uprzejmy live region. Zajęło to sześć tygodni dla jednego projektanta i jednego inżyniera. Zgłoszenia dostępności związane z kasą spadły o ok. 70% w następnym kwartale — ponieważ większość nowych zgłoszeń po prostu przestała być składana.

Transza 3 — Wzorce

Ostatnia transza była tą, którą Maya opisywała jako najłatwiejszą w realizacji i najtrudniejszą koordynacyjnie. Zespół udokumentował wzorce kompozycji — jak zbudować dostępny przepływ modalny na podstawie przebudowanych komponentów; jak złożyć listę elementów ze zmieszanymi mediami; jak zbudować stronę ustawień tak, by nawigacja działała pod kontrolą głosową. Wzorce trafiły do strony dokumentacji systemu projektowego jako uruchamialne przykłady kodu. Trudna część nie polegała na ich napisaniu. Trudna część polegała na przekonaniu każdego zespołu produktowego do ich używania zamiast wymyślania własnych.

Wdrożenie inżynierskie

Przeprojektowany system projektowy to biblioteka; sam w sobie nie jest wdrożeniem. Najtrudniejsza praca zarządzania projektem w programie — Maya była w tej kwestii jednoznaczna — to była migracja. Produkt miał ok. czterdziestu zespołów, z których każdy odpowiadał za dwie do pięciu powierzchni i każdy mógł w praktyce korzystać z systemu projektowego w dowolnym tempie, na jakie pozwalał jego roadmap. Naiwny plan zakładałby, że każdy zespół przeprowadzi migrację w ciągu kwartału. Ten plan by się nie powiódł.

Rozwiązaniem Mayi był stopniowy mandat. Nowe komponenty były dostarczane jako domyślne; stare pozostawały za feature flagiem, ale każde wydanie powierzchni nadal korzystającej z komponentu legacy automatycznie otwierało zgłoszenie P2 w zaległości tego zespołu. Zgłoszenie eskalowało automatycznie do P1 po dziewięćdziesięciu dniach i do P0 po stu osiemdziesięciu. W ciągu czterech kwartałów ok. 78% starszego użycia komponentów podstawowych przeszło migrację. W ciągu sześciu kwartałów ta wartość wynosiła ok. 94%.

„Trudna część to nie był system projektowy. Trudna część to był schemat organizacyjny czterdziestu zespołów i cykl budżetowy, który nie był na to zbudowany. Komponenty zajęły trzy miesiące pracy. Wdrożenie zajęło trzy lata.“

Maya Okafor, postać zbiorcza, o migracji

Ile kosztował program — i co zwrócił

Maya skrupulatnie prowadziła śledzenie. Do czasu, gdy program zakończył swoją formalną fazę w Q4 2024 r., wydatki wyniosły łącznie — przez dwa i pół roku, jedenaście dedykowanych etatów i zewnętrzne testy — gdzieś w górnej części jednocyfrowych milionów. Napływ zgłoszeń związanych z dostępnością spadł o ok. 73% względem wartości bazowej z 2022 r., mimo że baza użytkowników urosła o ok. 20%. Dwie sprawy prawne związane z ADA otwarte w oknie programu zostały obie zamknięte bez postępowania sądowego, na warunkach, które firma opisała w swoich rocznych sprawozdaniach jako nieistotne. Retencja produktu w segmencie użytkowników technologii wspomagającej — segmencie zidentyfikowanym przez Mayę w argumentacji finansowej — skurczyła się ze współczynnika odpływu 1,8-krotnie wyższego niż ogólna baza do ok. 1,15-krotnie. Finanse zaksięgowały różnicę. Maya nie powiedziała, jaka to była kwota.

Zaksięgowała też rzeczy, które nie pojawiają się w arkuszu. Obsługa VoiceOver rotor w natywnej aplikacji iOS, która przez lata była powszechnie znana jako zepsuta, stała się — w niezależnym audycie na początku 2025 r. — jedną z najlepiej działających w swoim sektorze. Motyw wysokiego kontrastu, który Maya forsowała wbrew sprzeciwom zespołu ds. marki, stał się domyślnym w regionach, gdzie lokalni regulatorzy zaczęli egzekwować EAA. Strona dokumentacji systemu projektowego, która na początku 2022 r. miała ok. 4 000 odsłon miesięcznie, w połowie 2025 r. osiągała ok. 38 000 miesięcznych odsłon. Powstała praktyka; przeżyje jej kadencję.

Co mówi projektantom z mniejszych organizacji

Do 2025 r. Maya rzadziej dyżurowała na własnym produkcie, a częściej prowadziła działalność doradczą dla projektantów w firmach o rząd wielkości mniejszych — dwudziestoosobowych zespołów produktowych, pięćdziesięcioosobowych zespołów produktowych, organizacji takiego rozmiaru, gdzie jeden projektant musi być domyślnym liderem dostępności. Miała niewielki zestaw rzeczy, które mówiła na każdym spotkaniu przy kawie. Warto je wymienić.

Jeden. Potok skarg jest dźwignią. Nie potrzebujesz miliona użytkowników, żeby mieć potok skarg; potrzebujesz skrzynki odbiorczej Supportu i gotowości do jej czytania. Wydrukuj zgłoszenia. Włóż do segregatora. Weź segregator na spotkanie. Segregator działa.

Dwa. Argumentacja finansowa ma trzy kolumny. Ryzyko prawne, szansa rynkowa i wolumen skarg. Nie potrzebujesz dokładnych liczb w żadnej z trzech. Potrzebujesz, żeby ta sama osoba zobaczyła wszystkie trzy w jednym miejscu, bo żadna pojedyncza kolumna nie przekona sali.

Trzy. Fundamenty przed komponentami, komponenty przed wzorcami. Zespół, który zaczyna od przepisywania komponentów, spędzi rok na ich robieniu i skończy z piękną biblioteką komponentów na niesemantycznej palecie kolorów, a następny projektant przepisze wszystko od nowa.

Cztery. Negocjuj weto. Największa pojedyncza dźwignia w firmie z wieloma zespołami to możliwość powiedzenia „ten nowy komponent nie jest wydawany, dopóki nie przejdzie listy kontrolnej“. Weto zastosowane dwa razy w ciągu dwóch lat jest wystarczające. To wiarygodność weta, a nie jego częstotliwość, robi robotę.

Pięć. Zatrudnij badacza z doświadczeniem w rekrutacji ze środowisk osób z niepełnosprawnościami. Pozycja w budżecie programu Mayi, której broniłaby najzacieklej, to miejsce badacza. Bez osób z niepełnosprawnościami w pętli praca to teatr.

Sześć. Zegar na komponentach legacy jest niepodważalny. Migracje bez zegarów nie dochodzą do skutku. Migracje z zegarami dochodzą do skutku w tempie, na jakie zegar pozwala.

Siedem. Weź zwycięstwo i odejdź. Maya opuściła program w Q1 2025 r. i przeszła do roli doradczej. Założycielka programu dostępności jest złą osobą do prowadzenia go w trybie stabilnym. Zadanie założycielki polega na tym, by program zaistniał. Zadanie w trybie stabilnym polega na tym, by być nudnym. Inne usposobienie; inna osoba.

Uwaga o segregatorze

Maya nadal ma ten segregator. Czasem wyciąga go na konferencjach, gdy starszy projektant pyta ją — zazwyczaj z zakłopotaniem, często po panelu — co zrobić z własną zaległością czterdziestu jeden otwartych zgłoszeń. Segregator ma grubość ok. dwóch centymetrów. Na naklejce na okładce widnieje napis, wykonany sans-serifowym pismem odręcznym kupionym w sklepie z artykułami rękodzielniczymi w 2022 r.: „Dzień pierwszy“. Czterdzieści jeden zgłoszeń w nim jest już zamkniętych. Imiona i nazwiska osób, które je złożyły, są zakryte czarnym markerem. Nie pokazuje imion. Pokazuje strony i mówi: tak wygląda ta praca i tu się zaczyna.