마우스를 내려놓으면 보이는 UX: 디자이너를 위한 키보드 접근성

컬러 대비를 확인하고, 본문 크기를 조정하고, 이미지에 대체 텍스트를 넣었습니다. 이 정도면 접근성을 충분히 고려한 디자인일까요?

한 가지를 더 해보면 좋겠습니다. 마우스에서 손을 떼고, 키보드만으로 화면의 핵심 작업을 끝내보는 것입니다. 눈에 보이는 버튼에 도달할 수 있는지, 지금 어디를 조작하는지 알 수 있는지, 팝업을 닫고 원래 작업으로 돌아갈 수 있는지 확인해보세요.

이번 글은 W3C의 WCAG 2.2 해설과 WAI-ARIA 모달 대화상자 패턴을 바탕으로, UX/UI 디자이너가 키보드 경험을 어떻게 설계하고 점검할지 정리한 실무 큐레이션입니다. 새로운 규정 발표를 다루는 뉴스가 아니라, 기존 기준을 디자인 리뷰에 적용하기 위한 글입니다.

한 줄 요약

접근성은 화면을 잘 보이게 만드는 데서 끝나지 않습니다. 사용자가 원하는 곳에 도달하고, 현재 위치를 알고, 작업을 마칠 수 있어야 합니다.

1. 클릭할 수 있다는 것과 사용할 수 있다는 것은 다릅니다

카드 전체를 누르면 상세 페이지로 이동하는 목록을 떠올려보세요. 마우스로는 자연스럽지만, 키보드로 이동할 때 그 카드에 도달할 방법이 없다면 다른 사용자는 같은 작업을 할 수 없습니다.

WCAG의 2.1.1 Keyboard는 레벨 A 기준입니다. 자유롭게 그림을 그리는 것처럼 이동 경로 자체가 본질적인 일부 기능을 제외하면, 콘텐츠의 기능을 키보드 인터페이스로 조작할 수 있어야 한다는 요구입니다. 핵심은 모든 시각 요소에 무조건 Tab 정지점을 만드는 것이 아니라, 같거나 동등한 기능을 키보드로도 수행할 수 있게 하는 것입니다.

디자인 리뷰에서도 “이 카드가 눌리나요?”보다 “키보드 사용자는 상세 내용을 어떤 경로로 여나요?”라고 물어보는 편이 구체적입니다. 드래그로 순서를 바꾸는 목록이라면, 순서 변경을 수행할 키보드 경로도 함께 정의해야 합니다.

실무 제안: 인터랙션 명세에는 클릭 후 화면뿐 아니라, 키보드로 진입하고 실행하는 방법도 한 줄씩 적어두세요. 개발이 끝난 뒤 대체 동작을 끼워 넣는 것보다 처음부터 경로를 함께 설계하는 편이 명확합니다.

2. 포커스는 장식이 아니라 ‘현재 위치’입니다

Tab 키를 눌렀는데 화면에서 아무 변화가 보이지 않는다면, 다음 Enter 키가 무엇을 실행할지 알기 어렵습니다. 여기서 필요한 것이 포커스 표시입니다. 포커스는 현재 키보드 입력을 받는 위치를 뜻합니다.

WCAG 2.4.7 Focus Visible은 레벨 AA 기준으로, 키보드로 조작할 수 있는 인터페이스에 포커스 표시가 보이는 작동 모드가 있어야 한다고 설명합니다. 포커스가 보이는 동안 그 표시가 임의의 시간 제한으로 사라져서도 안 됩니다.

디자인 시스템에서 Default, Hover, Pressed, Disabled 상태를 만들면서 Focus 상태만 빠뜨리기 쉽습니다. 하지만 Hover는 마우스 포인터의 위치를, Focus는 키보드 조작의 위치를 알려줍니다. 두 상태를 같은 것으로 취급하면 키보드 사용자의 단서가 사라질 수 있습니다.

브랜드에 맞는 포커스 스타일을 만드는 것은 가능합니다. 다만 기본 테두리를 지운 뒤 대체 표시를 제공하지 않는 것은 다른 문제입니다. 밝은 배경, 어두운 배경, 이미지 위에서도 현재 위치를 식별할 수 있는지 확인해야 합니다.

참고로 포커스 표시의 크기와 형태 등을 더 구체적으로 다루는 2.4.13 Focus Appearance는 AAA 기준입니다. 이를 2.4.7의 AA 요구와 섞어 설명하지 않도록 주의해야 합니다.

3. 고정 배너 아래로 사라지는 버튼을 확인하세요

