Szablon Starbis

Po raz kolejny dostałem od TemplateMonster szablon do oceny, tym razem pod wdzięczną nazwą Starbis. Zobaczmy zatem, co takiego ciekawego skrywa.

• Tradycyjnie zacznę od procesu sprzedaży, bo ten… znów się zmienił. Nie wiem jednak, czy na lepsze. Zakup szablonu bowiem spowodował automatyczne założenie konta. Z jednej strony fajnie, bo mam miejsce, w którym sprawdzę jakie szablony kupiłem. Z drugiej – czasami chcę coś kupić i po prostu zapomnieć o sklepie.
• Po ściągnięciu szablonu, zajrzałem do paczki. A tam – ku mojemu zdziwieniu – oprócz tradycyjnych plików źródłowych, do czegokolwiek bym sobie nie zażyczył, kreator strony. I to nawet o bardzo fajnym interfejsie. Co prawda dla mnie mało przydatne (no ok, nie aż tak bardzo, bo planuję taki stworzyć, więc warto wiedzieć, co oferuje konkurencja…), niemniej robi pozytywne wrażenie. Chyba najlepsza wartość dodana, jaką dotychczas widziałem w szablonach.
• Sam szablon strony dostajemy aż w 6 wersjach, różniących się branżą i brandingiem. Niby jeden szablon, a ile możliwości.
• Nie można też powiedzieć, że szablon nie ma dokumentacji, bo sam kreator ma 40 stron dokumentacji. Robi wrażenie.
• Dobrze, przejdźmy w końcu to samej strony. A tam od razu wita nas kolejny, źle zaprojektowany preloader. Jeśli bowiem strona nie doczyta jakiegoś zasobu (lub mimo wszystko trafimy na mitycznego użytkownika, który wyłączył JS), utkniemy na wirującym pasku ładowania i nie zobaczymy nic ze strony. Tego typu rzeczy są raczej zarezerwowane dla aplikacji internetowych, nie stron. Jeśli strona ma preloader, to poważnie bym się zastanowił, czy przypadkiem nie powinna być po prostu odchudzona. Zwłaszcza, że 5 MB to bardzo dużo!
• Nawigacja klawiaturą jest niemożliwa. Nie dość, że nie widzę, gdzie aktualnie jest focus, to jeszcze menu rozwijane nie działa po sfocusowaniu. Bardzo poważne błędy dostępności i użyteczności.
• W formularzach etykiety pól za bardzo przypominają [placeholder]. To sprawia, że formularz nie jest intuicyjny przy wypełnianiu, bo w chwili, gdy użytkownik kliknie pole, etykieta znika bezpowrotnie i w sumie nie wiadomo, co za pole się wypełnia.
• Przejdźmy do kodu. Walidację co prawda przechodzi, ale hierarchia nagłówków jest strasznie zmasakrowana.
• Duży plus za określenie języka dokumentu.
• Duży minus za umieszczenie deklaracji kodowania daleko w dole.
• Wyłączono skalowanie strony – jeśli czegoś nie widzisz, to jednak nie zobaczysz. Jeśli nie mamy pewności, że nasz layout jest tak zaprojektowany, że każdy odczyta wszystko (czyli de facto nigdy), nie blokujmy powiększania strony! To jedno z podstawowych narzędzi podnoszących dostępność. Nie widzę sensu w psuciu go.
• Natomiast muszę pochwalić za ładne dołączenie fontów. No prawie, bo jednak FOIT się pojawi.

• <a href="index.html" class="brand brand-md"><img src="images/logo-white.svg" width="139" height="22" alt="logo"/></a>

  Klasyka gatunku, czyli niewłaściwy atrybut [alt]. Jeśli obrazek jest wewnątrz linka, [alt] powinien wskazywać na to, gdzie link odsyła. A ten bynajmniej nie odsyła do logo.

• <nav data-layout="rd-navbar-fixed" data-sm-layout="rd-navbar-fixed" data-md-device-layout="rd-navbar-fixed" data-lg-layout="rd-navbar-static" data-lg-device-layout="rd-navbar-static" data-stick-up-clone="false" data-body-class="rd-navbar-static-smooth" data-md-stick-up-offset="60px" data-lg-stick-up-offset="60px" data-md-stick-up="true" data-lg-stick-up="true" class="rd-navbar rd-navbar-default">

  Wygląda to przerażająco. Tego typu konfigurację raczej powinno się przerzucić do JS-a – zwłaszcza jeśli jest jej aż tyle.

