WCAG 2.5.5: 대상 크기 (강화됨)

WCAG 2.5.5는 버튼과 링크와 같은 대화형 타깃이 최소 44×44 CSS 픽셀 크기여야 하며, 이를 통해 운동 장애, 떨림, 또는 제한된 손재주를 가진 사람들이 인접한 요소를 실수로 활성화하지 않고도 안정적으로 컨트롤을 작동할 수 있도록 요구합니다.

이 규칙의 의미

WCAG 2.5.5 Target Size (Enhanced)는 WCAG 2.2에서 레벨 AAA 기준으로, 인터랙티브 요소에 대해 엄격한 최소 크기를 설정한다. 구체적으로, 모든 사용자 인터페이스 구성 요소의 클릭 또는 탭 가능한 영역인 타깃의 크기는 너비와 높이 모두 최소 44×44 CSS 픽셀이어야 한다. 이는 마우스 클릭, 터치스크린 탭, 스타일러스 입력 등 모든 포인터 기반 상호작용에 적용된다.

이 문맥에서 정확히 무엇이 “타깃”을 구성하는지 이해하는 것이 중요하다. 타깃은 단순히 시각적 표현만이 아니라, 컨트롤의 전체 활성화 가능한 영역을 의미한다. 작은 아이콘이 시각적으로는 16×16 픽셀일 수 있지만, 주변 패딩이 클릭 가능한 영역을 44×44 픽셀로 확장한다면 이 기준을 충족할 수 있다. 이는 개발자가 시각적 디자인을 크게 변경하지 않고도 패딩을 전략적으로 사용해 요구사항을 충족할 수 있음을 의미한다.

이 기준에서 통과는 타깃 영역이 최소 44×44 CSS 픽셀인 모든 인터랙티브 요소로 정의된다. 실패는 인터랙티브 요소의 활성화 가능한 영역이 어느 한쪽 차원에서라도 이 임계값보다 작을 때 발생한다. 예를 들어, 링크의 너비가 44 픽셀이라도 높이가 20 픽셀에 불과하다면 여전히 실패에 해당한다.

WCAG 2.5.5는 44×44 요구사항이 적용되지 않는 몇 가지 공식 예외를 제공한다. 다음과 같다.

간격(Spacing): 타깃이 작더라도 다른 모든 타깃과 충분한 오프셋 간격으로 분리되어 있다면 허용된다. 타깃은, 중심에 44×44 CSS 픽셀의 원을 그렸을 때 그 원이 다른 어떤 타깃이나 다른 타깃의 44×44 원의 경계 상자와도 교차하지 않도록 배치되어야 한다. 이 예외는 인접한 컨트롤이 본질적으로 작지만 충분히 떨어져 있는 경우, 레이아웃 변경을 강제하지 않도록 하기 위한 것이다.
동등(Eqivalent): 동일한 페이지에 있는 대체 컨트롤이 같은 기능을 수행하며 최소 크기 요구사항을 충족하는 경우.
인라인(Inline): 타깃이 문장 안에 있거나, 그 크기가 비타깃 텍스트의 줄 높이(line-height)에 의해 제한되는 경우. 예를 들어, 본문 단락 내의 하이퍼링크는 크기를 조정하면 텍스트 흐름이 깨지기 때문에 예외로 인정된다.
사용자 에이전트 제어(User agent control): 크기가 브라우저나 운영체제에 의해 전적으로 결정되고, 제작자가 변경할 수 없는 경우. 스타일을 적용하지 않은 기본 브라우저 폼 컨트롤이 여기에 해당할 수 있다.
본질적(Essential): 타깃의 특정 표현 방식이 전달되는 정보에 본질적인 경우. 이는 타깃 크기를 변경하면 의미나 기능이 근본적으로 달라지는 경우에만 적용되는 좁은 범위의 예외이다.

이 기준은 WCAG 2.2에서 도입되었으며, 이전의 덜 엄격한 포인터 타깃 관련 지침을 대체한다. 동반 기준인 WCAG 2.5.8 Target Size (Minimum) 레벨 AA는 24×24 CSS 픽셀과 간격 기반 계산이라는 더 낮은 기준을 설정하지만, 2.5.5는 여전히 향상된 접근성을 위한 골드 스탠더드로 간주된다.

왜 중요한가

