모달을 닫은 뒤 포커스 돌려주기, 리뷰에서 함께 확인할 질문
모달을 닫은 뒤 키보드 포커스가 사라지면 사용자가 작업 위치를 잃는다. 코드 밖의 맥락 전달하기를 중심으로 작은 예제와 확인 기준을 정리합니다.
모달을 닫은 뒤 키보드 포커스가 사라지면 사용자가 작업 위치를 잃는다.
작성자에게 당연한 전제도 리뷰어에게는 보이지 않을 수 있다. 파일의 차이만 보여 주면 변경 이유와 확인 범위를 추측하게 된다. 이번 기록에서는 결과를 판단하는 데 필요한 맥락을 짧게 전달하고, 질문이 실제 개선으로 이어지도록 확인 순서를 정리한다.
코드 밖의 맥락 전달하기
열기 직전의 포커스 위치를 저장하고 모달을 닫을 때 복원한다. 모달 내부의 포커스 이동 범위와 Escape 동작도 실제 키보드 탐색으로 확인한다.
이번에 확인할 질문: 리뷰어가 변경 이유와 남아 있는 제약을 코드만 추측하지 않고 이해할 수 있는가?
작게 확인하는 예제
다음 예제는 핵심 조건을 드러내기 위한 출발점이다. 서비스의 전체 구현을 대신하지 않으므로 실제 입력 범위와 실패 처리 규칙을 함께 읽어야 한다.
const opener = document.activeElement;
function restoreFocus() {
if (opener instanceof HTMLElement && opener.isConnected) {
opener.focus();
}
}
// 모달이 완전히 닫힌 뒤 restoreFocus()를 호출한다.
키보드로 열기 버튼부터 모달 닫기까지 이동한 뒤 원래 버튼으로 포커스가 돌아오는지 확인한다.
놓치기 쉬운 조건
포커스 복원만으로 접근 가능한 모달이 완성되지는 않는다. 배경 콘텐츠의 상호작용 차단과 내부 포커스 순환을 함께 다뤄야 한다.
| 확인할 부분 | 살펴볼 내용 |
|---|---|
| 기준 동작 | 키보드로 열기 버튼부터 모달 닫기까지 이동한 뒤 원래 버튼으로 포커스가 돌아오는지 확인한다. |
| 비교 조건 | 입력과 실행 순서를 고정하고 한 번에 한 조건만 바꾼다. |
| 적용 범위 | 예제가 생략한 의존성과 실제 서비스의 제약을 구분한다. |
다음 변경에 적용할 순서
- 이번 변경이 해결하는 구체적인 상황을 먼저 설명한다.
- 재현 예제와 확인한 결과를 한곳에서 볼 수 있게 남긴다.
- 취향에 대한 제안과 지켜야 할 계약의 위반을 구분한다.
리뷰는 작성자의 지식을 시험하는 자리가 아니라 변경을 함께 책임지는 과정이다. 답변이 반복되는 질문은 설명이 부족한 신호일 수 있다. 대화가 끝난 뒤 가장 중요한 전제를 코드 가까이 남기면 다음 리뷰의 질문도 더 구체적이 된다.
이 이야기가 도움이 되었나요?