WCAG 3.3.5: 도움

이 규칙의 의미

\n

WCAG 성공 기준 3.3.5 Help (Level AAA)는 다음과 같이 규정한다. “문맥에 민감한 도움말이 제공된다.” 이는 웹 페이지나 애플리케이션이 사용자에게 정보를 입력하도록 요청하는 모든 곳에서, 무엇이 기대되는지 명확히 해 주는 적절한 도움말이 제공되어야 함을 의미한다. 도움말은 문맥적이어야 한다. 즉, 내비게이션 어딘가에 묻혀 있는 일반적인 도움말 페이지가 아니라, 사용자가 현재 수행 중인 필드, 작업 또는 프로세스와 직접적으로 관련되어야 한다.

\n

이 기준은 입력이 필요한 모든 사용자 인터페이스 구성 요소에 적용된다. 예를 들어 텍스트 필드, 드롭다운 메뉴, 날짜 선택기, 파일 업로드 컨트롤, 체크박스, 라디오 버튼, 다단계 양식 등이 있다. 문맥에 민감한 도움말은 인라인 안내문, 설명적인 레이블, 플레이스홀더 안내, 툴팁, 설명을 펼쳐 보여 주는 도움말 아이콘, 관련 도움말 문서로 연결되는 링크, 심지어 라이브 채팅 지원 등 다양한 형태를 취할 수 있다. 중요한 것은, 도움이 필요한 입력 요소와 가까운 위치에서 해당 도움말을 이용할 수 있어야 한다는 점이다.

\n

준수(통과)는 사용자에게 혼란을 줄 수 있는 각 입력에 대해 다음 중 최소 하나가 제공될 때 달성된다. 기대되는 입력을 완전히 설명하는 명확하게 작성된 레이블, 필드 인접에 있는 보조 설명 텍스트(입력 시 사라지는 플레이스홀더만 있는 경우는 제외), 추가 설명을 제공하는 눈에 잘 보이는 도움말 링크 또는 펼쳐지는 툴팁, 현재 문맥에 특화된 안내를 보여 주는 물음표 아이콘과 같은 쉽게 접근 가능한 도움말 메커니즘 등이 이에 해당한다. 모든 필드에서 동일한 도움말을 제공할 필요는 없다. 핵심 요구 사항은 사용자가 무엇을 입력해야 할지 불확실할 수 있는 곳마다 실제로 이용 가능하고 접근 가능한 도움말이 제공되는 것이다.

\n

실패는 필드가 기대되는 내용을 전혀 설명하지 않거나, 제출 후 오류가 발생한 뒤에만 도움말을 제공하거나, 툴팁이나 도움말 텍스트가 키보드 또는 스크린 리더 사용자에게 접근 불가능하거나, 도움말 링크가 특정 입력과 관련된 내용이 아닌 일반 FAQ 페이지로만 연결될 때 발생한다. 특히, 사후 오류 메시지에만 의존하는 것은 이 기준을 충족하지 못한다. 도움말은 실수가 발생한 이후가 아니라, 입력 이전 또는 입력 중에 제공되어야 한다.

\n

WCAG 3.3.5는 단일한 엄격한 구현 방법을 정의하지 않는다. 문맥에 민감한 도움말이 여러 유효한 방식으로 구현될 수 있음을 인정하여 개발자에게 유연성을 부여하지만, 의도는 분명하다. 사용자가 양식 필드가 무엇을 기대하는지 추측해야 하는 상황이 있어서는 안 된다. 이 기준에는 공식적인 예외가 없으며, 사용자 입력이 요청되는 모든 곳에 보편적으로 적용된다.

\n\n

중요한 이유

\n

양식은 모든 디지털 인터페이스에서 가장 도전적인 부분 중 하나다. 인지 장애가 있는 사용자(난독증, 주의력 결핍 장애, 지적 장애, 기억력 손상 등을 포함)는 모호한 양식 필드가 넘기 어려운 장벽이 될 수 있다. 명확하고 문맥적인 도움말이 없으면, 이들은 반복적으로 작업을 완료하지 못하거나, 큰 좌절감을 겪거나, 아예 과정을 포기할 수 있다. 세계보건기구(WHO)에 따르면 전 세계 인구 6명 중 약 1명은 어떤 형태로든 중대한 장애를 가지고 있으며, 이 중 상당 부분이 인지 장애에 해당한다.