운동 및 손재능(소근육) 장애는 전 세계 인구의 상당 부분에 영향을 미친다. 세계보건기구(WHO)에 따르면, 약 13억 명, 즉 전 세계 인구의 16%가 어떤 형태로든 중대한 장애를 가지고 있으며, 이 중 운동 및 근골격계 질환이 가장 흔한 유형에 속한다. 파킨슨병, 본태성 떨림, 뇌성마비, 다발성 경화증, 뇌졸중 관련 편마비, 반복성 긴장성 손상과 같은 질환은 모두 사람의 정밀한 포인터 움직임 수행 능력을 저하시킨다. 모바일 기기에서는 장애가 없는 사용자라도 장갑을 끼었을 때, 손이 젖어 있을 때, 또는 한 손으로 휴대폰을 사용할 때 작은 타깃을 누르는 데 어려움을 겪을 수 있다.

구체적인 실제 시나리오를 생각해 보자. 류머티즘 관절염이 있는 한 사람이 약을 구매하기 위해 터치스크린 태블릿으로 터키의 한 전자상거래 플랫폼을 이용하고 있다. 체크아웃 흐름에는 작은 라디오 버튼, 좁은 드롭다운 메뉴, 24×18 픽셀 크기의 “주문 확인(Confirm Order)” 버튼이 포함되어 있다. 탭을 잘못하면 잘못된 옵션이 선택되거나 아무 일도 일어나지 않아, 사용자는 여러 번 다시 시도해야 한다. 이 좌절감은 단순한 불편을 넘어, 사용자가 구매를 완전히 포기하게 만들 수 있으며, 이는 접근성 실패가 곧바로 비즈니스의 매출 손실로 이어지는 사례가 된다.

운동 장애를 넘어, 충분한 크기의 타깃은 다양한 사용자에게 이점을 제공한다. 노년층은 미세 운동 능력 저하와 시력 저하를 동시에 겪는 경우가 많아, 작은 타깃이 두 배로 어렵게 느껴진다. 인지 장애가 있는 사용자는 포인터를 위치시키는 데 더 오랜 시간이 걸리며, 타깃이 빽빽하게 배치된 경우 인접한 컨트롤을 잘못 활성화할 가능성이 더 크다. 심지어 시력이 좋고 신체적으로 건강한 사용자도 모바일 기기에서는 더 큰 타깃의 혜택을 본다. 이는 수년간 주요 기술 기업의 디자인 관행을 이끌어 온 사실이다. Apple의 Human Interface Guidelines는 최소 44×44 포인트의 탭 타깃을 권장하고, Google의 Material Design 가이드라인은 같은 이유로 최소 48×48 dp(density-independent pixels)를 권장한다.

SEO와 사용성 관점에서, Google의 Core Web Vitals 지표인 “Interaction to Next Paint”(INP)는 사용자 상호작용이 빠르고 정확하게 등록되는 인터페이스에 가점을 준다. 타깃이 너무 작아 발생하는 오탭은 상호작용 실패율을 높이고, 작업 소요 시간을 늘리며, 이탈률을 증가시킨다. 이 모든 것은 검색 순위에 간접적으로 영향을 줄 수 있는 신호이다. 따라서 포인터 수준에서의 접근성 개선은 단순한 규정 준수를 넘어 측정 가능한 비즈니스 효과를 가져온다.

테스트 방법

