Strona główna / Artykuły / Od „Div Soup” do znaczącego markupu: Praktyczny przewodnik po semantycznym HTML.

HTMLAccessibilitySEOWeb StandardsFrontend

Od „Div Soup” do znaczącego markupu: Praktyczny przewodnik po semantycznym HTML.

Dowiedz się, dlaczego ogólne elementy div psują dostępność, indeksowanie i możliwości konserwacji, jakie elementy semantyczne należy zamiast nich używać oraz jak przeredagować rzeczywisty komponent karty.

3527 słów

Otwórz inspektor elementów w typowej nowoczesnej aplikacji internetowej i często zobaczysz ten sam obraz: głęboką, anonimową stertę elementów <div>, z których każdy jest identyfikowany jedynie przez nazwę klasy. Strona może wyglądać doskonale, ale dla czytników ekranu, robotów wyszukiwawczych oraz następnego programisty w zespole nie mówi ona prawie nic o treści. Ten przewodnik wyjaśnia, jakie to ma dla ciebie konsekwencje, które elementy semantyczne zastępują większość tych divów, jak rozstrzygnąć kłopotliwe wybory (〈article〉 czy 〈section〉, link czy przycisk) oraz jak krok po kroku przebudować realistyczny komponent.

Oto ten wzorzec w jego najczystszej formie: nagłówek, menu nawigacyjne, główna treść i stopka, wszystko przedstawione jako ogólne ramki.

<!-- The modern web's favorite anti-pattern -->
<div class="header">
  <div class="nav-container">
    <div class="nav-item">Home</div>
    <div class="nav-item">About</div>
  </div>
</div>
<div class="main-content">
  <div class="article-title">Stop Using Divs</div>
  <div class="article-body">
    <div class="paragraph">Divs everywhere.</div>
  </div>
</div>
<div class="footer">
  <div class="copyright">© 2026</div>
</div>

Każdy element struktury w tym fragmencie znajduje się w nazwach klas. Usunięcie tych klas oznacza, że nie pozostanie nic, co mogłoby poinformować maszynę lub człowieka, gdzie kończy się nawigacja, a zaczyna artykuł. Taki styl jest zwykle nazywany „div soup” i występuje znacznie częściej, niż powinien.

Dlaczego HTML stał się narzędziem do stylizacji

Gdy frameworki takie jak React, Vue, Angular i Svelte zaczęły dominować w pracy nad interfejsem użytkownika, a CSS typu utility-first sprawił, że stylizacja stała się niemal bezproblemowa, markup po cichu stracił swoją pierwotną funkcję. HTML zaczął pełnić rolę neutralnej ramy do przymocowywania klas i obsługiwaczy zdarzeń, a nie języka służącego do opisywania treści. To błędne rozumienie platformy: HTML został zaprojektowany do wyrażania znaczenia, a nie jako silnik układu.

Gdy ta informacja znika, szkody rozprzestrzeniają się jednocześnie na kilka obszarów. Technologie wspomagające tracą narzędzia do nawigacji, silniki wyszukiwania otrzymują słabsze sygnały dotyczące tego, co jest ważne na stronie, przeglądarka nie może już zapewniać wbudowanego zachowania, a kod staje się trudniejszy do odczytania dla kolegów. Żaden z tych problemów nie jest widoczny na skrócie ekranu, i to właśnie dlatego nadal istnieją.

Korzenie komponentów domyślnie to div

Architektura komponentów dzieli interfejs na małe elementy takie jak <Button/>, <Card/>, <Navbar/> oraz <Sidebar/>. Każdy komponent wymaga elementu korzeniowego dla swojego JSX, a najprostszym rozwiązaniem jest <div>. Gdy umieścimy kilka komponentów jedno wewnątrz drugiego, renderowany DOM składa się z dziesięciu warstw anonimowych otoczeń, mimo że każdy pojedynczy komponent wyglądał sensownie sam w sobie. (Jeśli pracujesz z React, warto pamiętać, że fragment całkowicie eliminuje potrzebę otoczenia, gdy nie jest wymagana żadna ramka.)

Klasy pomocnicze skupiają uwagę na wyglądzie

