WCAG 1.3.3: 감각적 특성

WCAG 1.3.3은 콘텐츠를 사용하는 방법에 대한 지시가 모양, 색, 크기, 시각적 위치, 방향, 소리와 같은 감각적 특성에만 의존해서는 안 된다고 요구합니다. 이는 시각장애, 색각이상, 청각장애 또는 기타 장애로 인해 이러한 감각적 단서를 인지할 수 없는 사용자들도 모든 기능을 여전히 이해하고 조작할 수 있도록 보장합니다.

이 규칙의 의미

WCAG 성공 기준 1.3.3 — 감각적 특성(Sensory Characteristics) (레벨 A)는 콘텐츠를 이해하고 조작하기 위한 지침이 모양, 크기, 시각적 위치, 방향, 소리와 같은 구성 요소의 감각적 특성에만 전적으로 의존해서는 안 된다고 규정합니다. 다시 말해, 인터페이스가 어떤 요소와 상호작용하라고 지시하면서 그 요소가 어떻게 보이는지, 화면의 어디에 나타나는지, 어떤 소리가 나는지만을 근거로 삼는다면, 해당 감각적 특성을 지각할 수 없는 사용자에게는 그 지시가 아무 의미도 없게 됩니다.

여기서 핵심 단어는 전적으로(solely)입니다. 이 기준은 감각적 참조의 사용을 금지하는 것이 아니라, 그것을 유일한 식별 수단으로 사용하는 것을 금지합니다. "왼쪽에 있는 둥근 초록색 버튼을 클릭하세요"와 같은 지시는 사용자가 초록색을 구분하지 못하거나, 버튼의 모양을 볼 수 없거나, 리플로우된 레이아웃 때문에 좌우를 구분할 수 없는 경우 실패합니다. 그러나 "왼쪽에 있는 둥근 초록색 버튼인 제출(Submit) 버튼을 클릭하세요"는 통과합니다. 텍스트 레이블 "Submit"이 색, 모양, 위치와 무관하게 작동하는 비감각적 식별자를 제공하기 때문입니다.

이 기준의 영향을 받는 지시는 사용자가 행동을 취하거나 정보를 찾도록 안내하는 모든 텍스트, 오디오, 시각 콘텐츠를 포함합니다. 일반적인 실패 패턴은 다음과 같습니다.

"계속하려면 오른쪽에 있는 버튼을 클릭하세요" — 시각적 위치에만 의존.
"설정을 열려면 사각형 아이콘을 선택하세요" — 모양에만 의존.
"필수 필드는 빨간색으로 표시됩니다" — 색에만 의존.
"종소리가 들리면 다음 단계로 진행하세요" — 소리에만 의존.
"섹션을 확장하려면 큰 타일을 탭하세요" — 크기에만 의존.

통과하는 지시는 항상 최소 하나의 비감각적 식별자를 포함합니다. 일반적으로 텍스트 레이블, 프로그래밍 방식 이름, 또는 제목(heading) 등이 이에 해당합니다. 이를 통해 보조 기술에 의존하거나 감각적 단서를 사용할 수 없는 환경에서 작업하는 사용자도 지시를 따를 수 있습니다. 이 기준은 특히 지시(instructions)를 다룬다는 점에 유의해야 합니다. 모든 UI 요소를 재설계할 것을 요구하는 것이 아니라, 그 요소들에 대해 제공되는 모든 텍스트 또는 음성 안내가 감각적 구분 없이도 지각 가능하도록 할 것을 요구합니다.

1.3.3 자체에는 공식적인 예외가 정의되어 있지 않지만, Understanding 문서는 비감각적 식별자에 추가하여 감각적 특성을 사용하는 콘텐츠는 완전히 준수한다고 명시합니다. 이 기준은 색만을 다루는 1.4.1(색의 사용)과 보완 관계에 있지만, 1.3.3은 모든 감각 양식을 포괄하는 더 넓은 범위를 갖습니다.

왜 중요한가

감각 정보에만 의존하는 지시는 다양한 사용자에게 심각한 장벽을 만듭니다. 영향을 받는 각 집단을 살펴보면 다음과 같습니다.

