Podsumowanie
Dostępna strona internetowa to taka, która zapewnia pełną czytelność i nawigowalność dla wszystkich użytkowników – zarówno korzystających z myszy, jak i klawiatury czy technologii wspomagających. Kluczowe elementy to semantyczna i hierarchiczna struktura nagłówków (jedno h1
, następujące po nim h2–h6
), zgodność URL–
–h1
, właściwie opisane obrazy (alt
i responsywne srcset
), odpowiednio uzupełniane atrybuty title
przy linkach (szczególnie przy linkach graficznych), łatwa nawigacja klawiaturą (w tym link „Skip to content”), przejrzyste menu (5–9 pozycji) oznaczone rolami ARIA, responsywność z uwzględnieniem orientacji ekranu oraz zgodne z prawem i przystępne banery cookies. Dodatkowo ważna jest mapa strony jako alternatywna forma nawigacji.
Dalszą część artykułu przeczytasz poniżej - pod formularzem.
Hierarchia i semantyka nagłówków
Semantyczna struktura nagłówków jest fundamentem dostępnej treści – każde h1
–h6
oznacza kolejne poziomy ważności informacji. Nagłówki należy zagnieżdżać zgodnie z ich rangą: h1
najważniejszy (po jednym na stronę), h2
rozpoczyna nowe sekcje, a niższe poziomy (h3
–h6
) tworzą podsekcje W3C. Właściwe użycie hierarchii nagłówków pomaga zarówno czytnikom ekranu zrozumieć strukturę dokumentu, jak i wyszukiwarkom prawidłowo indeksować treść.
Ponadto, wyłącznie jeden nagłówek h1
na stronie sygnalizuje najważniejszy tytuł. Pozostałe sekcje powinny rozpoczynać się od kolejnych poziomów (h2
, h3
itd.), co utrzymuje porządek semantyczny i ułatwia orientację użytkownikowi oraz automatom wyszukiwawczym.
Zgodność URL,
i h1
Optymalizacja SEO i dostępność idą w parze: adres URL, zawartość tagu
(wyświetlanego w karcie przeglądarki) oraz widoczny na stronie h1
powinny być spójne i opisowe. Dzięki temu użytkownik i wyszukiwarka otrzymują jednoznaczny komunikat o treści danej podstrony MDN Web Docs. Zasada „trójnika” URL–
–h1
to podstawowy czynnik zarówno w UX, jak i SEO.
Obrazy i tekst alternatywny
Obrazy muszą zawierać tekst alternatywny (alt
), który opisuje ich zawartość w kontekście strony. Jeśli zdjęcie jest istotne merytorycznie, alt
powinien oddać kluczowe informacje; jeśli dekoracyjne – warto je oznaczyć jako puste (alt=""
) MDN Web Docs. Dodatkowo, dla zachowania wydajności i dostępności warto stosować responsywne obrazy z atrybutami srcset
i sizes
, co pozwala przeglądarce wybrać optymalną wersję pliku dla danego ekranu MDN Web Docs.
Linki i atrybut title
Linki tekstowe powinny być czytelne i zrozumiałe same w sobie, ale atrybut title
może dostarczać dodatkowego kontekstu, zwłaszcza przy linkach graficznych lub tam, gdzie tekst nie wystarcza. Należy jednak pamiętać, że korzystanie z title
bywa problematyczne na urządzeniach dotykowych i w niektórych czytnikach ekranu – dlatego informacja zawarta w title
powinna wzmocnić, a nie zastąpić treść linku MDN Web Docs. Warto także oznaczać grupy linków za pomocą ról ARIA, np. role="navigation"
dla elementów nawigacyjnych W3C.
Nawigacja klawiaturą i link „Skip to Content”
Zgodnie z Success Criterion 2.1.1 WCAG, całość interfejsu powinna być operowalna klawiaturą, bez konieczności używania myszy W3C. Ponadto, w celu szybkiego pominięcia powtarzalnych bloków (menu, nagłówka) zaleca się umieszczenie linku „Skip to content”, który skieruje fokus bezpośrednio na główną treść W3C webaim.org. To rozwiązanie znacząco przyspiesza dostęp do merytorycznej części strony, zwłaszcza dla użytkowników czytników ekranu i osób poruszających się wyłącznie za pomocą klawiatury.
Top strony (header) i projekt menu
Sekcja header, zwana często „topem strony”, powinna zawierać logo (linkujące do strony głównej) oraz główne menu MDN Web Docs. W menu głównym zaleca się mieścić od 5 do 9 pozycji (zasada 7±2) – liczba większa utrudnia przeglądanie i nawigację Nielsen Norman Group. W przypadku rozbudowanych struktur warto stosować podmenu lub kategorie rozwijane, pamiętając o responsywnej adaptacji do ekranów mobilnych.
Responsywność i orientacja ekranu
Responsywny design to nie tylko elastyczne siatki i media queries – to przede wszystkim dynamika layoutu dostosowująca elementy do wielkości ekranu, co poprawia czytelność i użyteczność . Dodatkowo, wg WCAG 2.1 SC 1.3.4: Orientation, treść powinna wyświetlać się poprawnie zarówno w orientacji poziomej, jak i pionowej, bez wymuszania konkretnego ustawienia urządzenia W3C. Na stronie warto też uwzględnić meta-tag viewport oraz umożliwić użytkownikowi powiększanie treści.
Cookie consent i dostępność banerów
Baner zgody na ciasteczka (cookie banner) jest dziś wymogiem prawnym, ale często narusza zasady dostępności. Dobry banner powinien być prosty, składać się z minimalnej liczby elementów (przyciski tak/nie, odnośnik do polityki prywatności) i pozostawać możliwy do zamknięcia klawiaturą i czytnikiem ekranu. Jednocześnie unikać należy skomplikowanych struktur (np. tabele, dropdowny) oraz rozwiązań, które całkowicie zasłaniają treść strony .
Mapa strony jako alternatywna nawigacja
Mapa serwisu to hierarchiczne zestawienie linków do najważniejszych sekcji i podstron. Najprostsza forma to lista odnośników przedstawiająca strukturę witryny – zgodnie z techniką G63 WCAG W3C. Dobrze przygotowana mapa strony pomaga użytkownikom (zwłaszcza tym korzystającym z czytników ekranu) szybko zorientować się w architekturze treści, a także służy celom SEO, gdy jest udostępniona w formacie XML i HTML Kontent.ai.
Dobre praktyki - wiedza ze szkolenia z dostępności cyfrowej
Kontrola animacji i karuzel (slidery)
Współczesne witryny często korzystają z dynamicznych elementów – karuzel, sliderów czy animowanych banerów – by przyciągnąć uwagę użytkownika. Jednak długotrwałe, automatyczne przewijanie treści może być nie tylko rozpraszające, ale wręcz wykluczające dla osób z zaburzeniami poznawczymi lub problemami ze wzrokiem. Dlatego każdy slider powinien oferować użytkownikowi intuicyjne, widoczne i dostępne klawiszowo (tab/enter) przyciski „pauza”, „stop” lub „następny/poprzedni”. Dodatkowo warto zaimplementować atrybuty ARIA (np. aria-live="polite"
, aria-atomic="true"
) oraz mechanizm poinformowania o zmianie slajdu, aby czytniki ekranu przekazywały użytkownikowi informację o nowej zawartości. Dzięki temu osoby korzystające z pomocy technologicznych zachowają kontrolę nad tempem prezentacji materiału.
Zastępowanie tekstu w obrazach rzeczywistym HTML-em (tekst w HTML, nie na zdjęciu)
Częstym błędem jest umieszczanie nagłówków lub istotnych informacji jako rasteryzowanych obrazów – zwłaszcza w elementach menu, przyciskach czy bannerach. Choć graficznie może to wyglądać atrakcyjnie, osoby korzystające z czytników ekranu czy te, które powiększają tekst, nie odczytają takiej zawartości. Zamiast tego zaleca się użycie czystego HTML‑owego tekstu z odpowiednim formatowaniem i stylami CSS. Tam, gdzie konieczne jest wykorzystanie grafiki, należy dodać prawidłowy alt
, a w razie potrzeby wspomóc się aria-label
lub aria-labelledby
, by zachować użyteczność i selekcjonowalność treści.
Semantyczne widoki i audyt różnorodnych szablonów
Duże portale i serwisy korporacyjne często składają się z kilku typów podstron (widoki artykułowe, listy, wyniki wyszukiwania, profil użytkownika itd.), każda oparta na dedykowanym szablonie HTML/CSS. W audycie dostępnym konieczne jest zbadanie co najmniej jednej reprezentatywnej podstrony z każdego widoku – dzięki temu wykryjemy powtarzalne wzorce błędów lub braków (np. brakujące h1
, niespójne ARIA landmarks czy różny poziom kontrastu). Ważne jest też, by zweryfikować, czy każdy szablon generowany przez CMS (autorski lub jak WordPress, Drupal itp.) nie zminifikuje semantycznej struktury kodu, a wręcz przeciwnie – stosuje logiczny porządek elementów.
ARIA landmarks i logika DOM
Oprócz semantycznych tagów HTML5 (
, ,
,
), należy zaimplementować ARIA landmarks, które ułatwiają czytnikom ekranu szybkie przejście do kluczowych sekcji strony. Atrybuty takie jak
role="navigation"
, role="banner"
, role="main"
czy role="contentinfo"
powinny zostać prawidłowo przypisane odpowiednim elementom. Istotne jest utrzymanie spójnego porządku DOM: nagłówek i nawigacja (header, nav) na początku dokumentu, treść w , a stopka (footer) na końcu – co pozwala na naturalne sekwencjonowanie przy skanowaniu strony.
Wielość dróg nawigacji i „3‑klikowa reguła”
Dobry projekt dostępności przewiduje, że użytkownik może dotrzeć do dowolnej podstrony wieloma ścieżkami: poprzez menu, wyszukiwarkę, linki kontekstowe czy mapę strony. Jednym z mierników użyteczności jest tzw. zasada maksymalnie trzech kliknięć, dzięki której nawet najgłębiej ukryty artykuł nie wymaga niepotrzebnej liczby akcji. Aby to osiągnąć, należy oprócz menu głównego i wyszukiwarki zapewnić także listy powiązanych treści w stopce, wewnątrz artykułów (breadcrumbs, powiązane wpisy) oraz klarowną, interaktywną mapę serwisu.
Testy na wielu przeglądarkach, urządzeniach i wbudowanych przeglądarkach aplikacyjnych
Chociaż Google Chrome dominuje wśród użytkowników desktopowych, należy pamiętać o właścicielach Apple (Safari), użytkownikach smartfonów, tabletów, a nawet wbudowanych przeglądarkach w aplikacjach (np. Gmail, Facebook). Warto przeprowadzić testy manualne i automatyczne (Wave, axe-core), zwracając uwagę na to, czy ciasteczka, banery i dynamiczne moduły nie blokują treści. Dodatkowo ważne jest, by na różnych rozdzielczościach – od pełnego HD (1920×1080), przez niższe ekrany 1366×768, aż po wąskie viewporty mobilne – elementy interfejsu wyświetlały się poprawnie i zachowywały dostępność.
Przygotowanie na przyszłe wytyczne WCAG 3.0 „Silver”
Choć obecnie obowiązujące WCAG 2.1 stanowi podstawę audytów, warto śledzić prace nad WCAG 3.0 (roboczo „Silver”), które rozszerzą zakres o nowe urządzenia – od smartwatchy po inteligentne lodówki z ekranami. Już dziś należy projektować z myślą o elastyczności wytycznych, modularności komponentów i rosnącym znaczeniu proporcjonalnych jednostek (rem, vw/vh), aby w przyszłości bez większych zmian wdrożyć bardziej zaawansowane kryteria dostępności.
Wnioski
Projektowanie dostępnych stron internetowych wymaga zrozumienia wielu powiązanych ze sobą aspektów: od semantyki HTML, przez właściwe opisy elementów, aż po intuicyjną nawigację i elastyczny, responsywny układ. Stosując się do przedstawionych wytycznych, możemy stworzyć witrynę przyjazną dla każdego użytkownika – niezależnie od urządzenia czy sposobu interakcji.
Źródła
- W3C WAI – Headings Tutorial: https://www.w3.org/WAI/tutorials/page-structure/headings/ W3C
- MDN – HTML: Accessibility Basics: https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Accessibility/HTML MDN Web Docs
- MDN – Global
title
attribute: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/title MDN Web Docs - Stefany Newman – Accessible Cookie Banners: https://medium.com/@web-accessibility-education/dos-and-donts-of-accessible-cookie-banners-2c1a3102df2f Medium
- W3C – WCAG 2.1 Understanding Success Criterion 2.1.1: Keyboard: https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html W3C
- W3C – WCAG 2.0 Understanding Success Criterion 2.4.1: Skip Navigation: https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-skip.html W3C
- MDN – Responsive Images Guide: https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Responsive_images MDN Web Docs
- Level Access – Responsive Web Design & Accessibility: https://www.levelaccess.com/blog/what-does-responsive-web-design-have-to-do-with-accessibility/ Level Access
- NN/g – Menu-Design Checklist: https://www.nngroup.com/articles/menu-design/ Nielsen Norman Group
- W3C – WCAG Technique G63 (Site Maps): https://www.w3.org/TR/WCAG20-TECHS/G63.html W3C
- W3C ARIA Authoring Practices – Navigation Landmarks: https://www.w3.org/WAI/ARIA/apg/patterns/landmarks/examples/navigation.html W3C
- W3C – WCAG 2.1 Understanding SC 1.3.4: Orientation: https://www.w3.org/WAI/WCAG21/Understanding/orientation.html W3C
- WebAIM – Skip Navigation Links: https://webaim.org/techniques/skipnav/ webaim.org
- web.dev – Accessible Responsive Design: https://web.dev/articles/accessible-responsive-design web.dev
- Smashing Magazine – Non-Accessibility of Cookie Notices: https://www.smashingmagazine.com/2023/04/potentially-dangerous-non-accessibility-cookie-notices/ Smashing Magazine
- MDN – ARIA
navigation
Role: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/navigation_role MDN Web Docs