WCAG 2.5.5: Rozmiar celu (rozszerzony)

Co oznacza ta zasada

WCAG 2.5.5 Target Size (Enhanced) to kryterium poziomu AAA w ramach WCAG 2.2, które określa rygorystyczny minimalny rozmiar elementów interaktywnych. Wymaga ono, aby rozmiar celu — klikalnego lub dotykowego obszaru dowolnego komponentu interfejsu użytkownika — wynosił co najmniej 44 na 44 piksele CSS zarówno na szerokość, jak i na wysokość. Ma to zastosowanie do wszystkich interakcji opartych na wskaźniku, w tym kliknięć myszą, stuknięć na ekranie dotykowym i użycia rysika.

Ważne jest, aby zrozumieć, co dokładnie stanowi „cel” w tym kontekście. Celem jest cały aktywowany obszar kontrolki, a nie tylko jej wizualna reprezentacja. Mała ikona może mieć wizualnie 16×16 pikseli, ale jeśli otaczający ją odstęp (padding) rozszerza klikalny obszar do 44×44 pikseli, kryterium nadal może być spełnione. Oznacza to, że deweloperzy mogą strategicznie używać paddingu, aby spełnić wymaganie bez drastycznej zmiany projektu wizualnego.

Kryterium definiuje zaliczenie jako każdy element interaktywny, którego obszar celu ma co najmniej 44×44 piksele CSS. Niezaliczenie występuje, gdy aktywowany obszar elementu interaktywnego spada poniżej tego progu w którymkolwiek wymiarze — na przykład link, który ma 44 piksele szerokości, ale tylko 20 pikseli wysokości, nadal nie spełnia wymagań.

WCAG 2.5.5 przewiduje kilka oficjalnych wyjątków, w których wymóg 44×44 nie ma zastosowania. Są to:

• Odstępy (Spacing): Niedowymiarowane cele są akceptowalne, jeśli wystarczający odstęp oddziela je od wszystkich innych celów. Cel musi być umieszczony tak, aby gdyby wycentrować na nim okrąg o średnicy 44×44 piksele CSS, okrąg ten nie przecinał żadnego innego celu ani ramki ograniczającej okręgu 44×44 innego celu. Ten wyjątek zapobiega konieczności zmian układu w sytuacjach, gdy sąsiadujące kontrolki są z natury małe, ale dobrze odseparowane.
• Equivalent: Alternatywna kontrolka na tej samej stronie wykonuje tę samą funkcję i spełnia minimalny wymóg rozmiaru.
• Inline: Cel znajduje się w zdaniu lub jego rozmiar jest w inny sposób ograniczony przez interlinię tekstu, który nie jest celem. Hiperłącza w akapicie tekstu głównego są na przykład zwolnione, ponieważ ich powiększenie zakłóciłoby przepływ tekstu.
• User agent control: Rozmiar jest całkowicie określany przez przeglądarkę lub system operacyjny i nie może być zmieniony przez autora. Natywne kontrolki formularzy przeglądarki w stanie bez stylów mogą należeć do tej kategorii.
• Essential: Określona prezentacja celu jest istotna dla przekazywanej informacji. Jest to wąski wyjątek dla przypadków, w których zmiana rozmiaru celu zasadniczo zmieniłaby znaczenie lub funkcjonalność.

Kryterium to zostało wprowadzone w WCAG 2.2 i zastępuje wcześniejsze, mniej rygorystyczne wytyczne dotyczące celów wskaźnika. Jego kryterium towarzyszące, WCAG 2.5.8 Target Size (Minimum) na poziomie AA, ustala niższy próg 24×24 piksele CSS z obliczeniem opartym na odstępach, ale 2.5.5 pozostaje złotym standardem dla zwiększonej dostępności.

Dlaczego to ma znaczenie

