Smultron.pl

Dzisiaj klasyczny WebKrytyk – króciutka recenzja strony WWW. Tym razem padło na stronę firmy Smultron.

Wygląd i działanie

Strona nie pokazuje dużej części treści w sytuacji, gdy JS nie działa. To sprawia, że istnieje możliwość niezobaczenia treści przez część odwiedzających. Dodatkowo taki sposób animowania treści (ukrycie jej „na chama”, od razu) może spowodować niezaindeksowanie treści oraz problemy z obsługą takiej strony przez technologię asystującą. Tego typu efekt lepiej jest zaaplikować, ukrywając treść dopiero wtedy, gdy wykryje się interakcję ze strony użytkownika (a dokładniej: rozpoczęcie scrollowania). Na starcie wszystko powinno być domyślnie pokazane.
Na stronie nie widać focusa. To oznacza, że nie da się w żaden sensowny sposób nawigować po stronie przy użyciu klawiatury. Dodatkowo część elementów, które są ukryte (np. zwinięte menu mobilne czy przykładowe realizacje, które nie mieszczą się na moim ekranie) są mimo to dostępne jako tzw. tab-stopy (elementy możliwe do sfocusowania przy pomocy klawisza Tab).
Wydaje mi się, że na polskiej wersji strony opinie klientów napisane po angielsku powinny mieć odpowiednie tłumaczenia (i w drugą stronę tak samo). Nie powinno sprawić to większych problemów.
Zastosowanie inline’owych etykiet w formularzu sprawia, że w momencie wypełnienia pól tracimy tak naprawdę informacje o tym, do czego dane pole służy. W przypadku tego formularza da się to zrozumieć z kontekstu, niemniej uważam, że etykieta powinna być zawsze widoczna, co znacząco podnosi dostępność formularza.
Niektóre linki w menu prowadzą do miejsc na stronie, które mają inne identyfikatory niż nazwa pozycji w menu, np. link „Nasze realizacje” prowadzi do kotwicy #projekty. Dodatkowo pozycja „Co robimy” odsyła do kotwicy #co_robimy. Podkreślnik nie jest optymalnym sposobem zaznaczania, że mamy do czynienia z kilkoma słowami i powinien zostać zastąpiony myślnikiem, co sugeruje nawet Google.

Kod

Przejdźmy do kodu. Walidator nie pokazuje nic ciekawego. Jedyne zastrzeżenia można mieć do hierarchii treści, która nie ma sensu.

<!--[if IE 9]> <html class="no-js ie9" lang="pl-PL"> <![endif]-->
<!--[if gt IE 8]><!-->
<html class="no-js desktop" dir="ltr" lang="pl-PL">
<!--<![endif]-->

Tego typu zapis sprawia, że IE9 dostanie dwa znaczniki html, ponieważ obydwa warunki będą spełnione (wersja IE to 9, a 9 jest przecież większe niż 8).

Osobiście nie jestem zwolennikiem zastosowanej tutaj techniki optymalizacyjnej polegającej na wklejeniu całego kodu CSS i sporej części kodu JS bezpośrednio do HTML-a. Mimo wszystko uważam, że techniki polegające na połączeniu HTTP/2 server pusha z preloadingiem dla większości aplikacji dadzą w dłuższej perspektywie o wiele lepsze wyniki (np. z powodu większych możliwości zarządzania cache’em). Zwłaszcza, że w head i tak znalazły się dwa blokujące skrypty, które niejako podważają sens takiej agresywnej optymalizacji.
Elementy takie jak body > header, nav mają domyślnie określone pewne role ARIA ([role=banner], [role=navigation]) i nadawanie im ich wprost nie jest zalecane.
W nawigacji pojawia się ciekawa sytuacja: logo jako link do strony głównej poza menu, a następnie reszta linków nawigacyjnych już w menu. Osobiście uważam, że w tym wypadku logo powinno być traktowane jako pierwszy element menu, który po prostu będzie inaczej ostylowany. Ma to sens, bo przecież link do strony głównej też powinien być częścią menu.
Następnie znajduje się sekcja, w której jest nagłówek h1 z klasą .is-hidden. Klasa ta ma nadane w CSS display: none, co sprawia, że tego nagłówka równie dobrze mogłoby najzwyczajniej w świecie nie być, bo jest ignorowany zarówno przez technologię asystującą, jak i wyszukiwarki (które dodatkowo mogą go uznać za ukrytą treść). Co więcej, ten nagłówek nie do końca oddaje sens tej strony. Na stronach typu one-page nagłówek powinien w sposób opisowy zaznaczać, o czym dokładnie jest ta strona (tutaj można się pokusić o nagłówek zawierający nazwę firmy).
Następujący po tym nagłówku h1 nagłówek h3.is-hidden nie ma najmniejszego sensu. Nie dość, że zaburza hierarchię treści, to dodatkowo jest duplikowany przez znajdujący się tuż po nim nagłówek h2, który już nie jest ukryty.

