모든 링크는 키보드로 닿게

KRDS CP-261 — 비활성화, 사용불가 상태인 경우를 제외하고 모든 링크는 키보드로 접근하고 조작할 수 있도록 하고 있다.

0. 들어가며 — 마우스 없이 링크 누르기

이번 381편은 비활성 상태를 제외한 모든 링크를 키보드로 접근·조작할 수 있게 하라는 규칙입니다.

링크는 웹의 가장 기본 인터랙티브 요소입니다. 이것이 마우스로만 작동하면 — 키보드 사용자는 웹을 거의 못 쓰죠. CP-261은 모든 링크가 키보드로 닿고(Tab) 실행(Enter)되게 하라고 규정합니다. 구조화 목록 CP-148, 탭 CP-235와 같은 키보드 접근성의 가장 기본 규칙이죠. 이번 편을 풀어냅니다.

1. 규칙 원문 — 모든 링크 키보드 접근·조작

CP-261 (컴포넌트 > 링크) “비활성화, 사용불가 상태인 경우를 제외하고 모든 링크는 키보드로 접근하고 조작할 수 있도록 하고 있다.”

비활성 상태가 아닌 모든 링크를 키보드로 초점 이동(Tab)하고 실행(Enter)할 수 있게 구현하라는 뜻입니다.

정리: (비활성 제외) 모든 링크를 키보드로 접근·조작 가능하게 하라. 이게 CP-261입니다.

2. 왜 모든 링크가 키보드로 접근돼야 하나

키보드 접근성은 웹 접근성의 가장 기본 토대입니다(WCAG SC 2.1.1) — 마우스를 못 쓰는 사용자(운동 장애· 스크린 리더·스위치)는 키보드로 웹을 씁니다. 링크는 — 웹에서 가장 흔하고 기본적인 이동 수단이라, 키보드로 닿지 않으면 그 사용자는 웹 탐색 자체가 막히죠.

키보드로 링크를 쓰는 방식 — Tab으로 링크에 초점을 옮기고, Enter로 실행(이동)합니다. 이것이 작동하려면 링크가 표준 인터랙티브 요소여야 하죠:

표준 링크 <a href="..."> — href 속성이 있는 앵커는 기본적으로 키보드 포커스를 받고 Enter로 실행됩니다. 즉 링크를 표준 <a href>로 만들면 키보드 접근이 자동으로 됩니다. 그래서 대부분의 링크는 별도 처리 없이 충족되죠.

문제는 비표준 구현:

<a> without href — href 없는 <a>(또는 href="#"만)에 JavaScript 클릭만 붙이면 — 키보드 포커스를 못 받거나 동작이 어색하죠. 링크는 href에 실제 목적지를 넣어야 합니다.

<div>/<span> + onclick 링크를 <div>나 <span>에 클릭 이벤트만 붙여 만들면 키보드 포커스를 못 받아 Tab으로 닿지 않고, Enter 실행도 안 됩니다(구조화 목록 CP-148, 디스클로저 CP-174 정신). 마우스 전용 함정이죠. 링크는 <a>로, 동작 버튼은 <button>으로 표준 요소를 써야 합니다.

tabindex="-1" 오용 — 링크에 tabindex="-1"을 주면 키보드 초점에서 빠지죠. (의도적 제외가 아니면) 실수로 키보드 접근을 막습니다.

초점 표시도 함께. 키보드로 닿는 것만으론 부족하고 — 그 초점이 시각적으로 보여야(focus indicator) 키보드 사용자가 위치를 압니다(구조화 목록 CP-149 정신). outline:none만 하고 대체 스타일을 안 주면 초점이 안 보여 길을 잃죠. 링크에도 명확한 포커스 표시가 필요합니다.

‘비활성 제외’. 규칙은 ‘비활성화, 사용불가 상태 제외’를 명시합니다 — 의도적으로 비활성화한 링크(현재 쓸 수 없는)는 키보드 접근 대상에서 빠질 수 있죠. 다만 — 링크의 ’비활성’ 처리는 신중해야 합니다. 탭 사용 불가 배제 (CP-232)에서 봤듯, 이유 불명확한 비활성은 혼란을 주므로, 정말 필요한 경우에만 비활성화하고 그 상태를 명확히 전달하죠.

왜 ‘기본인데 규칙으로?’ 표준 <a href>면 자동 충족인데 왜 규칙일까요? — 실무에서 비표준 구현(div 클릭, href 없는 a, JS 라우팅 SPA) 이 흔하기 때문입니다. 특히 SPA(React 등)에서 라우팅을 잘못 구현하면 키보드 접근이 깨지기 쉽죠. 그래서 ‘모든 링크가 키보드로 되는지’ 점검이 필요합니다.

이 규칙은 링크의 ’기본 접근성’을 보장하고, CP-264(적절한 크기, 누르기 쉬움)·CP-265(스크린 리더 링크 인지)와 함께 링크를 모든 사용자가 쓰게 하죠.

정리하면 — 링크는 가장 기본적인 이동 수단이므로, 표준 <a href>로 만들어(비활성 제외) 모든 링크가 키보드로 닿고 실행되게 하고 초점을 보이게 해, 마우스를 못 쓰는 사용자도 웹을 탐색하게 해야 합니다.

3. 점검 / 개선

무엇을 점검하나

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

표준 요소 — 링크가 <a href="..."> 표준 앵커인가(div 클릭·href 없는 a 아님).

초점 표시 — 링크의 키보드 초점이 시각적으로 보이는가.

개선 방향

링크를 <a href="실제목적지">로 구현. div 클릭·href 없는 a 제거.

초점 표시 제공(:focus-visible). SPA 라우팅 링크 키보드 접근 점검.

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

역할	책임
퍼블리셔/개발	표준 <a href>·키보드 접근·초점 구현
접근성 담당	키보드만으로 전 링크 사용 검증

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

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

5. 30초 자가진단 + FAQ

✅ 30초 자가진단

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

□ 링크가 <a href="..."> 표준 앵커인가요(div 클릭·href 없는 a 아님)?

□ 링크의 키보드 초점이 시각적으로 보이나요?

❓ FAQ

Q1. <a href>면 자동으로 키보드 접근되나요? 네. 표준 앵커는 기본적으로 포커스·Enter 실행이 됩니다. <div onclick>·href 없는 <a>가 문제죠. Q2. SPA에서 링크가 키보드로 안 돼요. JS 라우팅을 표준 <a href> 기반으로 구현하고 키보드 접근을 점검 하세요. Q3. 비활성 링크는요? 의도적 비활성은 제외 가능하지만, 비활성 처리는 신중히 하고 상태를 명확히 전달합니다.

6. 마무리

CP-261의 메시지:

모든 링크는 키보드로 닿게 — (비활성 제외) 표준 <a href>로 키보드 접근·조작 가능하게.

링크는 가장 기본적인 이동 수단이라 키보드로 닿지 않으면 웹 탐색이 막힙니다. 표준 <a href>로 만들면 자동 충족되지만, div 클릭·SPA 라우팅 등 비표준 구현이 함정이죠. 초점 표시도 챙겨야 합니다. 다음 편은 링크 텍스트의 목적지 설명입니다.

다음 편 예고 ▶ 「382. (CP-262) 링크 텍스트는 링크 목적지 정보를 적절하게 설명할 수 있는 내용으로 제공하고 있다.」

ViewCheck는 모든 링크가 키보드로 접근·조작 가능한지를 진단합니다.

📚 참고 출처

KRDS 컴포넌트 — 링크(Link) 가이드 — https://www.krds.go.kr/html/site/component/component_24.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컴포넌트,웹표준