Upośledzenia motoryczne i zręcznościowe dotykają znaczną część światowej populacji. Według Światowej Organizacji Zdrowia około 1,3 miliarda ludzi — czyli 16% populacji świata — żyje z jakąś formą znaczącej niepełnosprawności, przy czym schorzenia motoryczne i układu mięśniowo-szkieletowego należą do najpowszechniejszych. Schorzenia takie jak choroba Parkinsona, drżenie samoistne, porażenie mózgowe, stwardnienie rozsiane, hemiplegia poudarowa oraz urazy wynikające z powtarzalnego przeciążenia zmniejszają zdolność osoby do wykonywania precyzyjnych ruchów wskaźnikiem. Na urządzeniach mobilnych nawet użytkownicy bez niepełnosprawności mogą mieć trudności z małymi celami, gdy używają rękawiczek, gdy mają mokre ręce lub po prostu gdy obsługują telefon jedną ręką.

Rozważmy konkretny scenariusz z życia: osoba z reumatoidalnym zapaleniem stawów przegląda turecką platformę e-commerce na tablecie z ekranem dotykowym, aby kupić leki. Proces finalizacji zakupu obejmuje małe przyciski opcji (radio), wąskie menu rozwijane i przycisk „Potwierdź zamówienie” o rozmiarze 24×18 pikseli. Każde błędne stuknięcie albo wybiera złą opcję, albo nie robi nic, zmuszając użytkownika do wielokrotnych prób. Frustracja nie jest jedynie niedogodnością — może spowodować całkowite porzucenie zakupu, zamieniając błąd w dostępności w bezpośrednią stratę przychodu dla firmy.

Poza upośledzeniami motorycznymi odpowiednio duże cele przynoszą korzyści szerokiej grupie użytkowników. Osoby starsze często doświadczają jednocześnie obniżonej precyzji ruchów i pogorszonej ostrości wzroku, co sprawia, że małe cele są podwójnie trudne. Użytkownicy z niepełnosprawnościami poznawczymi mogą potrzebować więcej czasu na ustawienie wskaźnika i częściej przypadkowo uruchamiają sąsiednie kontrolki, jeśli cele są zbyt gęsto rozmieszczone. Nawet widzący, sprawni użytkownicy odnoszą korzyści z większych celów na urządzeniach mobilnych — to fakt, który od lat napędza konwencje projektowe w dużych firmach technologicznych. Wytyczne Apple Human Interface Guidelines zalecają minimalny cel dotykowy 44×44 punkty, a wytyczne Google Material Design zalecają co najmniej 48×48 piksele niezależne od gęstości z tych samych powodów.

Z perspektywy SEO i użyteczności metryka „Interaction to Next Paint” (INP) w ramach Google Core Web Vitals premiuje interfejsy, w których interakcje użytkownika są rejestrowane szybko i poprawnie. Błędne stuknięcia spowodowane zbyt małymi celami zwiększają odsetek nieudanych interakcji, wydłużają czas wykonania zadania i podnoszą współczynnik odrzuceń — wszystkie te sygnały mogą pośrednio wpływać na pozycję w wynikach wyszukiwania. Ulepszenia dostępności na poziomie celów wskaźnika mają zatem wymierne konsekwencje biznesowe wykraczające poza samą zgodność z przepisami.

Powiązane reguły Axe-core

WCAG 2.5.5 wymaga testów manualnych. Nie istnieje w pełni zautomatyzowana reguła axe-core, która niezawodnie oznacza wszystkie naruszenia rozmiaru celu dla tego rozszerzonego kryterium. Powody, dla których narzędzia automatyczne mają tu trudności, są wielorakie: efektywny rozmiar celu zależy od obliczonego układu CSS, w tym paddingu, marginesów i wymiarów pseudoelementów, które różnią się w zależności od widoku, współczynnika pikseli urządzenia i dynamicznego renderowania. Dodatkowo wyjątek dotyczący odstępów wymaga obliczenia geometrycznego przesunięcia między sąsiednimi celami — obliczenia, które wymaga pełnego drzewa układu po renderowaniu i analizy bliskości, czego automatyczne narzędzia parsujące DOM nie są w stanie dokładnie wykonać we wszystkich przypadkach. Ponadto to, czy element kwalifikuje się do wyjątku „inline” lub „equivalent”, wymaga zrozumienia semantycznego i kontekstowego, które wykracza poza możliwości automatycznych silników reguł.

