WCAG 2.5.8: 대상 크기(최소)

WCAG 2.5.8은 버튼과 링크와 같은 대화형 타깃이 최소 24×24 CSS 픽셀의 크기를 가지거나, 더 작은 타깃 주변에 충분한 간격을 두어 운동 장애가 있는 사용자가 이를 안정적으로 활성화할 수 있도록 할 것을 요구합니다. 이 기준을 충족하지 못하면 포인터를 정밀하게 제어할 수 없는 모든 사용자에게 실수로 인한 활성화와 좌절을 초래합니다.

이 규칙의 의미

WCAG 2.5.8 Target Size (Minimum)은 WCAG 2.2에서 도입된 레벨 AA 성공 기준이다. 이 기준은 포인터 입력을 위한 타깃의 크기가 최소 24×24 CSS 픽셀이어야 한다고 규정한다. 단, 중요한 예외가 하나 있다. 타깃 자체가 24×24 CSS 픽셀보다 작다면, 그 주변에 충분한 오프셋 간격(offset spacing)이 있어야 하며, 이 간격을 포함한 전체 영역이 모든 방향에서 24×24 기준을 충족해야 한다. 다시 말해, 타깃의 경계 박스와 그 주변의 다른 타깃이 없는 인접 공백을 합한 영역이 가로 24 CSS 픽셀, 세로 24 CSS 픽셀에 도달해야 한다.

이 기준은 포인터 이벤트를 받을 수 있는 모든 요소에 적용된다. 링크(<a>), 버튼(<button>), 체크박스, 라디오 버튼, 셀렉트 컨트롤, 슬라이더, 포인터 이벤트 리스너가 있는 커스텀 위젯, 그리고 상호작용성을 내포하는 ARIA role이 부여된 모든 요소가 이에 해당한다. 장식용 이미지나 정적인 텍스트처럼 비상호작용 요소에는, 설령 크기가 크더라도, 이 기준이 적용되지 않는다.

다음 중 하나 이상을 만족하면 타깃은 이 기준을 통과한다.

타깃의 렌더링된 크기가 두 방향 모두에서 최소 24×24 CSS 픽셀이다.
타깃이 한쪽 또는 양쪽 방향에서 24 CSS 픽셀보다 작지만, 타깃의 가장자리와 가장 가까운 인접 상호작용 요소 사이의 오프셋이 충분히 커서, 타깃과 오프셋을 합한 영역이 최소 24×24 CSS 픽셀에 도달한다.
타깃이 문장 또는 텍스트 블록 내의 인라인 요소이며, 이러한 타깃을 리플로우하면 읽기에 방해가 되기 때문에 명시적으로 제외된 경우이다.
타깃의 시각적 크기가 브라우저의 기본 사용자 에이전트 스타일시트에 의해 전적으로 결정되고, 작성자가 이를 수정하지 않은 경우 — 이른바 네이티브 컨트롤 예외이다.
동일한 정보를 제공하는 비상호작용 표현이 존재하고, 작은 타깃은 단지 대안일 뿐 유일한 활성화 수단이 아닌 경우이다.

타깃이 24×24 CSS 픽셀보다 작고 이를 보완할 만큼의 오프셋 간격이 충분하지 않으며, 위의 예외 사항 중 어느 것도 적용되지 않으면 타깃은 실패한다. 실제로 자주 발생하는 실패 사례로는 작은 아이콘 전용 버튼(예: 모달에서 16×16 닫기 아이콘), 패딩이 거의 없는 빽빽한 내비게이션 링크, 각 아이콘이 20×20 픽셀로 렌더링되고 아이콘 사이 여백이 2px에 불과한 소셜 공유 아이콘 행 등이 있다.

WCAG 2.5.8은 최소 요구사항이라는 점도 중요하다. 관련 AAA 기준인 2.5.5 Target Size (Enhanced)는 오프셋 간격 예외 없이 최소 44×44 CSS 픽셀을 요구하며, 많은 사용성 가이드라인은 편안한 터치 타깃 크기로 44–48 CSS 픽셀을 권장한다. 2.5.8을 충족하는 것은 바닥선일 뿐, 상한선이 아니다.

왜 중요한가

