Dostępność i SEO przez lata traktowane były jako dwa osobne światy – jedno to kwestia etyki i prawa, drugie to marketing i widoczność w Google. Tymczasem te dwa obszary mają więcej wspólnego niż się wydaje. Strona dostępna dla osób z niepełnosprawnościami jest jednocześnie stroną, którą Google rozumie lepiej – i nagradza wyższymi pozycjami.
Czym jest dostępność i dlaczego Google ją docenia?
Dostępność cyfrowa (z angielskiego web accessibility) to projektowanie stron i aplikacji w taki sposób, żeby mogły z nich korzystać osoby z różnymi rodzajami niepełnosprawności – wzrokową, słuchową, ruchową czy kognitywną. Osoby niewidome korzystają z czytników ekranu, które zamieniają treść strony na mowę. Osoby z zaburzeniami motorycznymi nawigują wyłącznie klawiaturą. Osoby słabowidzące powiększają tekst lub korzystają z wysokiego kontrastu.
Co to ma wspólnego z SEO? Bardzo dużo. Czytnik ekranu i bot Google działają w podobny sposób – obydwa „czytają” stronę w formie tekstowej, bez możliwości „zobaczenia” jej wizualnego układu. Strona zbudowana tak, żeby czytnik ekranu dobrze ją rozumiał, jest jednocześnie stroną, którą Google potrafi efektywnie zaindeksować i ocenić. To nie przypadek – to konsekwencja tego, że dobre praktyki dostępności i dobre praktyki SEO mają wspólny fundament: semantyczny, dobrze ustrukturyzowany HTML.
Warto też pamiętać o aspekcie prawnym. Dyrektywa UE o dostępności cyfrowej (WCAG 2.1) nakłada obowiązki na instytucje publiczne i coraz więcej podmiotów komercyjnych. Ignorowanie dostępności to w niektórych kontekstach nie tylko strata SEO, ale realne ryzyko prawne.
Semantyczny HTML – fundament dostępności i SEO jednocześnie
Największy błąd, który popełnia wiele stron, to budowanie całego layoutu z <div> i <span>. Dla wizualnego efektu w przeglądarce nie ma to znaczenia – CSS potrafi sprawić, że dowolny element wygląda jak cokolwiek. Dla czytnika ekranu i dla Google ma znaczenie fundamentalne.
HTML5 dostarcza bogaty zestaw znaczników semantycznych, które komunikują zarówno użytkownikom jak i botom, czym jest dany element na stronie:
<header> - nagłówek strony lub sekcji
<nav> - blok nawigacyjny
<main> - główna treść strony
<article> - samodzielna treść (wpis blogowy, artykuł)
<section> - tematyczna sekcja treści
<aside> - treść poboczna, sidebar
<footer> - stopka strony lub sekcjiZamiana <div class="navigation"> na <nav> to zmiana jednego słowa w kodzie, ale dla czytnika ekranu oznacza możliwość bezpośredniej nawigacji do menu. Dla Google oznacza lepsze zrozumienie struktury strony.
Równie ważna jest poprawna hierarchia nagłówków. Strona powinna mieć dokładnie jeden nagłówek <h1> – główny tytuł zawierający słowo kluczowe. Podsekcje oznaczasz <h2>, ich podsekcje <h3> i tak dalej. Nie pomijaj poziomów hierarchii (np. skaczące od H1 do H4) i nie dobieraj nagłówków według wyglądu – jeśli chcesz mniejszy tekst, użyj CSS, nie niższego nagłówka.
Atrybuty ARIA i alternatywy tekstowe – co Google widzi, a ludzie nie
Treści wizualne – zdjęcia, ikony, animacje, wykresy – są niewidoczne dla czytników ekranu i botów Google, dopóki nie dodasz do nich alternatywy tekstowej. To jeden z obszarów, gdzie poprawa dostępności bezpośrednio przekłada się na lepsze indeksowanie.
Atrybut alt przy obrazach to absolutna podstawa. Dobry tekst alternatywny opisuje, co faktycznie przedstawia zdjęcie w kontekście, w którym się pojawia. Google indeksuje tekst alt i używa go przy wyszukiwaniu grafik, co może być dodatkowym źródłem ruchu organicznego.
<!-- Źle - puste lub nieopisowe -->
<img src="wykres.png" alt="">
<img src="wykres.png" alt="wykres">
<!-- Dobrze - opisuje zawartość i kontekst -->
<img src="wykres.png" alt="Wzrost ruchu organicznego o 140% po wdrożeniu optymalizacji SEO w Q3 2024">Obrazy dekoracyjne – tła, ozdobniki, ikony bez znaczenia informacyjnego – powinny mieć pusty atrybut alt="". To sygnał dla czytnika ekranu, żeby je pominął, i dla Google, żeby nie próbował ich interpretować jako treści.
Atrybuty ARIA (Accessible Rich Internet Applications) uzupełniają semantykę HTML tam, gdzie standardowe znaczniki nie wystarczają – szczególnie przy dynamicznych komponentach jak rozwijane menu, modale, karuzele czy zakładki:
<button aria-expanded="false" aria-controls="menu-glowne">
Menu
</button>
<ul id="menu-glowne" aria-hidden="true">
...
</ul>aria-label pozwala dodać opisową etykietę do elementu, który wizualnie nie ma tekstu – np. przyciski z samą ikoną:
<!-- Bez ARIA czytnik powie tylko "przycisk" -->
<button>
<svg>...</svg>
</button>
<!-- Z ARIA czytnik powie "Otwórz wyszukiwarkę, przycisk" -->
<button aria-label="Otwórz wyszukiwarkę">
<svg>...</svg>
</button>Kontrast, czytelność i nawigacja klawiaturą
Dostępność to nie tylko kod – to też decyzje projektowe, które mają bezpośredni wpływ na to, jak Google ocenia jakość strony.
Kontrast kolorów między tekstem a tłem musi spełniać minimalne wymagania WCAG – współczynnik kontrastu co najmniej 4.5:1 dla zwykłego tekstu i 3:1 dla dużego tekstu (powyżej 18pt). Słaby kontrast to problem nie tylko dla osób słabowidzących – jasny szary tekst na białym tle jest trudny do czytania dla każdego w słonecznym otoczeniu. Narzędzie WebAIM Contrast Checker (webaim.org/resources/contrastchecker) pozwala sprawdzić dowolną parę kolorów w kilka sekund.
Nawigacja klawiaturą – każdy interaktywny element strony powinien być osiągalny i obsługiwalny wyłącznie przy pomocy klawiatury. Wypróbuj to sam: zamknij myszkę i spróbuj nawigować po własnej stronie używając tylko Tab, Shift+Tab, Enter i strzałek. Jeśli utkniesz, masz problem z dostępnością. Widoczny focus (obramowanie lub podświetlenie aktywnego elementu) jest konieczny – nie usuwaj domyślnego outline z CSS bez zapewnienia alternatywy.
Rozmiar tekstu i responsywność – tekst powinien zachowywać czytelność po powiększeniu do 200% bez utraty treści i funkcjonalności. Używaj jednostek względnych (rem, em) zamiast px dla rozmiarów czcionek, żeby strona respektowała ustawienia systemowe użytkownika.
Linki i przyciski muszą mieć opisowe etykiety. „Kliknij tutaj” i „więcej” to antywzorce – nie mówią nic ani czytnikowi ekranu, ani Google o tym, dokąd prowadzi link. „Przeczytaj artykuł o optymalizacji zdjęć” jest i dostępne, i bogate w słowa kluczowe.
Jak audytować dostępność i od czego zacząć?
Wiedza o tym, co poprawić, to jedno – wiedzieć gdzie szukać problemów, to drugie. Na szczęście narzędzia do audytu dostępności są bezpłatne i łatwo dostępne.
Lighthouse wbudowany w Chrome DevTools (F12, zakładka Lighthouse) przeprowadza automatyczny audyt dostępności i przyznaje wynik w skali 0-100. Pokazuje konkretne problemy z odnośnikami do wyjaśnień i sugestii naprawy. To dobry punkt startowy – rozwiąż wszystkie problemy, które Lighthouse wykrywa automatycznie, bo stanowią one ok. 30-40% typowych błędów dostępności.
axe DevTools – wtyczka do Chrome i Firefox od Deque – to bardziej zaawansowane narzędzie do automatycznego audytu, cenione przez profesjonalnych testerów dostępności. Wykrywa więcej problemów niż Lighthouse i lepiej wyjaśnia ich wpływ.
WAVE (wave.webaim.org) to narzędzie webowe, które wizualnie nakłada informacje o dostępności bezpośrednio na podgląd strony – widać dokładnie, które elementy mają problemy i gdzie się znajdują na stronie.
Automatyczne narzędzia wykrywają jednak tylko część problemów. Pełny audyt dostępności wymaga manualnego testowania – nawigacji klawiaturą, sprawdzenia czytnikiem ekranu (NVDA na Windows jest bezpłatny, VoiceOver wbudowany w macOS i iOS) i weryfikacji logiki treści przez człowieka.
Dostępność i SEO to inwestycja, która zwraca się podwójnie – poprawia doświadczenie realnych użytkowników i jednocześnie sygnalizuje Google, że strona jest zbudowana profesjonalnie i z dbałością o jakość. Jeśli chcesz przeprowadzić audyt dostępności swojej strony lub masz pytania dotyczące konkretnych implementacji – napisz przez formularz kontaktowy.
