마우스 없이도 닿아야

KRDS CP-102 — 메뉴 링크는 키보드로 탐색할 수 있도록 구현되어 있다.

0. 들어가며 — 마우스를 못 쓰는 사용자

이번 222편은 사이드 메뉴 링크를 키보드만으로 탐색할 수 있게 하라는 규칙입니다.

마우스를 쓰지 못하는 사용자가 있습니다 — 운동 장애로 마우스 조작이 어려운 분, 스크린 리더 사용자(키보드 중심 조작), 보조 스위치 기기 사용자 등이죠. 이들은 Tab·화살표·Enter 같은 키보드로 웹을 씁니다. 사이드 메뉴 링크가 키보드로 닿지 않으면 — 이들은 메뉴를 아예 못 쓰죠. CP-102는 모든 메뉴 링크가 키보드로 접근·작동되게 하라고 규정합니다. 이번 편을 풀어냅니다.

1. 규칙 원문 — 키보드 탐색 가능

CP-102 (컴포넌트 > 사이드 메뉴) “메뉴 링크는 키보드로 탐색할 수 있도록 구현되어 있다.”

사이드 메뉴의 모든 링크에 키보드로 초점을 이동(Tab 등) 하고 실행(Enter) 할 수 있어야 하며, 마우스 없이도 메뉴 전체를 사용할 수 있게 구현하라는 뜻입니다.

정리: 메뉴 링크는 키보드만으로 이동·실행 가능해야 한다. 이게 CP-102입니다.

2. 왜 키보드 탐색이 필수인가

키보드 접근성은 웹 접근성의 가장 기본 토대입니다(KWCAG ‘키보드 사용 보장’, WCAG SC 2.1.1 Keyboard). 이유는 키보드가 가장 보편적인 대체 입력 수단이기 때문이죠:

운동 장애 사용자 — 손 떨림·마비 등으로 마우스의 정밀한 포인팅이 어려운 분들은 키보드(또는 키보드를 모방하는 보조기기)로 조작합니다.

스크린 리더 사용자 — 화면을 못 보니 마우스 포인터를 겨냥할 수 없습니다. Tab으로 요소를 순회하며 듣고 Enter로 실행하죠.

보조 스위치·음성 제어 — 스위치 기기나 음성 명령도 결국 키보드 인터페이스를 통해 작동하는 경우가 많습니다.

파워 유저 — 마우스를 쓸 수 있어도 키보드가 더 빠른 사용자도 있습니다.

사이드 메뉴 링크가 키보드로 닿으려면 — 포커스를 받을 수 있는 요소여야 합니다. 표준 <a href="..."> 링크나 <button>은 기본적으로 키보드 포커스를 받고 Enter/Space로 실행되므로, 메뉴를 이 표준 요소로 만들면 대부분 자동 충족됩니다. 문제는 비표준 구현이죠 — <div>나 <span>으로 클릭만 처리하면, 이런 요소는 기본적으로 포커스를 못 받아 Tab으로 닿지 않고 Enter로 실행도 안 됩니다. 마우스로만 작동하는 ’함정’이 되죠.

그래서 핵심은 — 메뉴 링크를 시맨틱 인터랙티브 요소(<a>, <button>)로 만드는 것입니다. 부득이 <div>/ <span>을 써야 한다면 tabindex="0"으로 포커스를 받게 하고, 키보드 이벤트(Enter/Space) 핸들러를 직접 붙여야 하지만 — 표준 요소를 쓰는 편이 훨씬 안전하고 권장됩니다.

또 키보드로 닿더라도 지금 어디에 포커스가 있는지 보여야(포커스 표시, focus indicator) 키보드 사용자가 위치를 압니다 — outline을 제거(outline:none)하고 대체 스타일을 안 주면 포커스가 ‘보이지 않게’ 되어 키보드 사용자가 길을 잃죠. 포커스 가시성은 키보드 탐색의 짝입니다.

이 규칙은 다음 편들과 묶입니다 — CP-102가 ‘키보드로 닿을 수 있다(접근)’, CP-103이 ‘닿는 순서가 계층대로다 (순서)’, CP-104가 ‘펼침 상태가 보조기술에 전달된다’, CP-105가 ‘숨긴 메뉴는 키보드에서도 빠진다’. 함께 사이드 메뉴의 키보드·보조기술 조작 완결성을 이룹니다.

3. 점검 / 개선

무엇을 점검하나

Tab 도달 — 모든 메뉴 링크에 Tab으로 포커스가 가는가.

Enter 실행 — 포커스된 링크가 Enter로 실행되는가.

포커스 표시 — 현재 포커스 위치가 시각적으로 보이는가(focus indicator).

표준 요소 — 링크가 <a>/<button> 등 시맨틱 요소인가.

개선 방향

메뉴 링크를 <a href>/<button>로 구현(클릭 div 지양).

outline 제거 시 대체 포커스 스타일 제공(:focus-visible).

부득이 div 사용 시 tabindex="0" + 키 이벤트 핸들러.

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

역할	책임
퍼블리셔/개발	시맨틱 링크·키보드 작동·포커스 표시 구현
접근성 담당	키보드만으로 메뉴 전 항목 사용 검증

기관 유형	CP-102 적용
중앙행정기관(대표·운영) / 공공기관 / 지자체	✅ 필수 (사이드 메뉴 사용 시)

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

5. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 모든 메뉴 링크에 Tab으로 포커스가 가나요?

□ 포커스된 링크가 Enter로 실행되나요?

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

□ 링크가 <a>/<button> 같은 표준 요소인가요?

❓ FAQ

Q1. <a href>로 만들면 자동으로 키보드 접근되나요? 네. 표준 링크·버튼은 기본적으로 포커스·Enter 실행이 됩니다. <div onclick>이 문제죠. Q2. 포커스 테두리가 디자인을 해치는데 지워도 되나요? 그냥 지우면 키보드 사용자가 위치를 못 봅니다. 대체 스타일(:focus-visible)을 줘야 합니다. Q3. 마우스 사용자가 대부분인데 꼭 필요한가요? 키보드 접근은 법적 의무이자 다양한 사용자의 유일한 수단 입니다. 필수입니다.

6. 마무리

CP-102의 메시지:

마우스 없이도 닿아야 — 메뉴 링크는 키보드로 탐색·실행 가능해야 한다.

키보드 접근성은 웹 접근성의 기본 토대입니다. 운동 장애·스크린 리더·스위치 사용자는 키보드로 웹을 쓰죠. 메뉴를 표준 <a>/<button>로 만들면 대부분 자동 충족되고, 포커스 표시까지 갖춰야 완전합니다. 다음 편은 그 포커스가 ‘어떤 순서로’ 이동하는지입니다.

다음 편 예고 ▶ 「223. (CP-103) 키보드의 초점은 메뉴의 계층 순서대로 이동하도록 구현되어 있다.」

ViewCheck는 사이드 메뉴 링크가 키보드로 탐색·실행 가능한지를 진단합니다.

📚 참고 출처

KRDS 컴포넌트 — 사이드 메뉴(Side navigation) 가이드 — https://www.krds.go.kr/html/site/component/component_08.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컴포넌트,웹표준