<a class="sanim1 sanim" href="#co_robimy"><img src="https://smultron.pl/wp-content/themes/smultron2014/img/anim1-bg-100.png" srcset="https://smultron.pl/wp-content/themes/smultron2014/img/anim1-bg.png 1x, https://smultron.pl/wp-content/themes/smultron2014/img/anim1-bg-100.png 2x" alt="" /><img src="https://smultron.pl/wp-content/themes/smultron2014/img/anim1-1.png" id="a11" alt="" /><img src="https://smultron.pl/wp-content/themes/smultron2014/img/anim1-2.png" id="a12" alt="" /><img src="https://smultron.pl/wp-content/themes/smultron2014/img/anim1-3.png" id="a13" alt="" /></a>

Ten kod jest niedostępny, ponieważ obrazek nie zawiera żadnej etykiety tekstowej. Tym sposobem sam link takowej etykiety nie ma.

<h2><a href="#co_robimy"><span class="onDesktop">Oprogramowanie Frontend</span><span class="onMobi">Front-end</span></a></h2>

Zamiast tworzyć dwie całkowicie osobne wersje treści na desktopy i urządzenia mobilne, można przecież zastosować ukrycie części tekstu ze względu na urządzenie:

<h2>
	<a href="#co_robimy"><span class="hidden-on-mobile">Oprogramowanie</span> Frontend</a>
</h2>

Nawigacja znajdująca się wewnątrz main również mogłaby być umieszczona wewnątrz znacznika nav. Rozróżniać te dwie nawigacje można by było następnie przy pomocy różnych etykiet dla nich, nadanych choćby przy pomocy [aria-label].
Przycisk do otwierania menu w nav powinien być przyciskiem, który będzie odpowiednio oznaczony.

<section id="co_robimy" class="whatwedo group">
	<h2 class="sectionHeader">Co robimy</h2>
	<article class="whatwedo-item" id="frontend">
		<h3 class="is-hidden">Oprogramowanie Frontend</h3>
		<div class="layout"><i class="ico ico-frontend"></i>
			<div class="animc">
				<h2>Oprogramowanie Frontend</h2>
				<p><strong>Na froncie walki o dobry UX zwyciężamy nowoczesnym orężem: SASSem i LESSem. GRUNTownie czy PREPROSowo – nasz kod jest zawsze zgodny z projektem i działa jak trzeba, mobilnie i na desktopie. Priorytet to estetyka i pełna kompatybilność. Efektownymi dodatkami, czyli paralaksami i 3D rolloverami, dekorujemy przy okazji. Świeży, przejrzysty front to wizytówka nowoczesnej firmy – dobre wrażenie i pierwszy krok do zaangażowania klienta.</strong></p>
				<footer>
					<ul>
						<li>HTML5</li>
						<li>CSS3</li>
						<li>JQUERY</li>
						<li>RWD</li>
					</ul>
				</footer>
			</div>
		</div>
	</article>
	[…]
</section>

Ta struktura jest zła z kilku powodów:

h3.is-hidden razem z następującym po nim h2 nie ma najmniejszego sensu. Ten artykuł powinien mieć nagłówek 3. poziomu i tylko taki. Dodatkowo ten nagłówek powinien być widoczny.
Ikony powinno wstawiać się przy pomocy znacznika span[aria-hidden=true].
Znacznik strong służy do wyrózniania małych fragmentów tekstu, nie całych bloków. Dodatkowo w żadnym wypadku nie służy do pogrubiania (co jest prawdopodobnie motywacją do użycia go tutaj), a do nadawania specjalnej ważności tak oznaczonemu tekstowi:

The strong element represents strong importance, seriousness, or urgency for its contents.

[Element strong reprezentuje sporą ważność, poważność lub pilność swojej zawartości.]
Znacznik footer nie ma tutaj sensu, bo nie zawiera metadanych dotyczących treści artykułu. Lista technologii wchodzących w skład frontendu jest po prawdzie integralną częścią tego artykułu.

Osobiście całą tę strukturę widziałbym jako:

