WCAG 2.5.8: Minimalny rozmiar celu

Co Oznacza Ta Zasada

WCAG 2.5.8 Target Size (Minimum) to kryterium sukcesu na poziomie AA wprowadzone w WCAG 2.2. Stanowi ono, że rozmiar celu dla wejść wskaźnikiem musi wynosić co najmniej 24×24 piksele CSS, z jednym ważnym wyjątkiem: jeśli sam cel jest mniejszy niż 24×24 piksele CSS, to wokół niego musi istnieć wystarczająca przestrzeń odsunięcia, tak aby łączny obszar — łącznie z tą przestrzenią — spełniał próg 24×24 w każdym kierunku. Innymi słowy, prostokąt ograniczający celu plus wszelka przylegająca pusta przestrzeń, wolna od innych celów, muszą łącznie osiągać 24 piksele CSS w poziomie i 24 piksele CSS w pionie.

Kryterium dotyczy każdego elementu, który może otrzymać zdarzenie wskaźnika: linków (<a>), przycisków (<button>), pól wyboru (checkbox), przycisków opcji (radio), kontrolek select, suwaków, niestandardowych widżetów z nasłuchiwaczami zdarzeń wskaźnika oraz każdego elementu z nadaną rolą ARIA, która implikuje interaktywność. Nie dotyczy elementów nieinteraktywnych, takich jak dekoracyjne obrazy czy statyczny tekst, nawet jeśli są duże.

Cel spełnia to kryterium, gdy prawdziwy jest co najmniej jeden z poniższych warunków:

• Renderowany rozmiar celu wynosi co najmniej 24×24 piksele CSS w obu wymiarach.
• Cel jest mniejszy niż 24 piksele CSS w jednym lub obu wymiarach, ale odsunięcie między krawędzią celu a najbliższym sąsiednim elementem interaktywnym jest na tyle duże, że łączny obszar celu plus odsunięcie wynosi co najmniej 24×24 piksele CSS.
• Cel jest elementem inline w obrębie zdania lub bloku tekstu, co jest wyraźnie wyłączone, ponieważ zmiana przepływu takich celów zakłóciłaby czytanie.
• Wizualny rozmiar celu jest całkowicie determinowany przez domyślny arkusz stylów user-agenta przeglądarki i autor go nie modyfikował — jest to wyjątek dla natywnych kontrolek.
• Istnieje nieinteraktywna prezentacja tych samych informacji, a mały cel jest jedynie alternatywą, a nie jedynym sposobem aktywacji.

Cel nie spełnia kryterium, gdy jest mniejszy niż 24×24 piksele CSS i nie ma wystarczającej przestrzeni odsunięcia, aby to zrekompensować, a żaden z powyższych wyjątków nie ma zastosowania. Typowe przykłady z rzeczywistości to małe przyciski z samą ikoną (np. ikona zamknięcia 16×16 w modalu), gęsto upakowane linki nawigacyjne z minimalnym paddingiem oraz rzędy ikon udostępniania w mediach społecznościowych, gdzie każda ikona jest renderowana w rozmiarze 20×20 pikseli z jedynie 2 px marginesu między nimi.

Warto zauważyć, że WCAG 2.5.8 to wymaganie minimalne. Powiązane kryterium AAA 2.5.5 Target Size (Enhanced) wymaga co najmniej 44×44 piksele CSS bez wyjątku związanego z przestrzenią odsunięcia, a wiele wytycznych użyteczności zaleca 44–48 pikseli CSS jako wygodny cel dotykowy. Spełnienie 2.5.8 to podłoga, a nie sufit.

Dlaczego To Ma Znaczenie