하단 구매 버튼, 상단 고정 내비게이션, 쿠키 안내 배너는 유용한 UI입니다. 동시에 다른 요소를 가리는 레이어이기도 합니다.

예를 들어 Tab으로 이동하는 중 포커스를 받은 링크가 하단 고정 배너 뒤에 완전히 숨었다고 해보겠습니다. 기능은 작동하더라도 사용자는 현재 어디에 있는지 놓칠 수 있습니다. “포커스 스타일을 만들었다”는 것만으로 해결되지 않는 문제입니다.

WCAG 2.2에 추가된 2.4.11 Focus Not Obscured (Minimum)은 AA 기준입니다. 기본 요구는 포커스를 받은 컴포넌트가 제작자가 만든 콘텐츠 때문에 완전히 가려지지 않는 것입니다. 일부가 가려지는 것은 이 최소 기준에서 허용되지만, 어느 부분도 가려지지 않도록 하는 더 높은 기준은 2.4.12의 AAA에 해당합니다. 사용자가 직접 연 콘텐츠 등에는 별도 조건이 있으므로 실제 적합성 판단은 원문을 확인해야 합니다.

디자이너의 관점: 최소 기준을 통과하는 것과 편하게 사용할 수 있는 것은 같지 않습니다. 고정 요소를 배치할 때는 콘텐츠가 보이는 영역뿐 아니라, 포커스를 받은 요소가 드러나는 영역도 함께 검토해보세요. 특히 작은 화면이나 확대 상태에서 레이어가 겹치는 상황을 확인하는 것이 좋습니다.

4. 모달은 ‘뜨는 화면’보다 ‘이동 경로’가 중요합니다

모달 시안에는 보통 제목, 입력창, 확인 버튼, 닫기 버튼이 들어갑니다. 하지만 정적인 화면만으로는 다음 질문에 답하기 어렵습니다.

• 모달을 열었을 때 키보드 입력의 시작점은 어디인가요?
• 열린 동안 배경의 링크나 버튼으로 이동하지 않도록 되어 있나요?
• 키보드로 닫거나 작업을 마칠 수 있나요?
• 닫힌 뒤에는 어느 위치에서 작업을 이어가나요?

W3C의 WAI-ARIA Authoring Practices Guide는 모달이 열린 동안 바깥 콘텐츠와 상호작용할 수 없고, Tab과 Shift+Tab의 이동도 모달 내부에 머무는 패턴을 설명합니다. 반투명 배경을 깔았다는 이유만으로 모달의 동작까지 완성되는 것은 아닙니다.

여기서 중요한 구분이 있습니다. 열린 모달 안에서 이동 범위를 유지하는 것과 닫을 방법 없이 사용자를 가두는 것은 다릅니다. 디자이너가 정의해야 할 것은 진입 화면 하나가 아니라, 진입·내부 이동·종료·복귀의 흐름입니다.

실무 제안: “알림 설정 버튼에서 진입 → 제목과 내용을 이해할 수 있는 위치에서 시작 → 설정을 변경하고 닫기 → 알림 설정 버튼으로 복귀”처럼 경로를 문장으로 남겨보세요. 시작점과 복귀점은 내용과 작업 맥락에 맞게 팀에서 결정하면 됩니다. 이는 원문의 문장을 옮긴 것이 아니라 디자인 명세를 위한 예시입니다.

5. 다음 디자인 리뷰에서 해볼 짧은 점검

전체 사이트를 한 번에 평가하기보다, 회원가입이나 검색처럼 핵심 작업 하나를 정해보세요. 아래 순서는 공식 인증 절차가 아니라, 문제를 빠르게 찾기 위한 실무 점검안입니다.

첫째, 도달하기. Tab과 Shift+Tab으로 이동하며 핵심 기능을 수행할 경로에 접근할 수 있는지 확인합니다. 복합 위젯은 화살표 키 등 별도 조작 방식을 사용할 수 있으므로 Tab만 눌러보고 결론 내리지는 않습니다.

둘째, 위치 알기. 매 단계에서 현재 포커스가 어디 있는지 확인합니다. 배경색이 바뀌거나 배너가 등장해도 표시와 대상이 보이는지 살펴봅니다.

셋째, 실행하기. 링크 이동, 버튼 실행, 입력, 선택, 제출까지 실제로 해봅니다. 일반적으로 버튼은 Enter나 Space, 링크는 Enter로 실행하는 등 요소에 맞는 관례를 확인합니다.

