Test wtyczki WordPress – One Click Accessibility

„Najszybsza wtyczka, która pomoże Ci zwiększyć dostępność Twojej witryny.” One Click Accessibility to darmowe narzędzie z repozytorium WordPressa. Ma dodawać szereg funkcji zwiększających dostępność i pozwalać na ich łatwe ustawianie bez specjalistycznej wiedzy.

Sprawdźmy, jak faktycznie działa i jakie funkcje związane z dostępnością oferuje.

Nie masz czasu czytać całości testu?

Przejdź od razu do Podsumowania.

Instalacja i ustawienia domyślne wtyczki.

Wtyczkę instalujemy w menu administracyjnym WordPressa. Jest dostępna w repozytorium i w dniu pisania tego tekstu zainstalowano ją ponad 80 tysięcy razy. Całkiem sporo, w końcu tytuł kusi: „Dostępność jednym kliknięciem”.

Instalacja przebiega bez problemu i wtyczka nie powoduje żadnych widocznych konfliktów. Wtyczka nie jest przetłumaczona na język polski. Na szczęście zadbano o możliwość nadania własnych etykiet przycisków w panelu administracyjnym. Wtyczkę można też kompletnie przetłumaczyć np. programem Poedit. Od razu po aktywowaniu wtyczki na front-endzie pojawia się z boku ikona z wózkiem inwalidzkim. Kliknięta, wysuwa panel z opcjami („toolbar”):

  • Increase Text — powiększa czcionkę.
  • Decrease Text — zmniejsza czcionkę witryny.
  • Grayscale — zmienia koolory witryny na odcienie szarości.
  • High Contrast — zmienia kolory witryny na czarne tło i jasne teksty.
  • Negative Contrast — zmienia kolory witryny na czarne tło i jasne teksty (innego koloru).
  • Light Background — zmienia kolory witryny na białe tło i czarne teksty.
  • Links Underline — podkreśla wszystkie linki w witrynie.
  • Readable Font — zmienia czcionki witryny na rodzinę Verdana, Arial, Helvetica, sans-serif.
  • Reset — wyłącza wszystkie zmiany dokonane narzędziem.
Pasek narzędzi wtyczki One Click Accessibility

W menu administracyjnym możemy każdą z tych opcji przetłumaczyć i wyłączyć. Można również wyłączyć wyświetlanie paska narzędzi w witrynie.

W ustawieniach wtyczki znajdziemy jeszcze opcje ogólne:

  • Add Outline Focus — (domyślnie nieaktywne) dodaje obrys elementu, który przejmuje aktualnie fokus klawiatury.
  • Skip to Content link — (domyślnie aktywne) dodaje link do przeskoczenia do treści na górze strony.
  • Remove target attribute from links — (domyślnie nieaktywne) powoduje, że wszystkie odnośniki nie będą się otwierać w nowym oknie.
  • Add landmark roles to all links — (domyślnie nieaktywne) dodaje do wszystkich odnośników rolę ARIA „link”.
  • Sitewide Accessibility — (domyślnie nieaktywne) powoduje, że wybrana opcja z paska narzędzi jest zapamiętywana przy przejściu na inną stronę w witrynie.
  • Remember user for (ilość godzin) — (domyślnie 12) ustawia ważność sesji dla powyższej opcji.

Wtyczka pozwala jeszcze ustawić położenie paska narzędzi, kolor i wygląd ikony paska, kolor i rozmiar obrysu aktywnych elementów. Można to zrobić z poziomu menu personalizacji WordPressa.

Jak zmieniła się dostępność witryny po instalacji wtyczki?

Wtyczkę testowano z motywem opartym o „underscores” zmodyfikowanym tak, aby całkowicie spełniał wymagania wytycznych WCAG 2.1 na poziomie AAA. Aby sprawdzić niektóre funkcje, wyłączano w motywie funkcjonalności, które zapewniała wtyczka.


Co zyskujemy na pewno?

Opcja zmiany wielkości czcionki — WCAG wcale nie wymaga takiej funkcjonalności, ale jest ona znacznym ułatwieniem. Szczególnie dotyczy to osób starszych, lub takich, które niedawno dotknęła niepełnosprawność wzroku. W przypadku One Click Accessibility zrealizowana jest całkiem dobrze.