운동 장애는 포인터 정확도에 매우 다양한 방식으로 영향을 미친다. 파킨슨병, 본태성 떨림, 뇌성마비, 다발성 경화증, 뇌졸중 관련 편마비, 반복성 긴장 손상 등을 가진 사람들은 작은 타깃에 포인터를 안정적으로 맞추기 어려울 수 있다. 고령자 역시 미세 운동 조절 능력이 자연스럽게 저하되는데, 65세 이상 인구의 약 15%가 마우스나 터치스크린 사용에 상당한 어려움을 겪는다고 보고한다. 임상적 상태를 넘어, 상황적으로 장애를 겪는 사용자 — 움직이는 버스에서 한 손으로 스마트폰을 들고 있는 사람, 혹은 손가락 크기에 비해 휴대폰 화면이 작은 사람 — 역시 작은 타깃으로 인해 어려움을 겪는다.

세계보건기구에 따르면 전 세계 13억 명 이상이 어떤 형태로든 장애를 가지고 있으며, 그중 운동 장애는 가장 흔한 범주에 속한다. 상호작용 요소가 너무 작거나 서로 너무 가까이 붙어 있으면, 이 사용자들은 의도치 않은 활성화, 탭 실패, 반복적인 오류를 겪게 되고, 이는 사이트를 사실상 사용 불가능하게 만든다. 특히 터치 기기에서는 클릭을 확정하기 전에 커서 위치를 확인할 수 있는 호버 상태가 없기 때문에 이러한 좌절감이 더욱 커진다.

구체적인 상황을 생각해 보자. 전자제품을 판매하는 한 터키 전자상거래 사이트가 각 상품 페이지 상단에 5개의 소셜 공유 아이콘을 한 줄로 배치해 두었고, 각 아이콘은 18×18 픽셀에 아이콘 사이 간격은 3px에 불과하다. 본태성 떨림이 있는 한 사용자가 상품을 WhatsApp으로 공유하려고 할 때, 계속해서 잘못된 아이콘을 탭하여 원치 않는 Facebook 공유가 발생한다. 그녀는 이러한 공유를 빠르게 되돌릴 방법이 없고, 작업이 너무 오류가 잦아 결국 완전히 포기하게 된다. 각 아이콘을 24×24 CSS 픽셀로 키우거나, 클릭 가능한 영역이 24×24에 도달하도록 패딩을 추가하면 시각적 디자인을 크게 바꾸지 않고도 이 문제를 해결할 수 있다.

접근성을 넘어, 적절한 타깃 크기는 전환율 상승, 이탈률 감소, 상호작용 준비성과 관련된 Core Web Vitals 점수 향상과도 상관관계가 있다. 검색 엔진의 모바일 우선 인덱싱 역시 좋은 터치 사용성을 제공하는 페이지를 선호하므로, 타깃 크기는 접근성과 SEO가 교차하는 요소이기도 하다.

테스트 방법

axe DevTools를 사용한 자동 스캔: axe DevTools 브라우저 확장을 설치한다. 테스트할 페이지를 연다. axe DevTools 패널에서 스캔을 실행하기 전에 실험적 규칙을 활성화한다(규칙 태그 필터에서 experimental을 추가). 스캔이 완료되면 규칙 ID target-size로 결과를 필터링한다. 표시된 각 요소에 대해 보고된 치수를 확인한다. 실험적 규칙은 오탐 비율이 더 높으므로, 실패로 확정하여 기록하기 전에 반드시 수동으로 검증한다.
Lighthouse를 사용한 자동 스캔: Chrome DevTools 또는 CLI를 통해 Lighthouse 접근성 감사를 실행한다. Lighthouse에는 48×48 CSS 픽셀보다 작고 간격이 불충분한 타깃을 검사하는 tap-targets 감사가 포함되어 있다. 이는 WCAG 2.5.8보다 더 엄격한 기준을 사용하므로, Lighthouse 실패는 WCAG 실패의 상위 집합이다. 보고서에서 표시된 요소를 검토하고, 24×24 WCAG 기준과 교차 검토하여 어떤 것이 실제 레벨 AA 실패인지, 어떤 것이 모범 사례 권고사항인지 구분한다.
브라우저 DevTools를 사용한 수동 측정: DevTools를 열고 각 상호작용 요소를 검사한다. Computed 패널에서 width와 height를 확인한다. 둘 중 하나라도 24px 미만이면, Box Model 뷰로 전환하여 padding을 확인한다. 패딩으로 타깃이 24×24에 도달하면 통과이다. 그렇지 않다면, 요소의 경계 사각형을 사용해 가장 가까운 인접 상호작용 요소까지의 간격을 측정한다. 콘솔에서 document.querySelector('your-selector').getBoundingClientRect()를 실행하고, 인접 요소의 좌표와 비교한다. 각 방향에서 간격을 합산한 유효 도달 영역이 24px에 도달하면 통과이다.
터치 시뮬레이션: Chrome DevTools에서 디바이스 에뮬레이션을 활성화하고 터치 최적화 디바이스 프로파일로 전환한다. 작은 상호작용 요소를 각각 탭해 본다. 의도한 요소를 활성화하기 어렵거나 인접 요소가 실수로 활성화되는 경우를 기록한다.
키보드 및 스크린 리더 테스트(참고용): WCAG 2.5.8은 포인터 기준이지만, 작은 타깃에도 시각적 포커스 표시가 있고 키보드로 도달 가능함을 확인하면 복합적인 문제를 파악하는 데 도움이 된다. NVDA와 Firefox 또는 JAWS와 Chrome을 사용해 상호작용 요소를 탐색하고, 크기와 관계없이 도달 및 활성화가 가능한지 확인한다.
실제 디바이스 테스트: 실제 모바일 디바이스 — 가능하면 대형 화면 Android와 소형 iOS 디바이스 모두 — 에서 테스트하여, 데스크톱에서 통과한 타깃이 모바일 뷰포트에서도 통과하는지 확인한다. CSS 픽셀 밀도와 확대/축소 동작이 체감 타깃 크기에 영향을 줄 수 있기 때문이다.