\n

디지털 활용 능력이 낮은 사용자나 웹 인터페이스 경험이 제한적인 사용자도 문맥에 민감한 도움말로부터 큰 혜택을 얻는다. 예를 들어 정부 전자 서비스 포털을 처음 사용하는 사람, 온라인으로 건강 복지 혜택을 신청하는 고령자, 세금 신고서를 작성하는 소규모 사업자는 세금 식별 번호에 어떤 형식이 필요한지, 문서 업로드에 어떤 파일 형식이 허용되는지, 이름이 비슷한 두 필드가 무엇이 다른지 알지 못할 수 있다. 문맥 내 안내가 없다면, 이들은 오류에 취약해지고, 무엇을 잘못했는지 모른 채 불안감을 느끼게 된다.

\n

구체적인 상황을 생각해 보자. 인지 장애가 있는 한 사용자가 시(市) 교통 당국 웹 포털을 통해 교통비 지원 승차권을 신청하고 있다. 양식은 아무 설명 없이 “Reference Number(참조 번호)”를 요구한다. 사용자는 여러 문서를 가지고 있다. 국가 신분증, 교통카드, 이전 신청 확인서 등이며, 각각 다른 숫자 식별자가 있다. 어떤 특정 문서나 형식이 필요한지 알려 주는 문맥에 민감한 도움말이 없다면, 사용자는 잘못된 번호를 입력하고, 유효성 검사 오류를 발생시키며, 결국 포기할 수 있다. “교통카드 오른쪽 상단에 있는 10자리 번호를 입력하세요.”와 같은 간단한 도움말 아이콘이나 인라인 설명만 있었어도, 전체 상호작용은 첫 시도에 성공했을 것이다.

\n

시각장애가 있거나 저시력인 사용자에게도 문맥에 민감한 도움말은 중요하다. 스크린 리더는 연결된 도움말 텍스트, aria-describedby 설명, 연결된 도움말 콘텐츠를 읽어 줄 수 있지만, 이는 올바르게 구현되었을 때만 가능하다. 도움말이 색상 표시나 접근 가능한 텍스트가 없는 아이콘처럼 순수하게 시각적으로만 전달되면, 스크린 리더 사용자는 배제된다. 도움말이 존재할 뿐 아니라 접근 가능하도록 보장하는 것은 다양한 장애 그룹에 걸친 포용성을 강화한다.

\n

접근성을 넘어, 문맥에 민감한 도움말은 전반적인 사용성과 전환율을 향상시킨다. 명확한 양식 안내가 있는 웹사이트는 이탈률이 낮고, 지원 요청이 적으며, 양식 완료율이 높다. 특히 전자상거래 사이트의 경우, 결제 완료율이 1%포인트만 개선되어도 직접적인 매출 증가로 이어진다. 검색 엔진 역시 명확하고 구조화된 콘텐츠를 가진 페이지를 선호하며, 잘 레이블링되고 잘 설명된 양식은 페이지 품질 신호에 긍정적으로 기여한다.

\n\n

관련 Axe-core 규칙

\n

WCAG 3.3.5는 도움말 콘텐츠의 품질, 적절성, 문맥 적합성에 따라 준수 여부가 결정되기 때문에 수동 테스트가 필요하다. 자동화 도구는 레이블이 존재하는지, aria-describedby 속성이 실제 요소를 가리키는지 확인할 수 있지만, 해당 레이블이나 설명의 내용이 실제로 도움이 되는지, 정확한지, 특정 입력에 충분한지는 판단할 수 없다.

\n

