키보드로도 닿고, 흐름상 올바른 자리에

KRDS CP-111 — 키보드로 접근과 조작이 가능하도록 구현하고, 제목과 본문 사이에 배치하고 있다.

0. 들어가며 — 위치와 조작을 함께

이번 231편은 콘텐츠 내 탐색을 키보드로 접근·조작 가능하게 구현하고, 제목과 본문 사이에 배치하라는 규칙 입니다.

CP-110이 모바일 배치(제목-본문 사이)를 정했다면, CP-111은 그 배치를 다시 짚으면서 키보드 접근성을 더합니다. 페이지 목차 링크가 마우스로만 작동하면 키보드 사용자는 섹션 점프를 못 쓰죠. 또 목차가 DOM상 엉뚱한 위치에 있으면 키보드 초점 순서가 어긋납니다. 위치와 조작을 함께 갖춰야 모든 사용자가 목차를 씁니다. 이번 편을 풀어 냅니다.

1. 규칙 원문 — 키보드 접근·조작 + 제목-본문 사이 배치

CP-111 (컴포넌트 > 콘텐츠 내 탐색) “키보드로 접근과 조작이 가능하도록 구현하고, 제목과 본문 사이에 배치하고 있다.”

콘텐츠 내 탐색 링크를 키보드로 초점 이동·실행할 수 있게 구현하고, 그 목차를 제목과 본문 사이(논리적 위치)에 두어 읽기·초점 흐름이 자연스럽게 하라는 뜻입니다.

정리: 목차는 키보드로 닿고 조작되며, 제목과 본문 사이에 위치해야 한다. 이게 CP-111입니다.

2. 왜 키보드 접근과 배치를 함께 보나

이 규칙은 두 가지를 한데 묶습니다 — 키보드 접근성과 DOM/배치 순서. 둘은 사실 긴밀히 연결돼 있죠.

① 키보드 접근·조작. 콘텐츠 내 탐색 링크는 ’클릭하면 페이지 내 섹션으로 점프’하는 링크입니다. 사이드 메뉴 키보드 규칙(CP-102)에서 봤듯, 이 링크가 키보드로 닿으려면 표준 인터랙티브 요소(<a href="#section-id">) 여야 합니다. 표준 앵커 링크는 기본적으로 Tab 포커스를 받고 Enter로 실행되므로, 목차를 이런 앵커 링크로 만들면 키보드 접근이 자동 충족되죠. <div onclick> 같은 비표준 구현은 키보드로 닿지 않아 함정이 됩니다. 또 포커스 위치가 시각적으로 보여야(focus indicator) 키보드 사용자가 어느 항목에 있는지 압니다.

② 제목과 본문 사이 배치 — 시각 + DOM. CP-110에서 본 ‘제목-본문 사이’는 단지 화면상 위치만이 아니라 DOM 순서의 문제이기도 합니다. 목차가 DOM에서 제목 다음, 본문 앞에 위치하면 — 키보드 초점이 ’제목 → 목차 링크들 → 본문’ 순으로 자연스럽게 흐릅니다(CP-103의 초점 순서 원리). 사용자는 제목을 지나 목차에 닿고, 목차를 훑은 뒤 본문으로 들어가죠. 만약 목차가 시각적으론 위에 보이지만 DOM상으론 본문 뒤에 있으면(CSS로 위치만 위로 끌어올린 경우), 키보드 초점은 본문을 다 지나서야 목차에 닿아 순서가 어긋납니다. 그래서 시각 위치와 DOM 위치를 모두 제목-본문 사이로 맞춰야 하죠. 이것이 CP-110(시각 배치)에 더해 CP-111이 강조하는 ’배치 + 조작’의 핵심입니다.

이 둘을 함께 보는 이유 — 목차가 ’제목과 본문 사이’에 올바른 DOM 순서로 있으면, 키보드 사용자는 자연스러운 초점 흐름으로 목차에 닿고, 표준 앵커 링크라면 Enter로 섹션 점프까지 됩니다. 위치(흐름상 올바른 자리)와 조작(키보드 작동)이 맞물려야 비로소 모든 사용자가 목차를 온전히 쓰는 것이죠.

추가로 — 목차 링크를 Enter로 실행했을 때 ’화면 스크롤’뿐 아니라 ’키보드 초점’도 해당 섹션으로 이동해야 합니다. 이건 바로 다음 편 CP-112의 내용으로, CP-111(닿고 실행됨)에서 CP-112(실행 후 초점도 이동)로 이어지죠.

3. 점검 / 개선

무엇을 점검하나

키보드 접근 — 목차 링크에 Tab으로 닿고 Enter로 실행되는가.

표준 앵커 — 링크가 <a href="#..."> 등 표준 요소인가.

DOM 순서 — 목차가 DOM상 제목 다음·본문 앞에 위치해 초점 흐름이 자연스러운가.

포커스 표시 — 현재 포커스 항목이 시각적으로 보이는가.

개선 방향

목차를 <a href="#section-id"> 앵커 링크로 구현(클릭 div 지양).

시각·DOM 위치를 모두 제목-본문 사이로 맞춰 초점 순서 정렬.

:focus-visible 포커스 스타일 제공.

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

역할	책임
퍼블리셔/개발	앵커 링크·DOM 순서·포커스 표시 구현
접근성 담당	키보드 접근·초점 흐름 검증

기관 유형	CP-111 적용
중앙행정기관(대표·운영) / 공공기관 / 지자체	✅ 필수 (콘텐츠 내 탐색 사용 시)

웹접근성 의무 대상인 모든 공공 사이트가 해당됩니다.

5. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 목차 링크에 Tab으로 닿고 Enter로 실행되나요?

□ 링크가 <a href="#..."> 표준 앵커인가요?

□ DOM상 목차가 제목 다음·본문 앞이라 초점 흐름이 자연스럽나요?

□ 포커스 위치가 시각적으로 보이나요?

❓ FAQ

Q1. CP-110과 뭐가 다른가요? CP-110은 모바일 시각 배치, CP-111은 그 배치(시각+DOM) + 키보드 접근·조작을 함께 봅니다. Q2. 시각만 제목 아래로 올리면 안 되나요? CSS로 시각만 올리고 DOM이 본문 뒤면 키보드 초점 순서가 어긋 납니다. DOM 위치도 맞춰야 합니다. Q3. 앵커 링크면 자동으로 키보드 접근되나요? 네. <a href="#...">는 기본적으로 포커스·Enter 실행이 됩니다.

6. 마무리

CP-111의 메시지:

키보드로도 닿고, 흐름상 올바른 자리에 — 접근·조작과 DOM 배치를 함께 갖춰라.

목차는 표준 앵커 링크로 만들어 키보드로 닿고 실행되게 하고, 시각·DOM 위치를 모두 제목-본문 사이로 맞춰 초점 흐름을 자연스럽게 해야 합니다. 위치와 조작이 맞물려야 모든 사용자가 목차를 쓰죠. 다음 편은 실행 후의 초점 이동입니다.

다음 편 예고 ▶ 「232. (CP-112) 키보드로 콘텐츠 내 탐색 링크를 실행했을 때 화면과 함께 키보드 초점이 해당 섹션으로 이동되도록 구현하고 있다.」

ViewCheck는 콘텐츠 내 탐색의 키보드 접근·조작과 제목-본문 사이 배치를 진단합니다.

📚 참고 출처

KRDS 컴포넌트 — 콘텐츠 내 탐색(In-page navigation) 가이드 — https://www.krds.go.kr/html/site/component/component_09.html

WCAG 2.1 SC 2.1.1 Keyboard — https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html

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

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