시각장애 및 저시력 사용자는 스크린 리더나 화면 확대 소프트웨어에 의존합니다. "오른쪽 상단 모서리에 있는 아이콘을 클릭하세요"라는 지시는, 탭 순서나 제목 구조로 탐색하는 스크린 리더 사용자에게는 시각적 레이아웃의 "오른쪽 상단 모서리"라는 개념이 전혀 없습니다. 마찬가지로, 400%까지 확대해 사용하는 중증 저시력 사용자는 한 번에 화면의 작은 부분만 볼 수 있어 "왼쪽 패널", "하단 섹션"과 같은 위치 기반 참조가 완전히 신뢰할 수 없게 됩니다. 세계보건기구(WHO)에 따르면 전 세계적으로 약 22억 명이 어떤 형태로든 시각 장애를 가지고 있어, 이 집단은 가장 큰 영향 대상 중 하나입니다.

색각 이상 사용자는 — 남성 약 12명 중 1명, 여성 약 200명 중 1명 비율로 — 특정 색 조합을 구분하지 못합니다. "빨간색으로 강조 표시된 필드는 필수입니다"라는 지시는 적녹 색각 이상 사용자에게는 구분 신호로서 보이지 않습니다. 1.4.1은 UI 요소 자체에 대해 이 문제를 다루고, 1.3.3은 지시 텍스트 역시 대안을 제공하도록 보장합니다.

청각장애 및 난청 사용자는 오디오 전용 단서에 의해 영향을 받습니다. e-러닝 플랫폼이 "종소리가 들리면 진행하세요"라고 안내할 경우, 종소리를 들을 수 없는 사용자는 배제됩니다. 이 패턴은 인터랙티브 프레젠테이션, 동영상 기반 튜토리얼, 시간 제한 평가 등에서 자주 나타납니다.

인지 및 학습 장애가 있는 사용자는 방향 관련 언어를 이해하는 데 어려움을 겪을 수 있으며, 특히 보조 기술이 시각적 위치 정보를 제거하고 콘텐츠를 선형화된 형태로 렌더링할 때 그렇습니다. 스위치 장치나 시선 추적 시스템을 사용하는 사람 역시, 시각 디자이너가 상정한 2차원 공간 레이아웃과는 전혀 관계없는 순차적 방식으로 탐색합니다.

구체적인 실제 사례를 생각해 봅시다. 한 터키 정부 전자 서비스 포털이 시민에게 "파란색 테두리로 표시된 필드를 작성한 후 삼각형 버튼을 눌러 신청서를 제출하세요"라고 안내한다고 가정합니다. 폼 필드를 기준으로 탐색하는 시각장애 사용자는 스크린 리더를 통해 필드 레이블을 들을 수 있지만, 어떤 필드가 파란색 테두리인지 알 수 없고, 삼각형 모양만으로 버튼을 식별할 수도 없습니다. 신청 절차는 사실상 차단됩니다. "이름, 신분증 번호, 생년월일은 필수입니다"와 같은 실제 필드 레이블과 버튼의 텍스트 레이블("신청서 제출(Submit Application)")을 추가하면 이 장벽은 즉시 해소됩니다.

접근성을 넘어, 감각 정보에만 의존하는 지시를 제거하면 모든 사용자의 사용성이 향상됩니다. 반응형 디자인은 콘텐츠를 리플로우하여 위치 기반 참조가 모바일에서 부정확해지게 만듭니다. 다크 모드나 고대비 테마는 색 표현을 변경합니다. 음성 비서는 페이지 지시를 소리 내어 읽으면서 모든 시각적 맥락을 제거합니다. 일시적인 감각적 특성이 아니라 안정적인 프로그래밍 방식 레이블을 중심으로 지시를 구성하면, 모든 기기와 환경에서 콘텐츠가 더 견고해지며, 이는 SEO와 유지보수 측면에서도 직접적인 이점을 제공합니다.

테스트 방법

