GoWork.pl

Zostałem poproszony o rzucenie okiem na stronę GoWork.pl. No więc rzucam.

Przyjrzę się kilku podstronom portalu:

• stronie głównej,
• wynikom wyszukiwania,
• losowo wybranej ofercie pracy,
• losowo wybranej podstronie z opiniami o pracodawcy.

Ogólne uwagi

Na starcie wita nas – a jakże! – banner na dole strony, informujący o wykorzystywaniu przez stronę cookies. I tutaj miła niespodzianka: jest on całkowicie dostępny z poziomu klawiatury. Co więcej, focus jest w nim „uwięziony” i wymusza zaakceptowanie lub odmowę zaakceptowania cookies, zanim będzie można (przynajmniej przy pomocy klawiatury) nawigować po reszcie strony. Także po zamknięciu bannera focus jest poprawnie przerzucany na sam początek strony.

Oczywiście nie byłby to WebKrytyk, gdybym nie narzekał. W tym wypadku problemem jest wskaźnik focusu, zwłaszcza na przycisku do akceptowania wszystkich ciasteczek. Wskaźnik focusu jest niebieski, tak samo jak tło przycisku. To sprawia, że przycisk bez focusu wygląda praktycznie tak samo jak przycisk z focusem.

Zastanawia mnie też inna kwestia: czy aby na pewno doświadczenie dla osoby nawigującej klawiaturą oraz dla osoby nawigującej dotykiem/myszką są ekwiwalentne? Innymi słowy: czy jest to takie samo albo porównywalne doświadczenie? Jako użytkownik myszki mogę bez problemu klikać po całej stronie, skrzętnie ignorując banner zasłaniający mi mały kawałek u dołu strony. Niemniej w momencie, gdy zechcę posługiwać się zamiast tego klawiaturą, jestem zmuszony podjąć decyzję co do tego, co chcę zrobić z cookies. Podobnie banner zachowa się dla osób korzystających z czytników ekranowych, bo jest oznaczony jako modalny dialog. Dlaczego zatem dla jednej kategorii osób używających stronę nie jest – nie wiem.

Zauważyłem też pewną przypadłość tego banneru: treść w nim pokazuje się w języku przeglądarki. A to sprawia, że u mnie banner jest po angielsku, podczas gdy cała reszta strony – po polsku.

I już na sam koniec przygód odnośnie ciasteczkowego banneru – w konsoli przeglądarki jest ostrzeżenie z nim związane:

WARNING: Cookiebot script is included twice – please remove one instance to avoid unexpected results.