Niepełnosprawności motoryczne wpływają na precyzję wskaźnika na wiele różnych sposobów. Osoby z chorobą Parkinsona, drżeniem samoistnym, porażeniem mózgowym, stwardnieniem rozsianym, niedowładem połowiczym po udarze lub urazami wynikającymi z powtarzalnego przeciążenia mogą nie być w stanie wiarygodnie trafić wskaźnikiem w mały cel. U osób starszych również występuje naturalny spadek kontroli motoryki precyzyjnej: około 15% osób powyżej 65 roku życia zgłasza istotne trudności w korzystaniu z myszy lub ekranu dotykowego. Poza stanami klinicznymi, nawet użytkownicy z przejściowo ograniczoną sprawnością — ktoś trzymający smartfon jedną ręką w jadącym autobusie albo ktoś, czyj palec jest duży w stosunku do małego ekranu telefonu — mają problem z bardzo małymi celami.

Zgodnie z danymi Światowej Organizacji Zdrowia ponad 1,3 miliarda ludzi na świecie żyje z jakąś formą niepełnosprawności, a niepełnosprawność motoryczna należy do najczęstszych kategorii. Gdy elementy interaktywne są zbyt małe lub zbyt blisko siebie, użytkownicy ci doświadczają przypadkowych aktywacji, chybionych stuknięć i powtarzających się błędów, które sprawiają, że strona jest w praktyce bezużyteczna. Frustrację potęguje fakt, że na urządzeniach dotykowych nie ma stanu hover, który pozwoliłby potwierdzić pozycję kursora przed kliknięciem.

Rozważmy konkretny scenariusz: turecka strona e-commerce sprzedająca elektronikę wyświetla rząd pięciu ikon udostępniania w mediach społecznościowych na górze każdej strony produktu, każda o rozmiarze 18×18 pikseli z odstępem 3 px między nimi. Użytkowniczka z drżeniem samoistnym, próbując udostępnić produkt w WhatsApp, wielokrotnie stuka w niewłaściwą ikonę, wywołując niechciane udostępnienia na Facebooku. Nie ma możliwości szybkiego cofnięcia tych udostępnień, a zadanie staje się tak podatne na błędy, że całkowicie je porzuca. Zwiększenie każdej ikony do 24×24 piksele CSS lub dodanie paddingu tak, aby obszar klikalny osiągał 24×24, rozwiązałoby problem bez istotnej zmiany projektu wizualnego.

Poza dostępnością, odpowiedni rozmiar celów koreluje z wyższymi współczynnikami konwersji, niższymi współczynnikami odrzuceń i lepszymi wynikami Core Web Vitals związanymi z gotowością do interakcji. Indeksowanie mobile-first przez wyszukiwarki również faworyzuje strony zapewniające dobrą użyteczność dotykową, co sprawia, że rozmiar celów jest czynnikiem na styku dostępności i SEO.

Powiązane Reguły Axe-core

• target-size (experimental): Ta reguła sprawdza, czy elementy interaktywne mają renderowany rozmiar co najmniej 24×24 piksele CSS lub, w przypadku mniejszych elementów, czy istnieje wystarczająca przestrzeń odsunięcia, tak aby łączny osiągalny obszar spełniał próg. Reguła odczytuje obliczone wymiary i prostokąty ograniczające elementów fokusowalnych i interaktywnych dla wskaźnika i oznacza te, które nie spełniają testu rozmiar-lub-odsunięcie. Ponieważ jest obecnie oznaczona jako experimental, nie jest uwzględniona w domyślnym zestawie reguł axe-core i musi zostać jawnie włączona za pomocą runOnly: { type: 'tag', values: ['wcag22aa', 'experimental'] } lub przez włączenie reguł eksperymentalnych w axe DevTools. Reguła może generować fałszywie pozytywne wyniki dla linków tekstowych inline i natywnych kontrolek, które przeglądarki różnie rozmiarują na różnych platformach, dlatego po automatycznym skanowaniu zawsze zaleca się ręczny przegląd. Nie może ona wiarygodnie wykrywać przypadków zaliczenia na podstawie odstępów, gdy w grę wchodzą złożone układy CSS, transformacje lub nakładające się konteksty stosu z-index, dlatego ręczna inspekcja obliczonych stylów w DevTools pozostaje niezbędna.