먼저 자동 스캔 실행(axe DevTools 또는 Lighthouse): Chrome에서 페이지를 열고 axe DevTools 확장을 활성화한 뒤 전체 페이지 스캔을 실행합니다. 1.3.3에 직접 매핑되는 규칙은 없지만, "color", "label", "name" 카테고리에서 표시된 문제를 검토합니다. 이 결과는 기본선 역할을 합니다. UI 요소에 접근 가능한 이름이 없다면, 그 요소를 참조하는 지시 텍스트는 거의 확실히 감각적 단서에 의존하고 있습니다. 결과를 내보내고 프로그래밍 방식 레이블이 없는 모든 인터랙티브 요소를 기록합니다.
모든 지시 텍스트를 수동으로 식별: 사용자가 행동을 취하거나 정보를 찾도록 안내하는 페이지의 모든 문장을 읽습니다. 여기에는 도움말 텍스트, 폼 힌트, 툴팁, 튜토리얼 오버레이, 오류 메시지, 온보딩 플로우가 포함됩니다. 각 지시를 목록으로 만들고, 감각적 참조를 강조 표시합니다. 색 관련 단어(red, blue, green), 모양 관련 단어(round, square, triangular), 크기 관련 단어(large, small, big), 위치 관련 단어(left, right, top, bottom, above, below, corner), 방향 관련 단어(horizontal, vertical), 소리 관련 단어(chime, beep, alert sound) 등을 찾습니다.
각 감각적 참조에 비감각적 식별자가 추가로 있는지 평가: 발견된 각 감각적 참조에 대해 비감각적 식별자가 함께 제공되는지 확인합니다. 비감각적 식별자에는 요소의 가시 레이블 또는 접근 가능한 이름과 일치하는 텍스트 레이블, 제목(heading), 번호가 매겨진 단계, 고유한 프로그래밍 방식 역할, ARIA 레이블 등이 포함됩니다. 참조된 요소를 식별하는 유일한 방법이 감각적 지각뿐이라면, 해당 지시는 1.3.3을 위반합니다.
스크린 리더(NVDA + Firefox)로 테스트: 키보드만 사용해 NVDA로 페이지를 탐색합니다. 모든 인터랙티브 요소를 탭으로 이동하며 NVDA가 각 요소를 어떻게 읽어 주는지 확인합니다. 그런 다음 페이지의 지시 텍스트를 읽고, 오직 이 음성 안내만 듣는 사용자가 지시를 따를 수 있을지 자문해 봅니다. 지시가 "오른쪽에 있는 아이콘을 클릭하세요"라고 하지만 NVDA가 해당 요소를 "Settings, button"이라고 읽어 준다면, 위치 참조는 부가적일 뿐이며 레이블 덕분에 지시는 탐색 가능합니다. NVDA가 요소를 이름 없이 "button"이라고만 읽는다면, 시각적 위치에 의존하는 지시는 완전히 실패합니다.
VoiceOver + Safari(macOS/iOS)로 테스트: VoiceOver를 활성화하고 페이지를 탐색합니다. 로터를 사용해 버튼, 링크, 폼 컨트롤별로 탐색합니다. 지시에서 참조하는 모든 요소가 시각적 레이아웃의 위치에 의존하지 않고, 읽어 주는 이름만으로 도달 가능하고 식별 가능한지 확인합니다.
JAWS + Chrome으로 테스트: Chrome에서 JAWS를 실행한 상태로 페이지를 엽니다. Forms Mode를 사용해 입력 필드를 탐색하고 필드 안내를 듣습니다. 색이나 위치를 사용해 필수 필드를 표시하는 폼 수준 지시와 대조해 봅니다.
고대비 모드와 다크 모드에서 테스트: 운영체제를 고대비 모드로 전환하고 페이지를 다시 로드합니다. 특정 색을 언급하는 색 기반 지시는 색 렌더링이 변경되면 모호해지거나 보이지 않을 수 있습니다. 이를 통해 색을 유일한 감각 단서로 사용하는 숨겨진 의존성을 드러낼 수 있습니다.
확대 또는 리플로우된 모바일 뷰에서 테스트: 브라우저 창을 너비 320px로 조정하거나 모바일 기기를 사용합니다. "왼쪽 사이드바", "상단 내비게이션"과 같은 위치 기반 언어를 사용하는 지시는 레이아웃이 단일 열로 리플로우된 후에도 여전히 의미가 있어야 합니다.