넷째, 돌아오기. 모달이나 추가 패널을 열고 닫은 뒤에도 작업 맥락을 잃지 않는지 확인합니다. 잘못 선택했을 때 취소하거나 수정하는 경로도 포함합니다.

발견한 문제는 “접근성 개선 필요”보다 “검색 필터를 닫으면 포커스가 페이지 처음으로 돌아가 결과 목록까지 다시 이동해야 함”처럼 기록하는 편이 좋습니다. 발생 위치, 재현 순서, 기대 동작이 드러나야 팀이 같은 문제를 해결할 수 있습니다.

이 점검만으로 WCAG 준수나 스크린 리더 접근성이 보장되는 것은 아닙니다. 의미 구조, 접근 가능한 이름, 상태 전달, 명암 대비 등 다른 기준과 보조기술 환경은 별도로 검토해야 합니다.

마무리: 화면이 아니라 사용 경로를 디자인하기

키보드 접근성을 개발 단계의 예외 처리로만 보면 마지막에 고쳐야 할 목록이 됩니다. 반대로 디자인 단계에서 함께 보면, 인터페이스가 제공해야 할 상태와 이동 경로가 더 분명해집니다.

좋은 화면은 보기 편한 화면이기도 하지만, 사용자가 자신의 방식으로 일을 끝낼 수 있는 화면이기도 합니다. 다음 리뷰에서는 시안을 더 확대하기 전에, 마우스를 잠시 내려놓아보면 어떨까요.

도달할 수 있는가. 지금 위치를 알 수 있는가. 끝내고 돌아올 수 있는가. 이 세 질문만으로도 정적인 시안에서는 놓쳤던 UX를 발견할 수 있습니다.

참고 자료

• W3C · Understanding SC 2.1.1: Keyboard
• W3C · Understanding SC 2.4.7: Focus Visible
• W3C · Understanding SC 2.4.11: Focus Not Obscured (Minimum)
• W3C · Understanding SC 2.4.12: Focus Not Obscured (Enhanced)
• W3C · WAI-ARIA APG: Dialog (Modal) Pattern

자료 확인일: 2026.09.18. 이 글은 공식 가이드의 핵심 내용을 요약하고 디자이너 관점의 실무 제안을 덧붙인 큐레이션입니다. WCAG의 성공 기준과 APG의 구현 패턴 안내는 성격이 다르며, 본문 예시와 점검 순서는 별도로 구성했습니다.
컬러 대비를 확인하고, 본문 크기를 조정하고, 이미지에 대체 텍스트를 넣었습니다. 이 정도면 접근성을 충분히 고려한 디자인일까요?

한 가지를 더 해보면 좋겠습니다. 마우스에서 손을 떼고, 키보드만으로 화면의 핵심 작업을 끝내보는 것입니다. 눈에 보이는 버튼에 도달할 수 있는지, 지금 어디를 조작하는지 알 수 있는지, 팝업을 닫고 원래 작업으로 돌아갈 수 있는지 확인해보세요.

이번 글은 W3C의 WCAG 2.2 해설과 WAI-ARIA 모달 대화상자 패턴을 바탕으로, UX/UI 디자이너가 키보드 경험을 어떻게 설계하고 점검할지 정리한 실무 큐레이션입니다. 새로운 규정 발표를 다루는 뉴스가 아니라, 기존 기준을 디자인 리뷰에 적용하기 위한 글입니다.

한 줄 요약

접근성은 화면을 잘 보이게 만드는 데서 끝나지 않습니다. 사용자가 원하는 곳에 도달하고, 현재 위치를 알고, 작업을 마칠 수 있어야 합니다.

1. 클릭할 수 있다는 것과 사용할 수 있다는 것은 다릅니다

카드 전체를 누르면 상세 페이지로 이동하는 목록을 떠올려보세요. 마우스로는 자연스럽지만, 키보드로 이동할 때 그 카드에 도달할 방법이 없다면 다른 사용자는 같은 작업을 할 수 없습니다.

WCAG의 2.1.1 Keyboard는 레벨 A 기준입니다. 자유롭게 그림을 그리는 것처럼 이동 경로 자체가 본질적인 일부 기능을 제외하면, 콘텐츠의 기능을 키보드 인터페이스로 조작할 수 있어야 한다는 요구입니다. 핵심은 모든 시각 요소에 무조건 Tab 정지점을 만드는 것이 아니라, 같거나 동등한 기능을 키보드로도 수행할 수 있게 하는 것입니다.

디자인 리뷰에서도 “이 카드가 눌리나요?”보다 “키보드 사용자는 상세 내용을 어떤 경로로 여나요?”라고 물어보는 편이 구체적입니다. 드래그로 순서를 바꾸는 목록이라면, 순서 변경을 수행할 키보드 경로도 함께 정의해야 합니다.

실무 제안: 인터랙션 명세에는 클릭 후 화면뿐 아니라, 키보드로 진입하고 실행하는 방법도 한 줄씩 적어두세요. 개발이 끝난 뒤 대체 동작을 끼워 넣는 것보다 처음부터 경로를 함께 설계하는 편이 명확합니다.

2. 포커스는 장식이 아니라 ‘현재 위치’입니다

Tab 키를 눌렀는데 화면에서 아무 변화가 보이지 않는다면, 다음 Enter 키가 무엇을 실행할지 알기 어렵습니다. 여기서 필요한 것이 포커스 표시입니다. 포커스는 현재 키보드 입력을 받는 위치를 뜻합니다.

WCAG 2.4.7 Focus Visible은 레벨 AA 기준으로, 키보드로 조작할 수 있는 인터페이스에 포커스 표시가 보이는 작동 모드가 있어야 한다고 설명합니다. 포커스가 보이는 동안 그 표시가 임의의 시간 제한으로 사라져서도 안 됩니다.

디자인 시스템에서 Default, Hover, Pressed, Disabled 상태를 만들면서 Focus 상태만 빠뜨리기 쉽습니다. 하지만 Hover는 마우스 포인터의 위치를, Focus는 키보드 조작의 위치를 알려줍니다. 두 상태를 같은 것으로 취급하면 키보드 사용자의 단서가 사라질 수 있습니다.

브랜드에 맞는 포커스 스타일을 만드는 것은 가능합니다. 다만 기본 테두리를 지운 뒤 대체 표시를 제공하지 않는 것은 다른 문제입니다. 밝은 배경, 어두운 배경, 이미지 위에서도 현재 위치를 식별할 수 있는지 확인해야 합니다.

참고로 포커스 표시의 크기와 형태 등을 더 구체적으로 다루는 2.4.13 Focus Appearance는 AAA 기준입니다. 이를 2.4.7의 AA 요구와 섞어 설명하지 않도록 주의해야 합니다.

3. 고정 배너 아래로 사라지는 버튼을 확인하세요

하단 구매 버튼, 상단 고정 내비게이션, 쿠키 안내 배너는 유용한 UI입니다. 동시에 다른 요소를 가리는 레이어이기도 합니다.

예를 들어 Tab으로 이동하는 중 포커스를 받은 링크가 하단 고정 배너 뒤에 완전히 숨었다고 해보겠습니다. 기능은 작동하더라도 사용자는 현재 어디에 있는지 놓칠 수 있습니다. “포커스 스타일을 만들었다”는 것만으로 해결되지 않는 문제입니다.

WCAG 2.2에 추가된 2.4.11 Focus Not Obscured (Minimum)은 AA 기준입니다. 기본 요구는 포커스를 받은 컴포넌트가 제작자가 만든 콘텐츠 때문에 완전히 가려지지 않는 것입니다. 일부가 가려지는 것은 이 최소 기준에서 허용되지만, 어느 부분도 가려지지 않도록 하는 더 높은 기준은 2.4.12의 AAA에 해당합니다. 사용자가 직접 연 콘텐츠 등에는 별도 조건이 있으므로 실제 적합성 판단은 원문을 확인해야 합니다.

디자이너의 관점: 최소 기준을 통과하는 것과 편하게 사용할 수 있는 것은 같지 않습니다. 고정 요소를 배치할 때는 콘텐츠가 보이는 영역뿐 아니라, 포커스를 받은 요소가 드러나는 영역도 함께 검토해보세요. 특히 작은 화면이나 확대 상태에서 레이어가 겹치는 상황을 확인하는 것이 좋습니다.

4. 모달은 ‘뜨는 화면’보다 ‘이동 경로’가 중요합니다

모달 시안에는 보통 제목, 입력창, 확인 버튼, 닫기 버튼이 들어갑니다. 하지만 정적인 화면만으로는 다음 질문에 답하기 어렵습니다.

• 모달을 열었을 때 키보드 입력의 시작점은 어디인가요?
• 열린 동안 배경의 링크나 버튼으로 이동하지 않도록 되어 있나요?
• 키보드로 닫거나 작업을 마칠 수 있나요?
• 닫힌 뒤에는 어느 위치에서 작업을 이어가나요?

W3C의 WAI-ARIA Authoring Practices Guide는 모달이 열린 동안 바깥 콘텐츠와 상호작용할 수 없고, Tab과 Shift+Tab의 이동도 모달 내부에 머무는 패턴을 설명합니다. 반투명 배경을 깔았다는 이유만으로 모달의 동작까지 완성되는 것은 아닙니다.

여기서 중요한 구분이 있습니다. 열린 모달 안에서 이동 범위를 유지하는 것과 닫을 방법 없이 사용자를 가두는 것은 다릅니다. 디자이너가 정의해야 할 것은 진입 화면 하나가 아니라, 진입·내부 이동·종료·복귀의 흐름입니다.

실무 제안: “알림 설정 버튼에서 진입 → 제목과 내용을 이해할 수 있는 위치에서 시작 → 설정을 변경하고 닫기 → 알림 설정 버튼으로 복귀”처럼 경로를 문장으로 남겨보세요. 시작점과 복귀점은 내용과 작업 맥락에 맞게 팀에서 결정하면 됩니다. 이는 원문의 문장을 옮긴 것이 아니라 디자인 명세를 위한 예시입니다.

5. 다음 디자인 리뷰에서 해볼 짧은 점검

전체 사이트를 한 번에 평가하기보다, 회원가입이나 검색처럼 핵심 작업 하나를 정해보세요. 아래 순서는 공식 인증 절차가 아니라, 문제를 빠르게 찾기 위한 실무 점검안입니다.

첫째, 도달하기. Tab과 Shift+Tab으로 이동하며 핵심 기능을 수행할 경로에 접근할 수 있는지 확인합니다. 복합 위젯은 화살표 키 등 별도 조작 방식을 사용할 수 있으므로 Tab만 눌러보고 결론 내리지는 않습니다.

둘째, 위치 알기. 매 단계에서 현재 포커스가 어디 있는지 확인합니다. 배경색이 바뀌거나 배너가 등장해도 표시와 대상이 보이는지 살펴봅니다.

셋째, 실행하기. 링크 이동, 버튼 실행, 입력, 선택, 제출까지 실제로 해봅니다. 일반적으로 버튼은 Enter나 Space, 링크는 Enter로 실행하는 등 요소에 맞는 관례를 확인합니다.

넷째, 돌아오기. 모달이나 추가 패널을 열고 닫은 뒤에도 작업 맥락을 잃지 않는지 확인합니다. 잘못 선택했을 때 취소하거나 수정하는 경로도 포함합니다.

발견한 문제는 “접근성 개선 필요”보다 “검색 필터를 닫으면 포커스가 페이지 처음으로 돌아가 결과 목록까지 다시 이동해야 함”처럼 기록하는 편이 좋습니다. 발생 위치, 재현 순서, 기대 동작이 드러나야 팀이 같은 문제를 해결할 수 있습니다.

이 점검만으로 WCAG 준수나 스크린 리더 접근성이 보장되는 것은 아닙니다. 의미 구조, 접근 가능한 이름, 상태 전달, 명암 대비 등 다른 기준과 보조기술 환경은 별도로 검토해야 합니다.

마무리: 화면이 아니라 사용 경로를 디자인하기

키보드 접근성을 개발 단계의 예외 처리로만 보면 마지막에 고쳐야 할 목록이 됩니다. 반대로 디자인 단계에서 함께 보면, 인터페이스가 제공해야 할 상태와 이동 경로가 더 분명해집니다.

좋은 화면은 보기 편한 화면이기도 하지만, 사용자가 자신의 방식으로 일을 끝낼 수 있는 화면이기도 합니다. 다음 리뷰에서는 시안을 더 확대하기 전에, 마우스를 잠시 내려놓아보면 어떨까요.

도달할 수 있는가. 지금 위치를 알 수 있는가. 끝내고 돌아올 수 있는가. 이 세 질문만으로도 정적인 시안에서는 놓쳤던 UX를 발견할 수 있습니다.

참고 자료

• W3C · Understanding SC 2.1.1: Keyboard
• W3C · Understanding SC 2.4.7: Focus Visible
• W3C · Understanding SC 2.4.11: Focus Not Obscured (Minimum)
• W3C · Understanding SC 2.4.12: Focus Not Obscured (Enhanced)
• W3C · WAI-ARIA APG: Dialog (Modal) Pattern

자료 확인일: 2026.09.18. 이 글은 공식 가이드의 핵심 내용을 요약하고 디자이너 관점의 실무 제안을 덧붙인 큐레이션입니다. WCAG의 성공 기준과 APG의 구현 패턴 안내는 성격이 다르며, 본문 예시와 점검 순서는 별도로 구성했습니다.