CSS skupione na funkcjonalności jest doskonałe pod względem szybkości, ale skupia całą uwagę na wyglądzie elementu. Gdy kod to <div class="flex items-center space-x-4">, zadawane jest pytanie „jak to jest ułożone?”, a pytanie „co to jest?” w ogóle nie pojawia się. Wybór elementu staje się kwestią drugorzędną.

Piksele to tylko najwyższy poziom

Najniebezpieczniejszym nawykiem jest ocenianie swojej pracy na podstawie tego, co użytkownik myszką widzi na dużym monitorze. <div> z niebieskim tłem, zaokrąglonymi rogami i pogrubionym tekstem z pewnością wygląda jak przycisk. Ale poniżej renderowanych pikseli znajduje się DOM, drzewo dostępności udostępniane przez przeglądarkę technologiom wspomagającym, widok dokumentu przez crawlera oraz obsługa wprowadzanych danych przez przeglądarkę. Dla każdego z tych poziomów stylizowany div pozostaje po prostu divem.

Co naprawdę oznacza semantyczny HTML

„Semantyczny” odnosi się do znaczenia. Semantyczny HTML to praktyka wyboru elementów, których nazwy opisują rolę zawartego w nich treści, dzięki czemu przeglądarka, technologie wspomagające oraz ludzcy czytelnicy mogą zrozumieć dokument bez konieczności domyślania się.

Kontenery ogólne

Dwa elementy są celowo pozbawione znaczenia:

  • <div> to ogólny element grupujący na poziomie bloku.
  • <span> to ogólny element grupujący w linii tekstu.

Tekst znajdujący się wewnątrz <div> może być tytułem strony, linkiem nawigacyjnym, akapitem z posta na blogu, notatką w bocznym pasku lub oświadczeniem prawnym. Przeglądarka nie ma sposobu, by to stwierdzić, dlatego traktuje je wszystkie identycznie.

Elementy niosące znaczenie

Elementy semantyczne określają, jaka jest ich treść:

  • <header> zawiera treść wprowadzającą do strony lub sekcji, często obejmującą elementy nawigacyjne.
  • <nav> oznacza blok głównych linków nawigacyjnych.
  • <main> otacza główną, unikalną treść strony.
  • <article> reprezentuje samodzielny tekst, taki jak post lub artykuł prasowy.
  • <section> grupuje treści związane z jednym tematem.
  • <aside> zawiera materiały tylko pośrednio związane z główną treścią, np. panel boczny.
  • <footer> zawiera informacje końcowe, takie jak dane autorskie, informacje o prawach autorskich lub linki prawnicze.
  • <button> to element interaktywny służący do wykonywania określonej akcji.

Gdy przeglądarka napotka element <article>, wie, że jego zawartość może istnieć samodzielnie. Gdy natomiast napotka element <nav>, wie, że te linki służą do przemieszczania się po stronie. Na tej wiedzy opiera się reszta tego przewodnika.

Cztery powody, dla których semantyczne oznaczanie jest warte wysiłku

Wybór odpowiedniego elementu wymaga chwili zastanowienia, a stylizowany div wyświetla te same piksele. Korzyści są widoczne w czterech obszarach.

Dostępność: punkty orientacyjne i wbudowane elementy sterujące

wiele osób korzysta z Internetu za pomocą czytników ekranu takich jak NVDA, JAWS lub VoiceOver albo porusza się wyłącznie za pomocą klawiatury. Czytniki ekranu ignorują Twoje CSS – działają na podstawie drzewa dostępności, które przeglądarka tworzy na podstawie Twojego HTML.

Dzięki dobrze skonstruowanym znacznikom przeglądarka może wykazać elementy kluczowe, a technologie wspomagające mogą je przedstawić jako listę, pomiędzy którą użytkownik może przeskakiwać. Na stronie semantycznej lista ta wygląda mniej więcej tak:

Landmark Navigation Map:
- Header
- Navigation (3 links)
- Main Content
  - Heading 1: Stop Using Divs
  - Article
- Sidebar (Aside)
- Footer

Użytkownik może nacisnąć jeden skrót, aby pominąć dziesiątki linków nawigacyjnych i trafić bezpośrednio do <main> lub przejść prosto do artykułu. Teraz porównajmy tę samą stronę zbudowaną wyłącznie z elementów div:

Landmark Navigation Map:
- Division
  - Division
  - Division