<section id="co-robimy" class="whatwedo group">
	<h2 class="sectionHeader">Co robimy</h2>

	<article class="whatwedo-item" id="frontend">
		<div class="layout">
			<span class="ico ico-frontend" aria-hidden="true"></span>
			<div class="animc">
				<h2>Oprogramowanie Frontend</h2>
				<p>Na froncie walki o dobry UX zwyciężamy nowoczesnym orężem: SASSem i LESSem. GRUNTownie czy PREPROSowo – nasz kod jest zawsze zgodny z projektem i działa jak trzeba, mobilnie i na desktopie. Priorytet to estetyka i pełna kompatybilność. Efektownymi dodatkami, czyli paralaksami i 3D rolloverami, dekorujemy przy okazji. Świeży, przejrzysty front to wizytówka nowoczesnej firmy – dobre wrażenie i pierwszy krok do zaangażowania klienta.</p>
				<p>Wykorzystywane technologie:</p>
				<ul>
					<li>HTML5</li>
					<li>CSS3</li>
					<li>jQuery</li>
					<li>RWD</li>
				</ul>
			</div>
		</div>
	</article>
	[…]
</section>

W galerii zrealizowanych projektów zdecydowanie wyciągnąłbym opis projektu poza link, zostawiając w samym linku jedynie nazwę projektu. Odpowiednią interakcję można by zrobić przy pomocy selektora a:hover + .description, a:focus + .description + pointer-events: none; dla opisu, by nie zasłaniał on samego linka. No i oczywiście pozbyłbym się bezsensownego ukrywania nagłówka (ale nie samego nagłówka!).
```
<a class="fbLink" href="http://facebook.com/SmultronLab" target="_blank"><i class="ico ico-fb2"></i> Zobacz</a>
```
Tego typu link wyciagnięty z kontekstu nie ma najmniejszego sensu. Zawsze powinno się tak układać treść linków, by nawet wyciągnięte z kontekstu (np. przy pomocy funkcji przeglądarki do prezentacji wszystkich linków w formie listy) miały sens. W tym wypadku lepszy byłby tekst typu „Zobacz więcej o naszym zespole”.
Opinie klientów doskonale nadają się do prezentacji jako cytaty (blockqouote + cite) – bo tym przecież w gruncie rzeczy są: cytatami z wypowiedzi klientów. Wykorzystanie tutaj em, i jest błędem, bo przeznaczenie tych znaczników jest całkowicie inne.
Każda opinia powinna mieć unikalny nagłówek („Opinia klienta XYZ”), który oczywiście nie powinien być ukryty.
Dane adresowe bardzo fajnie można by przedstawić jako listę dl zamkniętą w znaczniku address.
No i na koniec proste pytanie: po co WordPress do tak prostej strony?

Choć strona wygląda ładnie, to pod spodem stosuje naprawdę sporo dziwnych rozwiązań, które skutecznie obniżają jej dostępność i użyteczność. Największym grzechem jest bez wątpienia superdziwaczny sposób używania nagłówków, który nie ma najmniejszego sensu. Przyznać jednak należy, że poprawne użycie nagłówków jest naprawdę rzadkie (tak rzadkie, że jest to jeden z argumentów w dyskusji nad zmianami w algorytmie outline’u w HTML LS!). A szkoda.

9 komentarzy do “Smultron.pl”

Tomek Różalski pisze:

30 kwietnia 2018 o 16:38

> No i na koniec proste pytanie: po co WordPress do tak prostej strony?

Przyganiał kocioł garnkowi, bo czyż ten blog nie jest też na WP 😉 Swoją drogą nie uważasz, że budowanie stron poświęconych webdevelopmentowi (blogi, strony firmowe firm IT) zaczyna być siarą? Na miejscu właścicieli Smultron, kazałbym swoim devsom jak najszybciej przerobić to na Gatsbiego. So fancy!

A tak z językowego punktu widzenia, czy tylko mnie razi sformułowanie „Oprogramowanie Frontend”? Jakieś takiego przesadzone, jak „metodyka używania cepa” 😀