수정 방법

색에만 의존하는 폼 필드 지시 — 잘못된 예

<p>Fields shown in red are required.</p>
<label for='email'>Email Address</label>
<input type='email' id='email' style='border-color: red;' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

색에만 의존하는 폼 필드 지시 — 올바른 예

<!-- The instruction now uses a text marker AND color, not color alone.
     The asterisk and the word "required" provide non-sensory identification. -->
<p>Fields marked with an asterisk (*) are required.</p>
<label for='email'>Email Address <span aria-hidden='true'>*</span></label>
<input type='email' id='email' aria-required='true' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

위치에만 의존하는 버튼 참조 — 잘못된 예

<p>To save your work, click the button on the right side of the toolbar.</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

위치에만 의존하는 버튼 참조 — 올바른 예

<!-- The instruction now references the button by its visible text label "Save",
     which matches the button's accessible name. Position is still mentioned
     but is no longer the sole identifier. -->
<p>To save your work, click the <strong>Save</strong> button (located on the right side of the toolbar).</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

모양에만 의존하는 아이콘 내비게이션 — 잘못된 예

<p>Tap the circular icon to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

모양에만 의존하는 아이콘 내비게이션 — 올바른 예

<!-- The button now has an accessible name via aria-label.
     The instruction references "Home" by name, not just by shape. -->
<p>Tap the <strong>Home</strong> button (the circular icon) to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home' aria-label='Home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

소리에만 의존하는 진행 상태 신호 — 잘못된 예

<p>Listen for the beep to know when the upload is complete.</p>
<button type='button' id='upload-btn'>Upload File</button>
<audio id='complete-chime' src='chime.mp3'></audio>

소리에만 의존하는 진행 상태 신호 — 올바른 예

<!-- A visible and screen-reader-accessible status message supplements the audio cue.
     Deaf users and users in silent environments now receive the same information. -->
<p>When the upload is complete, you will hear a chime and a <strong>"Upload Complete"</strong> message will appear below.</p>
<button type='button' id='upload-btn'>Upload File</button>
<div role='status' aria-live='polite' id='upload-status'></div>
<audio id='complete-chime' src='chime.mp3'></audio>
<!-- JavaScript sets #upload-status text to "Upload Complete" on success -->

자주 발생하는 실수

"빨간 버튼", "초록 필드"와 같이 색만으로 요소를 식별하면서, 버튼의 가시 레이블이나 필드 이름을 함께 제공하지 않는 폼 지시 또는 도움말 텍스트 — 이는 1.3.3과 1.4.1 모두를 위반합니다.
"왼쪽에 있는 메뉴", "상단의 패널"과 같은 위치 기반 표현을 사용하면서 메뉴나 패널의 이름을 명시하지 않는 도움말 문서나 온보딩 플로우 — 반응형 리플로우로 레이아웃이 단일 열로 접히면 이러한 지시는 쓸모없게 됩니다.
아이콘을 모양으로만 설명("삼각형 재생 버튼을 클릭하세요")하고, 스크린 리더 사용자가 키보드 탐색으로 실제로 찾을 수 있는 아이콘의 접근 가능한 이름이나 레이블을 사용하지 않는 경우.
필수 폼 필드를 테두리 색이나 배경색만으로 표시하면서, 같은 정보를 프로그래밍 방식으로 전달하는 기호, 레이블 접미사, aria-required='true' 속성을 사용하지 않고 "주황색 필드는 반드시 입력해야 합니다"와 같은 인라인 지시만 제공하는 경우.
인터랙티브 프로세스에 오디오 전용 피드백만 제공(파일 업로드, 폼 제출, 타이머 만료 등)하고, role='status'나 aria-live='polite'를 사용한 대응되는 가시 텍스트 상태 업데이트를 제공하지 않는 경우.
크기를 유일한 구분 단서로 사용 — "큰 카드를 클릭해 확장하세요"와 같은 지시는 사용자가 화면을 확대했을 때, 작은 뷰포트에서 카드가 동일한 크기로 렌더링될 때, 또는 스크린 리더 사용자가 DOM에서 카드의 상대적 크기를 전혀 인식할 수 없을 때 실패합니다.
"수평으로 스와이프해 탐색하세요"와 같은 방향 단서에 의존하면서, 설명 대상인 캐러셀이나 슬라이더에 대한 대체 상호작용 방법과 방향에 기반하지 않은 레이블을 제공하지 않는 경우.
오류 메시지도 지시라는 사실을 잊는 경우 — "아래에 강조 표시된 필드에 오류가 있습니다"라는 오류 메시지는 시각적 강조와 위치적 근접성에 의존하며, 각 오류 필드를 오류 메시지에서 명시적으로 이름으로 지칭하지 않으면 스크린 리더 사용자에게는 쓸모없습니다.
아이콘에 alt 텍스트를 추가하면 지시가 해결된다고 가정하는 경우 — 지시 문장이 여전히 "둥근 아이콘을 클릭하세요"라고만 말한다면, 이미지 요소에 alt 텍스트가 있다고 해서 그 지시 문장이 준수하게 되는 것은 아닙니다. 지시 문장 자체에 비감각적 식별자가 포함되어야 합니다.
단일 페이지 애플리케이션에서 동적으로 삽입되는 지시를 간과하는 경우 — JavaScript로 삽입되는 툴팁, 모달, 마법사(wizard) 단계에는 정적 페이지 감사에서 보이지 않아 QA 검토를 피하는 감각 정보 전용 안내가 자주 포함됩니다.