- Division

W praktyce sytuacja jest jeszcze gorsza, niż sugeruje ten szkic: zwykłe elementy div w ogóle nie są elementami kluczowymi, więc lista jest po prostu pusta. Użytkownik musi przeglądać elementy strony jeden po drugim, aby znaleźć to, czego szukał.

Klawisze pokazują ten sam problem w mniejszym stopniu. Oto fałszywy przycisk obok prawdziwego:

<!-- BAD: Fake Button -->
<div class="my-button" onclick="submitForm()">Submit</div>

<!-- GOOD: Native Button -->
<button type="submit">Submit</button>

Wbudowany element <button> oferuje bez żadnych kosztów:

  • Możliwość uzyskania fokusa, dzięki czemu pojawia się w kolejności Tab.
  • Aktywacja za pomocą klawiszy Enter i Space.
  • Prawidłowa rola, dzięki której czytnik ekranu ogłasza coś w rodzaju „Submit, przycisk” i użytkownik wie, że ma miejsce wykonywanie akcji.

    • Wersja z div nie może przyjąć fokusa, nie reaguje na klawiaturę i jest odczytywana jako zwykły tekst, bez żadnego wskazania, że jest interaktywna. Aby zachowywała się prawidłowo, potrzebne byłyby tabindex="0", role="button", obsługa klawiszy Enter i Space, stylizacja fokusa oraz obsługa stanu wyłączonego. To dużo kodu potrzebnego do odtworzenia, zazwyczaj w sposób niedoskonały, funkcji, które platforma już posiada.

    Szukiwarki: jaśniejszy obraz strony

    Boty takie jak Googlebot to w pewnym sensie specjalistyczne czytniki tekstu, które próbują ustalić, o czym jest dana strona. Struktura semantyczna dostarcza im przydatnych wskazówek:

    • <h1> wskazuje na główny temat.
    • <main> oddziela unikalną treść od nagłówka i stopki powtarzanych na każdej stronie.
    • <article> sygnalizuje odrębną część treści redakcyjnej.
    • <nav> pokazuje strukturę powiązań wewnętrznych.

    Strona złożona z nieuzasadnionych elementów div zmusza boty do wywnioskowania tego wszystkiego na podstawie samego układu i tekstu. Bądź jednak realistą co do skali tego efektu: znaczniki to tylko jeden z wielu czynników, a wyszukiwarki nie określają zasady, według której strony semantyczne mają wyższą pozycję niż inne. Traktuj czystą strukturę jako coś, co ułatwia analizę i prawidłowe indeksowanie treści, a nie jako gwarancję lepszej pozycji.

    Zdalność konserwacji: znaczniki, które same się dokumentują

    Kod to forma komunikacji z innymi programistami oraz z samym sobą po kilku miesiącach. Rozważmy dwie wersje tego samego układu. Pierwsza opiera się wyłącznie na nazwach klas:

    <div class="top-bar">
  <div class="logo-box">...</div>
  <div class="menu-list">
    <div class="menu-item"><a href="#">Home</a></div>
    <div class="menu-item"><a href="#">Blog</a></div>
  </div>
</div>
<div class="wrapper">
  <div class="content-box">
    <div class="title-text">My Post</div>
    <div class="body-text">Hello world...</div>
  </div>
  <div class="right-bar">
    <div class="widget">...</div>
  </div>
</div>
<div class="bottom-bar">
  <div class="legal">© 2026</div>
</div>

    Druga wersja przedstawia tę samą strukturę za pomocą elementów semantycznych:

    <header>
  <div class="logo">...</div>
  <nav>
    <ul>
      <li><a href="#">Home</a></li>
      <li><a href="#">Blog</a></li>
    </ul>
  </nav>
</header>
<main>
  <article>
    <h1>My Post</h1>
    <p>Hello world...</p>
  </article>
  <aside>
    <div class="widget">...</div>
  </aside>
</main>
<footer>
  <small>© 2026</small>