• target-size (axe-core experimental): Axe-core zawiera eksperymentalną regułę o nazwie target-size, która sprawdza elementy interaktywne względem progu WCAG 2.5.8 poziomu AA wynoszącego 24×24 piksele CSS z uwzględnieniem odstępów. Choć reguła ta może ujawnić niektóre mniejsze naruszenia, nie egzekwuje ona bardziej rygorystycznego progu 44×44 wymaganego przez 2.5.5 i może pominąć naruszenia, w których padding lub pseudoelementy wpływają na renderowany obszar trafienia w sposób, którego migawka DOM nie wychwytuje. Traktuj wszelkie wyniki tej reguły jako punkt wyjścia, a nie kompletny audyt.
• Manualna inspekcja wizualna: Ponieważ żadna reguła automatyczna nie obejmuje w pełni 2.5.5, testerzy muszą wizualnie sprawdzać i mierzyć cele interaktywne za pomocą narzędzi deweloperskich przeglądarki, linijek pikseli CSS lub rozszerzeń przeglądarki dotyczących dostępności. Obejmuje to sprawdzenie, czy padding jest wliczony w obszar trafienia oraz czy wyjątki dotyczące odstępów są faktycznie spełnione — a nie tylko zakładane.

Jak testować

1. Uruchom skan automatyczny jako punkt odniesienia: Otwórz axe DevTools lub Lighthouse w Chrome DevTools na testowanej stronie. W axe DevTools przefiltruj wyniki według „target-size”, jeśli jest dostępne w ramach reguł eksperymentalnych. Zanotuj wszystkie oznaczone elementy, ale miej świadomość, że ten skan nie wychwyci wszystkich naruszeń 2.5.5 i może odnosić się do progu 2.5.8 zamiast 44×44 piksele. Użyj audytu dostępności Lighthouse, aby wyszukać powiązane ostrzeżenia dotyczące celów wskaźnika.
2. Mierz rozmiary celów za pomocą DevTools przeglądarki: Otwórz DevTools Chrome lub Firefox i użyj panelu Elements, aby zbadać każdy element interaktywny — przyciski, linki, pola formularzy, pola wyboru, przyciski opcji, kontrolki niestandardowe i kontrolki składające się wyłącznie z ikon. W panelu stylów obliczonych (Computed) sprawdź renderowaną szerokość i wysokość. Pamiętaj, że padding jest wliczany w cel kliknięcia dla elementów blokowych, ale może nie być wliczany dla elementów inline. Zweryfikuj, że obliczony obszar trafienia ma co najmniej 44×44 piksele CSS.
3. Użyj wbudowanych narzędzi dostępności przeglądarki: W Chrome DevTools otwórz kartę Rendering i włącz „Emulate a focused page” lub użyj Accessibility Tree do inspekcji elementów. W Firefox użyj Accessibility Inspector, aby zidentyfikować elementy interaktywne i porównać ich wymiary ramki ograniczającej.
4. Testuj na prawdziwych urządzeniach dotykowych: Podłącz fizyczne urządzenie z iOS i testuj z włączonym VoiceOver (trzykrotne naciśnięcie bocznego przycisku, aby aktywować). Nawiguj, stukając, i używaj rotora, aby przechodzić między elementami interaktywnymi. Spróbuj aktywować małe cele i zanotuj, jak często przypadkowo uruchamiane są elementy sąsiednie. Powtórz na urządzeniu z Androidem, używając TalkBack (przesunięcie w prawo, aby nawigować, dwukrotne stuknięcie, aby aktywować). Zwróć szczególną uwagę na niestandardowe widżety zbudowane z elementów <div> lub <span>.
5. Ręcznie testuj wyjątki dotyczące odstępów: Dla każdego celu mniejszego niż 44×44 piksele, który powołuje się na wyjątek dotyczący odstępów, narysuj wyobrażoną ramkę 44×44 piksele wycentrowaną na tym celu i wizualnie potwierdź, że żaden inny element interaktywny nie znajduje się w tej ramce. Rozszerzenia przeglądarki lub narzędzia nakładkowe rysujące ramki mogą w tym pomóc.
6. Weryfikacja za pomocą klawiatury i czytników ekranu: Testuj z NVDA + Firefox i JAWS + Chrome, przechodząc klawiszem Tab przez wszystkie elementy interaktywne. Choć fokus klawiatury nie testuje bezpośrednio rozmiaru celu wskaźnika, pomaga zidentyfikować, czy wszystkie kontrolki są osiągalne, i potwierdza inwentarz elementów, względem którego będziesz porównywać rozmiary celów wskaźnika. VoiceOver + Safari na macOS można użyć do weryfikacji, czy kontrolki niestandardowe są poprawnie anonsowane i mają odpowiednie obszary aktywacji przy kliknięciu wskaźnikiem.
7. Testuj przy wielu szerokościach widoku: Rozmiary celów mogą się różnić między układami desktopowymi i mobilnymi. Testuj przy szerokościach widoku 320px, 768px i 1280px, aby potwierdzić, że projekty responsywne utrzymują minimum 44×44 na wszystkich punktach przerwania, szczególnie w menu hamburgerowych, karuzelach i kolumnach akcji w tabelach danych.