Każdy z elementów aktywnych wtyczki jest dostępny za pomocą klawiatury. W tym względzie jej działanie jest poprawne.


Co może (ale nie musi!) poprawić dostępność witryny?

Skip link — odnośnik do przeskoczenia do treści. Niezbędne, by spełnić kryterium sukcesu 2.4.1 Bypass Blocks. Ale UWAGA! W przypadku tej wtyczki implementacja może spowodować dodatkowe naruszenie dostępności! Informacja znajduje się w dalszej części artykułu.

Obrys elementów, które uzyskują fokus klawiatury — bardzo sensowna funkcja, zwłaszcza że większość motywów stara się ukryć wyświetlanie fokusu klawiatury. Niezbędne, by spełnić kryterium sukcesu WCAG 2.4.7: Focus Visible. Niestety nie daje się włączyć na stałe.

Wyłączenie otwierania odnośników w nowym oknie — może się przydać, zwłaszcza że poprawna implementacja tej funkcji wymaga poinformowania użytkownika, że opuści bieżące okno. Większość redaktorów treści zapomina o tym, lub wcale tego nie robi. Może pomóc spełnić kryterium 3.2.5 Change on Request.

Podkreślenie odnośników na stronie — pomaga spełnić kryterium sukcesu 1.4.1 Use of Color. Wiele motywów wyróżnia odnośniki tylko kolorem czcionki. Szkoda tylko, że nie można wybrać obszarów, w których ma działać. Nie zawsze chcemy podkreślać wszystkie linki. Niestety nie daje się też włączyć na stałe.

Ustawienie kontrastowego motywu kolorów — może pomóc w spełnieniu kryterium WCAG 1.4.3 Contrast (Minimum). Dopuszcza się możliwość zastosowana specjalnego trybu w przypadku, gdy kolory strony związane są z marką, określone w księdze identyfikacji wizualnej.


Problemy spowodowane przez wtyczkę.

„Toolbar”, Przyciski zmiany czcionki, kontrastu itd — jest po prostu niedostępny. Zasadniczo jest to dobry pomysł i samo działanie funkcji z widżetu One Click Accessibility jest całkiem poprawne. Czasem, zamiast zmieniać kolorystykę strony, rozsądnym wyjściem jest zapewnienie wyglądu alternatywnego, spełniającego wymogi kontrastu zgodne z WCAG. Nie wszyscy znają też skrót ctrl+kółko myszy do powiększania stron, więc zmiana wielkości czcionki pomoże im w dostępie do treści. Niestety kod paska narzędzi wtyczki powoduje wielokrotne błędy związane z dostępnością:

Wszystkie elementy aktywne, włącznie z ikoną wysuwającą pasek są zakodowane jako odnośniki tagiem <a>. Tymczasem nie pełnią takiej roli, donikąd nie prowadzą, za to wywołują funkcje. Nie zadbano o to, by użyć poprawnego tagu <button>, alternatywnie można było dodać odpowiednią rolą ARIA. Powoduje to naruszenie podstawowego (poziom A) kryterium 4.1.2 Name, Role, Value.

Sam kontener paska narzędzi oznaczono tagiem <nav> z niepotrzebnie dodaną rolą „navigation. Skoro nie zawiera nawigacji, należało użyć innych, semantycznie poprawnych elementów do zbudowania narzędzi. Ponownie narusza to podstawowe (poziom A) kryterium 4.1.2 Name, Role, Value.

Element powodujący wysunięcie i pokazanie paska narzędzi, a także elementy włączające funkcje nie informują o swoim stanie. Nie zadbano o atrybuty „aria-haspopup” ani „aria-checked” czy „aria-expanded„. To także narusza to podstawowe (poziom A) kryterium 4.1.2 Name, Role, Value.

Element powodujący wysunięcie i pokazanie paska narzędzi ma treść przeznaczoną dla czytników ekranu „Open toolbar”. Nie ma możliwości przetłumaczenia tego tekstu, nie jest on także oznaczony atrybutem wskazującym język. Powoduje naruszenie wytycznej 3.1.2 Language of Parts.