</footer>

    W pierwszej wersji trzeba przeczytać każdą nazwę klasy, aby zrozumieć jej cel. Jeśli ktoś pominie lub błędnie nazwie jakąś klasę, struktura zamienia się w mur identycznych elementów. W drugiej wersji kształt strony jest widoczny od razu: gdzie zaczyna się (<header>), gdzie znajduje się główna treść (<main>), co jest dodatkowe (<aside>) i gdzie się kończy (<footer>). Zauważ, że nawigacja również staje się prawdziwym списком, co umożliwia odczytarkom ekranu podanie informacji o liczbie zawartych w nim elementów.

    Markup samopisowy zmniejsza obciążenie umysłowe podczas przeglądania i ogranicza ryzyko uszkodzenia struktury przy zmianie układu.

    Wydajność i wbudowane zachowanie przeglądarki

    Silniki przeglądarek takie jak Chromium, Gecko i WebKit są dostosowane do standardowych elementów, które już zawierają wdrożone domyślne style, obsługę zdarzeń i zarządzanie stanem. Najlepszym przykładem są elementy formularzy – <input type="email"> oraz <input type="date"> umożliwiają użytkownikom mobilnym korzystanie z odpowiedniego klawiatury na ekranie lub wbudowanego wyborcy dat, a <details> dostarcza funkcjonalny element do pokazywania informacji, wszystko to bez użycia żadnego JavaScriptu od third party.

    Za każdym razem, gdy odbudowujesz rozwijaną listę lub przycisk na podstawie elementu div wraz z skryptami, wysyłasz dodatkowy kod przez sieć, powiększasz rozmiar pliku, zużywasz więcej zasobów procesora i baterii urządzenia, a także tworzysz kolejny komponent, który trzeba teraz utrzymywać i testować. Aby lepiej poznać tę koncepcję, zapoznaj się z sześcioma wbudowanymi funkcjami HTML, które zastępują popularne biblioteki interfejsu użytkownika w JavaScript.

    Rozwiązywanie trudnych wyborów semantycznych

    Znajomość listy elementów to łatwa część. Prawdziwe zamieszanie pochodzi od kilku par elementów, które wydają się być wymiennymi.

    article czy section

    To jest pytanie, o którym najczęściej dyskutują deweloperzy. Praktyczny test: czy ten treść można by wyjąć z strony, umieścić na innym serwisie i nadal miała pełny sens? Jeśli tak, użyj <article>. Jeśli ma sens tylko w swoim obecnym kontekście, użyj <section>.

    Dobre kandydaty na <article>:

    • Post na blogu lub artykuł prasowy.
    • Jeden komentarz użytkownika.
    • Karta produktu w siatce sklepu.
    • Samodzielny widget, np. panel z aktualną pogodą.

    Każdy z tych elementów można by udostępnić w formie syndykacji, włączyć do feedu lub wgrać gdzie indziej bez otaczającej go strony.

    Dobre kandydaty na <section>:

    • Blok „O nas” na stronie głównej.
    • Rozdział w książce cyfrowej.
    • Część przedstawiająca funkcje na stronie docelowej.
    • Grupa opinii klientów.

    <section> grupuje treść pod jednym tematem, dlatego prawie zawsze powinien zaczynać się od nagłówka od <h2> do <h6>. Jeśli nie możesz wymyślić odpowiedniego nagłówka, to prawdopodobnie nie jest to sekcja, a <div> może być lepszym wyborem.

    Te dwa elementy naturalnie się nakładają. Artykuł można podzielić na sekcje, z których każda ma swój własny nagłówek:

    <!-- Proper Nesting Example -->
<main>
  <!-- Main article describing a topic -->
  <article>
    <h1>Understanding Semantic HTML</h1>
    <p>Introductory paragraph...</p>

    <!-- Sections dividing the article into sub-topics -->
    <section>
      <h2>Why Accessibility Matters</h2>
      <p>Content about accessibility...</p>
    </section>

    <section>
      <h2>SEO Benefits</h2>
      <p>Content about SEO...</p>
    </section>
  </article>
</main>

    Link lub przycisk

    Płynięcie linków i przycisków jest jednym z najczęstszych błędów dotyczących dostępności. Zasada jest prosta:

    • Używaj <a> z rzeczywistym href, gdy jego aktywacja zmienia adres URL lub przenosi użytkownika na inną stronę lub lokalizację.
    • Używaj <button>, gdy jego aktywacja powoduje jakąś zmianę na obecnej stronie: wysyła dane, otwiera okno modalne, zmienia menu lub w inny sposób modyfikuje stan strony.

    Oba rodzaje błędów są powszechne, podobnie jak ich rozwiązania:

    <!-- WRONG: A link styled like a button that triggers JavaScript -->
