호버가 없는 화면에선

KRDS CP-381 — [모바일] 터치 인터페이스에서의 사용성을 고려하고 있다.

0. 들어가며 — 마우스 호버가 없는 터치 화면

이번 501편은 [모바일] 터치 인터페이스에서의 툴팁 사용성을 고려하라는 규칙입니다.

툴팁은 — 원래 마우스 호버로 뜨는 컴포넌트입니다. 그런데 — 모바일 터치 화면엔 ’호버’가 없죠. 손가락을 올린다고 호버가 되는 게 아니라 바로 탭(클릭)이 됩니다. CP-381은 호버가 없는 터치 환경에서도 툴팁이 동작하게 고려하라고 규정합니다. 이번 편을 풀어냅니다.

1. 원문 — 모바일 터치 사용성 고려

CP-381 (컴포넌트 > 툴팁) “[모바일] 터치 인터페이스에서의 사용성을 고려하고 있다.”

마우스 호버가 없는 모바일 터치 환경에서도 툴팁을 사용할 수 있게 동작·사용성을 고려하라는 뜻입니다.

정리: 터치 환경에서도 툴팁이 동작하게 고려하라. 이게 CP-381입니다.

2. 왜 터치 사용성을 고려하나

툴팁은 — 전통적으로 마우스 호버(hover) 로 뜹니다. 마우스 포인터를 요소 위에 올려두면(클릭은 안 하고) 툴팁이 나타나죠. 이는 마우스가 있는 데스크톱에서 자연스럽습니다. 하지만 — 터치 화면(모바일) 에는 근본적인 차이가 있습니다.

터치 환경의 문제 — 호버가 없음. 손가락 터치에는 — 마우스 같은 ‘호버’ 상태가 없습니다:

올려두기 불가 손가락은 화면에 닿으면 바로 탭(클릭) 입니다. 마우스처럼 ‘클릭 안 하고 위에 올려두기’ 가 안 되죠. 그래서 호버로 뜨는 툴팁은 터치 화면에서 트리거되지 않습니다.

탭 충돌 아이콘 버튼에 호버 툴팁과 탭 동작(그 버튼의 기능)이 같이 있으면, 터치하면 툴팁을 보려던 건지 버튼을 실행하려던 건지 충돌하죠. 검색 아이콘을 탭하면 툴팁(‘검색’)을 보고 싶었어도 바로 검색이 실행됩니다.

그래서 CP-381은 — 터치 환경에서의 사용성을 고려하라고 합니다. 방법들:

탭으로 툴팁 표시 터치 환경에선 호버 대신 탭으로 툴팁을 띄우는 방식을 고려합니다. 단, 그 요소가 버튼이면 탭 동작과 충돌하니 첫 탭은 툴팁, 다시 탭하면 실행하는 식의 구분이나, 별도 영역 분리가 필요하죠.

접근가능한 이름으로 대체 — 아이콘 버튼 이름 툴팁(CP-376)은 — 시각 툴팁이 터치에서 안 떠도, 접근가능한 이름(aria-label, CP-382)이 있으면 스크린 리더 사용자는 이름을 듣죠. 터치 + 스크린 리더 사용자에겐 aria가 핵심입니다.

대안 표현 — 중요한 부가 정보는 — 툴팁(호버)에만 의존하지 말고, 터치에서도 보이는 방식(인라인 텍스트, 탭으로 여는 맥락적 도움말 등)을 고려합니다. 호버 전용 정보는 터치 사용자가 못 보니까요.

필수 정보 본문 제공 — 애초에 필수 정보는 툴팁에 두지 않으므로(CP-378), 터치에서 툴팁이 안 떠도 작업엔 지장 없게 합니다.

호버 의존의 위험. 정보를 호버 툴팁에만 두면, 터치 사용자(모바일)는 그 정보에 접근 못 합니다. 모바일 사용자 비중이 큰 공공 서비스에선 호버 전용 정보가 큰 접근성 격차를 만들죠. 그래서 터치에서도 동작하거나, 대안이 있어야 합니다.

WCAG 1.4.13 Content on Hover or Focus. 관련 기준으로 — 호버/포커스로 뜨는 콘텐츠는, 사라지지 않고(dismissable, hoverable, persistent) 접근 가능해야 한다는 WCAG 1.4.13이 있죠. 터치 고려는 — 이 정신과도 통합니다(모든 입력 방식에서 콘텐츠 접근 보장).

