Jak design systemy wspierają dostępność

Dwa światy nie takie różne

Co ma wspólnego budowa Design Systemu (DS) z zapewnieniem dostępności? Jak design systemy mogą nas wesprzeć w tworzeniu dostępnych interfejsów?

O design systemach pisała już nie jedna osoba, więc nie będę rozpisywał się o jego zaletach. Jeśli jednak chcecie się dowiedzieć czegoś więcej polecam post o design systemie. Podobnie jest z tematem dostępności. Jednak w tej wypowiedzi chciałbym odpowiedzieć Wam na te 2 pytania, gdyż okazuje się, że budowa DS idzie w parze z zapewnianiem dostępności i te dwa tematy można ze sobą łatwo połączyć.

Zapewnienie dostępność dzięki zasadzie spójności

Zacznijmy od szybkiego podsumowania procesu projektowania interfejsów w produktach cyfrowych. Można go ująć w kilku krokach:

• Analiza konkurencji, potrzeb, założeń i celów
• Poznanie potrzeb użytkowników i zbudowanie person
• Stworzenie koncepcji produktu
• Ścieżki użytkownika
• Architektura informacji
• Makietowanie
• Badania z użytkownikami
• Projektowanie graficzne

Dla UX to żadna nowość, ale…

Problem jednak pojawia się, gdy klient podczas fazy projektowania lub(i) wytwarzania produktu cyfrowego postanawia coś zmienić. Obiera trochę inne podejście do produktu, chce zmienić komponent, rozbudować apkę o dodatkową podstronę, wprowadzić dodatkowy landing page lub inną nieprzewidzianą przez UX-ów zmianę.

Przykładem jest sytuacja, gdy jeden z UX-ów zmienia design lub jego część w zgodzie z poprzednimi ustaleniami, a drugi UX po chwilowym „zrywie klienta”, na szybko dodaje zmiany w UI. Obaj UX-i pracują bez wspólnego wzorca, co doprowadza do tworzenia wielu anty patternów i czasami "wymyślania koła na nowo".

Brak spójności w interfejsie na stronie www lub w aplikacji może implikować pojawienie się wielu niejednoznaczności, a co za tym idzie pojawienie się błędów dostępności wykrytych w audycie.

Ma to szczególne znaczenie, gdy na różnych podstronach lub miejscach w aplikacji (teoretycznie tak samo wyglądających), znajdujemy w kilka podobnych, jednak nieco różniących się od siebie błędów dostępności. Na przykład istnienie dwóch różnych formularzy kontaktowych, kilku różnych błędów związanych z kontrastem lub niespójnego umiejscowienia elementów UI na kilku stronach.

Ponieważ jedną z cech dobrego DS jest jego spójność, ma to niebagatelny wpływ na dostępność, a mianowicie na pryncypium postrzegalności (Perceivable) chociażby wymaganie 3.2.4 Spójna identyfikacja (Consistent Identification).

W DS stosuje się zasadę spójności do całego systemu komponentów interfejsowych, w związku z tym zapewnienie dostępności w jednym z template-ów czy organizmów design systemu, poprzez spójność i prace na jednym wzorcu, pozwala na zapewnienie dostępności też tam, gdzie wybrany komponent będzie re-używany – najczęściej w wielu miejscach aplikacji czy strony.

Zapewnienie dostępności dzięki wczesnej ewaluacji

Praca z dobrze zbudowanym DS pozwala na spełnienie także kilku wymagań WCAG 2.2 na poziomie potrójnego A (AAA), które de facto można już częściowo spełnić bez pisania ani jednej linijki kodu, już na etapie projektowania UI.

Spójrzmy na poniższą listę wymagań WCAG.

• 1.4.1: Use of Color
• 1.4.3: Contrast (Minimum) (AA)
• 1.4.6: Contrast (Enhanced) (AAA)
• 1.4.11: Non-text Contrast (AA)
• 2.3.3 Animations from Interaction
• 2.4.7: Focus Visible (AA)
• 2.4.11: Focus Appearance (Minimum) (AA)
• 2.4.12: Focus Appearance (Enhanced) (AAA)
• 2.5.5: Target Size (AAA)
• 2.5.8: Target Size (Minimum) (AA)

Powyższych 9 wymagań WCAG 2.2 odnosi się m.in. do designu. Jak wiemy na tym etapie projektowania aplikacji/strony ustalane są m.in. kolory, wielość przycisków, wygląd fokusu, typografia, ikony, animacje czy RWD. To na tym etapie kształtuje się całościowy wygląd naszej strony www lub aplikacji. Pamiętając o dostępności, projektowanie DS pozwoli nie tylko na spełnienie prawie 10% wymagań WCAG 2.2, ale dzięki wspomnianej re-używalności komponentów, będzie to miało odzwierciedlenie w całym produkcie i być może także w innych bazujących na DS. Dostępność zaczyna być skalowalna.

Oczywiście o ile programista czegoś nie spartoli po drodze, to testowanie powyższych wymagań WCAG w oparciu od DS jest czystą przyjemnością i de facto powinno być jedynie formalnością, gdyż wstępnych ewaluacji dostępności powinniśmy dokonać już na etapie testów UX z użytkownikami niepełnosprawnymi.

Zapewnianie dostępności jest tańsze przy użyciu DS

Weźmy następującą sytuację:

Mamy 2 grupy produktów cyfrowych A i B, niech każda z nich ma co najmniej 2 pod-produkty, powiedzmy aplikację webową i stronę internetową.

Grupa produktów A była projektowana przy użyciu DS, natomiast aplikacje z grupy B były projektowane osobno bez użycia DS.

Podczas testów dostępności w obu grupach projektów znaleziono błędy dostępności dotyczące interfejsu użytkownika, zarówno na stronie www jak i w aplikacji.

Błędom nadano priorytety i trafiają one do poprawy do dwóch UI designerów.

UI Designer 1 – poprawia błąd dostępności w aplikacji webowej z grupy A wprowadzając de facto zmiany do DS.

UI Designer 2 – także poprawia błąd dostępności w aplikacji webowej, po czym obie zmiany są odzwierciedlane przez programistów i oddane na testy.

Podczas re-testów okazuje się ze błędy interfejsu w produktach z grupy A zostały poprawione całkowicie, natomiast w grupie B w drugim produkcie (strona www) nadal istnieje błąd.

Ten naturalnie jest zwracany do poprawy i proces się powtarza, testy wydłużają, a właściciel produktu narzeka, że dostępność jest droga i opóźnia wdrożenie.

Za całą sytuację ciężko jest winić samego UX/UI designera, gdyż akurat nie on musi być autorem designu i nie musi znać pełnej zależności obu produktów albo zwyczajnie zapomniał o wprowadzeniu poprawki w drugim systemie. Nie chodzi w tym momencie o szukanie winnych, ale na fakt, że problem na pewno nie byłby tak odczuwalny, gdyby został tam wdrożony DS. Dzięki jednemu źródłu prawdy (z ang. SOT - source of true) jakim jest DS, programiści otrzymują jasną informację, gdzie jeszcze trzeba wdrożyć zmiany, co w przypadku wielu systemów opartych na tym samym designie bywa kluczowe.

Podsumowując

Wdrożenie design systemu przyniesie Ci korzyści nie tylko z istnienia jego kluczowych zalet, ale także w związku z dobrym wsparciem dla zapewnienia dostępności. Ze względu na koszty utrzymywania kilku designów, chęci wdrożenia dostępności czy optymalizacji procesów, wdrożenie DS systemu może okazać się nieodzowne.