www.RankHouse.pl

Dzisiaj na WebKrytyku będzie całkiem tradycyjnie, ponieważ przyjrzymy się zwykłej stronie internetowej, RankHouse.pl.

Wygląd/działanie

• Po wejściu na stronę jest nieco tłoczno. Z prawej strony znajduje się otwarty formularz pozwalający zamówić darmową wycenę, z lewej z kolei, na dole – przycisk do zamówienia rozmowy telefonicznej z konsultantem (którego, niestety, nie da się wyłączyć; przycisk, nie konsultanta). Z kolei gdy nieopatrznie wyjechałem myszą poza górny obszar strony, pojawił się popup, zachęcający mnie do zostawienia danych kontaktowych. Prawdę mówiąc uważam to już za dość nachalne nagabywanie mnie do skorzystania z usług.

• Co ciekawe, na samej górze strony znajduje się komunikat informujący o tym, że strona nie działa poprawnie przy włączonym dodatku blokującym reklamy. Nie bardzo wiem jednak, co konkretnie miałoby nie działać, bo strona wygląda tak w przeglądarce z wyłączonym blokowaniem reklam.

• Formularz zamówienia bezpłatnej wyceny nie działa bez JS-a, mimo że jest dość prosty. Odsyła jednak do nieistniejącej podstrony. A szkoda.

• Grafika w nagłówku strony jest tak naprawdę sliderem, który ma nawigację w postaci kropek. Niemniej kropki te są praktycznie niewidoczne, znajdując się na ciemnym tle. To dość poważny problem z użytecznością i dostępnością. O wiele lepiej byłoby umieścić w takim wypadku nawigację pod sliderem lub nadać kropkom wyraźne, jednolite tło.

• Spora część tekstu (fragmenty nagłówków, linki, aktywne linki w menu…) ma zdecydowanie za niski kontrast. To sprawia, że tekst staje się nieczytelny.

• Chociaż po stronie da się nawigować przy pomocy klawisza Tab, to niestety najczęściej nie widać, gdzie aktualnie znajduje się focus. Wypadałoby dodać jakieś bardziej wyróżniające się style dla :focus.

• Formularz kontaktowy ma źle podpięte etykiety, przez co ich klikanie nie przenosi focusu do odpowiedniego pola.

• Strona na urządzeniach mobilnych nie pozwala na powiększanie, co jest tak naprawdę złamaniem zalecenia 1.4.4 standardu WCAG 2.1. I choć strona na urządzeniu mobilnym wygląda moim zdaniem o wiele bardziej przejrzyście niż na urządzeniu desktopowym, to wciąż powinna istnieć możliwość powiększenia tekstu.

• Praktycznie wszystkie podstrony są skonstruowane w podobny sposób, dlatego też większość wymienionych tu uwag można odnieść także do nich.

Kod

• <!--    <meta charset="utf-8">-->
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

  Co prawda nie jest to błąd, ale ciekawi mnie, co stało za tym, by zamienić krótką wersję na długą.

• 13 arkuszy stylów oraz 19 skryptów JS, czyli łącznie 32 elementy blokujące rendering. To wpływa znacząco na wydajność strony – co zresztą PageSpeed pokazuje.

• <div id="nav-switch" class="nav-toggle">
  	<span class="l1"></span>
  	<span class="l2"></span>
  	<span class="l3"></span>
  </div>
  <nav id="main-menu">

  Tak stworzony przycisk do otwierania nawigacji jest niedostępny. Warto przy tym zauważyć, że przycisk powinien być wewnątrz elementu nav. Wówczas, gdy osoba posługująca się czytnikiem ekranowym przemieści się do elementu nawigacyjnego, znajdzie tam przycisk. W chwili, gdy przycisk jest poza nav, osoba korzystająca z czytnika ekranowego może trafić do pustego elementu, co wywoła zapewne konsternację.

• <h2>                    <strong></strong></h2>

  Na stronie powinna być zachowana sensowna hierarchia nagłówków. Co więcej, takie puste nagłówki mogą utrudniać poruszanie się po stronie użytkownikom czytników ekranowych, które umożliwiają przeskakiwanie od nagłówka do nagłówka. W takim wypadku użytkownik może natrafić na pusty, bezsensowny z jego punktu widzenia, nagłówek.

• <div class="element-row"><input type="text" id="fullName" name="fullName" value=""   placeholder="Firma lub imię i nazwisko"   class="form-control form-control form-control-text form-control form-control-text" /></div>

  Każde widoczne pole formularza powinno mieć label. Dodatkowo część środowiska specjalistów od dostępności twierdzi, że brak widocznej przez cały czas etykiety jest złamaniem zaleceń WCAG 2.1. Osobiście też przychylam się do takiej interpretacji.

• <a href="https://www.google.com/partners/agency?id=9785311800"><img src="/static/images/googlepartner.png" alt="" /></a>

  Tego typu link jest niedostępny, bo jego treść określa atrybut [alt] obrazka. W chwili, gdy jest on pusty, technologia asystująca (w tym czytniki ekranowe) dostaje informację, że to pusty link.

• Na dole strony znajduje się sporo kodu JS. Wyrzucenie go do zewnętrznego pliku wydaje się lepszym pomysłem niż trzymanie go bezpośrednio w kodzie HTML.

Mimo że strona wygląda profesjonalnie, a sama treść zachęca do skorzystania z usług SEO firmy, to nie można zignorować jej problemów z wydajnością i dostępnością. Osobiście czekam z utęsknieniem na czasy, w których wszystkie trzy aspekty (SEO, wydajność i dostępność) będą się uzupełniać i razem tworzyć strony, które są dostępne dla wszystkich, wydajne, responsywne, a równocześnie – dobrze się pozycjonują. Chociaż może zamiast z utęsknieniem czekać, wypada po prostu zakasać rękawy…