기본선으로 자동 스캔 실행: 테스트할 페이지에서 Chrome DevTools의 axe DevTools 또는 Lighthouse를 연다. axe DevTools에서 실험적 규칙에 “target-size”가 있다면 해당 결과만 필터링한다. 표시된 요소를 기록하되, 이 스캔이 모든 2.5.5 위반을 포착하지 못하며 44×44 픽셀이 아닌 2.5.8 기준을 참조할 수 있음을 이해해야 한다. Lighthouse의 접근성 감사를 사용해 관련 포인터 타깃 경고를 확인한다.
브라우저 DevTools로 타깃 크기 측정: Chrome 또는 Firefox DevTools를 열고 Elements 패널을 사용해 각 인터랙티브 요소(버튼, 링크, 폼 입력, 체크박스, 라디오 버튼, 커스텀 컨트롤, 아이콘 전용 컨트롤)를 검사한다. Computed 스타일 패널에서 렌더링된 너비와 높이를 확인한다. 블록 레벨 요소에서는 패딩이 클릭 타깃에 포함되지만, 인라인 요소에서는 그렇지 않을 수 있음을 기억한다. 계산된 히트 영역이 최소 44×44 CSS 픽셀인지 확인한다.
브라우저 내장 접근성 도구 사용: Chrome DevTools에서 Rendering 탭을 열고 “Emulate a focused page”를 활성화하거나 Accessibility Tree를 사용해 요소를 검사한다. Firefox에서는 Accessibility Inspector를 사용해 인터랙티브 요소를 식별하고, 그 경계 상자 크기를 교차 확인한다.
실제 터치 기기에서 테스트: 실제 iOS 기기를 연결하고 VoiceOver를 활성화(측면 버튼을 세 번 눌러 활성화)한 뒤 테스트한다. 탭으로 탐색하고 로터를 사용해 인터랙티브 요소 간을 이동한다. 작은 타깃을 활성화하려 시도하면서 인접 요소가 얼마나 자주 잘못 활성화되는지 기록한다. Android 기기에서는 TalkBack을 사용해(오른쪽으로 스와이프해 탐색, 두 번 탭해 활성화) 같은 테스트를 반복한다. <div>나 <span> 요소로 만든 커스텀 위젯에 특히 주의를 기울인다.
간격 예외를 수동으로 테스트: 44×44 픽셀보다 작은 타깃 중 간격 예외를 주장하는 경우, 해당 타깃을 중심으로 44×44 픽셀의 가상의 경계 상자를 그린다고 생각하고, 그 상자 안에 다른 인터랙티브 요소가 들어오지 않는지 시각적으로 확인한다. 경계 상자를 그려주는 브라우저 확장이나 오버레이 도구가 이 작업에 도움이 될 수 있다.
키보드 및 스크린 리더 검증: NVDA + Firefox, JAWS + Chrome 조합으로 모든 인터랙티브 요소를 Tab 키로 순회하며 테스트한다. 키보드 포커스는 포인터 타깃 크기를 직접 테스트하지는 않지만, 어떤 컨트롤이 도달 가능한지 파악하고, 포인터 크기를 교차 확인할 요소 목록을 확정하는 데 도움이 된다. macOS의 VoiceOver + Safari를 사용해 커스텀 컨트롤이 올바르게 안내되는지, 포인터 클릭 시 충분한 활성화 영역을 가지는지 확인할 수 있다.
여러 뷰포트 크기에서 테스트: 타깃 크기는 데스크톱과 모바일 레이아웃 사이에서 달라질 수 있다. 320px, 768px, 1280px 뷰포트 너비에서 테스트해, 반응형 디자인이 모든 브레이크포인트에서 44×44 최소값을 유지하는지 확인한다. 특히 햄버거 메뉴, 캐러셀, 데이터 테이블의 액션 열에 주의한다.

수정 방법

아이콘 전용 버튼의 크기가 부족한 경우 — 잘못된 예

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

아이콘 전용 버튼의 크기가 부족한 경우 — 올바른 예

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

div로 만든 커스텀 체크박스 — 잘못된 예

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

div로 만든 커스텀 체크박스 — 올바른 예

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

툴바에서 간격이 좁은 내비게이션 링크 — 잘못된 예

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

툴바에서 간격이 좁은 내비게이션 링크 — 올바른 예

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

자주 발생하는 실수

시각적 경계 상자가 히트 영역과 같다고 가정하는 경우: 버튼 안의 아이콘 이미지에 width: 44px; height: 44px를 설정해도 버튼 자체가 44×44가 되지는 않는다. 올바른 히트 영역을 만들려면 이 크기나 이에 상응하는 패딩을 <button> 요소 자체에 적용해야 한다.
보정 없이 padding: 0으로 브라우저 스타일을 리셋하는 경우: CSS 리셋은 종종 버튼과 입력 요소의 모든 패딩을 제거한다. 리셋 후에는 항상 충분한 패딩이나 명시적인 min-width, min-height 값을 다시 적용해 활성화 영역을 복원해야 한다.
타깃 높이를 늘리기 위해 line-height만 사용하는 경우: line-height를 늘리면 텍스트 간격에는 영향을 주지만, 앵커나 버튼의 클릭 가능한 영역을 항상 확장하는 것은 아니다. 대신 padding-top과 padding-bottom을 사용해야 한다.
충분한 간격 없이 작은 아이콘 버튼을 나란히 배치하는 경우: 24×24 크기의 소셜 미디어 공유 아이콘을 2px 마진만 두고 한 줄로 배치하면, 크기 요구사항과 간격 예외 모두를 위반하게 된다. 각 아이콘을 중심으로 한 44px 원이 서로 겹치기 때문이다.
인라인 텍스트 예외를 내비게이션 링크에 잘못 적용하는 경우: 이 예외는 문장이나 단락 내의 흐르는 텍스트에 포함된 링크에만 적용된다. 내비게이션 메뉴, 툴바, 링크 목록은 인라인 텍스트가 아니며, display: inline을 사용하더라도 이 예외에 해당하지 않는다.
<span>에 role='button'을 부여해 커스텀 컨트롤을 만들면서 span의 크기를 지정하지 않는 경우: 스크린 리더는 span을 버튼으로 안내하지만, 기본 렌더링 크기는 텍스트 내용에만 의해 결정되며, 이는 일반적으로 44×44 픽셀보다 훨씬 작다. 항상 display: inline-flex, min-width, min-height, padding을 추가해야 한다.
실제 뷰포트 크기의 실제 터치 기기에서 테스트하지 않는 경우: 데스크톱 DevTools에서 픽셀을 측정하는 것만으로는 충분하지 않다. CSS 픽셀 밀도와 OS 수준의 터치 타깃 히트 테스트 동작은 시뮬레이션 환경과 실제 기기 환경 사이에서 다를 수 있다.
동적으로 렌더링되는 컨트롤을 간과하는 경우: 툴팁, 날짜 선택기(day cell), 자동완성 제안 항목, 모달 닫기 버튼 등은 자바스크립트 라이브러리가 하드코딩된 작은 크기로 삽입하는 경우가 많다. 서드파티 위젯의 출력물을 점검하고 필요하다면 스타일을 재정의해야 한다.
측정 없이 간격 예외를 주장하는 경우: 간격 예외는 기하학적이며 정밀하다. 컨트롤이 충분히 떨어져 보인다는 시각적 추정만으로는 충분하지 않다. 각 미달 타깃에 대해 44px 원 테스트를 적용해 겹침이 없는지 확인해야 한다.
반응형 브레이크포인트 변경 후 검증을 잊는 경우: 데스크톱에서 44×44인 버튼이, 퍼센트 너비나 flexbox 축소 때문에 375px 모바일 뷰포트에서는 30×30으로 줄어들 수 있다. 주요 브레이크포인트마다 타깃 크기를 다시 테스트해야 한다.

