모달 포커스 트랩, AI 코드에서 최소 구현만 남기기
AI에게 모달 포커스 트랩을 시키면 라이브러리부터 권해요. 네이티브 dialog와 짧은 키보드 핸들러로 최소 구현만 남긴 과정을 정리했어요.
모달을 열었는데 Tab을 누르면 포커스가 배경으로 새어 나간 적, 혹시 없나요? 마우스로는 멀쩡해 보여도 키보드로만 쓰는 분에겐 길을 잃는 순간이에요.
이번에 플랜비(plan-b) 전술보드에서 멤버 편집 모달을 손보다가, AI에게 "포커스 트랩 붙여줘"라고 시켜봤어요. 결과가 생각보다 과했습니다.
AI는 거의 항상 라이브러리부터 권해요
돌려 보니 모델은 포커스 트랩 전용 패키지 설치나, 40줄 남짓 되는 이벤트 리스너 코드를 먼저 내밀었어요. 동작은 하지만 모달 하나 때문에 의존성이 하나 더 늘어나는 게 걸렸죠.
그래서 프롬프트를 이렇게 바꿔봤어요. "새 의존성 없이, 네이티브 기능부터 확인해서 최소 코드로." 관점을 좁혀 주니 답이 달라졌어요.
네이티브 dialog가 절반을 가져가요
<dialog> 요소를 showModal()로 열면 포커스가 자동으로 모달 안에 갇혀요. Tab 순환, Escape 닫기, 닫을 때 원래 버튼으로 포커스 복귀까지 브라우저가 처리해요. 직접 만들어 보니 여기까지는 추가 코드가 0줄이었어요.
커스텀 모달이면 세 가지만
디자인 때문에 <dialog>를 못 쓸 때만 손으로 만들어요. 테스트해 보면 필요한 건 세 가지뿐이에요.
- 포커스 가능한 요소 목록 구하기 (
a[href], button, input, select, textarea, [tabindex]:not([tabindex="-1"])) - Tab이 마지막 요소를 넘어가면 첫 요소로, Shift+Tab이 첫 요소 앞이면 마지막으로 되돌리기
- 열 때 첫 요소에 포커스, 닫을 때 원래 요소로 복귀
이 조건을 프롬프트에 그대로 박아두니, 적용해 봤더니 15줄 안쪽으로 정리됐어요.
- 포커스 목록 수집
- Tab 양방향 순환
- 열고 닫을 때 포커스 이동
AI에게 맡길 때의 요령
검증까지 모델에 맡기지 않는 게 좋아요. 코드를 받으면 직접 키보드로만 모달을 열고 Tab을 끝까지 눌러봐요. 5분이면 새는 지점이 보여요. AI는 그럴듯한 코드를 잘 만들지만, 실제로 갇히는지는 사람이 눌러봐야 알 수 있거든요.
정리하면 프롬프트에 "네이티브 우선·새 의존성 금지" 한 줄을 넣는 것만으로 결과물이 훨씬 담백해져요. 작은 도구일수록 이 습관이 반복을 줄여줘요.
관련 글
댓글
아직 댓글이 없어요. 첫 댓글을 남겨주세요.