[OSTRZEŻENIE: Skrypt Cookiebot jest załączony dwukrotnie – proszę usunąć jedną z jego instancji, żeby uniknąć nieoczekiwanych rezultatów.

I przejdźmy może już do ciekawszych rzeczy.

Jak np. problem z dostępem do jednej z pozycji w górnym menu nawigacyjnym! Wśród znajdujących się tam linków jest też jedno podmenu rozwijane, Poradniki. Niestety, do tego podmenu nie da się dostać przy pomocy klawiatury. Pozycja Poradniki bowiem jest niefocusowalna i naciskanie Tab po prostu ją pominie. Jest to spowodowane tym, że jest klikalnym divem:

<div class="[…]">
    <span>Poradnik</span>
    <img src="[…]" alt="Zobacz więcej" class="[…]">
</div>

O wiele lepiej sprawdziłby się tutaj przycisk rozwijający podmenu albo link do podstrony Poradnik z towarzyszącym mu przyciskiem do rozwijania podmenu.

A jak już jesteśmy przy focusie: warto spojrzeć, co się dzieje ze wskaźnikiem focusu, zwłaszcza w górnym menu. W Safari wskaźnik wygląda na domyślny (niebieska ramka), w Chrome jest ustawiona lepiej widoczna biała ramka z czarną ramką w środku, natomiast w Firefoksie widać białą i niebieską ramkę. Jest to spowodowane zostawieniem domyślnego wskaźnika focusu, co sprawia, że część przeglądarek ustawia wskaźniki focusu w taki sposób, żeby były one jak najbardziej dostępne. Można to zaobserwować na prostym przykładzie: przy nawigowaniu klawiaturą linki na czarnym tle będą miały białe obramowanie, a na białym – standardowe niebieskie. Przeglądarki dość dobrze radzą sobie z doborem kolorów wskaźnika focusu. Ale nie wszystkie (na ciebie patrzę, Safari). I choćby z tego powodu lepiej samemu dobierać kolor wskaźnika focusu.

Na każdej podstronie znaleźć można także pewien pseudoprzycisk, służący do otwierania hamburgerowego menu:

<img src="[…]"" alt="Menu">

O tym problemie już na WebKrytyku było.

Strona główna

Na samej górze strony głównej znajduje się wyszukiwarka ofert pracy. Umożliwia ona znalezienie stanowiska po nazwie, mieście, odległości od tego miasta, kategorii (branży) oraz trybu pracy (zdalna, dodatkowa, za granicą). Pod tymi opcjami jest także przycisk rozwijający bardziej dokładne filtry. Problem w tym, że ten przycisk jest niedostępny dla osób nawigujących przy pomocy klawiatury, ponieważ po raz kolejny jest divem, nie przyciskiem.

Nie to jest jednak największym problemem tego formularza. Są nim bowiem etykiety dla poszczególnych pól. Ich rolę spełnia atrybut [placeholder], który nie jest zastępstwem dla faktycznych etykiet. Choćby z tego powodu, że zawartość placeholdera znika w momencie rozpoczęcia wpisywania czegokolwiek do pola. Tutaj jednak problem jest o wiele poważniejszy, ponieważ placeholdery stanowią jedynie wizualne etykiety. Natomiast na potrzeby technologii asystującej każde pole ma etykietę zawartą w atrybucie [aria-label]. I ta etykieta jest już taka sama dla każdego pola i dodatkowo jest po angielsku – Search for option (Szukaj opcji). To oznacza, że osoba korzystająca z technologii asystującej będzie miała trudność ze zrozumieniem, do czego służą poszczególne pola oraz czym się różnią od siebie. Dodatkowo rozjazd między wizualną etykietą a tą przeznaczoną dla technologii asystującej znacząco utrudni używanie narzędzi do sterowania głosem.

Warto też przez chwilę przyjrzeć się kodowi poszczególnych zaawansowanych filtrów. Są one reprezentowane przez checkboxy podzielone na poszczególne grupy. Przykładowa grupa wygląda tak (obciąłem niepotrzebne atrybuty):

<div class="advanced-filters">
	<div class="advanced-filters__title">
		Tryb pracy
	</div>
	<div class="advanced-filters__filters">
		<label>
			<input type="checkbox">
			Stacjonarna
		</label>
		<label>
			<input type="checkbox">
			Hybrydowa
		</label>
		<label>
			<input type="checkbox">
			Mobilna
		</label>
	</div>
</div>

Są to zatem checkboxy wewnątrz diva, który zawiera także tytuł takiej grupy. Sęk w tym, że w HTML-u mamy element stworzony dokładnie do takich zastosowań – fieldset:

<fieldset class="advanced-filters">
	<legend class="advanced-filters__title">
		Tryb pracy
	</legend>
	<div class="advanced-filters__filters">
		<label>
			<input type="checkbox">
			Stacjonarna
		</label>
		<label>
			<input type="checkbox">
			Hybrydowa
		</label>
		<label>
			<input type="checkbox">
			Mobilna
		</label>
	</div>
</fieldset>

Dzięki zastosowaniu fieldset osoby korzystające z technologii asystującej dostaną dodatkową informację o tym, że dane checkboxy należą do grupy „Tryb pracy”. Przy zastosowaniu divów tytuł grupy w rzeczywistości nie był w żaden sposób powiązany z checkboxami.

Ciekawe jest także to, że tylko główna część formularza (nazwa stanowiska oraz miasto) jest faktycznie wewnątrz elementu form. Równocześnie jednak żadne z pól nie ma atrybutu [name], bez którego nie da się przesłać żadnych danych formularzem. Innymi słowy: ten formularz jest atrapą, która nie zadziała w momencie, gdy JS się wyglebi. Osobiście nie widzę powodu, dla którego ten formularz powinien być uzależniony od JS-a. Zastosowałbym tutaj podejście Progressive Enhancement (PE; Stopniowe Ulepszanie) i zrobił z tego prawdziwy formularz. Taki, który faktycznie wyśle dane do backendu w sytuacji, gdy JS nie zadziała. A jak JS zadziała, to może przechwycić taki formularz (co zresztą obecnie robi, podczepiając się pod zdarzenie submit) i zamienić jego wysłanie na zapytanie Ajaksowe.

Pod formularzem wyszukiwania znajdują się sekcje pokazujące najnowsze oferty pracy, opinie o pracodawcach oraz nowe artykuły na blogu czy tematy na forum. Każda z tych sekcji posiada swój tytuł z podtyułem/opisem. Te podtytuły oznaczone są przy pomocy nagłówków, przez co struktura treści niepotrzebnie się rozrasta. A to może stanowić problem m.in. dla osób posługująćych się technologią asystującą. Jak pokazują badania przeprowadzane regularnie przez WebAIM, nawigacja przy pomocy nagłówków to najczęściej wykorzystywana metoda wyszukiwania informacji przez osoby korzystające z czytników ekranowych. Wkładanie do nagłówków nadmiarowych rzeczy tak naprawdę powiększa jedynie szum informacyjny. Dlatego podtytuły warto oznaczać przy pomocy elementu hgroup:

<hgroup>
	<h2>Najnowsze oferty pracy</h2>
	<p>Zobacz <a href="/praca">oferty pracy</a> z największych miast w Polsce</p>
</hgroup>

Warto też zwrócić uwagę na pewną niekonsekwencję. W niektórych sekcjach każdy jej element ma swój własny nagłówek. Tak jest np. w sekcji z opiniami o pracodawcach – nazwa każdego pracodawcy jest nagłówkiem. Z kolei w innych sekcjach jedynymi nagłówkami są jej tytuł i podtytuł – jak w sekcji z ofertami pracy. Jeśli już idziemy w dużą liczbę nagłówków, to osobiście zdecydowanie więcej pożytku widzę w zrobieniu nagłówka np. z każdej nazwy miasta w sekcji z ofertami, niż zrobienie nagłówka z podtytułu tej sekcji. Bo jeśli chcę oferty z Katowic, to dzięki takiemu nagłówkowi będę w stanie szybciej do nich przeskoczyć. Nie potrzebuję przeskakiwać do tekstu typu „zobacz x”.

W niektórych sekcjach (np. Aktualności z życia firm) treść jest prezentowana w formie karuzel. Nie jestem ich fanem, a i badania wskazują, że osoby odwiedzające stronę z nich nie korzystają. Myślę, że można spokojnie usunąć karuzele i zostawić na stronie treść, jaka była prezentowana na ich pierwszych slajdach. Do reszty większość osób odwiedzających stronę prawdopodobnie i tak nigdy nie dotarła.

Wyniki wyszukiwania

Wyszukałem sobie oferty na stanowisko Programista JavaScript w okolicy Krakowa. Pierwsze, co rzuciło mi się w oczy, to dziwne zarządzanie focusem. W momencie, gdy nacisnę przycisk Szukaj, focus jest przerzucany z powrotem na początek formularza wyszukiwania. Bardziej intuicyjne wydaje się zostawienie go na przycisku lub przerzucenie do listy wyników (pierwszego wyniku). Mogłoby to działać podobnie do przykładu listy zadań autorstwa Heydona Pickeringa. Pod listą zadań znajduje się pole tekstowe umożliwiające dodanie nowego zadania. Gdy się to zrobi, osoba korzystająca z technologii asystującej jest informowana, że zadanie zostało dodane. W przypadku czytnika ekranowego taka informacja zostanie przeczytana na głos. Jest to możliwe dzięki zastosowaniu elementu z atrybutem [role=status]. Jeśli treść takiego elementu się zmieni, technologia asystująca poinformuje o tym osobę z niej korzystającą. Taki schemat bardzo dobrze sprawdzilby się tutaj: klikam przycisk Szukaj i technologia asystująca odczytuje liczbę znalezionych ofert. Dzięki temu osoba posługująca się technologią asystującą wie, czy jest sens nawigować do listy znalezionych ofert, czy jednak powrócić do formularza i zmienić zapytanie.

Warto też zwrócić uwagę, że formularz zachowuje się niespójnie. Częśc pól wymaga naciśnięcia przycisku Szukaj, żeby szukanie w ogóle się odbyło. Jednak filtry uruchamiają wyszukiwanie w momencie zaznaczenia/odznaczenia. A każde wyszukiwanie oznacza przerzucenie focusu na początek strony, co bardzo szybko robi się mocno irytujące. Skoro już jest przycisk w formularzu, to niech całość działa na ten przycisk.

Nawigacja klawiaturą po liście znalezionych ofert jest mocno utrudniona z powodu modalu, który pokazuje się po przejrzeniu pewnej liczby ofert. Choć to okienko przykrywa zawartość strony, to focus nie jest do niego przerzucany i zostaje na aktualnie przeglądanej ofercie. Okienka nie da się też zamknąć, naciskając Escape. Nie jest też w żaden sposób oznaczone jako dialog, przez co technologia asystująca je całkowicie zignoruje. Tego typu okienko powinno być oznaczone jako dialog, a focus powinien do niego trafić w momencie otwarcia. Inaczej osoba posługująca się klawaiturą będzie zmuszona przetabować przez całą stronę, aż w końcu trafi do wnętrza dialogu i będzie mogła go zamknąć. Osoba korzystająca z czytnika ekranowego prawdopodobnie nawet nie zorientuje się, że pojawił się jakiś dialog.

Przy niektórych ofertach jest przycisk Dodaj do aplikowania. Nie da się go jednak aktywować przy pomocy klawiatury, bo znów mamy do czynienia z divem zamiast prawdziwego przycisku:

<div>
	<img src="[…]" alt="Ikona wybranych ofert" class="checkmark-svg" style="display: none;">
	<img src="[…]" alt="Ikona wybranych ofert" class="checkmark-svg">
	<span>Dodaj do aplikowania</span>
</div>

W powyższym kodzie widać także dwa obrazki. W zależności od tego, czy dana oferta jest dołączona do listy ofert, na które chce się aplikować, czy też nie, będzie widoczny jeden z tych obrazków, a drugi będzie schowany. Ich atrybut [alt] jest fatalnie dobrany, bo zupełnie nie wskazuje na funkcję, jaką te obrazki spełniają na stronie. A są jedynie wizualnym wskaźnikiem, czy dana oferta jest wybrana przez osobę przeglądającą oferty. Informację o tym zawiera już element span (Dodaj do aplikowania lub Dodane do aplikowania), stąd ikony pełnią tak naprawdę rolę dekoracyjną. W takim przypadku powinny mieć pusty [alt]. Z kolei całość oznaczyć można przy pomocy elementu button z dodatkowym atrybutem [aria-pressed]. Dzięki niemu będzie można zaznaczyć, czy przycisk jest obecnie włączony, czy wyłączony.

Dodanie oferty do listy aplikowanych powoduje pojawienie się paska z wybranymi ofertami na górze strony. Żeby dostać się do niego przy pomocy nawigowania klawiaturą, trzeba przejechać na samą górę strony. I uważać, żeby go nie minąć, bo przycisk w nim nie ma wskaźnika focusu. A jak już uda się sfocusować przycisk i go kliknąć, otwiera się modal… do którego focus nie jest przerzucany i trzeba przejechać przez całą stronę, żeby się do niego dostać. Auć.

Na stronie znajduje się także infografika, wyjaśniająca, w jaki sposób aplikować można na wiele ofert równocześnie. Wymienia ona 5 punktów:

1. Znajdź,
2. Wybierz,
3. Uzupełnij,
4. Aplikuj,
5. Ciesz się.

Problem w tym, że ta infografika jest umieszczona jako obrazek, którego atrybut [alt] jest ustawiony na cart-infographics. Innymi słowy, osoby korzystające z czytnika ekranowego nigdy nie dowiedzą się, jak działa takie aplikowanie. Zostanie im jedynie zapewnienie, że jest proste.

Oferta pracy

W widoku pojedynczej oferty po raz kolejny jest coś nie tak z zarządzaniem focusem. Obok nazwy oferty znajdują się przyciski do jej udostępniania i drukowania. Po kliknieciu w przycisk udostępniania rozwija się podmenu z wyborem opcji, w jaki sposób chcemy ofertę udostępnić. Po zamknięciu tego podmenu przy pomocy klawiatury i naciśnięciu Tab, focus jest przerzucany na sam początek strony. W przypadku takich rozwijanych menu po ich zamknięciu focus powinien zostać na elemencie, który to menu rozwinął – czyli przycisku udostępniania.

Pod samą ofertą znajduje się także lista najczęściej zadawanych pytań odnośnie szukania ofert pracy i aplikowania na nie. Jest ona pokazana w formie akordeonu. Nie da się go jednak obsługiwać przy pomocy klawiatury, ponieważ przyciski do rozwijania poszczególnych sekcji nie są przyciskami. Tym samym – nie da się ich sfocusować. Dodatkowo nie ma tutaj odpowiednich atrybutów ARIA, w tym najważniejszego, [aria-expanded], który informuje o tym, czy dana sekcja jest zwinięta, czy rozwinięta.

Co ciekawe, na tej podstronie jest zdecydowanie lepsza struktura nagłówków. Tytuł ogłoszenia to h1, natomiast poszczególne sekcje oferty – h2. Nagłówków nie ma także aż tyle, co na stronie głównej.

Opinie o pracodawcy

Osobiście moje doświadczenie z podstroną opinii jest dość… przytłaczające. Po chwili interakcji z nią wyświetlił się wyskakujący komunikat z pytaniem, czy chcę otrzymywać powiadomienia o nowych opiniach. Kilka sekund po jego zamknięciu pojawił się inny wyskakujący komunikat, zachęcający mnie do dodania opinii o pracodawcy, na którego podstronie byłem. Tego typu elementy strony mogą prowadzić do przeciążenia sensorycznego, zwłaszcza u osób neuroróżnorodnych. Ostrzegają przed tym m.in. materiały dla instytucji publicznych:

Pop-ups can be very disruptive, especially when they come up a few seconds after a user has started to engage with a platform. They should be avoided and disabled whenever possible.

[Popupy mogą być mocno rozpraszające, zwłaszcza, jeśli pojawiają się kilka sekund po rozpoczęciu przez osobę interakcji ze stroną. Popupy powinny być unikane i usuwane w każðym możliwym przypadku.]

Na tej podstronie również nawigacja klawiaturą jest mocno utrudniona, ponieważ spora część elementów nie ma widocznego wskaźnika focusu. Trzeba więc nawigować na czuja. Jednym z takich elementów, które nie mają wskaźnika focusu, są przyciski do oceniania, czy opinia była pomocna, oraz do zaraportowania obraźliwej lub niemerytorycznej opinii. Co ciekawe, przyciski do oceniania mają nadane etykiety (przy pomocy atrybutu [aria-label]), ale już przycisk do raportowania – nie. A to w połączeniu z faktem, że te przyciski są zakodowane jako linki, sprawia, że np. czytnik ekranowy VoiceOver przeczyta ten przycisk jako link, <adres linku>. To sprawia, że dla osoby korzystającej z czytnika ekranowego ten przycisk jest całkowicie niezrozumiały.

Przy każdej opinii jest też przycisk Udostępnij, który ma atrybuty [aria-expanded] i [aria-haspopup] sygnalizujące, że po jego kliknięciu otworzy się menu! Problem w tym, że sam przycisk… nie jest przyciskiem. Przez co nie da się go sfocusować przy pomocy klawiatury.

Jeśli chce się dodać nową opinię lub odpowiedzieć na już istniejącą, otwiera się dialog z formularzem. I tu pozytywna niespodzianka: focus jest poprawnie przerzucany do tego formularza! Ale żeby nie było za dobrze, to znajdują się w nim dwa pytania – jedno o typ opinii (pozytywna, negatywna, neutralna), drugie o status osoby piszącej opinię (pracownik, były pracownik, itd.). W obydwu przypadkach mamy do czynienia z polem jednokrotnego wyboru, ale są one zaprojektowane i zakodowane zupełnie inaczej. Typ opinii wygląda jak trzy klikalne przyciski, podczas gdy status osoby piszącej opinię – jak standardowe pole jednokrotnego wyboru. I niestety, ale tylko to drugie jest dostępne z poziomu klawiatury. Trzy klikalne przyciski są tym razem spanami, które nie łapią nawet focusu. A przecież obecnie można to załatwić ładnie stylujac pola formularza. Dodałem też wokół div z atrybutem [role=group]. Dzięki czemu zastępuje fieldset dla tych pól wyboru, bo ten do dzisiaj ma spore problemy ze stylowaniem.

Krótkie podsumowanie

GoWork.pl to zdecydowanie strona dostosowana pod myszkę, względnie dotyk, niekoniecznie pod klawiaturę.

I po tym jakże krótkim podsumowaniu, chciałbym życzyć wszystkim dostępnych ostatnich minut Światowego Dnia Świadomości Dostępności!