\n
• 수동 검토 — 문맥에 민감한 도움말의 존재 여부: 자동화 도구는 도움말 텍스트가 특정 필드에 대해 사용자가 가질 법한 질문을 실제로 해결하는지 평가할 수 없다. 도구는 <label> 요소가 존재하는지 감지할 수 있지만, 형식화된 VAT 등록 번호를 기대하는 필드에 “Enter your number(번호를 입력하세요)”라는 문구가 충분히 설명적인지 판단할 수 없다. 수동 테스터는 혼란을 야기할 수 있는 각 입력이 그 혼란을 의미 있게 줄여 주는 안내와 함께 제공되는지 평가해야 한다.
\n
• 수동 검토 — 도움말의 접근성: 도움말이 시각적으로 존재하더라도, 자동화 도구는 그 도움말이 보조 기술에 접근 불가능한 경우를 표시하지 못할 수 있다. 예를 들어 마우스 오버에서만 표시되고 키보드로는 접근할 수 없는 툴팁은 많은 자동 검사에서 통과하지만 실제 사용자에게는 실패다. 테스터는 모든 도움말 메커니즘(툴팁, 펼쳐지는 섹션, 도움말 링크 등)이 키보드로 도달 가능하고 조작 가능하며, 스크린 리더에 의해 올바르게 읽히는지 확인해야 한다.
\n
• 수동 검토 — 도움말의 위치와 근접성: 자동 스캔은 도움말 텍스트가 관련 필드와 충분히 가까운 위치에 있어 의미 있게 연관되는지 평가할 수 없다. 페이지 하단에 있는 도움말 문단이나, 여러 번의 상호작용을 거쳐야 도달할 수 있는 모달 안의 도움말은 기술적으로 존재하더라도 문맥에 민감한 도움말의 취지를 충족하지 못할 수 있다. 수동 검토를 통해 도움말이 필요 시점에 제공되는지 확인해야 한다.
\n
• 수동 검토 — 복잡한 양식 전반의 완전성: 복잡한 다단계 양식은 추가적인 과제를 제기한다. 자동화 도구는 개별 필드를 개별적으로 검사하지만, 다단계 마법사 전체에 걸쳐 제공되는 누적 도움말이 복잡한 프로세스를 안내하기에 충분한지 평가할 수 없다. 양식을 전체적으로 경험해 보았을 때에만 드러나는 안내의 공백을 찾기 위해 수동 워크스루가 필요하다.
\n

\n\n

테스트 방법

\n

\n
1. 기본선으로 자동 접근성 스캔을 실행한다. 양식이 포함된 페이지에서 axe DevTools(브라우저 확장 또는 CLI), Chrome DevTools의 Lighthouse, IBM Equal Access Checker를 사용한다. 이 도구들은 3.3.5 위반을 직접 표시하지는 않지만, 누락된 레이블(label 요소가 입력과 연결되지 않은 경우), 누락된 aria-describedby 대상, 접근 불가능한 툴팁 구현 등 관련 문제를 드러낸다. 먼저 이러한 기초 문제를 해결하면, 문맥에 민감한 도움말을 추가했을 때 기술적으로도 접근 가능해진다.
\n
2. 모든 양식 필드를 수동으로 검토하여 도움말 제공 여부를 확인한다. 각 입력 필드에 대해 다음을 자문한다. (a) 레이블만으로 요구되는 입력과 형식 요구 사항을 완전히 설명하는가? (b) 필드 인접에 보이는 보조 도움말 텍스트가 있는가? (c) 추가 안내를 제공하는 도움말 아이콘, 툴팁, 펼쳐지는 섹션이 있는가? (d) 관련 도움말 콘텐츠로 연결되는 링크가 있는가? 이 모든 질문에 대한 답이 “아니오”이고, 필드에 어떤 모호성이라도 있다면, 이는 3.3.5의 실패다.
\n
3. 모든 도움말 메커니즘의 키보드 접근성을 테스트한다. 마우스를 사용하지 않고 키보드만으로 Tab 키를 이용해 양식을 탐색한다. 모든 툴팁, 도움말 아이콘, 펼쳐지는 설명, 도움말 링크에 키보드로 도달하고 활성화할 수 있는지 확인한다. 툴팁은 포커스 시에도, 호버 시와 마찬가지로 나타나야 한다. 도움말 버튼은 Enter 또는 Space 키로 활성화되어야 한다. 마우스로만 접근 가능한 도움말 메커니즘은 이 테스트에서 실패다.
\n
4. NVDA + Firefox로 테스트한다. Tab 키로 각 양식 필드로 이동한다. NVDA가 각 필드에 대해 무엇을 읽어 주는지 확인한다. 레이블을 읽는가? 연결된 설명(aria-describedby를 통해)을 읽는가? 도움말 아이콘이나 툴팁을 활성화하고 그 내용이 읽히는지 확인한다. 연결된 도움말 콘텐츠에 도달해 현재 필드와 관련 있는지 검증한다.
\n
5. VoiceOver + Safari(macOS 또는 iOS)로 테스트한다. VoiceOver를 사용해 양식을 탐색한다. macOS에서는 Tab 키로 필드 간 이동을 하며 각 필드에 대한 전체 안내를 듣는다. iOS에서는 스와이프 내비게이션을 사용한다. 입력과 연결된 모든 도움말 콘텐츠가 음성으로 읽히는지, 도움말 트리거(버튼, 링크)가 VoiceOver로 접근 가능하고 올바르게 레이블링되어 있는지 확인한다.
\n
6. JAWS + Chrome으로 테스트한다. JAWS 폼 모드(폼 요소에 있을 때 Enter로 활성화)를 사용한다. Tab 키로 필드 간 이동을 하며 JAWS가 연결된 안내와 설명을 읽는지 확인한다. JAWS 가상 커서를 사용해 표준 레이블 연결 외부에 배치된 도움말 콘텐츠도 도달 가능한지 확인한다.
\n
7. 인지 워크스루를 수행한다. 양식에 익숙하지 않은 사람에게(또는 잠시 휴식을 취한 후 스스로) 외부 안내 없이 양식을 완료해 보도록 요청한다. 기대가 불명확해 망설이거나, 질문을 하거나, 오류를 범하는 모든 지점을 기록한다. 이러한 지점 각각이 3.3.5에 따라 문맥에 민감한 도움말을 개선해야 할 후보가 된다.
\n