Jak naprawić

Przycisk z samą ikoną o niewystarczającym rozmiarze — niepoprawne

<!-- A close button rendered as a small SVG icon with no padding.
     The rendered size is approximately 16x16 CSS pixels, far below the 44x44 minimum. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

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

Przycisk z samą ikoną o niewystarczającym rozmiarze — poprawne

<!-- Padding is added to expand the hit area to at least 44x44 CSS pixels
     while preserving the visual icon size. The button itself has explicit
     min-width and min-height to guarantee compliance across browsers. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

<style>
.close-btn {
  background: none;
  border: none;
  padding: 14px; /* 16px icon + 14px * 2 padding = 44px total hit area */
  min-width: 44px;
  min-height: 44px;
  cursor: pointer;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}
</style>

Niestandardowe pole wyboru zbudowane z div — niepoprawne

<!-- A visually styled custom checkbox that is too small to meet the target size
     requirement. The div has no padding and renders at 20x20 pixels. -->
<div role='checkbox' aria-checked='false' tabindex='0' class='custom-check'></div>

<style>
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  cursor: pointer;
}
</style>

Niestandardowe pole wyboru zbudowane z div — poprawne

<!-- The visual box remains 20x20 pixels but is wrapped in a label element
     whose total clickable area is expanded to 44x44 via padding.
     Using a native input element is strongly preferred over role=checkbox
     because it provides built-in keyboard and pointer behavior. -->
<label class='check-wrapper'>
  <input type='checkbox' class='sr-only'>
  <span class='custom-check' aria-hidden='true'></span>
  Subscribe to newsletter
</label>

<style>
.check-wrapper {
  display: inline-flex;
  align-items: center;
  gap: 8px;
  min-height: 44px; /* entire label row is at least 44px tall */
  cursor: pointer;
  padding: 12px 0; /* vertical padding expands the hit area */
}
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  flex-shrink: 0;
}
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0,0,0,0);
  white-space: nowrap;
  border: 0;
}
</style>

Linki nawigacyjne w pasku narzędzi z ciasnymi odstępami — niepoprawne