Ponieważ rozmiar celu zależy od renderowania wizualnego, obliczonego CSS, wymiarów viewportu oraz bliskości sąsiednich elementów interaktywnych, narzędzia automatyczne mogą oznaczać oczywiste błędy, ale nie zastąpią ludzkiego osądu. Narzędzie może zmierzyć prostokąt ograniczający przycisku, ale ustalenie, czy odsunięcie między dwoma sąsiednimi celami jest rzeczywiście wolne od innych elementów interaktywnych — zwłaszcza w dynamicznych interfejsach lub napędzanych JavaScriptem — wymaga ręcznej weryfikacji.

Jak Testować

1. Automatyczny skan z axe DevTools: Zainstaluj rozszerzenie przeglądarki axe DevTools. Otwórz testowaną stronę. W panelu axe DevTools włącz reguły eksperymentalne przed uruchomieniem skanowania (znajdź filtr tagów reguł i dodaj experimental). Po zakończeniu skanowania przefiltruj wyniki według identyfikatora reguły target-size. Dla każdego oznaczonego elementu zanotuj zgłoszone wymiary. Zweryfikuj znalezisko ręcznie, zanim zarejestrujesz je jako potwierdzoną niezgodność, ponieważ reguły eksperymentalne mają wyższy odsetek fałszywie pozytywnych wyników.
2. Automatyczny skan z Lighthouse: Uruchom audyt dostępności Lighthouse w Chrome DevTools lub przez CLI. Lighthouse zawiera audyt tap-targets, który sprawdza cele mniejsze niż 48×48 piksele CSS z niewystarczającymi odstępami — zwróć uwagę, że używa to bardziej rygorystycznego progu niż WCAG 2.5.8, więc błędy Lighthouse są nadzbiorem błędów WCAG. Przejrzyj oznaczone elementy w raporcie i porównaj je z progiem 24×24 WCAG, aby ustalić, które stanowią faktyczne niezgodności na poziomie AA, a które są rekomendacjami dobrych praktyk.
3. Ręczny pomiar w DevTools przeglądarki: Otwórz DevTools i zbadaj każdy element interaktywny. W panelu Computed sprawdź width i height. Jeśli którykolwiek jest poniżej 24 px, przełącz się na widok Box Model i sprawdź padding. Jeśli padding zwiększa cel do 24×24, jest on zgodny. Jeśli nie, zmierz odstęp do najbliższego sąsiedniego elementu interaktywnego, używając prostokąta ograniczającego elementu: uruchom w konsoli document.querySelector('your-selector').getBoundingClientRect() i porównaj współrzędne sąsiednich elementów. Jeśli łączny odstęp w każdym wymiarze zwiększa efektywny osiągalny obszar do 24 px, cel jest zgodny.
4. Symulacja dotyku: W Chrome DevTools włącz emulację urządzenia i przełącz się na profil urządzenia zoptymalizowanego pod dotyk. Spróbuj stuknąć każdy mały element interaktywny. Zanotuj przypadki, w których aktywacja zamierzonego elementu jest trudna lub gdy przypadkowo wyzwalane są elementy sąsiednie.
5. Testowanie klawiaturą i czytnikiem ekranu (dla kontekstu): Choć WCAG 2.5.8 dotyczy konkretnie wskaźnika, potwierdzenie, że małe cele mają również widoczne wskaźniki fokusu i są dostępne z klawiatury, pomaga zidentyfikować problemy złożone. Użyj NVDA z Firefoxem lub JAWS z Chrome, aby nawigować po elementach interaktywnych i potwierdzić, że są one osiągalne i aktywowalne niezależnie od rozmiaru.
6. Testowanie na rzeczywistych urządzeniach: Przetestuj na fizycznym urządzeniu mobilnym — najlepiej zarówno na dużym Androidzie, jak i mniejszym urządzeniu z iOS — aby potwierdzić, że cele, które przechodzą test na desktopie, są również zgodne przy mobilnych rozmiarach viewportu, ponieważ gęstość pikseli CSS i zachowanie powiększania mogą wpływać na postrzegany rozmiar celu.

