Próba obejmuje 50 plików Figma z 28 zespołów produktowych z sektorów SaaS, handlu detalicznego, fintech, sektora publicznego i edtech. Uzyskaliśmy dostęp tylko do odczytu na zasadzie nieprzypisywania autorstwa: nic w tym artykule nie identyfikuje marki, zespołu ani designera. Pliki wybrano tak, aby odzwierciedlały to, co inżynier faktycznie otrzymuje przy przekazaniu — nie dopracowane studium przypadku z portfolio — dlatego poprosiliśmy każdy zespół o udostępnienie pliku, z którego dostarczono ostatnią funkcję, a nie pliku, z którego są najbardziej dumni. Dwanaście plików pochodziło od zespołów z dedykowaną praktyką systemu projektowania; pozostałe 38 to pliki na poziomie produktu, które importowały bibliotekę systemu lub tworzyły komponenty lokalnie.

Przeglądaliśmy każdy plik pod kątem pięciu właściwości dostępności: projektu stanu fokusa na każdym interaktywnym komponencie, adnotacji tekstu alternatywnego na każdym obrazie lub ikonie niebędącej dekoracją, dokumentacji kolejności czytania w całym układzie, obsługi preferencji ruchu dla każdego animowanego lub przechodzącego elementu oraz specyfikacji kontrastu w trybie ciemnym dla każdego komponentu dostarczanego zarówno w jasnym, jak i ciemnym motywie. Dla każdej właściwości plik był oceniany jako „udokumentowany“ tylko wtedy, gdy kompetentny inżynier mógłby zaimplementować projekt bez samodzielnego wymyślania odpowiedzi. „Wspomniane w notatce samoprzylepnej“ nie liczyło się. „Kolor szesnastkowy podany w jednym stanie hover“ nie liczyło się. Poprzeczka była: czy decyzja jest w pliku w formie, na której inżynier może działać bez pytania?

Główne ustalenie jest takie, że przy tej poprzeczce, przekazanie pomija decyzje dotyczące dostępności znacznie częściej niż je zawiera. Projekt stanu fokusa pojawił się na ok. 40% interaktywnych komponentów w całym korpusie. Adnotacje tekstu alternatywnego pojawiły się na ok. 22% obrazów, które ich potrzebowały. Kolejność czytania była wyraźnie udokumentowana w 16% plików. Preferencje ruchu zostały uwzględnione w 10%. Kontrast w trybie ciemnym — dla 31 plików dostarczanych w obu motywach — był określony dla 30% komponentów. Luka nie dotyczy żadnej konkretnej właściwości. Dotyczy wszystkich pięciu, a inżynier musi je wypełniać jednym osądem na raz.

Spośród ok. 1800 interaktywnych komponentów objętych audytem w całym korpusie — przycisków, łączy, pól wejściowych, pól wyboru, przełączników, zakładek, list rozwijanych, elementów menu, kart-jako-przycisków, wszystkiego, co użytkownik klawiatury może osiągnąć — ok. 40% zawierało zaprojektowany stan fokusa. Pozostałe 60% zawierało stan domyślny, aktywny i hover, a następnie się zatrzymywało. Inżynier budujący komponent wybiera kontur fokusa podczas implementacji, zazwyczaj kopiując domyślny styl przeglądarki, zazwyczaj bez sprawdzenia, czy domyślny ma kontrast 3:1 względem powierzchni komponentu zarówno w jasnym, jak i ciemnym motywie, w których plik jest dostarczany.

Jak wygląda „brak projektu stanu fokusa“ w praktyce? Wygląda jak komponent przycisku z trzema wariantami na kanwie — domyślny, hover, naciśnięty — i bez czwartego wariantu. Wygląda jak pole wejściowe ze stylizowaną ramką i bez drugiego stylu ramki dla stanu fokusa. Wygląda jak prymityw pola wyboru z pierścieniem fokusa tylko w wariancie domyślnym, a inżynier musi zgadywać, czy ten sam pierścień powinien pojawiać się w wariancie zaznaczonym lub nieokreślonym. Wzorzec powtarza się w komponentach, w zespołach, w sektorach. Jest to jedyna największa luka dostępności w korpusie i jednocześnie ta najłatwiejsza do zaprojektowania.

Zespoły, które dobrze projektowały stany fokusa, miały jedną z dwóch rzeczy. Pierwsza to wyraźna reguła systemu projektowania: każdy interaktywny komponent musi zawierać wariant, którego nazwa zaczyna się od focus-, a komponent nie jest wydawany do biblioteki, dopóki ten wariant nie istnieje. Drugą była właściwość komponentu Figma o nazwie state z fokusem, focus-visible i focus-within jako wartościami wyliczanymi, dzięki czemu przeglądarka komponentów pliku wizualnie eksponuje brakujące warianty. Zespoły bez jednego z tych dwóch rusztowań pozostawiały stan fokusa inżynierowi mniej więcej dziewięć razy na dziesięć.

