웹사이트 팝업·모달 접근성: 키보드와 포커스를 놓치지 않는 점검법
웹사이트 모달은 열릴 때 내부로 포커스를 옮기고, Tab 이동을 안에 유지하며, 닫힌 뒤 원래 버튼으로 돌려보내야 합니다. 기획·디자인·개발팀이 함께 확인할 순서를 정리했습니다.

읽기 전에 핵심만
- 좋은 모달은 열기, 내부 이동, 닫기 뒤 복귀까지 키보드 흐름이 끊기지 않습니다.
- 포커스 시작 위치는 첫 버튼이 아니라 사용자가 내용을 이해하고 안전하게 행동할 수 있는 곳으로 정해야 합니다.
- 기본 dialog 요소를 쓰더라도 실제 브라우저와 모바일에서 전체 사용자 여정을 다시 확인해야 합니다.
웹사이트 모달 접근성은 세 장면으로 점검하면 됩니다. 열었을 때 포커스가 모달 안으로 들어오는지, 열린 동안 키보드 사용자가 내용을 빠짐없이 조작할 수 있는지, 닫았을 때 원래 있던 자리로 돌아가는지 확인하세요. 배경을 어둡게 만드는 것만으로는 모달이 완성되지 않습니다.
먼저 팝업의 역할부터 나눈다
화면 위에 떠 보인다고 모두 모달은 아닙니다. 사용자가 지금 결정을 내려야 다음 작업으로 갈 수 있다면 모달이 맞습니다. 도움말이나 추가 설명처럼 본문을 계속 읽어도 되는 내용은 비모달 대화상자나 펼침 영역이 더 자연스럽습니다.
모달이 열리면 뒤쪽 페이지는 조작할 수 없는 상태가 되고, Tab과 Shift+Tab은 모달 내부에서만 움직여야 합니다. W3C의 ARIA Authoring Practices Guide(APG)는 Escape로 닫을 수 있게 하고, 열리는 순간 포커스를 모달 안의 적절한 요소로 옮기도록 안내합니다.[1]
다음 질문 중 하나라도 답하기 어렵다면 모달이 아닌 방식을 먼저 검토하세요.
- 이 창을 닫지 않고도 원래 페이지의 일을 계속해도 되는가?
- 내용이 길어서 작은 창 안에서 읽기 불편하지 않은가?
- 사용자가 취소하고 돌아갈 방법이 분명한가?
- 같은 정보를 별도 페이지나 펼침 영역으로 보여 주는 편이 단순하지 않은가?
열리는 순간의 포커스를 직접 확인한다
마우스로 모달을 열고 눈으로만 살피면 가장 흔한 결함을 놓칩니다. 키보드의 Tab 키로 열기 버튼까지 이동한 뒤 Enter 또는 Space로 여세요. 이때 포커스 표시가 모달 안에서 보여야 합니다.
처음 포커스를 어디에 둘지는 내용에 따라 달라집니다. 짧은 확인창은 주 작업 버튼이나 닫기 버튼이 적절할 수 있습니다. 설명이 길면 첫 버튼으로 바로 보내기보다 제목이나 첫 문단에 tabindex="-1"을 주고 그곳부터 읽게 하는 방법을 APG가 제시합니다.[1] 무조건 첫 번째 버튼을 고르지 말고, 사용자가 상황을 이해한 뒤 행동할 수 있는 위치를 정하세요.
모달을 열었는데 포커스가 주소창이나 배경 페이지에 남아 있다면, 키보드 사용자에게는 새 창이 나타난 사실 자체가 전달되지 않을 수 있습니다.
모달 안의 키보드 동선을 한 바퀴 돈다