<!-- Toolbar links rendered as small inline elements.
     Each link is approximately 32px wide and 24px tall,
     and they are spaced only 4px apart — failing both size and spacing exceptions. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 12px;
  padding: 2px 4px;
  margin: 0 2px;
}
</style>

Linki nawigacyjne w pasku narzędzi z ciasnymi odstępami — poprawne

<!-- Each link now has padding that expands its hit area to at least 44x44 px.
     The gap between links is also increased so the spacing exception would
     apply even if sizing were relaxed in future. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 14px;
  display: inline-flex;
  align-items: center;
  min-height: 44px;
  padding: 0 16px; /* horizontal padding extends width well past 44px */
  margin: 0 4px;
  text-decoration: underline;
}
</style>

Typowe błędy

• Zakładanie, że wizualna ramka ograniczająca jest równa obszarowi trafienia: Ustawienie width: 44px; height: 44px na obrazie ikony wewnątrz przycisku nie sprawia, że przycisk ma 44×44 — tylko nadanie tych wymiarów lub równoważnego paddingu samemu elementowi <button> tworzy poprawny obszar trafienia.
• Używanie padding: 0 do resetowania stylów przeglądarki bez kompensującego minimalnego rozmiaru: Resety CSS często usuwają cały padding z przycisków i pól formularzy. Po resecie zawsze ponownie zastosuj wystarczający padding lub jawne wartości min-width i min-height, aby przywrócić obszar aktywacji.
• Poleganie wyłącznie na line-height w celu zwiększenia wysokości celu: Zwiększenie line-height wpływa na odstępy tekstu, ale nie zawsze rozszerza klikalny obszar odnośnika lub przycisku. Zamiast tego używaj padding-top i padding-bottom.
• Umieszczanie wielu małych przycisków z ikonami obok siebie bez wystarczających odstępów: Rząd ikon udostępniania w mediach społecznościowych 24×24 z marginesami tylko 2px nie spełnia ani wymogu rozmiaru, ani wyjątku dotyczącego odstępów, ponieważ okręgi 44px wycentrowane na każdej ikonie nachodziłyby na sąsiednie.
• Błędne stosowanie wyjątku dla tekstu inline do linków nawigacyjnych: Wyjątek dotyczy linków w zdaniu lub akapicie płynącego tekstu. Menu nawigacyjne, paski narzędzi i listy linków nie są tekstem inline i nie kwalifikują się do tego wyjątku, nawet jeśli używają display: inline.
• Budowanie kontrolek niestandardowych z role='button' na <span> i zapominanie o nadaniu rozmiaru spanowi: Czytniki ekranu ogłoszą span jako przycisk, ale jego domyślny renderowany rozmiar będzie określony wyłącznie przez treść tekstową, która zazwyczaj jest znacznie mniejsza niż 44×44 piksele. Zawsze dodawaj display: inline-flex, min-width, min-height i padding.
• Brak testów na prawdziwych urządzeniach dotykowych przy rzeczywistym rozmiarze widoku: Mierzenie pikseli w DevTools na desktopie nie jest wystarczające. Gęstość pikseli CSS i zachowanie systemowe przy wykrywaniu celów dotykowych mogą się różnić między środowiskami symulowanymi a fizycznymi urządzeniami.
• Pomijanie dynamicznie renderowanych kontrolek: Podpowiedzi (tooltips), komórki dni w selektorach dat, elementy podpowiedzi w polach autouzupełniania i przyciski zamykania w modalach są często wstrzykiwane przez biblioteki JavaScript z twardo zakodowanymi małymi rozmiarami. Audytuj wynik widżetów zewnętrznych i nadpisuj ich style, jeśli to konieczne.
• Powoływanie się na wyjątek dotyczący odstępów bez jego zmierzenia: Wyjątek dotyczący odstępów jest geometryczny i precyzyjny. Wizualne założenie, że kontrolki wyglądają na wystarczająco oddalone, nie jest wystarczające — test z okręgiem 44px musi być zastosowany do każdego niedowymiarowanego celu, aby potwierdzić brak nakładania się.
• Zapominanie o weryfikacji po zmianach punktów przerwania w układzie responsywnym: Przycisk, który ma 44×44 na desktopie, może skurczyć się do 30×30 przy szerokości widoku 375px z powodu szerokości procentowych lub kurczenia się flexboxa. Zawsze ponownie testuj rozmiary celów na każdym głównym punkcie przerwania.