Na koniec dodajmy, że kontener zawierający narzędzia nie jest responsywny. Przy powiększeniu 250% jego część znalazła się poza ekranem (rozdzielczość HD) i nie dało się jej wyświetlić. Pasek narzędzi może więc dodatkowo naruszać kryterium 1.4.10 Reflow.

Samo pojawienie się paska gwarantuje brak zgodności witryny z wytycznymi WCAG 2.1.

Skip link — odnośnik do przeskoczenia do treści. Niezbędne, by spełnić kryterium sukcesu 2.4.1 Bypass Blocks. Niestety adres linku ustawiono na kotwicę #content i nie ma w konfiguracji wtyczki możliwości zmiany tego adresu. W przypadku, gdy nie mamy możliwości, lub umiejętności zmodyfikowania kontenera głównej treści i nadania mi atrybutu id="content", zamiast przeskoczenia do treści dostajemy uszkodzony link. Taka sytuacja będzie naruszeniem podstawowego (poziom A) kryterium 4.1.2 Name, Role, Value.

Opcja dodawania do odnośników roli „link” – trudno powiedzieć, czemu miałoby to zapobiegać. Na szczęście nie jest to naruszenie WCAG, ale przykład całkowitego niezrozumienia ARIA. Element <a>, czyli link, ma wbudowaną rolę „link”. Podobnie jest z <nav role="navigation">.


Podsumowanie

Zalety

  • Pokazywanie położenia fokusu klawiatury w witrynie.
  • Tworzenie skip linku do treści (ale tylko do kotwicy #content).
  • Wyłączenie otwierania linków w nowej karcie.
  • Opcja podkreślania linków w witrynie — niestety niewłączana na stałe.
  • Możliwość kompletnego przetłumaczenia wtyczki (plik *.mo lub np. Loco Translate) oraz przetłumaczenia samych etykiet toolbara z poziomu panelu opcji.

Wady

  • Bardzo niesemantycznie napisany „toolbar” – powoduje naruszenie 3 kryteriów sukcesu WCAG. Same funkcje zmiany kontrastu i wielkości czcionki mogą być pożyteczne, ale są tylko dodatkową opcją dostępności. Wbrew powszechnej opinii, WCAG nie wymaga takich przycisków na stronie.
  • Tworzenie skip linku do treści, ale tylko do kotwicy #content. Jeśli nie masz treści w kontenerze o id=”content”, spowoduje kolejne naruszenie kryteriów WCAG.
  • Wymuszanie podkreślania linków tylko z poziomu wadliwego „toolbara”. To pożyteczna funkcja, a tu jest całkiem zmarnowana. Dodatkowo podkreśla wszystkie linki, bez możliwości wyboru np. obszarów.
  • Opcja dodawania do odnośników atrybutu ARIA role=”link” jest zaprzeczeniem naczelnej zasady: „the best ARIA is no ARIA”. Bezmyślne dodawanie atrybutów do elementów, które już semantycznie je mają, oznacza brak zrozumienia zasad i daje szkodliwy przykład.

Werdykt

Zgodność z WCAG 2.1

Poprawnie skonfigurowana nadaje się dla stron w pełni zgodnych z WCAG 2.1. (rządowe, publiczne). Niestety niewiele poprawi dostępność.

Użyteczność i obsługa.

Nie ma wpływu na faktyczną dostępność strony. Bardzo powierzchownie traktuje temat dostępności.

One Click Accessibility potrafi bardziej zepsuć dostępność niż ją poprawić. Funkcje „toolbara” działają naprawdę nieźle, ale co z tego, kiedy jego wyświetlenie spowoduje, że strona nie ma szans na pomyślne przejście audytu dostępności.

Choć żadna wtyczka nie zapewni pełnej dostępności, ta skupia się raczej na dość powierzchownych aspektach i jej główną funkcją, najbardziej eksponowaną, jest ten nieszczęsny „toolbar”.

Można oczywiście wyłączyć szkodliwe komponenty. Wówczas zostają opcje, które można łatwo samemu dodać przy użyciu kilku łatwych linijek kodu z poziomu Administratora WordPress. I to znacznie lepiej. Czy dla takiej funkcjonalności warto instalować całą wtyczkę? Moim zdaniem nie.

Dodaj komentarz