Jak Naprawić

Mały przycisk z samą ikoną — Nieprawidłowo

<!-- Close button is only 16x16 CSS pixels, no padding, adjacent to other controls -->
<button class='close-btn' aria-label='Close dialog'>
  <svg width='16' height='16' aria-hidden='true'></svg>
</button>

<style>
  .close-btn {
    width: 16px;
    height: 16px;
    padding: 0;
    border: none;
    background: none;
    cursor: pointer;
  }
</style>

Mały przycisk z samą ikoną — Prawidłowo

<!-- Adding padding increases the interactive area to 24x24 CSS pixels
     while the visual icon remains 16x16. The min-width/min-height
     ensures the target meets the WCAG 2.5.8 threshold. -->
<button class='close-btn' aria-label='Close dialog'>
  <svg width='16' height='16' aria-hidden='true'></svg>
</button>

<style>
  .close-btn {
    min-width: 24px;
    min-height: 24px;
    padding: 4px;
    border: none;
    background: none;
    cursor: pointer;
    display: inline-flex;
    align-items: center;
    justify-content: center;
  }
</style>

Gęsto upakowane linki nawigacyjne — Nieprawidłowo

<!-- Each link renders at roughly 20px tall with 1px margin,
     leaving insufficient offset spacing between targets -->
<nav aria-label='Main navigation'>
  <ul class='nav-list'>
    <li><a href='/about'>About</a></li>
    <li><a href='/services'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

<style>
  .nav-list li { margin: 1px 0; }
  .nav-list a { font-size: 12px; line-height: 1.4; display: block; }
</style>

Gęsto upakowane linki nawigacyjne — Prawidłowo

<!-- Padding on each anchor ensures the target area is at least 24px tall.
     The gap between items is now large enough to satisfy the offset rule
     even if the text itself is smaller than 24px. -->
<nav aria-label='Main navigation'>
  <ul class='nav-list'>
    <li><a href='/about'>About</a></li>
    <li><a href='/services'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

<style>
  .nav-list { list-style: none; padding: 0; margin: 0; }
  .nav-list a {
    display: block;
    padding: 6px 8px; /* vertical padding brings block height to >= 24px */
    font-size: 14px;
    line-height: 1.4;
    text-decoration: none;
  }
</style>

Pole wyboru z bardzo małym obszarem trafienia — Nieprawidłowo

<!-- The default checkbox is visually 13px on many browsers and has no
     associated label providing additional target area -->
<input type='checkbox' id='agree'>
<span>I agree to the terms</span>

Pole wyboru z powiązaną etykietą — Prawidłowo

<!-- Wrapping the input in a <label> makes the entire label text also
     a valid pointer target. The label's line-height and padding ensure
     the combined hit area easily exceeds 24x24 CSS pixels.
     The input itself is given min-width/min-height as a fallback. -->
<label class='checkbox-label'>
  <input type='checkbox' id='agree' class='checkbox-input'>
  I agree to the terms
</label>

<style>
  .checkbox-label {
    display: inline-flex;
    align-items: center;
    gap: 8px;
    padding: 4px 0;
    cursor: pointer;
    min-height: 24px;
  }
  .checkbox-input {
    min-width: 24px;
    min-height: 24px;
    cursor: pointer;
  }
</style>

Rząd ikon udostępniania w mediach społecznościowych — Nieprawidłowo

<!-- Each icon is 18x18px with only 2px gap; the combined
     reachable area for each icon is only 20px, below the 24px threshold -->
<div class='share-row'>
  <a href='#' aria-label='Share on Twitter'>
    <img src='twitter.svg' width='18' height='18' alt=''>
  </a>
  <a href='#' aria-label='Share on Facebook'>
    <img src='facebook.svg' width='18' height='18' alt=''>
  </a>