Odpowiedz
1. Comandeer pisze:
  
  30 kwietnia 2018 o 16:41
  
  Kontekst to ważna sprawa 😛 Strona Smultrona to tak naprawdę 2 widoki (wersja polska i angielska), nie ma tam nic więcej. Z tego też powodu nie sądzę, by jakikolwiek CMS był tam potrzebny. I tak, Gatsby czy Jekyll byłyby IMO o wiele lepsze.
  
  Tak, ten blog stoi na WordPressie, ale – jest blogiem 😉 Poza tym stał na WP od zarania dziejów i prawdę mówiąc na razie nie mam czasu się zastanowić nad jakąś migracją.
  
  Co do „Oprogramowania Frontend” – tak po prawdzie jest to wyrażenie niepoprawne. Powinno być „Frontend” albo „Oprogramowanie frontedowe”.
  
  Odpowiedz
  1. Marcin Stawowiak pisze:
    
    14 maja 2018 o 12:57
    
    „Poza tym stał na WP od zarania dziejów i prawdę mówiąc na razie nie mam czasu się zastanowić nad jakąś migracją.”
    
    świetny argument, właśnie między innymi z tych dwóch powodu nasza strona http://www.smultron.pl stoi na WP 😉
    
    A poważnie, to dziękuję za uwagi. Strona ma już swoje lata (ponad 3 lata), i w zasadzie już ponad rok temu planowaliśmy ją zmieniać, niestety jak dotąd nie mieliśmy na to czasu. Co, jak sądzę, zdarzy się w ciągu najbliższego kwartału 🙂
    
    Zapraszam zatem do rewizyty gdzieś we wrześniu 🙂
    
    P.S. nowa strona również będzie na WP
    
    P.S. 2 – szukamy frontendowców, javascriptowców oraz wordpressowców, korzystając z okazji zapraszam do aplikowania 🙂
    
    Odpowiedz
    1. Comandeer pisze:
      
      14 maja 2018 o 12:59
      
      świetny argument, właśnie między innymi z tych dwóch powodu nasza strona http://www.smultron.pl stoi na WP 😉
      
      Touché…
      
      Odpowiedz
SpeX pisze:

5 maja 2018 o 21:57

A tak z ciekawości, trafiłeś może na ten raport?
http://www.rynek-kolejowy.pl/wiadomosci/ranking-dostepnosci-stron-internetowych-przewoznikow-wiekszosc-niedostatecznie-83478.html
Co prawda chodzi tylko o strony kolejowe, ale jest właśnie w aspekcie osób niedowidzących.

Odpowiedz
1. Comandeer pisze:
  
  5 maja 2018 o 22:02
  
  Przewinął mi się gdzieś tam, wrzuciłem go na listę rzeczy do przeczytania i nigdy już do tego nie wróciłem. Dzięki za przypomnienie.
  
  Odpowiedz
wiernyFanWebKrytyka pisze:

16 maja 2018 o 20:36

Comandeer napisałeś:

„W nawigacji pojawia się ciekawa sytuacja: logo jako link do strony głównej poza menu, a następnie reszta linków nawigacyjnych już w menu. Osobiście uważam, że w tym wypadku logo powinno być traktowane jako pierwszy element menu, który po prostu będzie inaczej ostylowany. Ma to sens, bo przecież link do strony głównej też powinien być częścią menu.”

Chciałbym poznać Twoje rozwiązanie w tej sytuacji, bo jeśli zrobimy tak jak mówisz i wsadzimy to logo jako pierwszy element menu to wtedy przy zmniejszeniu szerokości przeglądarki do momentu pojawienia się togglera logo zniknie i będzie widoczne już tylko w „rozwijanym” menu, a więc by to wszystko miało sens wypadałoby poza menu umieścić pierwsze logo i nadać mu display:none a drugie logo byłoby tak jak wspomniałeś w menu i po zmniejszeniu szerokości przeglądarki wypadałoby temu pierwszemu nadać display:block by było widoczne tak jak jest teraz, a znowu to drugie logo w menu ukryć, o takie coś Ci chodziło?

Odpowiedz
1. Comandeer pisze:
  
  17 maja 2018 o 01:23
  
  Prawdę mówiąc przy hamburgerze to niestety średnio działa. Pisząc to, miałem w głowie raczej rozwiązania, jakie można spotkać u specjalistów do spraw dostępności, np. u Adriana Roselliego, Scotta O’Hary, Heydona Pickeringa czy Paciello Group. Zresztą nie tylko oni unikają hamburgera, bo Jeremy Keith też ma uczulenie na niego, tak samo jak i ja.
  
  Osobiście uważam, że takie zaprojektowanie nawigacji, by nie trzeba było się uciekać do hamburgera, jest lepsze i użyteczniejsze.
  
  Odpowiedz
Tomasz Gąsior pisze:

19 maja 2018 o 19:28

Mam propozycję na następną krytykę: pajacyk.pl. Nie działa bez JS, outline skryty, silna ingerencja w scroll.

Odpowiedz