Development to nie wszystko, czyli fokus na UXa

Popularny pogląd, z którym spotykam się na co dzień w swojej praktyce zawodowej związanej z dostępnością cyfrową mówi o tym, że odpowiedzialność za nią ponoszą głównie osoby zajmujące się programowaniem front-endu. To częściowo prawda. Wszakże to spod ich rąk wychodzi kod, który potem renderowany jest przez przeglądarki. Jeśli skupią się na wykorzystaniu standardów, zastanowią się nad tym, jakie odpowiednie znaczniki HTML dobrać i jak to wszystko spiąć JavaScriptem i CSS — to może być całkiem dobrze i efekt końcowy okaże się w miarę dostępny.
Kiedy coś się nie udaje, uderzamy do osób developerskich i prosimy o więcej uwagi i dokładności. Spędzamy długie godziny na spotkaniach, zastanawiając się nad tym, jak coś inaczej zakodować w świetle ograniczeń, które naciskają na nas z lewa i prawa.
A ja dzisiaj trochę włożę kijek w mrowisko lub, mówiąc mniej eufemicznie, trochę nakupkam we własne gniazdko. Dlaczego? Ano dlatego, że…

Początkiem dostępnościowej układanki jest UX

Bez obaw, osoby braterskie i siostrzańskie — wciąż się lubimy. UX to mój sweet spot i obszar szczególnej uwagi. Ale nie da się ukryć, że widuję rozwiązania, które, zaprojektowane źle od początku, po prostu trudno zaimplementować z poszanowaniem dostępności. Jednym z problemów jest absolutna fiksacja na komponentach frameworków, które same z siebie są brutalnie, wstrętnie niedostępne. Wbrew pozorom Angular, React czy Flutter mogą posłużyć do stworzenia rozwiązań, które obronią WCAG, ale potrzeba do tego wysiłku. I o ile podjąć go mogą osoby zajmujące się programowaniem, to od UXów często zależy, czy wstawią gdzieś komponent, który nie jest dostępny out of the box.

Boli mnie w liście

Przykład? Rozwijane listy wyboru. W HTML dostępne mamy całkiem dobrze działające elementy <select>, z którymi za pomocą CSS i JavaScriptu można zrobić naprawdę wiele. Ja jednak napotykam co i rusz “kombosy” ugotowane z zupy źle pozagnieżdżanych <div> okraszonych sowicie dodatkiem ARIA. Żeby chociaż, zresztą… Często nieokraszone są niczym. I użyte tylko dlatego, że “ładnie wyglądają”, bo tak naprawdę nie przyspieszają ani interakcji użytkowników, ani nie ułatwiają praktyk programistycznych. Często po zmianie takich elementów na prosty, semantyczny HTML ostylowany wedle potrzeb estetycznych interfejs zachowuje się o wiele lepiej. Nie szwankuje klawiaturowa nawigacja, nie sypią się czytniki ekranowe. Wszystko gra. A zatem, wystarczy przytemperować chucie projektowe i zastanowić się chwilę. Czy fakt, że w organizacji ktoś zadecydował o tym, że “używamy Angulara z biblioteką X” to na pewno dobry wybór? Może coś, co projektujemy, jest na tyle proste (albo na tyle skomplikowane!), że warto jednak uczynić powrót do korzeni i podmienić elementy, dajmy na to, formularza, na proste kontrolki HTML? Warto się nad tym zastanowić.

O nieprzemyślanej podróży

Dostępność to nie tylko WCAG (o tym będzie jeszcze dużo), ale organiczne doświadczenie. Oznacza to, że jeśli nie klei się podróż użytkownika, to i dobra dostępność interfejsu nie pomoże. Co Ci po formularzu, który odptaszkujesz na liście WCAG, jeśli siedzi on we flow bez sensu? Tutaj kłania się umiejętność zaplanowania architektury procesu, a potem takiego ubrania go w ciuszki interfejsu, żeby wszystko stanowiło solidną podstawę do zaimplementowania zasad dostępności. Na przykład, mechanizmy wielokrotnego uwierzytelniania polegają często na kilkukrotnym skakaniu z urządzenia na urządzenie i z kontekstu w kontekst. Na przykład ze strony internetowej do SMS, a potem do maila. Albo w klienta uwierzytelniania jak freeOTP czy coś od Gugla albo Microsoftu. Tymczasem to można często uprościć, tylko wystarczy się zastanowić razem z kolegami i koleżankami z działów dev i bezpieczeństwa. Kiedy zaczniemy patrzeć na dostępnośc organicznie i holistycznie, czyli całościowo, odkryjemy, że wiele zaprojektowanych przez nas procesów nie ma w zasadzie prawa dostarczyć wspierającego, inkluzywnego doświadczenia.

Co zatem zrobić?

  1. Przyjrzyj się flow swoich aplikacji i postaraj się zidentyfikować i rozwiązać problemy związane z użytecznością podróży. W ten sposób zbudujesz bazę, na której (z odrobiną wysiłku) postawisz dostępne rozwiązanie.
  2. Zastanów się za każdym razem, kiedy projektujesz interakcje: jak można to uprościć? Zadaj sobie to pytanie. I niekoniecznie myśl wtedy nawet o wymaganiach dostępności, tylko użyteczności właśnie.

Bo jedno i drugie idzie w parze.


Komentarze

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *