JiSoo's Devlog

⌨️ 키보드만으로 웹을 사용할 수 있을까? 본문

카테고리 없음

⌨️ 키보드만으로 웹을 사용할 수 있을까?

지숭숭숭 2025. 10. 14. 18:00

 

 

웹사이트를 만들면서 우리는 대부분 마우스로 클릭하고, 스크롤하고, 드래그하면서 페이지를 사용합니다.

하지만 이런 생각해 본 적 있으신가요?

 

"마우스 없이도 사용할 수 있을까?"

 

이 질문은 단순 호기심이 아니라 웹 접근성의 핵심이에요.

시각장애인, 단축키로 작업하는 개발자들까지 키보드만으로 웹사이트를 조작하는 사람들도 있어요.

 

그런데 현실에서는 마우스 없이 모든 기능이 가능한 사이트가 흔치 않아요.

버튼처럼 보이는데 클릭이 되지 않거나 포커스조차 이동하지 않는 요소들이 가득합니다.

 

 

 

🌟 왜 키보드 접근성이 중요할까요?

 

웹 접근성은 '누구나, 어떤 방식으로든 웹을 이용할 수 있게 하는 것'을 목표로 합니다.

즉, 입력 장치에 구애받지 않고 동일한 경험을 제공해야 해요.

 

키보드 접근성은 시각장애인을 위한 기능일 뿐만 아니라

웹 폼, 에디터, 개발 도구, 관리자 페이지 등 대부분의 환경이 이미 키보드 중심으로 설계되어 있어요.

 

W3C의 WCAG(Web Content Accessibility Guidelines)에서도

모든 인터랙션 요소는 키보드로 접근 가능해야 한다(Keyboard Accessible)”는 항목을 명시하고 있습니다.

 

마우스 없이도 완전히 작동하는 구조가 곧 접근성의 기본이며 사용자 경험과 SEO 모두에 긍정적인 영향을 줍니다.

 

 

🤷🏻‍♀️ div로 만든 버튼은 진짜 버튼일까?

버튼을 만들 때 <button> 태그를 사용할 때도 있지만 디자인 제약이나 스타일 문제로 <div>를 사용하는 경우도 종종 있는데요.

이 두 가지는 접근성 측면에서 큰 차이가 있어요.

<div onClick="alert('clicked!')" class="btn">버튼1</div>
<button onClick="alert('clicked!')">버튼2</button>

위의 두 코드는 겉보기엔 같아 보이지만

키보드로 접근하면 차이가 확실히 보입니다.

기능 <div> <button>
Tab 포커스
Enter 클릭
Space 클릭
스크린리더 텍스트 버튼

 

이런 차이는 단순한 편의성의 문제가 아니라 웹 접근성을 결정짓는 핵심 요소입니다.

 

시맨틱 태그는 브라우저가 이미 기본 상호작용을 내장하고 있기 때문에 사용자가 키보드만으로도 조작할 수 있게 만들어줍니다.

반면 <div>, <span> 같은 태그는 그저 레이아웃용 요소일 뿐이에요.

onClick 속성으로 클릭 가능하게 만들었다고 해도 키보드나 스크린리더 입장에서는 여전히 그냥 글자일 뿐이랍니다.

 

 

 

💻 키보드 접근 가능한 웹 만들기

그렇다면 어떻게 키보드만으로도 조작 가능한 웹을 만들 수 있을까요?

아래 원칙 4가지를 기억해 두면 됩니다!!

 

📍 1. 모든 인터랙션 요소는 Tab으로 포커스가 가능해야 합니다.

CSS에서 포커스 스타일을 지우지 말고 명확한 outline을 지정해줘야 해요.

:focus {
  outline: 2px solid #4a90e2;
  outline-offset: 2px;
}

사용자가 Tab으로 이동할 때 현재 포커스 위치가 눈에 보여야 해요.

outline: none;은 시각적 접근성을 크게 해칠 수 있어요.

 

📍 2. 시맨틱 태그 사용은 기본!

모두 잘 알고 계시겠지만

버튼은 <button> 링크는 <a> 입력은 <input> 등

이런 시맨틱 태그만 잘 써도 접근성의 80%는 해결된다고 합니다.

 

📍 3. 불가피하게 div를 써야 한다면 tabIndex로 포커스 추가하기

<div
  tabIndex="0"
  onkeydown="if(event.key === 'Enter') alert('Enter로 클릭됨!')"
>
  버튼
</div>

tabIndex="0"을 주면 Tab 키로 포커스 할 수 있고, onKeyDown으로 Enter키를 처리해 주면 키보드 사용자가 접근할 수 있어요.

 

📍 4. 포커스 순서와 시각 순서 맞추기

flex-direction: row-reverseposition: absolute로 시각 순서를 바꾸면 스크린리더가 엉뚱한 순서로 읽을 수 있어요.

DOM 구조 순서 → 탐색 순서

항상 HTML 구조가 논리적으로 자연스러운 흐름이 되게 설계해야 합니다.

 

 

 

📈 Lighthouse 접근성 테스트 결과 비교

같은 디자인의 버튼을 HTML만 다르게 작성했을 때 측정한 접근성 점수 비교입니다.

항목 비시맨틱 div 버튼 개선된 접근성 버튼
구조 <div class="btn"> <div role="button" tabIndex="0"><div class="btn">
Tab 이동 불가능 가능
Enter / Space 동작 안 됨 작동
Lighthouse 접근성 점수
경고 메시지 “Some elements are not focusable via keyboard”  없음

 

두 버튼이 시각적으로는 완전히 같지만 접근성 점수는 극명하게 다른 걸 볼 수 있습니다.

눈에 보이지 않는 접근성은 결국 웹의 신뢰도와 SEO 성능까지 연결된다는 걸 알 수 있어요.

 

 

 

🔗 참고

https://developer.mozilla.org/en-US/docs/Web/Accessibility/Guides/Understanding_WCAG/Keyboard

 

Keyboard accessible - Accessibility | MDN

If an element can be focused using the keyboard, then it should be interactive; that is, the user should be able to do something to it and produce a change of some kind (for example, activating a link or changing an option). Note: One important exception t

developer.mozilla.org

https://web.dev/articles/use-semantic-html?hl=ko

 

시맨틱 HTML을 사용하여 간편한 키보드 사용  |  Articles  |  web.dev

올바른 의미론적 HTML 요소를 사용하면 키보드 액세스 요구사항의 대부분 또는 전부를 충족할 수 있습니다. 따라서 tabindex를 조정하는 데 드는 시간을 줄이고 더 많은 사용자를 만족시킬 수 있습

web.dev

https://www.w3.org/WAI/WCAG22/quickref/?versions=2.1#keyboard-accessible

 

How to Meet WCAG (Quickref Reference)

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatic

www.w3.org

 

 

728x90