화면만 옮기면 반쪽

KRDS CP-112 — 키보드로 콘텐츠 내 탐색 링크를 실행하였을 때 화면과 함께 키보드 초점이 해당 섹션으로 이동되도록 구현하고 있다.

0. 들어가며 — 스크롤은 됐는데 초점은 그대로면

이번 232편은 목차 링크를 키보드로 실행했을 때, 화면(스크롤)뿐 아니라 키보드 초점도 해당 섹션으로 이동 하게 하라는 규칙입니다.

목차의 “3. 주요 내용”을 Enter로 눌렀습니다. 화면은 그 섹션으로 스크롤됐죠. 그런데 키보드 초점은 여전히 목차 링크에 머물러 있으면? 다음 Tab을 누르면 초점이 목차의 다음 항목으로 가버려, 정작 점프한 섹션의 내용을 키보드로 읽지 못합니다. 화면만 옮기고 초점은 안 옮기면 반쪽짜리죠. CP-112는 화면과 초점을 함께 이동시키라고 규정합니다. 이번 편을 풀어냅니다.

1. 규칙 원문 — 화면 + 초점 함께 이동

CP-112 (컴포넌트 > 콘텐츠 내 탐색) “키보드로 콘텐츠 내 탐색 링크를 실행하였을 때 화면과 함께 키보드 초점이 해당 섹션으로 이동되도록 구현 하고 있다.”

목차 링크를 키보드로 실행하면, 화면 스크롤과 더불어 키보드 초점도 점프 대상 섹션으로 옮겨가, 사용자가 이어서 그 섹션을 키보드로 조작·탐색할 수 있게 하라는 뜻입니다.

정리: 목차 점프 시 화면뿐 아니라 키보드 초점도 해당 섹션으로 이동시켜라. 이게 CP-112입니다.

2. 왜 초점까지 이동해야 하나

이것은 페이지 내 앵커 링크의 잘 알려진 접근성 함정입니다. <a href="#section3">을 클릭하면 브라우저는 보통 화면을 해당 위치로 스크롤합니다. 시각 마우스 사용자에게는 이걸로 충분하죠 — 눈으로 섹션을 보고 이어 읽으면 되니까요. 하지만 키보드·스크린 리더 사용자에게는 문제가 생깁니다.

키보드 사용자 관점. 화면은 섹션3으로 스크롤됐지만, 키보드 초점(focus)은 여전히 클릭한 목차 링크에 남아 있는 경우가 많습니다(브라우저·구현에 따라). 그러면 사용자가 다음으로 Tab을 누르면 — 초점은 섹션3이 아니라 목차의 ‘다음 목차 링크’로 이동하죠. 즉 점프는 했는데, 키보드 탐색은 여전히 목차 안에 갇혀 섹션3의 내용으로 들어가지 못합니다. 사용자는 ’분명 점프했는데 왜 내용을 못 읽지?’ 하고 혼란에 빠집니다.

스크린 리더 사용자 관점. 스크린 리더는 보통 ‘초점’이나 ’읽기 커서’ 위치를 기준으로 낭독합니다. 초점이 목차에 남아 있으면, 화면이 섹션3으로 스크롤됐어도 스크린 리더는 섹션3을 읽기 시작하지 못하죠. 사용자는 점프의 결과를 전혀 체감하지 못합니다.

그래서 CP-112는 — 링크 실행 시 화면 스크롤과 함께 키보드 초점도 대상 섹션으로 옮기라고 합니다. 그러면 사용자는 점프 직후 그 섹션에서 바로 이어 읽고, 다음 Tab도 섹션 내부로 진행하죠. 화면과 초점이 일치해 ’점프 했다’는 결과가 모든 사용자에게 온전히 전달됩니다.

구현 방법. 대상 섹션(또는 그 제목)에 초점을 명시적으로 옮깁니다:

대상 섹션 요소(예: 섹션 제목 <h2 id="section3">)에 tabindex="-1"을 부여하고, 링크 실행 핸들러에서 element.focus()를 호출 → 화면 스크롤 + 초점 이동이 함께 일어남.

tabindex="-1"은 그 요소가 일반 Tab 순서에는 안 들어가되 프로그래밍 방식 포커스는 받게 합니다(섹션 제목은 원래 포커스 대상이 아니므로 이 설정이 필요).

잘 구성된 앵커 링크는 일부 브라우저에서 자동으로 초점을 옮기기도 하지만, 일관성을 위해 명시적 focus()가 권장됩니다.

이 규칙은 CP-111(키보드로 링크 실행 가능)의 결과 처리입니다 — 실행까지 됐으면(111), 그 실행의 결과로 초점도 따라가야(112) 비로소 점프가 완성됩니다. 난이도가 한 단계 높은(★★★★) 이유는, 단순 앵커 링크만으론 부족하고 JavaScript로 초점을 명시 관리해야 하기 때문이죠.

3. 점검 / 개선

무엇을 점검하나

초점 이동 — 키보드로 목차 링크 실행 시 초점이 대상 섹션으로 가는가.

이어 탐색 — 점프 후 Tab이 섹션 내부로 진행되는가(목차에 안 갇힘).

스크린 리더 — 점프 후 스크린 리더가 대상 섹션을 읽기 시작하는가.

개선 방향

link.addEventListener('click', e => { const target = document.querySelector(link.getAttribute('href')); target.setAttribute('tabindex', '-1'); target.focus(); // 화면 스크롤 + 초점 이동 });

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

역할	책임
퍼블리셔/개발	대상 섹션 tabindex=-1 + focus() 초점 관리 구현
접근성 담당	점프 후 초점·낭독 위치 검증

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

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

5. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 키보드로 목차 링크 실행 시 초점이 대상 섹션으로 가나요?

□ 점프 후 Tab이 섹션 내부로 진행되나요(목차에 안 갇힘)?

□ 점프 후 스크린 리더가 대상 섹션을 읽기 시작하나요?

❓ FAQ

Q1. 화면이 스크롤되면 충분하지 않나요? 마우스 사용자에겐 충분하지만, 키보드·스크린 리더 사용자는 초점이 안 따라오면 점프 결과를 못 씁니다. Q2. 앵커 링크면 자동으로 초점도 가지 않나요? 브라우저마다 다릅니다. 일관성을 위해 tabindex="-1" + focus()로 명시 관리가 권장됩니다. Q3. 왜 tabindex="-1"인가요? 섹션 제목은 원래 포커스 대상이 아니라, 프로그래밍 방식 포커스를 받게 하려면 -1이 필요합니다(일반 Tab 순서엔 안 들어감).

6. 마무리

CP-112의 메시지:

화면만 옮기면 반쪽 — 점프 시 키보드 초점도 해당 섹션으로 이동시켜라.

페이지 내 앵커 링크의 흔한 함정입니다. 화면은 스크롤됐는데 초점이 목차에 남으면, 키보드·스크린 리더 사용자는 점프 결과를 못 씁니다. 대상 섹션에 tabindex="-1" + focus()로 초점을 옮겨야 점프가 완성되죠. CP-111의 실행 다음 단계입니다. 다음 편은 목차 그룹의 마지막 — <h1> 미사용입니다.

**다음 편 예고 ▶ 「233. (CP-113) 링크 목록에

을 사용하지 않고 있다.」**

ViewCheck는 콘텐츠 내 탐색 점프 시 키보드 초점이 대상 섹션으로 이동하는지를 진단합니다.

📚 참고 출처

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

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

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