<a href="#" onclick="openModal()">Open Modal</a>

<!-- WRONG: A button that navigates to a new webpage -->
<button onclick="window.location.href='/about'">About Us</button>

<!-- RIGHT -->
<button type="button" onclick="openModal()">Open Modal</button>
<a href="/about">About Us</a>

    Różnica ta ma znaczenie, ponieważ czytniki ekranu podają rolę elementu. „Link” budzi oczekiwanie, że lokalizacja się zmieni; „przycisk” sugeruje, że coś tu ma się wydarzyć. Błędne użycie psuje te oczekiwania. Istnieją również praktyczne konsekwencje: link z href="#" może przenieść użytkownika na początek strony i nie można go aktywować klawiszem przestrzeni, a przycisk służący do nawigacji nie może zostać otwarty w nowej karcie ani mieć swojej adresu skopiowanego.

    Budowanie sensownej struktury nagłówków

    Nagłówki tworzą spis treści strony, od których zależą zarówno technologie wspomagające, jak i boty przeglądarek. Użytkownicy czytników ekranu często nawigują wyłącznie za pomocą nagłówków. Kilka zasad pomaga utrzymać tę strukturę przydatną:

    • Użyj jednego elementu <h1> dla głównego tematu strony, takiego jak tytuł artykułu lub nazwa panelu sterowania. Specyfikacja HTML nie zabrania ściśle używania kilku takich elementów, ale jedno nagłówek najwyższego poziomu jest powszechnie zalecaną praktyką i zapewnia najjaśniejszy podział treści.
    • Nie pomijaj poziomów nagłówków. Przejście od <h2> bezpośrednio do <h4> z powodu chęci uzyskania mniejszego rozmiaru tekstu to decyzja stylizacyjna zamaskowana jako strukturalna; zamiast tego zmień rozmiar czcionki za pomocą CSS.
    • Układaj elementy logicznie: pod tytułem <h1> znajdują się główne sekcje oznaczone <h2>, z których każda zawiera własne podsekcje <h3>, a następnie kolejna sekcja oznaczona <h2>.

    Należy również zauważyć, że element <header> oraz elementy nagłówkowe to różne rzeczy. <header> to obszar strony, natomiast <h1> do <h6> to tytuły, które tworzą strukturę nagłówków.

    Kiedy div jest odpowiednim narzędziem

    To wszystko nie oznacza, że użycie <div> jest zabronione. Ma ono uzasadniony cel: otaczanie treści wyłącznie w celach układu lub stylizacji, gdy nie ma żadnego znaczenia semantycznego. Ustawienie czegoś na środku za pomocą flexbox, stworzenie przerwy w siatce, nadanie tła gradientowego lub uruchomienie animacji CSS to wszystko doskonałe powody, by użyć <div> (lub <span> dla treści wierszowej).

    W poniższej karcie części o znaczeniu używają elementów semantycznych, natomiast pojedynczy div służy wyłącznie do umieszczenia dwóch przycisków obok siebie:

    <!-- PERFECTLY VALID USE OF A DIV -->
<article>
  <h1>Card Title</h1>
  <p>Card description goes here...</p>

  <!-- This div exists purely to align two buttons side-by-side with Flexbox -->
  <div class="button-group flex gap-4 mt-4">
    <button type="button">Save</button>
    <button type="button">Cancel</button>
  </div>
