Dlaczego nie piszemy stron zgodnych z wytycznymi WCAG? Czy jest to kwestia czasochłonności? Braku wiedzy? A może Twojej wypłaty? Lenistwa? Te i pewnie stos innych powodów przyczyniają się do wykluczenia cyfrowego rzeszy niewinnych ludzi. A większość z nas, programistów, przykłada do tego swoje mniejsze lub większe cegiełki. Ach, ta nieszczęsna dostępność.
W tym artykule chcę Ci udowodnić, że odrobina zaangażowania wystarczy, aby namacalnie ułatwić komuś życie. Odrobina. Nie potrzebujesz do tego specjalnej wiedzy, ani umiejętności. Wystarczy ziarno empatii.
Na początku zachęcam Ciebie do zapoznania się z podstawowymi pojęciami związanymi z a11y. A teraz do konkretów.
Oto 3 działania, niechlubnie powszechne, które mordują dostępny Internet.
1. Divlandia
Nie umiemy w semantykę. Albo umiemy, ale lenistwo skutecznie zapobiega wykorzystaniu owej wiedzy w praktyce. Tymczasem moglibyśmy te nasze prymitywne divy zamienić na szereg samoopisujących się tagów.
Tagi nie-semantyczne to np. div, span
Tagi semantyczne to np. body, header, nav, main, article, section, figure, figcaption, footer, aside, cite, blockquote, abbr, h1–h6, kbd
Tagi semantyczne ułatwiają przeglądanie strony za pomocą czytników. Poza tym umożliwiają nawigację po stronie za pomocą klawiatury. W jaki sposób?
Generalnie HTML posiada 6 elementów, które domyślnie posiadają stan focus: <a>, <link>, <button>, <input>, <select>, <textarea>. Tagi typu <div> oraz <span> mają domyślnie ustawiony tabindex="-1". To oznacza, że nie można nadać im stanu focus. To z kolei oznacza, że nie ma ich na liście elementów dostępnych za pomocą klawisza TAB. W konsekwencji dla czytników są one po prostu niewidoczne. Pytanie, jak uratować sytuację? Jakiekolwiek manewry atrybutem tabindex należy uważać jako ostatnią deskę ratunku. W pierwszej kolejności po prostu myśl o semantyce.
Nagłówki
Nagłówki zasługują na osobną uwagę. Korzystasz z tagów h1, h2, …, prawda? A czy pilnujesz ich struktury, kolejności? Niestety, często gęsto korzystamy z tych nagłówków, których rozmiar pasuje nam do aktualnego pomysłu na stronę. Wybieramy to, co ładnie wygląda. A nie to, co powinno się znajdować wg zasad semantyki. Wyobraź sobie taką sytuację…
Czytnik, jakiekolwiek technologie przeczytają strukturę w sposób taki, w jaki ją napisałeś, nie analizując tego, czy jest ona logiczna. Ostatecznie użytkownik będzie totalnie zagubiony. Albo zniechęcony zamknie stronę, albo desperacko będzie błądził po systemie. Jednak próba dotarcia do interesującej treści w takiej konfiguracji wydaje się być niezłą zagadką, której nie wstydziłby się sam Sherlock Holmes.
W przypadku prac komercyjnych oczywistym rozwiązaniem jest zmiana guidelina. Rozumiem jednak, że czasami pewne reguły stylistyczne są narzucone przez osoby trzecie. Grafików, klienta blabla. Wtedy być może dobrą praktyką okaże się poniższy przykład – wydzielenie warstwy styli od semantyki.
2. Dyskusyjny outline
Ten temat poruszałam już na blogu w kontekście przykładu Angular + Material Design.
Otóż na własnej skórze doświadczyłam sytuację, kiedy tester zgłosił mi błąd stylów przycisku w stanie focus. Nie podobały mu się. Stwierdził, że trzeba je usunąć, a sam przycisk nie powinien się niczym odznaczać w stanie focus.
A tak być nie może! Element w stanie focus – aktualnie aktywny, gotowy do interakcji element na stronie – powinien być wyraźnie oznaczony! Wyobraź sobie osobę, która ze względów na niepełnosprawność motoryczną nie może korzystać z myszki. Skąd ona ma wiedzieć, w którym miejscu na stronie się znajduje, jeśli tego NIE WIDAĆ!? Możliwość korzystania z aplikacji za pomocą klawiatury to podstawowa zasada dostępności! Element w stanie focus musi odznaczać się na interfejsie aplikacji.
Domyślne style stanu focus różnią się na różnych przeglądarkach. Oczywiście jest to źródłem wielu dyskusji na styku zespołów grafików, programistów i testerów. Jednak, jeśli tylko się chce – można wypracować wizję outlina eleganckiego, spójnego z identyfikacją wizualną produktu.
Da się? Da się.
3. Elementy graficzne.
Chodzi mi oczywiście o uzupełnianie atrybutu alt w tagu <img>. Jednak uwaga – zasady wypełniania jego treści nie są takie pojedyncze…
Wersja podstawowa, dla leniwych, brzmi – zawsze uzupełniaj atrybut alt odpowiednim opisem, z wyjątkiem elementów dekoracyjnych.
Wersja dla zaawansowanych wygląda w ten sposób:
Ściągę możecie swobodnie pobierać i drukować. Znajdziecie ją też na moim blogu we wpisie, w którym szczegółowo tłumaczę zasady uzupełniania atrybutu alt.
Znacie jeszcze inne dobre praktyki tworzenia dostępnych aplikacji, które nie zabierają wiele czasu i energii?
P.S. Drugą część serii o praktykach mordujących dostępny internet znajdziesz TUTAJ!
Źródła: bitsofco, hacks.mozilla, dev.to,