</div>

<style>
  .share-row { display: flex; gap: 2px; }
  .share-row a { display: inline-block; line-height: 1; }
</style>

Rząd ikon udostępniania w mediach społecznościowych — Prawidłowo

<!-- Each anchor now has min-width and min-height of 24px via padding,
     and the gap between anchors is at least 3px so the offset rule is
     satisfied independently even without the padding. -->
<div class='share-row'>
  <a href='#' class='share-link' aria-label='Share on Twitter'>
    <img src='twitter.svg' width='18' height='18' alt=''>
  </a>
  <a href='#' class='share-link' aria-label='Share on Facebook'>
    <img src='facebook.svg' width='18' height='18' alt=''>
  </a>
</div>

<style>
  .share-row { display: flex; gap: 6px; }
  .share-link {
    display: inline-flex;
    align-items: center;
    justify-content: center;
    min-width: 24px;
    min-height: 24px;
    padding: 3px;
  }
</style>

Typowe Błędy

• Ustawianie width i height na ikonie wewnątrz przycisku zamiast na samym przycisku: Programiści często ograniczają SVG lub obraz do 16–20 px, ale zapominają, że element <button> potrzebuje min-width: 24px; min-height: 24px i odpowiedniego paddingu, aby utworzyć wystarczający cel dotykowy.
• Usuwanie domyślnego paddingu przeglądarki z przycisków i pól formularza za pomocą padding: 0 lub globalnego resetu: Resety CSS, które zerują padding na elementach formularza, usuwają bufor utrzymujący natywne kontrolki w użytecznym rozmiarze. Zawsze ponownie dodawaj jawny padding po resecie.
• Poleganie wyłącznie na line-height, aby zwiększyć wysokość linku bez display: block lub display: inline-block: Elementy inline nie reagują na height ani pionowy padding w taki sposób jak elementy blokowe, więc link może wydawać się wizualnie wyższy, podczas gdy jego faktyczny klikalny prostokąt ograniczający pozostaje mały.
• Używanie pointer-events: none na wrapperze i podpinanie obsługi kliknięć do małego wewnętrznego elementu: Niweczy to wszelki padding lub minimalny rozmiar zastosowany do wrappera, redukując efektywny cel do renderowanego rozmiaru wewnętrznego elementu.
• Stosowanie overflow: hidden do kontenera przycisku, który przycina padding przycisku: Wizualny obszar kliknięcia jest przycinany do granic kontenera, co sprawia, że efektywny cel jest mniejszy, niż sugerują wymiary samego przycisku.
• Zapominanie o uwzględnieniu transformacji CSS, takich jak scale(): Przycisk pomniejszony wizualnie za pomocą transform: scale(0.7) w większości przeglądarek nadal ma oryginalny prostokąt ograniczający dla zdarzeń wskaźnika, ale to zachowanie jest niespójne i niepewne — zawsze ustawiaj rozmiar celów w ich docelowej skali renderowania.
• Zakładanie, że duży <label> kompensuje małe <input>, gdy etykieta i pole nie są powiązane programowo: Jeśli <label> nie używa atrybutu for odpowiadającego id pola lub jeśli pole nie jest zawarte wewnątrz etykiety, kliknięcie tekstu etykiety nie aktywuje pola, więc działa tylko mały obszar celu samego pola.
• Brak testowania w rozmiarach viewportu, w których cele są faktycznie renderowane: Przycisk, który ma 32×32 piksele CSS na desktopie, może być renderowany jako 22×22 piksele CSS w wąskim mobilnym viewportcie z powodu płynnego skalowania lub jednostek zależnych od viewportu (vw, vmin), co tworzy błąd widoczny tylko na urządzeniach mobilnych.
• Zbyt szerokie traktowanie wyjątku WCAG 2.5.8 dla linków tekstowych inline: Wyjątek dotyczy tylko linków, które są rzeczywiście inline w ciągu tekstu (np. hiperłącze w akapicie). Samodzielne linki wystylizowane tak, by wyglądały jak tekst — takie jak link „Forgot password?” pod formularzem — nie są linkami inline i muszą spełniać próg 24×24.
• Brak audytu widżetów zewnętrznych i osadzonych komponentów: Banery zgody na pliki cookie, widżety czatu i nakładki analityczne często zawierają małe przyciski (akceptuj, zamknij, zminimalizuj) wstrzykiwane przez zewnętrzne skrypty. Nadal są one częścią profilu dostępności strony i muszą być zgodne z WCAG 2.5.8, nawet jeśli kod nie został napisany wewnętrznie.