</article>

    Elementy <article>, <h1>, <p> oraz <button> opisują treść; <div> służy wyłącznie do układu. To cała zasada w jednym zdaniu: używaj elementów semantycznych do przekazywania znaczenia, a div-ów do układu. (Na prawdziwej stronie, gdzie ta karta znajduje się w większym dokumencie, jej tytuł zazwyczaj będzie <h2> lub <h3>, aby pasował do struktury strony.)

    Refaktoryzacja karty posta na blogu, krok po kroku

    Rozważmy komponent kartowy typu, który znajduje się niemal na każdej stronie z treścią: obraz, etykieta, tytuł, autor i data, fragment tekstu oraz dwie opcje działania. Oto wersja z użyciem div-ów:

    <div class="card">
  <div class="card-image">
    <img src="tech.jpg" alt="Technology background" />
    <div class="badge">Article</div>
  </div>
  <div class="card-content">
    <div class="post-title" onclick="goToPost()">10 Tips for Better Code</div>
    <div class="post-author">By Jane Doe</div>
    <div class="post-date">August 12, 2026</div>
    <div class="post-excerpt">
      Learn how to write cleaner, more maintainable frontend code today...
    </div>
    <div class="card-footer">
      <div class="share-btn" onclick="sharePost()">Share</div>
      <div class="read-more" onclick="goToPost()">Read More</div>
    </div>
  </div>
</div>

    Problemy są łatwe do wymienienia, gdy tylko zaczniesz ich szukać:

    • Zewnętrznym kontenerem jest <div>, chociaż karta stanowi samodzielny element treści, do czego właśnie służy <article>.
    • Tytuł to klikalny div, więc użytkownicy klawiatury nie mogą do niego dotrzeć, a czytniki ekranu nie wiedzą, czy jest to nagłówek, czy link.
    • Autor i data znajdują się w ogólnych kontenerach, które nie mają znaczenia czytelnego dla maszyn.
    • Przyciski „Podzielić się” i „Czytaj więcej” to fałszywe przyciski, które powodują problemy z klawiaturą oraz informacjami wyświetlanymi wcześniej.

    Oto przepisana wersja:

    <article class="card">
  <figure class="card-image">
    <img src="tech.jpg" alt="Abstract technology grid pattern" />
    <span class="badge">Article</span>
  </figure>

  <div class="card-content">
    <h2>
      <a href="/posts/10-tips-for-better-code">10 Tips for Better Code</a>
    </h2>

    <p class="meta-info">
      Written by <span class="author">Jane Doe</span> on
      <time datetime="2026-08-12">August 12, 2026</time>
    </p>

    <p class="post-excerpt">
      Learn how to write cleaner, more maintainable frontend code today...
    </p>

    <footer class="card-footer">
      <button type="button" onclick="sharePost()" aria-label="Share this article">
        Share
      </button>
      <a href="/posts/10-tips-for-better-code" class="btn-primary">
        Read More
      </a>
    </footer>
  </div>