Spośród plików w korpusie zawierających obrazy treści — zdjęcia produktów, ilustracje hero, przyciski z samymi ikonami, figury infograficzne — 78% nie miało adnotacji tekstu alternatywnego na warstwach obrazów. Obraz był umieszczony, przeskalowany i ostylowany; tekstowy odpowiednik, który inżynier miał wstawić do renderowanego <img>, nie był w pliku. Osiem z 50 plików miało tekst alternatywny na niektórych obrazach, ale nie wszystkich — zazwyczaj z adnotacją na ilustracji hero i pustymi obrazami w treści. Trzy pliki miały tekst alternatywny na każdym obrazie. Inżynier, w 47 z 50 plików, był zobowiązany do wymyślenia tekstu alternatywnego — a w praktyce często dziedziczył go z nazwy pliku, figcaption lub dowolnego ciągu pasującego do rytmu wizualnego.

Luka ma strukturalne podłoże w prymitywie obrazu Figma. Nie istnieje natywna właściwość „alt“ w wypełnieniu obrazu ani w warstwie obrazu; tekst alternatywny musi być przenoszony jako nazwa warstwy, komentarz, notatka samoprzylepna, oddzielny dokument specyfikacji lub pole dodane przez wtyczkę. Żadne z nich nie przechodzi przez panel inspekcji domyślnie, więc inżynier odczytujący plik w widoku inspekcji nie widzi tekstu alternatywnego nawet jeśli designer go gdzieś napisał. Zespoły, które konsekwentnie zamykały tę lukę, stosowały jedno z trzech obejść: pola tekstu alternatywnego zarządzane przez wtyczkę na każdym wariancie obrazu, udokumentowaną konwencję, że nazwa warstwy jest tekstem alternatywnym, lub osobny arkusz kalkulacyjny tekstu alternatywnego z kluczem na podstawie nazw plików obrazów, dostarczany wraz z plikiem.

Przyciski z samymi ikonami były subporażką wewnątrz tego trybu awarii. W 41 z 50 plików przyciski z ikonami — lupka wyszukiwania, hamburger menu, X zamknięcia, strzałka udostępniania — nie miały adnotacji dostępnej nazwy, pozostawiając inżynierowi napisanie aria-label=“Szukaj” na podstawie kontekstu wizualnego bez potwierdzenia, że „Szukaj“ to właściwe słowo w głosie marki (czy to „Znajdź“? czy „Wyszukaj“? czy nic, bo przycisk otwiera panel oznaczony w innym miejscu?). Nazewnictwo ikon to dokładnie taki rodzaj decyzji dotyczącej mikrotekstu, który korzysta z pióra designera, i dokładnie taki, który przekazanie traci.

Trzy pozostałe właściwości miały odrębne kształty awarii. Kolejność czytania — kolejność, w której czytnik ekranu narruje stronę, która we współczesnych responsywnych układach nie jest już gwarantowana zgodna z wizualną kolejnością od góry do dołu — była udokumentowana w 16% plików. Dokumentacja, tam gdzie istniała, zazwyczaj stanowiła numerowaną nakładkę na kanwie (1, 2, 3 …) dodaną za pomocą wtyczki. Pozostałe 84% pozostawiało inżynierowi mapowanie kolejności czytania na podstawie kolejności DOM, którą się zdarzało pisać, która w układzie CSS Grid z jawnym umieszczaniem w wierszach i kolumnach może się różnić od układu wizualnego o całą kolumnę.

Preferencje ruchu wypadły najgorzej. Dziesięć procent plików w ogóle wspominało prefers-reduced-motion. Pozostałe 90% określało animacje i przejścia — wejścia modalu, rozwijanie akordeonu, przesuwanie powiadomień, przejścia stron — bez określania, co ten sam komponent powinien robić, gdy użytkownik ma włączone zmniejszone animacje. Inżynier albo budował przypadek zmniejszonego ruchu podczas implementacji (często bez odniesienia wizualnego), albo dostarczał tę samą animację wszystkim, co jest wartością domyślną i narusza kryterium 2.3.3 Animacja z interakcji dla użytkowników, którzy ustawili tę preferencję.

Kontrast w trybie ciemnym był określony dla 30% komponentów w plikach dostarczanych w obu motywach. Pozostałe 70% określało kontrast jasnego motywu — zazwyczaj z adnotacją Stark lub sprawdzarki kontrastu w pliku — a następnie wydawało ciemny motyw z odwróconą paletą kolorów, pozostawiając inżynierowi sprawdzenie, czy odwrócona para nadal osiąga 4,5:1 dla tekstu głównego i 3:1 dla komponentów interfejsu. W ok. jednej piątej z 31 plików z podwójnym motywem przynajmniej jeden komponent spadał poniżej progu kontrastu w ciemnym motywie, ponieważ ciemna powierzchnia i ciemny tekst były oba dostrojone do matematyki kontrastu jasnego motywu, a nie ciemnego.