터키 접근성 규정과의 관계

2025년 6월 21일 관보 제32933호에 게재된 터키 대통령령 2025/10은 터키에서 운영되는 광범위한 공공 및 민간 기관에 대해 의무적인 웹 접근성 요구사항을 수립합니다. 이 대통령령은 WCAG 2.1 레벨 AA 준수를 기준선 표준으로 의무화하며, 레벨 A 기준인 WCAG 1.3.3 역시 모든 적용 대상 기관에 전면적으로 의무 사항이 됩니다.

대통령령의 적용 대상에는 공공 기관 및 기관, 전자상거래 플랫폼, 은행 및 금융 기관, 병원 및 의료 서비스 제공자, 200,000명 이상의 가입자를 보유한 통신 회사, 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 사립 학교가 포함됩니다. 공공 기관은 대통령령 공포일로부터 1년 이내에 완전한 준수를 달성해야 하며, 민간 부문은 2년의 이행 기간이 부여됩니다.

WCAG 1.3.3은 터키 전자정부 포털, 뱅킹 애플리케이션, 전자상거래 결제 플로우에서 색상 기반 폼 안내와 아이콘 전용 내비게이션 패턴이 널리 사용된다는 점에서 특히 관련성이 큽니다. 예를 들어, 한 공공 기관의 온라인 신청서가 시민에게 "빨간색으로 표시된 필드를 작성한 후 오른쪽 하단 모서리에 있는 버튼을 눌러 제출하세요"라고 안내한다면, 이는 1.3.3을 직접적으로 위반하며 대통령령 불이행에 해당합니다. 마찬가지로, 다단계 거래를 오직 위치와 색 단서만으로 안내하는 은행의 모바일 웹 인터페이스는 민간 부문 2년 기한 전에 수정되어야 합니다.

터키의 디지털 접근성 규제 환경이 성숙해짐에 따라, 비준수는 평판 및 법적 리스크를 수반합니다. 적용 대상 기관은 1.3.3 준수를 단순한 문구 수정이 아니라, 모든 지시 콘텐츠 — 도움말 텍스트, 오류 메시지, 온보딩 플로우, 지원 문서 등을 포함 — 에 대한 체계적인 검토로 간주해야 합니다. 이를 통해 감각적 참조가 항상 안정적인 프로그래밍 방식 텍스트 기반 식별자와 함께 제공되도록 해야 합니다. Accsible의 오버레이 SDK는 많은 관련 문제를 드러내고 수정하는 데 도움을 줄 수 있지만, 1.3.3이 요구하는 수동 콘텐츠 검토는 궁극적으로 자동화 도구와 함께 작업하는 자격 있는 인적 감사자가 수행해야 합니다.