Od czasu do czasu zdarza się, że jakiś czytelnik sam pragnie, żebym napisał dla niego krytykę jego własnej strony WWW. Tak było i tym razem, gdy dostałem prośbę o ocenę strony RadioLista.
- Strona wygląda schludnie i czysto. Podoba mi się.
- Jedyny problem, jaki dostrzegam w wyglądzie tej strony, to niski kontrast między tekstem a tłem (niestety, moja strona domowa też cierpi na objawy tej choroby – przyznaję bez bicia). Bardzo dobrze przydaje się do wyszukiwania tego typu problemów dodatek do Chrome, Color Contrast Analyzer.
- Strona serwowana jest po HTTPS – dobrze, ale mogłoby być lepiej. Brakuje bowiem wsparcia dla HTTP/2.0
- Bardzo dobrze widoczny outline dla obecnie focusowanego elementu. Ba, nawet style z
:hoversą przepisane na:focus! Duży plus! - Nie przekonuje mnie jednak domyślny kursor myszy dla tekstu. Mimo wszystko oczekuję tutaj kursora tekstowego. Tego typu kursor widziałbym dla aplikacji internetowych (chociaż też nie do końca mi tam pasuje), nie dla prostych stron.
- Tak samo nie przekonuje mnie podświetlanie
labelprzy najechaniu kursorem myszy. Sama zmiana na łapkę wystarczy – zwłaszcza, że takie podświetlenie sugeruje, że to link. - Zakładki przy formularzach rejestracji i logowania są nie do końca dobrze zrobione. Skoro każdy z tych formularzy ma swój własny adres, oczekuję, że przełączenie się na któryś z nich spowoduje zmianę tego adresu na odpowiedni. Przy obecnej implementacji można to zrobić albo po prostu dodając do tych zakładek linki, albo używając linków wraz z History API.
- W przypadku formularza rejestracji jest jeden mały problem, związany z kolejnością TAB-owania. Focus najpierw zahacza o opis checkboxa odnośnie akceptacji regulaminu, a dopiero potem przechodzi na tego checkboxa – podczas, gdy na ekranie jest to wyświetlane na odwrót. Jest to mylące dla użytkownika.
- Błędy wyświetlane przez formularz rejestracji nie są zbyt informatywne. Dowiaduję się, że nazwa użytkownika podana przeze mnie jest błędna… ale nie wiem dlaczego. Tak samo dostaję informację, że hasło jest za krótkie bez informacji o tym, ile znaków mieć powinno. Co więcej, prezentowany jest mi jeden błąd naraz, więc w najgorszym wypadku będę musiał wysyłać formularz 4 razy. To trochę za dużo. Wypadałoby, żeby komunikaty o błędach zawierały więcej informacji. Osobiście doczepiłbym je bezpośrednio do pól, a nie w formie wyskakującego komunikatu u góry – powinno to dodatkowo zwiększyć czytelność. Pomyślałbym także o walidacji w JS, która pozwoliłaby zmniejszyć maksymalną liczbę prób potrzebnych do rejestracji aż do 1. Oczywiście walidacja w JS miałaby na celu jedynie poprawienie UX, a nie zastąpienie walidacji po stronie serwera.
- Jak się już czepiamy formularza: jest mała literówka –
regularmin
zamiast regulamin. - Jeśli chodzi o kod, pozwolę sobie skupić się głównie na interfejsie dla osób niezalogowanych. Tradycyjnie zaczniemy od walidatora, który jest zadowolony.
- Również PageSpeed Insights nie narzeka zbytnio, chociaż pokazuje, że strona nie jest responsywna – a szkoda.
- Jest określenie języka strony przy pomocy
html[lang]– to wciąż rzadkość. - Kod CSS jest zminifikowany i umieszczony w jednym arkuszu – plus za to.
- W przypadku skryptu statystyk pomyślałbym nad przeniesieniem ich nad arkusze stylów.
- Ostatnio zauważyłem, że zaczęły mnie drażnić encje typu
—. Osobiście po prostu wstawiłbym tam odpowiedni znak (–). Co ciekawe, narzędzia typu grunt-contrib-htmlmin uznają tego typu zamianę encji na odpowiedni znak za optymalizację. - W końcu jest poprawny główny nagłówek strony.
-
<section><header class="home"> <h2>Strona główna</h2> </header>Prawdę mówiąc nie pasuje mi ta sekcja. Pominąłbym ją całkowicie, w ostateczności ten nagłówek umieścił bezpośrednio w
main - W przypadku prostych formularzy, składających się z jednego pola i przycisku, lista
dljest wg mnie niepotrzebną komplikacją. - Sekcji z wyszukiwarką/samej wyszukiwarce można z czystym sumieniem dodać
[role=search]. - Noooo… Od biedy to to
[target]dla reklamy można stolerować. - Lista w stopce może być otoczona dodatkowo przez
nav. Natomiast informacja o prawach autorskich nie pasuje jako element tej listy – to raczej powinien być akapit poza nią, odpowiednio ostylowany. - Na stronie poszczególnego wykazu mamy tabelkę, ale ciut jej brakuje, a mianowicie: ładnego podziału na
theaditbody. -
<th data-sort="T" tabindex="0" class="">Nazwa</th>Rozumiem zamysł, ale jest on wykonany źle, przez co element jest niedostępny i nie do końca działa tak, jak oczekuje od niego użytkownik. Samo uczynienie elementu focusowalnym nie czyni zeń przycisku. Przycisk musi się przedstawiać jako przycisk (
[role=button]), być focusowalny ([tabindex=0]) oraz reagować na odpowiednie klawisze (Enter i Spację). Dokładnie te wymagania opisane zostały na blogu The Paciello Group. -
<dt class="checkboxes"><label for="el7">Akceptuję <a target="_blank" title="Strona otworzy się w nowej karcie." href="regulamin">regularmin</a> serwisu RadioLista</label></dt><dd><input id="el7" name="acceptServiceTerms" type="checkbox" value="1"></dd>Jak widać, tutaj etykietka pola znajduje się przed nim, mimo że na ekranie wyświetlane jest to odwrotnie, co powoduje wspomniany już przeze mnie problem. Nie istnieje idealne rozwiązanie tego problemu, ale raczej szedłbym w coś typu:
<dt class="checkboxes">Akceptacja regulaminu</dt> <dd> <label><input id="el7" name="acceptServiceTerms" type="checkbox" value="1"> Akceptuję <a target="_blank" title="Strona otworzy się w nowej karcie." href="regulamin">regularmin</a> serwisu RadioLista</label> </dd>Albo (co wg mnie lepsze w tym wypadku) po prostu nie przestawiał kolejności tych elementów w CSS.
Nie jest źle. Powiem więcej: jest dobrze – chociaż wciąż nie idealnie. Bez wątpienia to jedna z najlepszych stron, jakie przyszło mi recenzować na łamach WK. Błędy nie są zbyt duże, choć z drugiej strony: dotykają głównie sfery dostępności i użyteczności.
Niemniej: było miło.
Jako autor skrytykowanej tutaj strony WWW bardzo dziękuję za poświęcenie czasu i wypunktowanie błędów. Z niektórymi bezsprzecznie się zgadzam, z niektórymi polemizowałbym. Jednakże dłuższą odpowiedź na krytykę napiszę za parę miesięcy, gdy będę pracował nad poprawkami na stronie (pojawi się też wtedy arkusz CSS w wersji responsywnej).
Minęło już trochę od mojej ostatniej odpowiedzi, mam już teraz czas na wprowadzenie poprawek i skomentowanie twoich uwag.
–
„Jedyny problem, jaki dostrzegam w wyglądzie tej strony, to niski kontrast między tekstem a tłem [..]”.
Przetestowałem podane rozszerzenie (szkoda, że tylko dla Chrome…) oraz poczytałem na stronie autora o standardzie kontrastu WCAG i sposobie jej działania. Hmm… Mam szacunek do standardów, ale no bez przesady. Żeby komputer mówił mi, jaka ma być różnica między kolorem tła i tekstu? No to potrzebny jest zdrowy rozsądek, a nie automat. Właściwie ten algorytm czepiał się na mojej stronie głównie linków, które rzekomo są zbyt jasne. No kurde. Nie są zbyt jasne, są czytelne. Mam szacunek do osób niepełnosprawnych czy niedowidzących, ale bez przesadyzmu…
—
„Strona serwowana jest po HTTPS – dobrze, ale mogłoby być lepiej. Brakuje bowiem wsparcia dla HTTP/2.0”
Korzystam ze StartSSL. W starej wersji strony (a nowa weszła miesiąc przed ww. krytyką) nawet tego nie było. 😉 Czy polecisz coś *koniecznie darmowego* co obsługuje HTTP dwójkę?
—
„Nie przekonuje mnie jednak domyślny kursor myszy dla tekstu. Mimo wszystko oczekuję tutaj kursora tekstowego. Tego typu kursor widziałbym dla aplikacji internetowych (chociaż też nie do końca mi tam pasuje), nie dla prostych stron.”
Mam nadzieję, że zwracanie się do ciebie na ty cię nie urazi. Bardzo cię szanuję, to dzięki twojemu ewangelizowaniu na różnych forach internetowych dbam o semantykę kodu i dostępność.
W twoich wypowiedziach dostrzegam jednak pewną tendencję — mieszasz obiektywne fakty z odczuciami subiektywnymi. Za subiektywne uważam na przykład negowanie używania target=”_blank” (ja zawsze daję ten atrybut linkom poza moją witrynę, gdy zmienia się layout, by zasygnalizować użytkownikowi wyjście z mojego serwisu; co więcej, nie lubię, gdy na innych stronach inni autorzy nie mają tego samego podejścia 😉 ).
Tak też jest z tą uwagą. Bardzo nie lubię, gdy najeżdżam na tekst strony WWW i widzę kursor „pionowej kreski” (no chyba, że to input lub textarea 😉 ). Także to jest dość subiektywne. Dla mnie kod CSS „body {cursor:default}” to taki must-have. Tak samo jak „body{ overflow-y: scroll }”, żeby przy zmianie wysokości treści strona nie skakała parę px w lewo lub prawo.
—
„Tak samo nie przekonuje mnie podświetlanie label przy najechaniu kursorem myszy. Sama zmiana na łapkę wystarczy – zwłaszcza, że takie podświetlenie sugeruje, że to link.”
Na wielu stronach WWW nawet nie ma labeli niestety. Dlatego chciałem zaznaczyć użytkownikowi, że gdy kliknie ten napis, coś się zadzieje. Rzeczywiście to trochę mylące. Poprawione.
—-
„Błędy wyświetlane przez formularz rejestracji nie są zbyt informatywne. Dowiaduję się, że nazwa użytkownika podana przeze mnie jest błędna… ale nie wiem dlaczego […]”
Słuszne uwagi — nie zauważyłem tego. Ze względu na wrodzone lenistwo oraz pragnienie zachowania prostoty kodu strony problem rozwiązałem następująco:
— zmieniłem komunikat o haśle na „Hasło musi mieć co najmniej 10 znaków”.
— do pola loginu dopisałem atrybut pattern (oczywiście walidacji po stronie serwera nie tknąłem!); dodałem kod JS wykorzystujący zdarzenie oninvalid oraz setCustomValidity() by podmienić zawartość systemowego popupa z komunikatem „niewłaściwy format” na bardziej informacyjny, dodałem atrybut title (który również pojawi się obok komunikatu o niewłaściwym formacie, gdy JS będzie wyłączony oraz w IE&Edge, które oninvalid nie obsługują).
Poprawka: usunąłem kod JS, uznałem za zbędny.
—–
„W przypadku skryptu statystyk pomyślałbym nad przeniesieniem ich nad arkusze stylów.”.
Nie rozumiem, dlaczego. Przeczytałem podany tekst. Dość słaby jestem z angielskiego, ale to, co zrozumiałem, już wiedzialem. Wynika z niego, że skrypty inline blokują renderowanie strony do momentu wykonania się (przecież właśnie dlatego umieszczam skrypt na końcu kodu witryny) oraz że warto używać atrybutów defer i async (używam ich intensywnie, choć akurat nie w miejscu kodu statystyk).
——-
„Ostatnio zauważyłem, że zaczęły mnie drażnić encje typu —. Osobiście[..]”
Gdy używałem Windows, korzystałem z encji z dwóch powodów: systemowy układ klawiatury nie umożliwia wpisania pauzy i półpauzy, a w foncie monotypicznym (a przecież takich używamy do programowania) trudno rozpoznać znaki — – -. Od dwóch lat używam Linuksów, gdzie można wpisywać te znaki z klawiatury, ale moje podejście zmienia się powoli. 😉
——
„W końcu jest poprawny główny nagłówek strony.”
To twoja zasługa!
——–
„Sekcji z wyszukiwarką/samej wyszukiwarce można z czystym sumieniem dodać [role=search].”
„Na stronie poszczególnego wykazu mamy tabelkę, ale ciut jej brakuje, a mianowicie: ładnego podziału na thead i tbody.”
Poprawione.
————
„Sekcji z wyszukiwarką/samej wyszukiwarce można z czystym sumieniem dodać [role=search].”
Gdy dodałem role=”search” do inputa, walidator zgłosił błąd. Czy nie wystarczy type=”search”?
—————
„Przycisk musi się przedstawiać jako przycisk ([role=button]), być focusowalny ([tabindex=0]) oraz reagować na odpowiednie klawisze (Enter i Spację).”
Tak naprawdę w moim kodzie brakuje jedynie role=”button”, dobrze rozumiem? Reakcja na klawisz jest w kodzie JS, zresztą tabindex też dodaję przez JS, gdyż bez skryptu nie miałby on sensu. Inspirując się artykułem, dodałem też aria-label.
————-
„Prawdę mówiąc nie pasuje mi ta sekcja. Pominąłbym ją całkowicie, w ostateczności ten nagłówek umieścił bezpośrednio w main”
Użyłem tego znacznika celowo. Bez niego nie ma zagnieżdzenia w outline. A przecież main nie wpływa na outline, prawda? Natomiast headera użyłem z przyzwyczajenia. Zawsze używam tego tagu dla głównego nagłówka serwisu oraz dla nagłówka podstrony — nawet gdy ten drugi składa się tylko z tytułu. Wiem, że to niepotrzebne, ale jest to dla mnie bardziej intuicyjne.
———–
„Zakładki przy formularzach rejestracji i logowania są nie do końca dobrze zrobione. Skoro każdy z tych formularzy ma swój własny adres, oczekuję, że przełączenie się na któryś […]”
„Jak widać, tutaj etykietka pola znajduje się przed nim, mimo że na ekranie wyświetlane jest to odwrotnie, co powoduje wspomniany już przeze mnie problem.”
Jesteś bardziej zaawansowanym ode mnie programistą, więc na pewno znasz moje uczucie, ten problem, być może nauczyłeś się dzięki doświadczeniu, jak sobie z nim radzić. Otóż czasem tak jest, że gdy stworzę jakiś zautomatyzowany i z założenia uniwersalny mechanizm w kodzie (np. klase do generowania kodu HTML pól formularzy lub kod JS wraz z „szablonem umysłowym” kodu HTML dla sekcji formularzy podzielonej na taby) to potem staram się go konsekwentnie i bardzo spójnie używać. Aż w pewnym momencie zachodzi potrzeba użycia tego mechanizmu odrobinę zmodyfikowanego w tylko jednym z konkretnych przypadków, „użyć”. I dochodzi wtedy do problemu konstrukcyjnego, jak to rozwiązać.
Wspomniany wcześniej kod JS i HTML dla foremek z tabami miał takie założenie: pojedyncza strona (np. ustawień wykazu) będzie zawierać jedną „foremkę”, której pola będą podzielone na części, a dostęp do każdej z nich będzie możliwy dzięki generowanym przez JS tabom. Kliknięgo na tab nie miało zmieniać adresu URL, bowiem wszystkie taby miały być w obrębie jednej strony serwisu.
Aż tu nagle doszło do stworzenia strony logowania i rejestracji. Chciałem by były one pod osobnymi URLami, ale chciałem też wykorzystać ten samą strukturę, co w innych „otabowanych foremkach”. Wyszło to, co widzisz. 😉 Oczywiście mogłem np. umieścić ręcznie kod HTML zamiast używać do tego JS generującego reagujące na kliknięcie taby (buttony tak naprawdę) albo mogłem dodać do kodu „otabowanego” interfejsu możliwość zmiany adresu URL przez dodanie atrybutu data-cośtam do naglówka sekcji pól formularza (tytuły do tabów są brane z tytułów poszczególnych sekcji). Mogłem to wszystko, ale zaburzyłoby mi to strukturę kodu, bo użyłbym tego tylko jeden raz w jednym miejscu — byłbym niezadowolony z niespójności kodu.
W przypadku zakładek na stronie rejestracji/logowania na razie zostawię, jak jest. A jeśli chodzi o ten link „regulamin”, zależało mi na użyciu tagu dl w kodzie. Bo przecież on najbardziej pasuje. Zdecydowanie bardziej niż p lub — o zgrozo — table. Ale skoro etykieta pola tekstowego ląduje w dt, a samo pole w dd, to w przypadku pól checkbox/radio też tak musi być. A własnie w przypadku tych pół większość userów (w tym ja też) jest przyzwyczajona do odwrotnej kolejności na ekranie, dlatego podmnieniam przez CSS kolejność.
W tej chwili zastosowałem chamskie rozwiązanie o nazwie tabindex=”-1″ dla linku do regulaminu. Jak ktoś niepełnosprawny ruchowo będzie chciał go przeczytać, może użyć linku w stopce.
——-
„Lista w stopce może być otoczona dodatkowo przez nav. Natomiast informacja o prawach autorskich nie pasuje jako element tej listy – to raczej powinien być akapit poza nią, odpowiednio ostylowany.”
Poprawione. To dzięki twojej ewangelizacji użyłem w ogóle ul. Kiedyś robiłem to przez pionową kreskę… Eh.
A co do tego nav, to czytałem gdzieś kiedyś, że tym tagiem należy oznaczać tylko główną nawigację, a nie każdą możliwą. Dlatego też zawsze unikałem tego tagu w stopce. Co na ten temat mówi twoje doświadczenie? W specce tagu nav czytam:
„Not all groups of links on a page need to be in a nav element — the element is primarily intended for sections that consist of major navigation blocks. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases; while a nav element can be used in such cases, it is usually unnecessary.”
——-
„Również PageSpeed Insights nie narzeka zbytnio, chociaż pokazuje, że strona nie jest responsywna – a szkoda.”.
Już jest.
—-
Na razie tyle poprawek. Chętnie przeczytam twoją odpowiedź, gdy oczywiście znajdziesz na nią chwilkę czasu.
Czy mógłbym jeszcze prosić o skrytykowanie mojego kodu JS? pliki „formsUI”, „radioTable” oraz „radioTableColumnsUI” znajdują się z odpowiednim rozszerzeniem niezminifikowane w podkatalogu „scripts”. Z góry dzięki, jeśli znajdziesz dla mnie jeszcze czas. 😉
A co jeśli Ci powiem, że zwróciłem na to uwagę właśnie dlatego, że dla mnie linki są lekko rozmyte? Owszem, dla większości użytkowników nie powinno to zrobić żadnej różnicy (zwłaszcza, że czcionka jest duża), ale zawsze zdarzy się ktoś taki jak ja 😉
Certyfikat może być dowolny (BTW polecam od siebie Let’s Encrypt), a samą obsługę HTTP/2.0 można dodać z poziomu serwera WWW (np. mod_http2 dla Apache 2.4+). Niemniej najpierw polecam poczytać jakie korzyści taka zmiana może przynieść (np. server push).
Oczywiście, że nie.
Prawdę mówiąc powiedziałbym raczej intersubiektywnymi, bo nie tylko ja tak uważam 😉
Problem polega na tym, że user sam umie sobie otworzyć stronę w nowej karcie jeśli zajdzie taka potrzeba. Natomiast, gdy dostawi się
[target=_blank]osoby chcące otworzyć stronę w tej samej karcie mają problem.Pytanie, czy Twoi użytkownicy również tego nie lubią 😉 Na przeważającej większości stron mimo wszystko pozostawiany jest domyślny kursor dla tekstu. Tym samym stał się on de facto standardem. Trzeba by było zrobić odpowiednie badania UX, ale z osobistego doświadczenia mogę powiedzieć, że
cursor: defaultdla tekstu powoduje wrażenie (przynajmniej u części userów), że… strona się zepsuła (kursor się nie zmienił).Skrypty inline blokują rendering tylko jeśli są słane po arkuszach stylów. W chwili, gdy taki skrypt wstawi się przed arkusze, nie blokuje renderingu, bo… nie ma czego blokować. CSSOM jeszcze nie istnieje i nie trzeba aplikować stylów. Co więcej – takie umiejscowienie skryptu statystyk pozwoli złapać jeszcze więcej userów (choćby takich, którzy tylko wejdą i od razu zamkną stronę, zanim się nawet doczyta).
Raczej chodziło mi dla całej sekcji/formularza, nie samego pola.
Nie, brakuje jeszcze reakcji na spację. Mimo wszystko Enter bardziej kojarzy się z linkami niż przyciskami.
Tak, to prawda. Ale jeśli nie użyłbyś sekcji, nagłówek
h2bezpośrednio wmain/bodybyłby na tym samym poziomie, co nagłówek dlanav(czyli dokładnie taki sam efekt jak obecnie). Poza tym: algorytm outline to totalna fikcja i wręcz usuwa się polecanie go ze specyfikacji HTML5. Tym samym wracamy do starego, dobrego tworzenia outline przy pomocyh1–h6. Częściowo co prawda zabija to sens używania sekcji, no ale co poradzić…Jeśli menu w stopce jest powtórzeniem menu z
header, to IMO można to spokojnie otoczyćnav– niemniej nie trzeba. Natomiast fakt, że specyfikacja stwierdza, że jest to niekonieczne, śmieszy tym bardziej, gdy spojrzy się na przykłady użycia np.kbd, gdzie znajdziemy potworki typukbd > samp > kbd😉Wieczorem postaram się spojrzeć i dorzucę to tutaj jako następny koment.
Pozwolę sobie dodać dwie uwagi od strony dostępności. WCAG określa parametrem kontrast pomiędzy tłem i tekstem właśnie dlatego, żeby projektant nie zastanawiał się, czy jest wystarczający. Można to zignorować i wtedy należy mieć świadomość naruszenia zasad dostępności. Kontrast jest poważnym problemem dla osób słabowidzących, których w Polsce jest ponad 700 tysięcy. Nie piszę tu o okularnikach, a osobach naprawdę mających problemy ze wzrokiem.
Druga uwaga dotyczy atrybutu role=”search”. Kiedyś odkryłem, co było dla mnie zaskoczeniem, że tej rodziny atrybutów można używać tylko ze znacznikiem DIV. Osobiście uważam to za nielogiczne, bo powinno się dać stosować z każdym znacznikiem z obowiązkowym zamknięciem, na przykład FORM. Tak to jednak wymyślono, więc tego trzeba się trzymać.
Pozdrowienia
Hmm, walidator nie wskazuje obecności tego atrybutu na
formjako błędu. W specyfikacji HTML5 z kolei zaznaczono, żeformmoże przyjąć dowolną rolę ARIA. Być może zatem ten mankament został już naprawiony?Zaraz zerknę i w razie czego – walnę się w pierś. Sprawdzałem dla znacznika OL dla tworzenia menu. Tam aż się prosi o role=”navigation” i się nie dało. Trzeba było otoczyć DIV. Pewnie więc jakoś uogólniłem to na wszystkie znaczniki.
Pamiętam, że swego czasu czytałem uzasadnienie tego: że nawigacja to coś więcej niż menu. I to bardzo ładnie w sumie widać po patternie, jaki wytworzył się dzisiaj wokół
nav, gdzie sam rejon nawigacji wyznaczanav, a dopiero w nim znajduje się menu. Często towarzyszy też temu nagłówek określający dokładną rolę akurat tego rejonu nawigacyjnego.Oczywiście można to machnąć przy pomocy
ul[role=navigation][aria-label], ale gdzieś traci się przejrzystość kodu.