해결 방법

작은 아이콘 전용 버튼 — 잘못된 예

<!-- 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>

작은 아이콘 전용 버튼 — 올바른 예

<!-- 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>

빽빽한 내비게이션 링크 — 잘못된 예

<!-- 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>

빽빽한 내비게이션 링크 — 올바른 예

<!-- 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>

히트 영역이 매우 작은 체크박스 — 잘못된 예

<!-- 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>

연결된 레이블이 있는 체크박스 — 올바른 예

<!-- 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>

소셜 공유 아이콘 행 — 잘못된 예

<!-- 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>

소셜 공유 아이콘 행 — 올바른 예

<!-- 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>

자주 발생하는 실수

버튼 내부 아이콘에만 width와 height를 설정하고 버튼 자체에는 설정하지 않는 경우: 개발자는 종종 SVG나 이미지를 16–20px로 제한하면서, 실제로는 <button> 요소에 min-width: 24px; min-height: 24px와 적절한 패딩을 주어 충분한 탭 타깃을 만들어야 한다는 점을 잊는다.
padding: 0 또는 전역 리셋으로 버튼과 입력 요소의 기본 브라우저 패딩을 제거하는 경우: 폼 요소의 패딩을 0으로 만드는 CSS 리셋은 네이티브 컨트롤을 사용 가능한 크기로 유지해 주는 버퍼를 제거한다. 리셋 이후에는 항상 명시적으로 패딩을 다시 추가해야 한다.
display: block 또는 display: inline-block 없이 line-height만으로 링크 높이를 늘리려는 경우: 인라인 요소는 블록 요소와 달리 height나 수직 패딩에 제대로 반응하지 않기 때문에, 링크가 시각적으로는 더 높아 보이더라도 실제 클릭 가능한 경계 박스는 여전히 작을 수 있다.
래퍼에 pointer-events: none을 적용하고 작은 내부 요소에 클릭 핸들러를 붙이는 경우: 이는 래퍼에 적용된 패딩이나 최소 크기를 무력화하여, 실제 유효 타깃을 내부 요소의 렌더링된 크기로 축소시킨다.
버튼 컨테이너에 overflow: hidden을 적용해 버튼의 패딩을 잘라내는 경우: 시각적인 클릭 영역이 컨테이너 경계로 잘려 나가, 버튼 자체의 치수만으로 예상되는 것보다 실제 타깃이 더 작아진다.
scale()과 같은 CSS transform을 고려하지 않는 경우: 많은 브라우저에서 transform: scale(0.7)로 시각적으로 축소된 버튼은 여전히 원래 경계 박스를 포인터 이벤트에 사용하지만, 이 동작은 일관되지 않고 신뢰하기 어렵다. 항상 최종 렌더링 스케일에서 타깃 크기를 맞춰야 한다.
<label>과 <input>이 프로그래밍적으로 연결되어 있지 않은데도 큰 <label>이 작은 <input>을 보완한다고 가정하는 경우: <label>이 input의 id와 일치하는 for 속성을 사용하지 않거나, input이 label 안에 포함되어 있지 않다면, 레이블 텍스트를 클릭해도 input이 활성화되지 않는다. 이 경우 실제로 동작하는 타깃 영역은 input의 작은 영역뿐이다.
타깃이 실제로 렌더링되는 뷰포트 크기에서 테스트하지 않는 경우: 데스크톱에서는 32×32 CSS 픽셀인 버튼이, 유동적 스케일링이나 뷰포트 상대 단위(vw, vmin) 때문에 좁은 모바일 뷰포트에서는 22×22 CSS 픽셀로 렌더링되어, 모바일에서만 나타나는 실패를 유발할 수 있다.
WCAG 2.5.8의 인라인 텍스트 링크 예외를 지나치게 넓게 해석하는 경우: 이 예외는 문단 안의 하이퍼링크처럼 실제로 텍스트 흐름 내에 인라인으로 존재하는 링크에만 적용된다. 폼 아래의 "Forgot password?" 링크처럼 독립적으로 배치되었지만 텍스트처럼 보이도록 스타일링된 링크는 인라인 링크가 아니며, 24×24 기준을 충족해야 한다.
서드파티 위젯과 임베디드 컴포넌트를 감사하지 않는 경우: 쿠키 동의 배너, 채팅 위젯, 분석 오버레이 등은 외부 스크립트가 삽입하는 매우 작은 버튼(동의, 닫기, 최소화)을 자주 포함한다. 이들 역시 페이지 접근성의 일부이며, 코드가 내부에서 작성되지 않았더라도 WCAG 2.5.8을 준수해야 한다.