이 규칙은 툴팁의 ’터치 접근성’을 담당합니다 — 호버가 없는 터치 환경에서도 툴팁을 쓰거나 대안을 제공해(381), 모바일 사용자가 정보에서 배제되지 않게 하죠. 반응형·멀티 디바이스 시대의 필수 고려입니다.

정리하면 — 툴팁은 호버 기반이라 호버가 없는 터치 환경에선 안 뜨므로, 탭 표시·접근가능한 이름·대안 표현 등으로 터치 사용성을 고려해 모바일 사용자도 정보에 접근하게 해야 합니다.

3. 점검 / 개선

무엇을 점검하나

터치 동작 — 터치 환경에서 툴팁이 뜨거나 대안으로 정보를 얻을 수 있는가.

탭 충돌 처리 — 버튼의 탭 동작과 툴팁 표시가 충돌하지 않게 처리됐는가.

호버 의존 배제 — 중요 정보가 호버 툴팁에만 의존하지 않는가(터치 사용자 접근 가능).

개선 방향

터치에서 탭 표시·접근가능한 이름(CP-382)·대안 표현 제공.

호버 전용 정보 배제. 필수는 본문(CP-378). WCAG 1.4.13 준수.

4. 누가 담당하나 / 우리 사이트에 해당될까?

역할	책임
기획/UX	터치 환경 도움 표현 설계
퍼블리셔/개발	터치 동작·대안 구현
QA	모바일 터치 툴팁 검증

기관 유형	CP-381 적용
중앙행정기관(대표·운영) / 공공기관 / 지자체	✅ 필수 (모바일 + 툴팁 사용 시)

모바일을 지원하며 툴팁을 쓰는 사이트에 해당됩니다.

5. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 터치 환경에서 툴팁이 뜨거나 대안으로 정보를 얻을 수 있나요?

□ 버튼의 탭 동작과 툴팁 표시가 충돌하지 않게 처리됐나요?

□ 중요 정보가 호버 툴팁에만 의존하지 않나요?

❓ FAQ

Q1. 왜 터치에서 툴팁이 안 뜨나요? 툴팁은 마우스 호버 기반인데, 터치엔 ’올려두기’가 없고 바로 탭(클릭)이라 호버가 트리거되지 않습니다. Q2. 어떻게 고려하나요? 탭으로 툴팁 표시(버튼은 충돌 처리), 접근가능한 이름(aria), 대안 표현(인라인·맥락적 도움말) 등을 씁니다. Q3. 정보를 호버 툴팁에만 두면요? 터치 사용자가 못 봅니다. 호버 전용 정보는 피하고, 필수는 본문에 두죠(CP-378). WCAG 1.4.13과도 통합니다.

6. 마무리

CP-381의 메시지:

호버가 없는 화면에선 — 터치 인터페이스에서의 툴팁 사용성을 고려하라.

툴팁은 호버 기반이라 터치 환경에선 안 뜹니다. 탭 표시·접근가능한 이름·대안 표현으로 터치 사용성을 고려해 모바일 사용자도 정보에 접근하게 하는 게 핵심이죠. 다음 편은 버튼의 고유한 이름입니다.

다음 편 예고 ▶ 「502. (CP-382) 스크린 리더 사용자가 활성화 버튼의 용도를 이해할 수 있도록 각각의 버튼에 이름을 고유하고 적절하게 제공하고 있다.」

ViewCheck는 툴팁이 터치 인터페이스 사용성을 고려하는지를 진단합니다.

📚 참고 출처

KRDS 컴포넌트 — 툴팁(Tooltip) 가이드 — https://www.krds.go.kr/html/site/component/component_37.html

WCAG 2.1 SC 1.4.13 Content on Hover or Focus — https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html

KRDS #ViewCheck #공공웹사이트 #전자정부 #디지털정부 #웹접근성 #디자인시스템 #UIUX #UI컴포넌트 #웹표준

KRDS,ViewCheck,공공웹사이트,전자정부,디지털정부,웹접근성,디자인시스템,UIUX,UI컴포넌트,웹표준