</article>

    Co się zmieniło i dlaczego to pomaga:

    • Kontener <article> informuje technologie wspomagające i roboty przeglądarek, że karta jest elementem samodzielnym.
  • Zdjęcie wraz z jego ikonką znajdują się w elementie <figure>, a tekst alternatywny teraz opisuje zdjęcie zamiast go jedynie ogólnikowo oznaczać.
  • Tytuł to prawdziwy element <h2> zawierający rzeczywisty link, więc pojawia się w strukturze nagłówków, można do niego dotrzeć za pomocą klawisza Tab i jest widoczny dla botów przeglądających stronę.
  • Data jest przedstawiona za pomocą tagu <time datetime="2026-08-12">, co zapewnia narzędziom do wykopywania danych, programom tłumaczeniowym oraz integracjom kalendarzowym jednoznaczną, czytelną przez maszyny wartość, niezależnie od formatu tekstu widocznego dla użytkowników.
  • Przycisk „Podzielić się” to element <button>, ponieważ działa na bieżącej stronie, natomiast „Przeczytaj więcej” to element <a>, ponieważ służy do przemieszczania się po stronie.
  • aria-label na przycisku udostępniania dostarcza użytkownikom odczytującym ekran większej ilości informacji na temat tego, co będzie udostępniane. Zachowaj widoczny tekst wewnątrz etykiety, tak jak tutaj („Share” jest częścią „Share this article”), aby użytkownicy sterujący głosem mogli nadal aktywować przycisk, mówiąc to, co widzą.

    • Jedna poprawka, nad którą warto się zastanowić: karta zawiera teraz dwa linki do tego samego adresu URL. Niektóre zespoły zachowują tylko link z tytułem lub sprawiają, że cała karta jest klikalna za pośrednictwem tego jednego linku, aby użytkownicy klawiatury i odczytujący ekran nie trafiali dwukrotnie w ten sam adres.

    Nawyki, które utrzymują semantykę twojego kodowania

    Nie musisz na nowo uczyć się programowania webowego, aby pisać lepszy HTML. Kilka rutynowych sprawdzeń pozwala wykryć większość problemów.

    Prowadź automatyczną audytę

    Rozszerzenia przeglądarki, takie jak axe DevTools czy WAVE, dostępne dla Chrome i Firefox, skanują stronę w ciągu kilku sekund i zaznaczają problemy takie jak nieważne atrybuty ARIA, brak typów przycisków, błędny porządek nagłówków oraz elementy interaktywne bez odpowiedniej semantyki. Narzędzia automatyczne wykrywają jedynie część istotnych problemów, dlatego traktuj czysty raport jako punkt wyjścia, a nie dowód dostępności.

    Próbuj strony bez CSS

    Wyłącz wszystkie style, czy to za pomocą narzędzi deweloperskich, czy rozszerzenia wyłączającego CSS, i sprawdź, co pozostanie. Czy nadal jest to czytelny dokument? Czy potrafisz odróżnić nagłówki od akapitów oraz znaleźć elementy nawigacyjne? Jeśli rezultatem jest nierozróżniony blok tekstu, struktura zależy od CSS pod względem swojego znaczenia. Dobrze zorganizowany dokument pozostaje uporządkowany nawet bez żadnych stylów.

    Odstaw myszkę

    Spróbuj uruchomić swoją aplikację używając jedynie klawiszy Tab, Shift + Tab, Enter, Przestrzeń oraz klawiszy strzałek i sprawdź:

    • Czy do każdego elementu interaktywnego można dotrzeć.
    • Czy zawsze widać, który element ma fokus.
    • Czy formularze, listy rozwijane i okna modalne wszystkie działają.

    Gdy napotkasz problem z elementem div, który ignoruje klawisze Enter lub Przestrzeń, zastąp go elementem <button>. To często jeden z najszybszych sposobów naprawy dostępności.

    Zapytaj o treść przed napisaniem div

    Zanim stworzysz nowy kontener, zatrzymaj się i zapytaj, co tak naprawdę reprezentuje jego treść:

    • Nawigacja wymaga elementu <nav>.
    • Boczna lista wymaga elementu <aside>.
    • Akcja, na którą można kliknąć, wymaga elementu <button>.
    • Niezależna karta lub post wymaga elementu <article>.
  • Główna treść strony wymaga użycia tagu <main>.
  • Tylko otoczka układu, która sama w sobie nie ma żadnego znaczenia, wymaga użycia tagu <div>.

    • To samo dotyczy komponentów: element korzeniowy komponentu React jest częścią ostatecznego dokumentu, więc należy go wybierać z taką samą starannością. Aby dowiedzieć się więcej na temat różnic między JSX a prawdziwym HTML, zapoznaj się z artykułem JSX to nie HTML: prawdziwe kompromisy stojące za markupiem komponentów.

    Główne wnioski

    • Renderyzowane piksele to tylko jedna warstwa; drzewo dostępności, boty przeglądarek oraz obsługa wprowadzanych danych w przeglądarce czytają wszystkie twoje elementy, a nie style.
    • Elementy wbudowane, takie jak <button>, <a>, <input> i <details>, zapewniają fokus, obsługę klawiatury, role oraz zachowanie w urządzeniach mobilnych – rzeczy, których odtworzenie ręcznie jest kosztowne.
    • Używaj <article> dla treści, które istnieją samodzielnie, oraz <section> dla tematycznej części większej całości, i nadaj każdej sekcji nagłówek.
    • Linki służą do nawigacji, a przyciski do działania; ich mieszanie myli użytkowników i zakłóca oczekiwane zachowanie przeglądarki.
    • Zachowaj jednolitą strukturę nagłówków bez pomijanych poziomów i używaj CSS zamiast poziomów nagłówków do kontrolowania rozmiaru.
    • Divy pozostają odpowiednim wyborem do prostego układu. Frameworki zmieniają się co kilka lat, ale ta podstawa funkcjonuje od dziesięcioleci, a markup, który jasno określa znaczenie elementów, przynosi korzyści zarówno użytkownikom, motorom wyszukiwania, jak i twojemu zespołowi.

    Pozycje pokrewne

    Wszystkie artykułyWyślij brief