W3C는 모달이 열린 동안 바깥 페이지를 비활성 상태로 두고, 모달을 닫으면 포커스를 열기 버튼이나 그다음의 논리적인 요소로 돌려보내는 사례를 설명합니다.[2] 실제 점검에서는 아래 순서를 한 번 끝까지 실행하세요.
Tab으로 모달 안의 모든 입력칸과 버튼을 순서대로 이동합니다.- 마지막 요소에서
Tab을 눌렀을 때 첫 요소로 돌아오는지 봅니다.[1] - 첫 요소에서
Shift+Tab을 눌러 마지막 요소로 이동하는지 확인합니다.[1] - 포커스 테두리가 배경색과 구분되고 화면에서 계속 보이는지 살핍니다.
Escape와 화면 안의 닫기 버튼을 각각 시험합니다.[1]
| 점검 장면 | 기대 결과 | 발견하기 쉬운 결함 |
|---|---|---|
| 모달 열기 | 포커스가 모달 안으로 이동 | 배경 버튼에 포커스가 남음 |
| Tab 이동 | 내부 요소를 논리적인 순서로 순환 | 닫기 버튼을 건너뜀 |
| 역방향 이동 | Shift+Tab도 내부에서 순환 | 포커스가 주소창으로 빠짐 |
| 모달 닫기 | 열기 버튼 또는 다음 작업으로 복귀 | 페이지 맨 위로 이동 |
모달 안에서 포커스를 순환시키는 것과 사용자를 가두는 것은 다릅니다. WCAG 2.2의 '키보드 함정 없음' 기준은 키보드만으로 구성 요소를 빠져나올 수 있어야 한다고 설명합니다. 모달 내부로 이동을 제한하는 경우에도 사용자가 닫는 방법을 알고 실행할 수 있어야 합니다.[3]
닫기와 취소를 같은 동작으로 보지 않는다
닫기 아이콘, 취소 버튼, 배경 클릭, Escape가 모두 같은 결과를 내는지 결정해야 합니다. 작성 중인 입력값이 있다면 배경을 한 번 눌렀다는 이유로 사라지지 않게 해야 합니다. 삭제나 결제처럼 되돌리기 어려운 작업은 기본 포커스를 실행 버튼에 두기보다 취소처럼 안전한 선택에 두는 편이 낫습니다.[1]
닫힌 뒤 포커스가 돌아갈 자리도 기획 단계에서 적어 두세요. 상품 옵션 모달이면 '옵션 선택' 버튼, 이미지 확대 모달이면 방금 본 썸네일, 삭제 완료 뒤 해당 항목이 없어졌다면 다음 목록 항목이 자연스럽습니다. 포커스 순서는 화면의 의미와 조작 순서를 보존해야 한다는 WCAG 기준에 부합해야 합니다.[2]
가능하면 기본 dialog 요소에서 시작한다
브라우저의
자주 묻는 질문
모달이 열리면 포커스는 어디에 두어야 하나요?
짧은 확인창은 첫 번째 조작 요소나 안전한 선택에 둘 수 있습니다. 설명이 길다면 제목이나 첫 문단처럼 내용을 이해하기 좋은 위치부터 읽게 하고, 바로 실행 버튼으로 건너뛰지 않는 편이 좋습니다.
모달에서 Tab 키가 밖으로 나가지 않게 해야 하나요?
네. 모달이 열린 동안 Tab과 Shift+Tab은 내부의 포커스 가능 요소를 순환해야 합니다. 대신 Escape나 닫기 버튼으로 모달을 종료할 수 있어야 하며, 종료 방법을 사용자가 알 수 있어야 합니다.
dialog 태그만 쓰면 모달 접근성이 해결되나요?
아닙니다. showModal()은 브라우저의 모달 동작을 활용하게 해 주지만, 적절한 제목과 시작 포커스, 닫기 방식, 포커스 복귀, 작은 화면의 스크롤은 제품 코드와 실제 사용 흐름에서 따로 확인해야 합니다.
모달을 닫은 뒤 포커스는 어디로 돌아가야 하나요?
대부분 모달을 연 버튼으로 돌아가는 것이 자연스럽습니다. 작업 완료로 그 버튼이 사라졌다면 다음 목록 항목이나 완료 메시지처럼 사용자가 이어서 조작할 수 있는 논리적인 위치를 정하세요.


