버튼 다음에 그 툴팁을

KRDS CP-384 — 스크린 리더 사용자가 도움말 팝오버 콘텐츠에 논리적인 순서로 접근할 수 있도록 관련 있는 활성화 버튼 다음 요소로 제공하고 있다.

0. 들어가며 — 버튼 따로, 툴팁 따로면

이번 504편은 스크린 리더 사용자가 툴팁 콘텐츠에 논리적 순서로 접근하도록, 관련 활성화 버튼 다음 요소로 제공 하라는 규칙입니다. 이로써 툴팁 9개 규칙이 마무리됩니다.

툴팁 콘텐츠가 — DOM에서 그 버튼과 동떨어진 곳에 있으면, 스크린 리더 사용자가 버튼을 읽은 뒤 툴팁을 어디서 만날지 모르죠. CP-384는 툴팁 콘텐츠를 관련 버튼 다음에 두라고 규정합니다. 맥락적 도움말 CP-364·코치마크 CP-375와 통하는 DOM 순서 규칙이죠. 이번 편을 풀어냅니다.

1. 원문 — 관련 버튼 다음 요소로 제공

CP-384 (컴포넌트 > 툴팁) “스크린 리더 사용자가 도움말 팝오버 콘텐츠에 논리적인 순서로 접근할 수 있도록 관련 있는 활성화 버튼 다음 요소로 제공하고 있다.”

툴팁(도움말 팝오버) 콘텐츠를 DOM상 관련 활성화 버튼 바로 다음에 배치해, 스크린 리더 사용자가 논리적 순서로 접근하게 하라는 뜻입니다.

정리: 툴팁 콘텐츠를 관련 버튼 다음 DOM 요소로 두어라. 이게 CP-384입니다.

2. 왜 관련 버튼 다음 요소인가

스크린 리더·키보드 사용자는 — DOM 순서(HTML 작성 순서)대로 콘텐츠를 읽고 탐색합니다. 툴팁은 — 활성화 버튼과 그 툴팁 콘텐츠가 짝인데, 이 둘의 DOM 순서가 논리적이어야 스크린 리더 사용자가 자연스럽게 접근하죠. CP-384는 그 순서를 규정합니다(맥락적 도움말 CP-364, 코치마크 CP-375와 같은 정신).

시각 위치 vs DOM 순서. 툴팁 콘텐츠는 시각적으로 버튼 근처에 뜹니다(CP-377). 하지만 구현상 툴팁 콘텐츠 요소를 DOM 어디에 두느냐는 별개죠. 흔히 툴팁을 페이지 끝이나 별도 컨테이너(portal)에 모아두기도 합니다. 그러면 시각적으론 버튼 옆이지만, DOM상으론 버튼과 멀리 떨어지죠.

툴팁 콘텐츠가 버튼과 멀 때의 문제:

논리 순서 깨짐 — 스크린 리더 사용자가 — 버튼을 읽은 뒤, 그 툴팁 콘텐츠를 만나려면 DOM을 한참 더 가야 하면, ‘이 버튼의 툴팁은 어디 있지?’ 하고 연결이 끊깁니다. 버튼과 그 도움말이 따로 노는 거죠.

탐색 비효율 — 키보드/스크린 리더로 순서대로 읽는데 — 관련 콘텐츠가 멀리 있으면, 맥락을 잡기 어렵습니다.

그래서 CP-384는 — 툴팁 콘텐츠를 관련 활성화 버튼 다음 요소로 두라고 합니다:

버튼 직후 배치 DOM에서 활성화 버튼 바로 다음에 그 툴팁 콘텐츠를 둡니다. 그러면 스크린 리더가 버튼을 읽은 직후 그 툴팁 내용을 만나, 논리적으로 이어지죠. ‘검색 버튼’ → 바로 그 설명/이름으로요.

<button aria-labelledby="tip1">🔍</button> <span role="tooltip" id="tip1">검색</span> <!-- 버튼 바로 다음 -->

aria 연결과 함께 — DOM 순서(384)에 더해 — aria-labelledby/describedby(CP-383)로 연결하면, 순서·관계가 모두 명확합니다. DOM 인접(384) + aria 연결(383)이 함께 가죠.