Związek z Tureckimi Regulacjami Dotyczącymi Dostępności

Prezydencki Okólnik Turcji 2025/10, opublikowany w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia wiążące wymagania dotyczące dostępności dla szerokiego zakresu dostawców usług cyfrowych działających w Turcji. Okólnik wprost odwołuje się do WCAG 2.2 jako standardu technicznego, a zgodność na poziomie AA jest wymagana, aby kwalifikować się do Erişilebilirlik Logosu (Logotyp Dostępności) wydawanego przez Ministerstwo Rodziny i Usług Społecznych (Aile ve Sosyal Hizmetler Bakanlığı). Ponieważ WCAG 2.5.8 jest kryterium na poziomie AA w WCAG 2.2, wchodzi bezpośrednio w zakres tego obowiązkowego ramowego dokumentu.

Typy podmiotów objętych Okólnikiem obejmują instytucje publiczne i agencje rządowe na szczeblu centralnym i lokalnym, banki i firmy usług finansowych, szpitale i prywatnych dostawców usług zdrowotnych, operatorów telekomunikacyjnych z 200 000 lub większą liczbą abonentów, platformy e-commerce, biura podróży, prywatne firmy transportowe oraz szkoły prywatne upoważnione przez Ministerstwo Edukacji Narodowej (Milli Eğitim Bakanlığı). Dla wszystkich tych organizacji zgodność z WCAG 2.5.8 nie jest jedynie rekomendacją dobrych praktyk — jest obowiązkiem regulacyjnym powiązanym z możliwością wyświetlania Logotypu Dostępności i wykazania zgodności z prawem podczas audytów.

W praktyce oznacza to, że responsywna mobilnie aplikacja webowa tureckiego banku musi zapewnić, że jej przyciski potwierdzenia przelewu, pola wprowadzania jednorazowych haseł oraz kontrolki nawigacyjne spełniają minimalny rozmiar celu 24×24 piksele CSS. Podobnie, serwis e-commerce musi zweryfikować, że jego przyciski dodawania do koszyka, selektory ilości i kontrolki filtrów mają odpowiedni rozmiar we wszystkich profilach urządzeń. Portale zdrowotne muszą przeprowadzić audyt kalendarzy rezerwacji wizyt, które są notorycznie znane z małych komórek dat, i albo powiększyć te komórki, albo zapewnić wystarczającą przestrzeń odsunięcia. Portale samoobsługowe operatorów telekomunikacyjnych muszą sprawdzić, czy linki do zarządzania kontem i kontrolki przełączników w selektorach planów danych spełniają próg.

Brak zgodności z Okólnikiem może skutkować sankcjami administracyjnymi i może uniemożliwić organizacji wyświetlanie Logotypu Dostępności, który jest coraz częściej używany jako sygnał zaufania przez tureckich konsumentów. Poza sankcjami, niezgodność naraża organizacje na skargi składane do właściwych organów nadzorczych. Biorąc pod uwagę, że Turcja ma rosnącą populację osób starszych — Turecki Instytut Statystyczny prognozuje, że osoby w wieku 65 lat i więcej będą stanowić 16,3% populacji do 2040 r. — praktyczny wpływ małych celów będzie tylko rósł z czasem, co czyni wczesną zgodność zarówno priorytetem etycznym, jak i rozsądną długoterminową strategią biznesową.