Dzisiaj na ostrze WebKrytyka nadzieje się strona Pietrak.NET.
Wygląd i działanie
- Pierwszy rzut oka na oferowane pakiety stron WWW zwraca uwagę na oferowanie zgodności ze standardem WCAG 2.0. To oznacza, że strona powinna spełniać dość rygorystyczne normy dostępności. Sprawdzę to zatem!
- Pierwszy zgrzyt pojawia się już w pierwszej sekcji po nagłówku:
Najedź po więcej detali
. Żeby najechać na cokolwiek, trzeba być w stanie posługiwać się myszą. Co więcej, na urządzeniach mobilnych napisuNajedź […]
nie ma w ogóle, przez co cała ta sekcja wygląda jak ozdobnik niepełniący żadnej funkcji. Paradoksalnie ta sekcja jest najbardziej dostępna dla użytkowników czytników ekranowych – ci po prostu usłyszą każdy „kafelek” w sekcji. - Kontrast wielu elementów jest zdecydowanie za niski, np. kontrast pomiędzy tłem a tekstem w elementach menu czy kolor wskaźnika focusu.
- Strona bez JS-a działa. Niemniej wyświetlony jest komunikat o tym, że poprawne działanie wymaga JS-a i niektóre elementy strony przez to nie działają – głównie slidery. W tym wypadku wydaje mi się, że lepszym rozwiązaniem byłaby rezygnacja z komunikatu i po prostu rozwinięcie treści ze sliderów.
- Bardzo dziwna rzecz się dzieje po przejściu na adres
https://www.pietrak.net
. Następuje wtedy przekierowanie na… Example.com. - Na stronie znajduje się również martwy link.
Kod
- Walidator pokazuje kilka błędów. Niemniej są bardzo łatwe do poprawienia.
- Hierarchia nagłówków wygląda dobrze, za co duży plus. Można się jedynie zastanowić nad sensownością dodawania nagłówków do każdego
nav
. -
<a href="#tresc" class="focus-only" tabindex="1">Przejdź do treści</a>
Skoro ten link i tak jest pierwszy w
body
, to nie ma sensu dodatkowo mu dawać[tabindex=1]
. Zasada kciuka brzmi: nie używa się w[tabindex]
wartości większych od zera. - Jeśli już dajemy nagłówek do każdego
nav
, dodatkowo podpiąłbym go przy pomocy atrybutu[aria-labelledby]
. - Przycisk otwierający menu ma niepotrzebny atrybut
[aria-haspopup]
. Atrybut[aria-expanded]
jest całkowicie wystarczający. -
Użycie
[role=menubar]
wnav
jest niepoprawne. Ta rola oznacza bowiem menu aplikacyjne, nie zaś – nawigację:The
menubar
role is used to create a menu bar similar to those found in Windows, Mac, and Gnome desktop applications. A menu bar is used to create a consistent set of frequently used commands. Authors SHOULD ensure thatmenubar
interaction is similar to the typical menu bar interaction in a desktop graphical user interface.[Rola
menubar
jest używana do tworzenia paska menu podobnego do tych znajdujących się w Windowsie, Macu czy Gnome w aplikacjach desktopowych. Pasek menu jest używany do tworzenia spójnego zestawu często używanych komend. Autorzy POWINNI zapewnić, że interakcja z elementem o rolimenubar
jest podobna do typowej interakcji z paskami menu w graficznych desktopowych interfejsach użytkownika.]Co więcej,
[role=menuitem] > a
może być nieco mylące. Lepiej byłoby w takim wypadku zmienić rolęli
na[role=presentation]
, a[role=menuitem]
przenieść bezpośrednio na link.W tym jednak kontekście najlepiej po prostu zostawić normalną listę z linkami.
address.header-address
na chwilę obecną bardziej przypomina kolejnenav
(zwłaszcza z powodu linku do CMS-a).-
<section class="offer-container" id="offer">
Znacznik
main
posiada polskie[id]
, niemniej ten – już nie. Akurat punkty nawigacyjne wszystkie powinny być w języku strony. -
<h2 class="visuallyhidden">Co oferujemy?</h2>
Choć takie ukrywanie nagłówków wizualnie ujdzie, to jednak mimo wszystko tak projektowałbym strony, żeby miejsce na nagłówek po prostu było
. -
<aside aria-hidden="true" class="offer-tooltip"><img src="/images/arrow.png" alt="">Najedź po więcej detali</aside>
Prawdę mówiąc, nie widzę, czemu to jest
aside
. Wygląda to na najzwyklejszy akapit. - Zastanowiłbym się, czy w tym wypadku nie będzie sensowniej odwrócić zależności: z
#offer
zrobićarticle
a z poszczególnych usług –section
. -
<button data-index-slide="0" class="button-clear" title="Przewiń do: Pracownia wnętrz JW" aria-label="Przewiń do: Pracownia wnętrz JW"> <span class="visuallyhidden">Projekt Pracownia wnętrz JW</span> </button>
W takim wypadku
[aria-label]
ma pierwszeństwo nad zawartością elementu. Dodatkowo duplikacja zawartości tego atrybutu w atrybucie[title]
może sprawić, że czytnik ekranowy przeczyta ten tekst dwa razy – raz jako etykietkę przycisku ([aria-label]
), a drugi raz jako jego opis ([title]
). - Jeśli w stopce znajduje się
[role=menuitem]
z submenu, wypadałoby je odpowiednio oznaczyć ([role=menu]
). Niemniej znów mamy tutaj do czynienia z nawigacją i te role w ogóle nie powinny zostać użyte. - Informacja o konieczności włączenia JS pojawi się tylko, jeśli skrypty zostały wyłączone po stronie przeglądarki. Zamiast znacznika
noscript
proponowałbym technikę z klasą.no-js
.
Nie jest źle. Widać, że autor strony posiada wiedzę z zakresu semantyki HTML-a i co najmniej podstawy dotyczące dostępności stron WWW. Niemniej niektóre zasady WCAG nie zostały zachowane (niski kontrast niektórych elementów strony), a w innych miejscach – postarano się za bardzo (oznaczenie menu nawigacyjnych).
Dziękuję za recenzję, szczerze nie spodziewałem się, że kiedyś tu trafię. Nie mam pojęcia w jaki sposób trafiłeś na moja stronę.
Większość wymienionych błędów poprawiłem, lecz teraz, w dobie walki o każdego klienta strona ma wywołać efekt wow i zrobić pierwsze dobre wrażenie, dlatego czasami trzeba iść w kompromis.
Kilka błędów to typowe błędy nieuwagi lub relikty przeszłości kopiowane ze starych projektów, a już na pewno dziwny menubar i przekierowanie na example.com
Nie zgodzę się co tu użycia title i label razem. Pierwszy jest dla osób widomych, drugi natomiast dla niewidomych. Zgodnie z tymi artykułami: https://dev.opera.com/articles/ux-accessibility-aria-label/#accessible-name-calculation https://silktide.com/i-thought-title-text-improved-accessibility-i-was-wrong/ NVDA nie czyta title, natomiast JAWS pomija identyczne atrybuty.
Kolejna kwestia to informacja o JS. Przede wszystkim jest to spowodowane trudnym do ostylowania sliderze z komputerem przy wyłączonym JS oraz używaniem na blogu wykresów i kolorowania składni. Nie widzę również sensu rezygnowania z natywnego noscript. Ile osób ma zablokowany JS w firewallu, przez dostawce czy cokolwiek innego? Zapewnię mniej niż używa IE7, a od wspierania ich już dawno się odeszło.
Jeszcze przy okazji się spytam: Skąd jest polityka prywatności umieszczona na twojej stronie? Widzę już taką na którejś z kolei. To jakiś ogólnodostępny wzór?
Oprócz NVDA i JAWS istnieje jeszcze spora grupa innych czytników ekranowych, choćby TalkBack na Androidzie czy VoiceOver na macOS-ie i iOS-ie. Niewykluczone, że przy jakiejś konfiguracji są czytane obydwa atrybuty – zwłaszcza, że zawartość [title] jest przekazywana do drzewka dostępności jako opis danego elementu.
Mam też wątpliwości co do tego, że ten atrybut jest dla osób widomych. To nie do końca prawda, bo jest tylko dla osób widomych posługujących się myszką. Dla osób korzystających z klawiatury czy urządzeń dotykowych ten atrybut może równie dobrze nie istnieć.
A co jeśli JS po prostu się nie doczyta, bo komuś na chwilę zabraknie zasięgu w telefonie albo AdBlock coś zablokuje? 😉 To już nie brzmi jak odosobniony przypadek.
Z blogu Prakreacja.pl.