aria 연결이 있으면 순서가 덜 중요하지 않나? aria-labelledby/describedby로 연결하면 스크린 리더가 버튼을 읽을 때 툴팁 내용을 이름/설명으로 읽어주긴 합니다. 하지만 사용자가 DOM을 순차 탐색(브라우즈 모드)할 때나, 연결이 완벽히 동작하지 않을 때를 대비해 DOM 순서도 논리적이어야 견고하죠. 즉 aria 연결(383) + DOM 인접(384) 둘 다 갖추는 게 안전합니다.

portal 주의. React 등에서 — 툴팁을 document.body 끝에 portal로 렌더링하는 경우가 흔한데, 이러면 DOM상 버튼과 멀어집니다. 이때도 — aria 연결(383)로 관계를 유지하거나, 가능하면 버튼 근처 DOM에 두는 걸 고려하죠. CP-384의 정신은 ’버튼과 툴팁 콘텐츠를 DOM상 논리적으로 인접·연결’하는 것입니다.

이 규칙은 툴팁의 ’DOM 순서 접근성’을 담당합니다 — 툴팁 콘텐츠를 관련 버튼 다음에 둬(384), 스크린 리더 사용자가 버튼과 그 툴팁을 논리적 순서로 접근하게 하죠. 툴팁 9개 규칙(용도·위치·길이·중첩·혼용·모바일·이름·연결·순서)이 이로써 마무리됩니다.

정리하면 — 툴팁 콘텐츠가 DOM에서 버튼과 멀면 스크린 리더 사용자가 연결을 못 잡으므로, 툴팁 콘텐츠를 관련 활성화 버튼 다음 요소로 두고 aria로 연결해 논리적 순서로 접근하게 해야 합니다.

3. 점검 / 개선

무엇을 점검하나

버튼 다음 배치 — 툴팁 콘텐츠가 DOM상 관련 버튼 다음에 있는가.

논리 순서 — 스크린 리더가 버튼 읽은 직후 툴팁 내용을 만나는가.

aria 연결 병행 — DOM 인접에 더해 aria-labelledby/describedby로 연결됐는가(CP-383).

개선 방향

툴팁 콘텐츠를 활성화 버튼 바로 다음 DOM에 배치. portal이면 aria 연결로 관계 유지.

aria-labelledby/describedby(CP-383) + role=“tooltip” 병행.

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

역할	책임
퍼블리셔/개발	DOM 순서·aria 연결 구현
QA/접근성	스크린 리더 버튼-툴팁 순서 검증

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

웹접근성 의무 대상이며 툴팁을 쓰는 사이트에 해당됩니다.

5. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 툴팁 콘텐츠가 DOM상 관련 버튼 다음에 있나요?

□ 스크린 리더가 버튼 읽은 직후 툴팁 내용을 만나나요?

□ DOM 인접에 더해 aria-labelledby/describedby로 연결됐나요?

❓ FAQ

Q1. aria로 연결했으면 DOM 순서는 안 중요한가요? aria 연결이 핵심이지만, 순차 탐색·연결 불완전 대비로 DOM 순서도 논리적이어야 견고합니다. 둘 다 갖추죠. Q2. portal로 body 끝에 렌더하면요? DOM상 버튼과 멀어집니다. aria 연결(CP-383)로 관계를 유지하거나, 가능하면 버튼 근처 DOM을 고려하죠. Q3. 맥락적 도움말 CP-364·코치마크 CP-375와 같나요? 같은 DOM 순서 정신입니다. 관련 요소(버튼)와 콘텐츠를 논리적으로 잇죠.

6. 마무리

CP-384의 메시지:

버튼 다음에 그 툴팁을 — 툴팁 콘텐츠를 관련 활성화 버튼 다음 DOM 요소로 제공하라.

툴팁 콘텐츠가 DOM에서 버튼과 멀면 스크린 리더 사용자가 연결을 못 잡습니다. 콘텐츠를 관련 버튼 다음에 두고 aria로 연결해 논리적 순서로 접근하게 하는 게 핵심이죠. 이로써 툴팁 9개 규칙이 마무리됩니다. 다음 편부터는 날짜 입력 (Date input)입니다.

다음 편 예고 ▶ 「505. (CP-385) 날짜 입력 — 사용자가 날짜를 입력하는 데 사용하고 있다.」

ViewCheck는 툴팁 콘텐츠가 관련 버튼 다음 요소로 제공되는지를 진단합니다.

📚 참고 출처

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

WCAG 2.1 SC 1.3.2 Meaningful Sequence — https://www.w3.org/WAI/WCAG21/Understanding/meaningful-sequence.html

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

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