튜토리얼
Claude Opus 5.5로 제품 페이지 대화상자 초점 고치기
Claude Opus 5.5로 제품 대화상자를 열기, 탐색, 닫기, 복귀라는 키보드 상태 흐름으로 검토하세요.
Claude Opus 5.5로 제품 대화상자를 열기, 탐색, 닫기, 복귀라는 키보드 상태 흐름으로 검토하세요. 화면 중앙에 잘 보여도 초점이 배경에 남거나 닫은 뒤 페이지 맨 위로 갈 수 있습니다. 컴포넌트와 실제 초점 기록을 제공해야 제안한 수정을 검증할 수 있습니다.
각 동작의 결과 정의하기
| 동작 | 기대 결과 | 수집할 증거 |
|---|---|---|
| 제품 사양 열기 | 유용한 대화상자 내용으로 초점 이동 | 열린 직후 활성 요소 |
| Tab 및 Shift+Tab | 모달 안에 초점 유지 | 처음과 마지막 접근 가능 컨트롤 |
| Escape 또는 보이는 닫기 버튼 | 대화상자 닫힘 | 이후 표시 상태와 활성 요소 |
| 열기 버튼이 사라진 뒤 닫기 | 논리적인 다음 위치로 이동 | 대체 위치와 선택 이유 |
W3C 모달 대화상자 패턴은 키보드 이동 범위와 초점 복귀를 설명합니다. 보통 대화상자를 연 요소로 돌아가며, 그 요소가 없어졌다면 작업 흐름에 맞는 위치를 선택합니다. 이는 동작 요건이며 일반 오버레이에 `aria-modal`만 붙이면 된다는 뜻이 아닙니다.
제품 사양의 초점 경로
가상의 머그 페이지에 '사양' 버튼, 긴 사양 대화상자, 바깥의 '장바구니 담기' 버튼이 있다고 가정하세요. 열 때 아래쪽 첫 링크로 건너뛰기보다 `tabindex="-1"`을 설정한 정적 제목으로 이동하는 편이 유용할 수 있습니다. 이 제목은 프로그램의 초점 대상이며 일반 Tab 순서에 추가 정류장을 만들지 않습니다. 짧은 확인 창이라면 관련 컨트롤이 더 적절할 수 있습니다.
경로를 사양 → 대화상자 제목 → 닫기 → 관리 안내 링크 → Tab 순환 후 닫기 → Escape 후 사양으로 적으세요. 정확한 순서는 문서에 따라 달라집니다. 제품 변경으로 원래 버튼이 사라졌다면 새 제품 제목이나 다음 관련 컨트롤을 대체 위치로 기록합니다. 단언을 통과시키려고 임의의 버튼으로 보내지 마세요. 이는 가상 테스트 상황이며 Opus 실행 기록이 아닙니다.
눈에 보이는 닫기 컨트롤을 유지하세요. 배경 클릭은 명확한 종료 버튼과 키보드 조작의 대안이 아닙니다. 새 구현은 네이티브 dialog 요소와 `showModal()`을 먼저 살펴보세요. 기존 라이브러리가 있다면 그 수명 주기와 초점 API를 유지하고 충돌할 수 있는 별도 초점 제한 코드를 덧붙이지 마세요.
완성된 수정 프롬프트
이 제품 대화상자의 키보드 수명 주기를 검토해 주세요. 컴포넌트, 사용 중인 대화상자 라이브러리 버전, 열기 버튼 코드, 관련 CSS, 열기·정방향 Tab·역방향 Tab·Escape·보이는 닫기 버튼의 초점 기록을 제공합니다. 실행 증거가 없으면 알 수 없음으로 표시하세요.
동작, 기대 초점, 관찰 초점 표를 만드세요. 초기 초점, 범위 제한, 닫기, 복귀 문제를 구분하세요. 초기 대상이 긴 정적 내용 또는 짧은 동작 대화상자에 맞는지 설명하세요. 기존 접근 가능한 이름, 보이는 닫기 버튼, 컴포넌트 API를 유지하세요. aria-modal만으로 배경이 비활성화된다고 가정하지 마세요.
현재 라이브러리 또는 네이티브 dialog 동작으로 최소 수정을 제안하세요. 호출 요소가 삭제된 경우 명시적이고 논리적인 복귀 위치를 정하세요. 패치와 일반 닫기 및 호출 요소 삭제 상황의 키보드 점검을 반환하세요. 실제 로그 없이 보조 기술을 테스트했다고 주장하지 말고 필요하다는 증거 없이 전체 화면을 교체하지 마세요.공식 Opus 안내는 맥락과 명확한 요구를 제공하는 참고 자료입니다. 여기서는 검토 방법을 제안하며 모델이 점검을 통과했다고 주장하지 않습니다.
열기뿐 아니라 돌아오는 경로 검증하기
실제 앱에서 키보드로 경로를 실행하세요. 반복 열기와 닫기, 역방향 Tab, 가장 긴 내용, 호출 버튼을 없애는 상태 업데이트도 포함합니다. 단계마다 초점 표시를 확인하세요. DOM에 대화상자가 있다는 단언만으로 배경 접근 차단이나 올바른 복귀를 증명할 수 없습니다. 실제 수행한 보조 기술 검증에는 브라우저와 보조 기술 버전을 기록하세요.
자주 묻는 질문
**항상 첫 버튼에 초점을 줘야 하나요?** 아닙니다. 긴 구조적 내용에는 정적 시작점이, 파괴적인 확인에는 영향이 적은 동작이 적합할 수 있습니다.
**배경을 눌러 닫으면 충분한가요?** 아닙니다. 명확한 닫기 컨트롤과 해당 창에 맞고 검증된 키보드 종료 경로가 필요합니다.
**자동 초점 기록만으로 접근성을 인증할 수 있나요?** 특정 회귀를 잡을 수 있지만 이름, 읽기 순서, 실제 보조 기술 동작 확인을 대신하지 못합니다.
상호작용 수정 후 캠페인 작업하기
제품 페이지가 정상 작동하면 승인된 제품 사진과 메시지로 Panelly Studio에서 광고 변형을 만드세요. 대화상자 탐색이 아닌 제출 실패 문제는 별도의 폼 오류 복구 흐름을 참고하세요. Panelly는 여기서 창작 작업 공간이며 Opus 통합을 주장하는 것이 아닙니다.