• <button data-custom-toggle=".rd-navbar-nav-wrap" data-custom-toggle-disable-on-blur="true" class="rd-navbar-toggle"><span></span></button>

  Pusty element = niedostępny element! Ten przycisk nie ma treści dla nikogo więcej poza szczęśliwcem, któremu doczytał się CSS i obrazki. Nie ma treści zwłaszcza dla użytkowników czytników ekranowych.

  Niestety, widzę, że ta choroba dotknęła większość przycisków na stronie…

• Spory divitis.
• Nie ma żadnego głównego nagłówka strony. Pierwsze nagłówki to te ze slidera, co zaburza hierarchię nagłówków i utrudnia nawigację osobom z niepełnosprawnościami.
• Oczywiście przyciski w sliderze nie są przyciskami, przez co nie da się choćby operować nimi z poziomu klawiatury.
• Zastąpienie figure > figcaption przez figure + h4 to poważne naruszenie semantyki i tworzenie niepotrzebnych nagłówków. Miałoby to sens, gdyby wywalić figure, nagłówek wstawić przed obrazkiem i dodać krótki opis do każdego projektu.
• Stosowany tutaj zapis section > article zamieniłbym na article > section (ma więcej sensu semantycznego).
• div.divider to dobrzy kandydaci na pseudoelementy.
• figure>img[alt=""] wskazuje na niepoprawne użycie figure. Ten znacznik nie służy do wstawiania ozdobników, a obrazków niosących treść!
• Nagle jest wysyp stylów inline, które łamią zasady CSP i przy okazji zasadę podziału warstw aplikacji.

• <address class="contact-info text-left">
  	<div class="unit unit-horizontal unit-spacing-xs unit-middle unit-align-center unit-sm-left">
  		<div class="unit-left"><span class="icon icon-md-custom icon-gunsmoke material-icons-phone"></span></div>
  		<div class="unit-body">
  			<div class="link-wrap"><a href="callto:#" class="link-white-03 text-light">+123 234 984 47 45</a></div>
  			<div class="link-wrap"><a href="mailto:#" class="link-white-03 text-light">info@demolink.com</a></div>
  		</div>
  	</div>
  </address>

  Kolejny klasyk: linki bez opisu. Ikonka nie niesie żadnej treści, stąd lepiej to zrobić na liście dl i ikonkę (wraz z dodatkowym opisem dla czytników ekranów) wstawić do dt.

•  <ul class="list-inline list-inline-xs">
  	<li><a href="#" class="icon icon-sm-custom link-tundora-inverse fa-facebook"></a></li>

  I znów klasyk: podwójny. Raz, że dostajemy listę bez opisu, dwa, że ikonka sama w sobie nie jest treścią.

• Oczywiście nie byłbym sobą, gdybym nie sprawdził jak zrobione są formularze:

  <div class="form-group">
  	<input id="feedback-time" type="text" name="time" data-constraints="@Required" data-time-picker="time" class="form-control">
  	<label for="feedback-time" class="form-label">Time Interval</label>
  </div>

  Niby dobrze, ale jednak źle. W chwili, gdy użytkownik będzie korzystał z czytnika ekranowego, najpierw trafi do pola, a dopiero po jego wypełnieniu pozna, co tak naprawdę wypełniał. Kolejność w kodzie jest ważna!

I znów mam straszny dylemat… Jeśli wziąć pod uwagę liczbę dostępnych dodatków, pełny dostęp do kodu źródłowego, rozległość samego szablonu czy wreszcie kreator, to bez wątpienia jest to najbardziej zaawansowany szablon jaki widziałem. Ale po raz kolejny, gdy spoglądam w kod, widzę, że był pisany z myślą o pełnosprawnych osobach, które używają wyłącznie najnowszych, dobrych przeglądarek.

Mimo że połączenie dostępności i piękna jest trudnym wyzwaniem, to myślę, że właśnie na tym powinien obecnie skupiać się webdesign. Jak bardzo jest to ważne a równocześnie wcale nie aż tak trudne, najlepiej chyba pisze Heydon Pickering w swojej nowej książce Inclusive Design Patterns. Coding Accessibility Into Web Design. Naprawdę otwiera oczy i gdyby choć 5% webdesignerów na świecie ją przeczytało i w pełni przyswoiło, jakże piękną Sieć byśmy mieli! A jeśli już nie piękną, to przynajmniej dla wszystkich.

Szablon w wersji podstawowej (z niedziałającym PHP ze względów bezpieczeństwa) wrzuciłem już na serwer.