WCAG.pl

Dzisiaj będzie inaczej niż zwykle, bo… przyjrzymy się dobrze zrobionej stronie. Tak, nie przywidziało Ci się, mój drogi Czytelniku: dobrze zrobionej stronie. Jeśli oczekiwałeś dużo zrzędzenia, wróć za miesiąc. Tymczasem ja przyjrzę się stronie WCAG.pl.

  • Nazwa strony nie jest przypadkowa i nawiązuje do nazwy standardu określającego wytyczne mające na celu tworzenie stron przystosowanych dla osób z niepełnosprawnością. To oczywiście sprawia, że będę się tego czepiał bardziej niż zwykle.
  • Mimo że strona nazywa się WCAG, domyślnie ostylowanie ma problemy z kontrastem, na które wskazuje nawet WAVE. Owszem, są osobne wersje z wysokim kontrastem, ale prawdę mówiąc wydaje mi się, że podstawowa wersja również powinna spełniać odpowiednie normy odnośnie kontrastu, co jest sztuką trudną, ale nie niemożliwą (np. nowa skórka CKEditora daje radę). Wówczas wersje z wysokim kontrastem nie byłyby potrzebne.
  • Inną kwestią związaną z wysokim kontrastem jest fakt, że po włączeniu tego trybu… znikają animacje. I w sumie dobrze, bo są ciut irytujące. Niemniej nie bardzo widzę związek pomiędzy tymi dwiema rzeczami.
  • W prawym górnym rogu strony mamy przyciski do przełączania pomiędzy różnymi rodzajami kontrastu. Szkoda, że nie ma żadnego tooltipu dla nich. I nie myślę tutaj o prostym [title], bo akurat na takiej stronie aż nie przystoi zadbać tylko o „myszkowych”. Wypada dodać jakieś ładne [role=tooltip] czy też pokazywać etykietę z [aria-label] przy sfocuowaniu z poziomu klawiatury.
  • Z ciekawości sprawdziłem, jak te wszystkie przyciski czyta czytnik ekranowy… a tu zonk. Te 8 (osiem!!!) elementów interaktywnych jest ukrytych przed czytnikami ekranowymi!!! Jednak fakt, że są to elementy interaktywne sprawia, że focus i tak jest przez nie łapany. A to oznacza, że użytkownik czytnika ekranowego nie bardzo ma pojęcie, co się dzieje – zwłaszcza jeśli do nawigacji używa Tab. Bardzo, bardzo słabo.
  • Jak już jesteśmy przy czytniku ekranowym, częste zmiany treści w sliderze są równie słabe. Prawdę mówiąc nie bardzo mi się podoba, że co 5 sekund czytana jest mi zawartość jednego z dwóch slajdów, na zmianę. W idealnym świecie treść byłaby zaprezentowana jako normalna lista albo przynajmniej czas pomiędzy zmianą slajdów mógłby wynosić sensowne 30 lub więcej sekund.
  • Bardzo fajne w menu jest to, że podmenu pokazują się także przy focusie z poziomu klawiatury – spory plus. Szkoda tylko, że wystarczy najechać na rozwinięte z poziomu klawiatury podmenu myszką, a następnie zjechać nią i podmenu się zamyka. Klawiaturowy focus powinien mieć wyższy priorytet w tym wypadku moim zdaniem.
  • Inna rzecz, że w przypadku podmenu ograniczenie klikalnego pola do samego linku jest niedobrym rozwiązaniem. Sprawić to może problemy zwłaszcza na ekranach dotykowych.
  • Muszę pochwalić za style dla focusu klawiaturowego – są bardzo wyraźne. Zaimplementowane są także bardzo dobre skiplinki.
  • Za to sama obsługa klawiaturą jest zaimplementowana błędnie. Przyciski, w przeciwieństwie do linków, można aktywować także naciskając Spację. W przypadku przycisków na tej stronie (zwłaszcza w sekcji FAQ i w przyciskach od kontrastu i czcionki w prawym górnym rogu strony) działa tylko Enter, co przeczy np. instrukcjom, jakie czytają czytniki ekranowe dla przycisków (czyli elementom z [role=button]).
  • I na sam koniec: główny banner strony głosi hasło intetnetu bez barier.
  • Natomiast gdy zerkam w kod, to rzuca w oczy mi się przede wszystkim to:

    <span class="fa fa-search"></span>

    Akurat dzisiaj napisałem słów kilka o ikonkach, w których pokrótce tłumaczę, czemu to nie najlepszy pomysł.

  • Jeszcze jedna rzecz mnie w kodzie drażni: za dużo [aria-label] podczas, gdy mogłyby być to nagłówki – zwłaszcza, że hierarchia treści jest uboga. Nie zapominajmy, że z nagłówków skorzystają wszyscy (a jak się dodatkowo użyje ich wraz z [aria-labelledby], to i zastąpią w pełni [aria-label]), a atrybuty ARIA-owe są wyraźnie kierowane dla użytkowników czytników ekranowych.
  • Pokusiłbym się o oznaczenie referencji przy użyciu blockquote > cite (czy wręcz figure > blockquote) – wszak to cytowanie wypowiedzi klientów.

Bardzo fajnie trafić na stronę, która wyraźnie stara się dbać o dostępność i robi to nawet dobrze. Niemniej wciąż są pewne obszary, które można dodatkowo dopracować. Natomiast sam pomysł na założenie firmy tworzącej dostępne strony WWW… cóż, ktoś mi ukradł pomysł na biznes!

5 komentarzy do “WCAG.pl”

  1. Ja znalazłem kolejny błąd w dostępności. Nie na stronie głównej, ale wystarczy przejść do strony blog i tam przyjrzeć się artykułom. Każdy z nich ma zdjęcie tylko, że jest ono wsadzone w link przez co staje się elementem interaktywnym, a więc alt nie powinien opisywać zdjęcia, tak jak ma to właśnie miejsce na tej stronie, czyli: alt=”Logotyp Światowego Dnia Świadomości Dostępności a obok słowo Opole” a powinno wyglądać mniej więcej tak: alt=”Przejdź to artykułu Konferencja dotycząca dostępności stron internetowych w Opolu”

    1. Hmmm, tutaj w sumie jest ciekawsza sytuacja, bo oprócz [alt] obrazka mamy też [title] samego linku, przez co całość jest czytana jako „Logotyp […], Konferencja […]”. W tym wypadku informacja o logotypie jest po prostu zbędna.

  2. A co by było w sytuacji gdyby ten obrazek nie był osadzony w linku i zapomnijmy też o title, taka prosta budowa artykułu jak na większości stron, czyli:

    h2 Tytuł artykułu /h2
    img=’zdjecie.png’ alt=”
    p Część treści artykułu… /p

    to wtedy alt zostawiamy pusty, ponieważ jest już tytuł w nagłówku h2 i zdjęcie pełni tutaj rolę bardziej ozdobnika dla tego artykuły, czy mimo to i tak opisujemy zdjęcie w alt?

    1. Zależy, czy to faktycznie jest ozdobnik, czy jednak coś wnosi do treści. W wypadku takiego logo zdarzenia, o którym piszemy, można jednak uznać, że nie jest to tylko ozdobnik. Wówczas opis takiego logo w [alt] jak najbardziej pasuje.

Skomentuj Comandeer Anuluj pisanie odpowiedzi

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

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.