Dwie wtyczki, które najczęściej pojawiają się w korpusie, to Stark i Able. Obie są dojrzałe, obie cieszą się dobrą opinią, a obie oferują funkcje zamykające kilka z udokumentowanych powyżej luk. Stark dodaje sprawdzarkę kontrastu, nakładkę kolejności fokusa, podgląd zmniejszonego ruchu i pole adnotacji tekstu alternatywnego na warstwach obrazów. Able dodaje inspektor kontrastu kolorów, nakładkę symulacji widzenia i sprawdzarkę obszarów dotyku. Każda z tych wtyczek, stosowana konsekwentnie w całym pliku, wywindowałaby ten plik z dolnego kwartyla korpusu.

„Stosowana konsekwentnie“ to kluczowe wyrażenie. Spośród 50 plików Stark był zainstalowany i wyraźnie używany w 18, a Able w 11. W plikach, w których wtyczka była używana, zazwyczaj stosowano ją do komponentu hero i głównego CTA — komponentów z największym prawdopodobieństwem widocznych na kanwie, gdy designer otwierał wtyczkę — i tylko sporadycznie gdzie indziej. Sześć plików używało Stark do globalnego przeglądu; jeden używał Able do globalnego przeglądu. Wzorzec jest następujący: wtyczki istnieją, designerzy o nich wiedzą, są stosowane do wyrywkowych kontroli, a kontrola zatrzymuje się na komponentach, na które designer patrzył, gdy wtyczka była otwarta.

Dwa zespoły, które zamknęły audyt pod względem użycia wtyczek, robiły jedną rzecz inaczej: uruchamiały funkcję audytu wtyczki na każdej stronie pliku jako krok bramki wydania przed udostępnieniem pliku inżynierii. Audyt był uruchamiany w pliku, generował raport, a raport musiał być pusty (lub z udokumentowanymi wyjątkami) zanim plik przeszedł z „w projektowaniu“ do „gotowy do inżynierii“. To wtyczka jako przepływ pracy, a nie wtyczka jako wyrywkowa kontrola — i to różnica między pokryciem 80% a 20% w naszej próbie.

Audyt generuje listę kontrolną i kontrakt. Lista kontrolna to to, co designer powinien móc odfajkować przed udostępnieniem pliku inżynierii. Kontrakt to kształt tokenów projektowych towarzyszących plikowi, dzięki czemu inżynier odwzorowuje zmienne Figma na właściwości niestandardowe CSS bez wymyślania wartości pośrednich. Obie są celowo krótkie: każda pozycja na liście kontrolnej to właściwość zmierzona przez audyt, a każdy token w kontrakcie to wartość, która zamknęła lukę w korpusie.

Audyt 50 plików kończy się prostym ustaleniem. Przekazanie projektu zawodzi dostępność nie dlatego, że designerom na niej nie zależy, i nie dlatego, że inżynierom na niej nie zależy, ale dlatego, że plik — plik Figma, jedyny artefakt, który każda ze stron czyta — nie nosi decyzji dotyczących dostępności jako właściwości pierwszej klasy. Stany fokusa, tekst alternatywny, kolejność czytania, preferencje ruchu, kontrast w trybie ciemnym: każda z tych właściwości to decyzja projektowa, każda należy do pliku, każda jest obecnie gdzieś indziej. W notatce samoprzylepnej, w wiadomości Slack, w osobnym arkuszu kalkulacyjnym, w głowie inżyniera o 16:00 w piątek.

Rozwiązaniem nie jest heroiczny designer ani heroiczny inżynier. To zmiana przepływu pracy na poziomie zespołu: każdy interaktywny komponent zawiera wariant fokusa, każdy obraz nosi tekst alternatywny w jednym miejscu zarządzanym przez wtyczkę, kolejność czytania jest nakładana na każdej nietrywialnej stronie, animacje określają swój odpowiednik ze zmniejszonym ruchem, kontrast w trybie ciemnym jest sprawdzany osobno od jasnego, a plik jest dostarczany wraz z kontraktem tokenów, który nazywa każdą zmienną, do której implementacja się powiązuje. Żaden z tych kroków nie jest nowy, żaden nie wymaga narzędzia, którego jeszcze nie mamy, a każdy zespół, który wdroży je jako kroki bramki wydania, zamknie większość zmierzonych przez nas luk w jednym cyklu wydawniczym.

Głębsze ustalenie jest takie, że zespoły z systemem projektowania już to robią mniej więcej dwukrotnie częściej niż zespoły produktowe. Dźwignia, jaką zapewniają zespoły z systemem projektowania, to dokładnie ta dźwignia, którą narzuca dyscyplina budowania systemu: komponenty są nazwane, właściwości są wyliczone, warianty są widoczne, tokeny są jawne. Przeniesienie tej samej dyscypliny do plików na poziomie produktu — nawet bez pełnego systemu projektowania poniżej — zamyka większość luki przekazania. To już nie jest problem narzędziowy. To wybór przepływu pracy.