터키 접근성 규정과의 관계

터키의 2025/10호 대통령령은 2025년 6월 21일 관보 제32933호에 게재되었으며, WCAG 2.2 표준을 기반으로 한 웹 및 모바일 접근성 의무 요건을 수립한다. 이 대통령령은 터키 내에서 운영되는 특정 유형의 주체에 적용되며, 특정 WCAG 레벨에 대한 준수 의무를 법적으로 규정한다.

대통령령의 적용 대상에는 중앙 및 지방 정부 수준의 공공 기관 및 기관, 은행 규제감독청(BDDK)의 규제를 받는 은행 및 금융 기관, 공공 및 민간 병원 및 의료 서비스 제공자, 20만 명 이상의 가입자를 보유한 통신 사업자, 특정 매출 또는 거래 기준을 초과하는 전자상거래 플랫폼, 온라인 예약 서비스를 운영하는 여행사, 디지털 발권 또는 예약을 제공하는 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 사립 학교 및 교육 기관이 포함된다.

WCAG 2.5.5 Target Size (Enhanced)는 레벨 AAA 기준이며, 주로 레벨 A와 AA 준수에 초점을 맞춘 대통령령이 정한 최소 의무 요건에는 포함되지 않는다. 그러나 대통령령은 특히 대중, 의료 환자, 학생을 대상으로 하는 기관이 가능하다면 AAA 준수를 추구하도록 명시적으로 장려하고 있으며, 이를 최고 수준의 접근성 실천으로 인정한다.

터키의 조직에게 WCAG 2.5.5를 구현하는 것은 여러 맥락에서 전략적 가치를 가진다. 고령 시민을 대상으로 하는 정부 포털, 만성 질환 환자가 사용하는 의료 예약 시스템, 운동 장애가 있는 사람들이 이용하는 뱅킹 애플리케이션은 모두 44×44 픽셀 타깃 크기에서 큰 혜택을 본다. 터키는 빠르게 고령화되는 인구 구조를 가지고 있으며, 터키 통계청(TÜİK)은 2040년까지 65세 이상 시민이 전체 인구의 16%를 넘을 것으로 전망한다. 이 연령대에게 포인터 타깃 크기는 중요한 사용성 요소이다.

AAA가 법적으로 의무 사항이 아닌 경우에도, WCAG 2.5.5를 자발적으로 충족하는 조직은 소송 위험을 줄이고, 접근성 문서를 요구하는 정부 조달 계약에서의 입찰 자격을 강화하며, 전자상거래와 핀테크와 같은 경쟁 시장에서 사용자 만족도 지표를 개선하는 데 도움이 되는 의지를 보여준다. Accsible의 SDK는 조직이 이 기준을 충족하거나 근접할 수 있도록 돕는 구성 가능한 터치 타깃 향상 기능을 제공하며, 이러한 노력에 대한 문서는 기관 조달 절차에서 요구되는 접근성 적합성 보고서(ACR) 또는 VPAT 제출의 일부가 될 수 있다.