터키 접근성 규정과의 관계

2025년 6월 21일 관보 제32933호에 게재된 터키 대통령령 2025/10은 터키에서 운영되는 광범위한 디지털 서비스 제공자에 대해 구속력 있는 접근성 요구사항을 수립한다. 이 대통령령은 WCAG 2.2를 기술 표준으로 명시적으로 참조하며, 가족·사회서비스부(Aile ve Sosyal Hizmetler Bakanlığı)가 발급하는 Erişilebilirlik Logosu(접근성 로고)를 획득하기 위해서는 레벨 AA 준수가 요구된다. WCAG 2.5.8은 WCAG 2.2에서 레벨 AA 기준이므로, 이 의무적 프레임워크의 범위에 직접 포함된다.

대통령령이 적용되는 주체 유형에는 중앙 및 지방 수준의 공공기관과 정부 기관, 은행 및 금융 서비스 회사, 병원 및 민간 의료 제공자, 200,000명 이상의 가입자를 보유한 통신 사업자, 전자상거래 플랫폼, 여행사, 민간 운송 회사, 그리고 교육부(Milli Eğitim Bakanlığı)의 인가를 받은 민간 학교 등이 포함된다. 이 모든 조직에 대해 WCAG 2.5.8 준수는 단순한 모범 사례 권고가 아니라, 접근성 로고 표시 능력 및 감사 시 법적 준수 입증과 연계된 규제 의무이다.

실질적으로 이는 터키 은행의 모바일 대응 웹 애플리케이션이 이체 확인 버튼, 일회용 비밀번호 입력 필드, 내비게이션 컨트롤 등이 모두 최소 24×24 CSS 픽셀 타깃 크기를 충족해야 함을 의미한다. 마찬가지로 전자상거래 사이트는 장바구니 담기 버튼, 수량 선택기, 필터 컨트롤이 모든 디바이스 프로파일에서 충분한 크기를 갖추었는지 확인해야 한다. 의료 포털은 작은 날짜 셀로 악명이 높은 예약 달력을 감사하고, 해당 셀을 확장하거나 충분한 오프셋 간격을 제공해야 한다. 통신사의 셀프 서비스 포털은 계정 관리 링크와 데이터 요금제 선택기 내 토글 컨트롤이 기준을 충족하는지 확인해야 한다.

대통령령을 준수하지 않을 경우 행정 제재를 받을 수 있으며, 조직은 접근성 로고를 표시할 수 없게 될 수 있다. 이 로고는 터키 소비자들 사이에서 신뢰의 신호로 점점 더 많이 사용되고 있다. 제재를 넘어, 비준수는 관련 감독 기관에 제기되는 민원에 조직을 노출시킨다. 터키는 고령 인구가 증가하고 있으며, 터키 통계청은 2040년까지 65세 이상 인구가 전체의 16.3%를 차지할 것으로 전망한다. 작은 타깃의 실질적 영향은 시간이 지날수록 커질 것이므로, 조기 준수는 윤리적 우선순일 뿐 아니라 장기적인 비즈니스 전략 측면에서도 현명한 선택이다.