\n\n

수정 방법

\n

설명이 없는 모호한 텍스트 필드 — 잘못된 예

\n

<!-- No help provided for an ambiguous field expecting a specific format -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input type='text' id='tc-kimlik' name='tc-kimlik'>

\n

인라인 도움말이 있는 모호한 텍스트 필드 — 올바른 예

\n

<!-- Inline description associated via aria-describedby gives format guidance before the user types -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input\n  type='text'\n  id='tc-kimlik'\n  name='tc-kimlik'\n  aria-describedby='tc-kimlik-help'\n  autocomplete='off'\n  maxlength='11'\n>\n<p id='tc-kimlik-help'>\n  Nüfus cüzdanınızda yer alan 11 haneli TC Kimlik Numaranızı giriniz.\n  (Enter your 11-digit Turkish National ID number as shown on your ID card.)\n</p>

\n\n

키보드 사용자에게 접근 불가능한 도움말 아이콘 툴팁 — 잘못된 예

\n

<!-- Tooltip only shown on mouseover; keyboard users and screen reader users cannot access it -->\n<label for='iban'>IBAN <span class='help-icon' title='What is IBAN?'>?</span></label>\n<input type='text' id='iban' name='iban'>

\n

모든 사용자에게 접근 가능한 도움말 아이콘 툴팁 — 올바른 예

\n

<!-- Button with aria-expanded controls a help panel; accessible via keyboard and screen readers -->\n<label for='iban'>IBAN</label>\n<button\n  type='button'\n  aria-expanded='false'\n  aria-controls='iban-help'\n  class='help-toggle'\n  aria-label='Help: What is an IBAN?'\n>\n  ?\n</button>\n<input type='text' id='iban' name='iban' aria-describedby='iban-help'>\n<div id='iban-help' hidden>\n  <p>\n    IBAN (International Bank Account Number) is a 26-character code starting\n    with "TR" used to identify your Turkish bank account. You can find it\n    in your bank's mobile app under Account Details.\n  </p>\n</div>\n<!-- JavaScript toggles aria-expanded and the hidden attribute on button click/keypress -->

\n\n

단계별 안내가 없는 복잡한 다단계 양식 — 잘못된 예

\n

<!-- Step 2 of a 4-step application with no explanation of what documents are needed -->\n<h2>Step 2: Upload Documents</h2>\n<label for='doc-upload'>Upload File</label>\n<input type='file' id='doc-upload' name='doc-upload'>

\n

문맥에 맞는 단계 도움말이 있는 복잡한 다단계 양식 — 올바른 예

\n\n

(Content truncated due to token limit — please retry this article.)