Związek z tureckimi regulacjami dotyczącymi dostępności

Turecka Okrężnica Prezydencka nr 2025/10, opublikowana w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia obowiązkowe wymagania dotyczące dostępności stron internetowych i aplikacji mobilnych oparte na standardzie WCAG 2.2. Okrężnica ma zastosowanie do określonego zestawu podmiotów działających w Turcji i nakłada prawne obowiązki w zakresie zgodności z określonymi poziomami WCAG.

Typy podmiotów objętych okrężnicą obejmują: instytucje i agencje publiczne na szczeblu centralnym i lokalnym; banki i instytucje finansowe regulowane przez Banking Regulation and Supervision Agency (BDDK); szpitale i świadczeniodawców opieki zdrowotnej, zarówno publicznych, jak i prywatnych; operatorów telekomunikacyjnych z 200,000 lub większą liczbą abonentów; platformy e-commerce powyżej określonych progów przychodów lub liczby transakcji; biura podróży prowadzące internetowe usługi rezerwacji; prywatne firmy transportowe oferujące cyfrową sprzedaż biletów lub rezerwacje; oraz szkoły prywatne i instytucje edukacyjne upoważnione przez Ministry of National Education (MoNE).

WCAG 2.5.5 Target Size (Enhanced) jest kryterium poziomu AAA i nie należy do minimalnych obowiązkowych wymagań ustanowionych przez okrężnicę, która koncentruje się głównie na zgodności z poziomami A i AA. Jednak okrężnica wyraźnie zachęca podmioty objęte regulacją — szczególnie te obsługujące społeczeństwo, pacjentów i uczniów — do dążenia do zgodności z poziomem AAA tam, gdzie jest to wykonalne, uznając, że reprezentuje on najlepsze praktyki w zakresie dostępności.

Dla organizacji w Turcji wdrożenie WCAG 2.5.5 ma szczególną wartość strategiczną w kilku kontekstach. Portale rządowe obsługujące osoby starsze, systemy rezerwacji wizyt medycznych używane przez pacjentów z chorobami przewlekłymi oraz aplikacje bankowe używane przez osoby z upośledzeniami motorycznymi w znacznym stopniu korzystają z celów o rozmiarze 44×44 piksele. Turcja ma szybko starzejącą się populację, a Turecki Instytut Statystyczny (TÜİK) prognozuje, że obywatele w wieku 65 lat i starsi będą stanowić ponad 16% populacji do 2040 r. — jest to grupa demograficzna, dla której rozmiar celu wskaźnika jest kluczowym czynnikiem użyteczności.

Nawet tam, gdzie poziom AAA nie jest prawnie wymagany, organizacje, które dobrowolnie spełniają WCAG 2.5.5, demonstrują zaangażowanie, które może zmniejszyć ryzyko sporów sądowych, wzmocnić kwalifikowalność w przetargach publicznych wymagających dokumentacji dostępności oraz poprawić wskaźniki satysfakcji użytkowników na konkurencyjnych rynkach, takich jak e-commerce i fintech. SDK Accsible zapewnia konfigurowalne funkcje zwiększania celów dotykowych, które mogą pomóc organizacjom spełnić to kryterium lub się do niego zbliżyć, a dokumentacja takich działań może stanowić część Accessibility Conformance Report (ACR) lub zgłoszenia VPAT wymaganego w procesach zamówień instytucjonalnych.