복사해서 쓰는 프롬프트 모음

역할: 웹 서비스 기획을 함께 정리하는 파트너.

만들려는 것: [아이디어를 한두 문장으로]

아래 여섯 항목으로 요구사항 문서를 작성해줘.
1. 한 문장 정의 — 이 서비스가 무엇인지
2. 주 사용자와 사용 상황 — 누가, 어떤 상황에서, 어떤 기기로 여는지
3. 핵심 과업 1~2개 — 사용자가 반드시 완료해야 하는 일
4. 화면 목록 — 핵심 과업에 필요한 최소한만
5. 이번에 만들지 않을 것 — 다음으로 미룰 기능
6. 완성 판정 기준 — 무엇이 되면 1차 완성인지, 확인 가능한 문장으로

작성 규칙
- 내가 답하지 않은 항목은 추측으로 채우지 말고 [미정]으로 두고,
  무엇을 정해야 하는지 질문으로 남겨줘.
- 화면 목록은 늘리지 말고 줄이는 쪽으로 제안해줘.
  빼도 되는 화면이 보이면 이유와 함께 알려줘.
- 사용자 정의에는 키보드만 사용하는 사람과 화면을 소리로 듣는 사람을
  포함해줘. 이 전제가 각 항목에 어떻게 반영됐는지 표시해줘.

출력: 여섯 항목을 소제목으로 나눈 문서.
끝에 '아직 결정하지 못한 것' 목록을 붙여줘.

역할: 배포를 처음 하는 사람에게 절차를 안내하는 조력자.
나는 명령어를 다뤄본 적이 거의 없어.

목표: 이 프로젝트를 인터넷에 올려서 링크로 다른 사람에게 보여주기.

순서대로 진행해줘.
1. 이 프로젝트가 정적 사이트인지 서버가 필요한지 판단하고,
   근거가 된 파일이나 코드를 알려줘.
2. 무료로 시작할 수 있는 호스팅 2~3곳을 비교해줘.
   비교 항목: 무료 범위, 상업적 사용 허용 여부, 도메인 연결 가능 여부,
   이 프로젝트와의 적합성. 표로 정리하고 하나를 추천해줘.
3. 추천한 곳 기준으로 배포 절차를 단계별로 안내해줘.
   각 단계마다 무엇을 하는 단계인지 한 줄 설명을 먼저 쓰고,
   그다음에 실행할 명령어나 클릭할 위치를 알려줘.
4. 배포 후 확인할 체크리스트를 만들어줘.
   접속 확인, 링크 동작, 모바일 화면, 주소창 자물쇠(HTTPS)를 포함해서.

진행 규칙
- 한 번에 한 단계씩만 안내하고, 내가 "다음"이라고 하면 이어서 진행해줘.
- 되돌리기 어려운 작업(도메인 구입, 유료 전환, 저장소 공개 설정 변경)은
  실행 전에 경고해줘.
- 내가 오류 메시지를 붙여넣으면 원인을 한 줄로 설명하고 해결 단계를 알려줘.
  추측이라면 추측이라고 표시해줘.

지금부터 이 프로젝트의 모든 UI 작업에 적용할 기준을 알려줄게.
앞으로의 모든 요청에 이 기준이 기본으로 적용돼.

목표
- 키보드만 사용하는 사용자와 스크린리더 사용자를 포함해
  누구나 전 기능을 사용할 수 있는 웹.
- 기준은 WCAG 2.2 AA, 국내 기준으로는 KWCAG 2.2.

항상 지킬 것
- 시맨틱 HTML 우선. 동작 실행은 button, 페이지 이동은 a href.
- 모든 이미지에 alt. 장식이면 alt=""로 명시.
- 모든 입력 필드에 label 연결. placeholder로 대신하지 않기.
- 텍스트와 배경의 명도 대비 4.5:1 이상.
- 색만으로 정보를 전달하지 않기. 아이콘이나 텍스트 병행.
- 포커스 표시 유지. 디자인 변경은 괜찮지만 제거는 금지.

작업 방식
- UI 코드를 만들거나 고칠 때마다 위 기준을 어떻게 지켰는지
  코드 아래에 목록으로 보고해줘.
- 내 요청이 이 기준과 충돌하면 그대로 진행하지 말고,
  충돌 지점과 대안을 먼저 알려줘.
- 지키기 어려운 부분이 있으면 임의로 우회하지 말고 이유를 설명해줘.

이 기준을 이해했으면 핵심만 요약해서 확인해주고,
이후 작업에 계속 적용해줘.

[만들 것]을 만들어줘.

화면의 목적
- 사용자가 이 화면에서 완료해야 하는 일: [핵심 과업]
- 반드시 담길 정보: [핵심 정보]

사용자 조건
- 키보드만 사용하는 사용자가 [핵심 동선]을
  처음부터 끝까지 완료할 수 있어야 해.
- 스크린리더 사용자가 [핵심 정보]를 순서대로 이해할 수 있어야 해.
- [이 화면에 특히 중요한 조건 1~2개]

만들 때 지킬 것
- 제목 구조(h1~h3)를 먼저 잡고 그 안에 내용을 배치해줘.
- 클릭 요소는 button 또는 a로. div에 클릭 이벤트를 붙이지 마.
- 내가 정하지 않은 결정(문구, 색상, 세부 배치)이 필요하면
  임의로 정하지 말고 물어봐줘.

완성 후 보고할 것
1. 적용한 접근성 처리 목록
2. Tab 키를 눌렀을 때의 포커스 이동 순서
3. 제목 구조를 h1부터 들여쓰기로 표시한 개요
4. 위 사용자 조건을 스스로 점검한 결과.
   확신이 없으면 '사람 확인 필요'로 표시해줘.

## 접근성 규칙 (모든 UI 작업에 적용)

이 프로젝트의 화면은 키보드만 사용하는 사용자와 스크린리더 사용자가
모든 기능을 사용할 수 있어야 한다. 아래 규칙은 예외 없이 적용한다.

### 구조
- 클릭 요소: 동작 실행은 <button>, 페이지 이동은 <a href>.
  div/span + onclick 금지. role과 tabindex로 흉내 내지 않는다.
- 제목은 <h1>~<h6>를 순서대로. 스타일 때문에 제목 레벨을 건너뛰지 않는다.
- 페이지 구조는 <header> <nav> <main> <footer> 랜드마크를 사용한다.

### 이미지·색
- 모든 <img>에 alt 작성. 정보가 있으면 내용을 설명하고,
  장식이면 alt=""(빈 값)로 둔다. 파일명을 alt에 넣지 않는다.
- 텍스트와 배경의 명도 대비는 4.5:1 이상(큰 텍스트 3:1).
- 색만으로 상태를 구분하지 않는다. 아이콘·텍스트를 병행한다.

### 폼·상호작용
- 모든 입력 필드에 <label>을 연결한다. placeholder로 label을 대신하지 않는다.
- 오류 메시지는 텍스트로 표시하고 해당 필드와 연결한다.
- 모달을 열면 포커스를 모달 안으로 옮기고, 닫으면 원래 위치로 되돌린다.
  ESC로 닫을 수 있게 한다.
- 포커스 표시(outline)를 제거하지 않는다. 디자인 변경은 허용, 삭제는 금지.

### 모바일·모션·문서
- 뷰포트에서 확대를 막지 않는다 (user-scalable=no, maximum-scale 금지).
- 양수 tabindex 금지. 글자 크기는 rem 단위, 본문 1rem(16px) 이상.
- 애니메이션에는 prefers-reduced-motion 대응을 포함한다.
- 문서에 lang="ko"와 페이지를 설명하는 <title>을 지정한다.
- 화면 갱신을 시각으로만 알리지 않는다. 상태 메시지는 role="status"로 함께 알린다.

### 작업 방식
- UI 코드를 생성·수정한 뒤에는 위 규칙 위반 여부를 스스로 점검하고,
  위반이 있으면 수정한 뒤 결과에 점검 내역을 표시한다.

역할: 시맨틱 HTML로 리팩터링하는 작업.
동작과 디자인은 그대로 두고 요소만 올바르게 바꾸는 게 목표야.

1단계 — 조사
클릭 이벤트가 달린 div와 span을 전부 찾아 표로 정리해줘.
| 파일:줄 | 현재 요소 | 하는 일 | 바꿀 요소 | 판단 이유 |
- 동작을 실행하는 것은 button type="button",
  페이지를 이동하는 것은 a href로 분류해줘.
- 애매한 것은 '확인 필요'로 표시하고 이유를 적어줘.

2단계 — 수정 (내가 승인한 뒤)
- 승인한 목록을 한 파일씩 수정하고 파일마다 변경 내용을 보여줘.
- 카드처럼 넓은 영역이 클릭되는 UI는 내부 제목을 링크로 만들고,
  클릭 영역만 CSS로 카드 전체에 확장해줘.
- role="button", tabindex, onkeydown으로 버튼을 흉내 내지 마.
- 기존 클래스와 스타일은 유지하고, 필요하면 버튼의 브라우저 기본
  스타일(테두리, 배경, 글꼴)만 초기화해줘.
- 요소가 바뀌면서 동작이 달라질 수 있는 부분은 미리 알려줘.

제약
- 클릭 요소가 아닌 div는 건드리지 마.
- 전체를 한 번에 수정하지 말고 파일 단위로 끊어서 진행해줘.

방금 수정한 파일들을 검증해줘.

클릭 가능한 요소를 전부 나열하고 다음 표로 정리해줘.
| 파일:줄 | 사용한 요소 | Tab 도달 | Enter 동작 | Space 동작 |
| 스크린리더가 읽는 역할 | 접근 가능한 이름 |

판정 규칙
- 코드를 근거로 판단하고, 실행해봐야 아는 항목은
  '코드상 추정'이라고 표시해줘.
- 하나라도 충족하지 못하는 요소는 원인과 수정안을 함께 제시해줘.
- 이름이 비어 있거나 "버튼", "클릭" 같은 무의미한 이름도 문제로 잡아줘.

마지막으로 이번 수정으로 새로 생겼을 수 있는 문제를 점검해줘.
중복된 포커스 대상, 링크 안의 버튼처럼 중첩된 조작 요소,
기존 이벤트 위임이 끊긴 곳이 있는지.

이 프로젝트의 대체 텍스트를 전수 점검해줘.
대상: 모든 img, 인라인 svg, 아이콘 폰트,
그리고 배경 이미지로 정보를 전달하는 요소.

1단계 — 분류표
| 파일:줄 | 이미지 | 분류 | 현재 alt | 제안 alt | 판단 근거 |

분류 기준
- 정보: 사라지면 정보가 사라진다. 사라지는 정보를 alt에 쓴다.
- 기능: 링크나 버튼 안에 있다.
  생김새가 아니라 눌렀을 때 일어나는 일을 쓴다.
- 장식: 사라져도 정보 손실이 없다. alt=""로 명시한다. 생략은 금지.

금지할 값
- 파일명, "이미지", "사진", "아이콘" 같은 무의미한 값
- 바로 옆 화면 텍스트와 그대로 중복되는 값

추가 규칙
- 이미지 안에 글자가 있으면 그 글자를 alt에 포함하고,
  실제 텍스트로 대체 가능한지 별도 열에 표시해줘.
- 장식용 svg는 aria-hidden="true",
  기능용 svg는 접근 가능한 이름을 부여해줘.
- 페이지 맥락을 모르면 지어내지 말고 '사람 확인 필요'로 표시해줘.

2단계 — 적용
표를 먼저 보여주고 내가 승인한 항목만 반영해줘.
적용 후 '사람 확인 필요' 목록을 따로 정리해줘.

이 프로젝트의 색 대비를 점검하고 고쳐줘.

1단계 — 진단
CSS에서 텍스트와 배경 색 조합을 전부 추출해 표로 만들어줘.
| 사용 위치 | 전경색 | 배경색 | 대비 비율 | 적용 기준 | 통과 여부 |
기준: 본문 4.5:1, 큰 텍스트(18pt 이상)와 UI 요소 경계 3:1.

2단계 — 수정안
미달 조합마다 다음 규칙으로 대안을 제시해줘.
- 색상(hue)은 유지하고 명도만 조정해 브랜드 색 계열을 지켜줘.
  조정 후 대비 값도 함께 적어줘.
- 그라데이션이나 이미지 배경 위 텍스트는 가장 불리한 지점을
  기준으로 판단하고, 필요하면 텍스트 뒤 반투명 배경층을 제안해줘.
- 색상 변수나 디자인 토큰이 있으면 개별 선언이 아니라
  변수 단위로 고치는 안을 우선 제시해줘.

3단계 — 색 단독 의존 점검
색만으로 상태를 구분하는 UI를 찾아줘.
상태 점, 차트 범례, 오류 표시, 필수 항목 표시 같은 것들.
각각에 아이콘, 텍스트, 무늬 중 무엇을 병행할지 제안해줘.

적용 전에 이 변경이 영향을 주는 화면 목록을 알려줘.
다크 모드가 있으면 두 모드 모두 점검해줘.

이 프로젝트의 키보드 접근성을 점검하고 고쳐줘.

점검 항목
1. 포커스 표시를 제거하는 CSS(outline: none, outline: 0)
2. 양수 tabindex
3. CSS(order, row-reverse, position)로 시각 순서와 DOM 순서가
   어긋난 구간
4. Tab으로 도달할 수 없는 조작 요소
5. 포커스가 들어가면 빠져나올 수 없는 위젯

발견 사항을 먼저 표로 보고해줘.
| 항목 | 파일:줄 | 현재 상태 | 문제 | 수정안 |

수정 규칙 (승인 후)
- 포커스 표시는 제거하지 말고 :focus-visible 기반으로 교체해줘.
  배경과 대비 3:1 이상, 두께 2px 이상, outline-offset으로 살짝 띄우기.
- 양수 tabindex는 DOM 순서 조정으로 해결해줘.
  구조를 바꿔야 하면 먼저 알려줘.
- 모달의 포커스 순환은 유지하되 ESC로 나갈 수 있는지 확인해줘.
  나갈 수단이 있으면 함정이 아니야.

수정 후 변경 내역을 파일별로 정리하고,
Tab 순서가 시각 순서와 일치하는지 화면별로 알려줘.

이 프로젝트의 모든 폼을 점검하고 고쳐줘.

1단계 — 필드별 진단표
| 폼 | 필드 | label 연결(for/id) | placeholder를 label로 쓰는지 |
| 필수 표시 방식 | autocomplete | 오류 메시지 위치와 연결 |

2단계 — 수정 규칙
- placeholder만 있는 필드는 보이는 label을 추가하고,
  placeholder는 형식 예시로만 남겨줘.
- 오류 메시지는 해당 필드 곁에 텍스트로 표시하고
  aria-describedby로 연결해줘.
  무엇이 왜 잘못됐고 어떻게 고치는지가 문장에 들어가야 해.
- 제출 시 첫 오류 필드로 포커스를 옮기고,
  이미 입력한 값은 절대 지우지 마.
- 필수 표시는 색이나 별표 단독으로 하지 말고
  required 속성과 텍스트를 병행해줘.
- 이름, 이메일, 전화번호, 주소 필드에 표준 autocomplete 값을 넣어줘.
- 글자 판독형 CAPTCHA가 있으면 대체 인증 수단을 제안해줘.
- 시간제한이 있으면 경고와 연장 수단이 있는지 확인해줘.

제약
- 폼의 제출 로직과 검증 규칙은 동작이 바뀌지 않게 유지해줘.
  바꿔야 한다면 이유를 먼저 설명하고 승인을 받아줘.

변경 전후 코드를 필드별로 보여주고,
마지막에 키보드만으로 폼을 완료하는 경로를 순서대로 설명해줘.

이 프로젝트의 모달, 팝업, 오버레이를 전부 점검하고 고쳐줘.

1단계 — 목록과 판단
| 위치 | 용도 | 현재 구현 방식 | dialog로 교체 가능 | 판단 이유 |

2단계 — 모달별 체크리스트
- 열릴 때 포커스가 모달 안으로 들어가는가
- Tab과 Shift+Tab이 모달 안에서 순환하는가
- ESC로 닫히는가
- 닫힐 때 포커스가 열었던 요소로 돌아가는가
- role="dialog"와 aria-modal="true"가 있는가
- aria-labelledby로 모달 제목과 연결됐는가
- 배경 콘텐츠가 inert 처리되는가
- 닫기 버튼에 "닫기"라는 접근 가능한 이름이 있는가

3단계 — 수정 (승인 후)
- 교체 가능한 것은 dialog 요소와 showModal()로 바꿔줘.
  기존 디자인과 애니메이션은 유지해줘.
- 교체가 어려운 것은 위 체크리스트를 하나씩 보완해줘.
- 사용자의 답이 반드시 필요한 경우가 아니면,
  모달 대신 페이지 안에서 처리하는 대안도 함께 제안해줘.

수정 전후로 같은 체크리스트 표를 보여줘.

이 프로젝트를 모바일 접근성 관점에서 점검하고 고쳐줘.

점검 항목
1. 뷰포트 메타태그의 user-scalable=no, maximum-scale 제한
2. 화면 방향을 고정하는 설정, CSS, 스크립트
3. 드래그, 스와이프, 길게 누르기, 흔들기로만 조작되는 기능
4. 호버에만 의존해 나타나는 콘텐츠(툴팁, 드롭다운, 숨은 버튼)
5. 터치 대상이 44×44px 미만이거나 이웃과 간격이 부족한 곳
6. 가로 스크롤이 생기는 구간

발견 사항을 표로 보고한 뒤 승인을 받고 수정해줘.
| 항목 | 위치 | 문제 | 수정안 | 데스크톱 영향 |

수정 규칙
- 확대 제한은 제거해줘. 레이아웃이 깨진다면 그 사실을 알려주고
  반응형으로 고치는 안을 제시해줘.
- 제스처 기능은 없애지 말고 단순한 탭 대안을 추가해줘.
  제스처는 지름길로 남겨두면 돼.
- 호버 콘텐츠는 포커스와 탭으로도 열리게 하고,
  열린 상태를 유지할 수 있게 해줘.
- 터치 대상은 아이콘을 키우지 말고 패딩으로 영역만 넓혀줘.

각 수정이 데스크톱 화면에 영향을 주는지 함께 확인하고,
영향이 있으면 적용 전에 알려줘.

역할: 이미 만들어진 서비스의 접근성을 진단하고
수리 계획을 세우는 컨설턴트.

1단계 — 진단
프로젝트 전체를 다음 유형으로 나눠 문제를 찾아줘.
가짜 버튼 / 무의미한 alt / 색 대비 / 키보드(포커스 표시·순서·함정) /
폼(label·오류) / 모달 / 모바일(뷰포트·제스처) /
문서 기본(lang·title·제목 구조)

각 문제에 표기할 것
| 문제 | 위치 | 공통 컴포넌트 여부 | 심각도 | 핵심 동선 해당 | 예상 범위 |
- 심각도: 차단은 그 사용자가 아예 못 쓰는 것,
  불편은 쓸 수는 있지만 힘든 것, 미관은 나머지.
- 핵심 동선은 가입, 로그인, 검색, 주문, 결제, 문의처럼
  서비스의 목적에 직결되는 경로야.

2단계 — 묶기
같은 원인에서 나온 문제를 묶어줘.
증상 개수가 아니라 원인 개수로 계획을 세울 거야.

3단계 — 수리 계획
"핵심 동선 × 공통 컴포넌트 × 차단"이 겹치는 것부터 정렬해
단계별 계획을 만들어줘. 한 단계는 한 컴포넌트 또는 한 원인으로 끊고,
각 단계마다 예상 변경 범위와 확인 방법을 적어줘.

지금은 진단과 계획만. 수정은 내가 승인한 뒤 단계별로 진행하자.

아래는 개발자도구 접근성 패널에서 복사한 이 요소의 정보야.

[role/name/state 붙여넣기]

내가 의도한 것은 "[예: 장바구니에 담는 버튼]"인데 일치하는지 판정해줘.
판정 기준
- role이 generic이면 실패다. 어떤 요소로 바꿔야 하는지 알려줘.
- name이 비어 있거나 "버튼", "링크" 같은 값이면 실패다.
- state가 코드의 실제 동작과 어긋나면(예: aria-expanded가 있는데
  토글되지 않음) 실패다.

실패한 항목마다 원인이 되는 코드와 수정안을 보여줘.
고친 뒤에는 트리에서 무엇이 어떻게 바뀌어야 하는지도 알려줘.
내가 다시 확인할 거야.

아래는 자동 검사 도구의 결과야. 아직 고치지는 말고 정리만 해줘.

[검사 결과 붙여넣기]

1. 같은 원인에서 나온 위반끼리 묶어줘.
   40건이 버튼 컴포넌트 하나 때문이면 1건으로 세는 방식으로.
2. 원인별로 표를 만들어줘.
   | 원인 | 위반 수 | 발생 위치 | 공통 컴포넌트 여부 | 심각도 |
3. '검토 필요(needs review)' 항목은 통과로 치지 말고 따로 모아서,
   내가 눈으로 무엇을 확인해야 하는지 한 줄씩 적어줘.
4. 핵심 동선([가입·결제 등 우리 서비스의 핵심])에 걸린 것을
   맨 위로 올려줘.

정리가 끝나면 어느 원인부터 고칠지 내가 정할게.

역할: 웹 접근성 전문 코드 리뷰어.
아래 컴포넌트를 WCAG 2.2 AA 기준으로 리뷰해줘.

[코드 붙여넣기]

출력 형식
| 심각도 | 위치 | 문제 | 근거 기준(WCAG 번호) | 영향받는 사용자 | 수정안 |

리뷰 관점 (다섯 가지를 빠뜨리지 말고 전부 확인)
1. 키보드: 도달, 조작, 순서, 함정
2. 이름과 역할: 스크린리더가 무엇으로 읽는지, 이름이 적절한지
3. 상태 전달: 열림·닫힘, 선택, 오류, 로딩을
   시각 외의 방법으로도 알리는지
4. 색과 대비: 색 단독 의존, 명도 대비
5. 구조: 제목 레벨, 목록, 폼 연결

규칙
- 수정안은 네이티브 HTML 우선.
  ARIA는 네이티브로 안 되는 경우에만 써줘.
- 문제가 없다고 판단한 관점도 다섯 가지 모두 '확인함'으로 표시해줘.
- 확신이 없는 항목은 '사람 확인 필요'로 분리하고,
  무엇을 확인해야 하는지 적어줘.
- 이 코드 바깥이 원인으로 의심되는 문제(전역 CSS, 공통 레이아웃,
  상위 컴포넌트)는 추정 위치와 함께 별도로 알려줘.
- 코드에 없는 동작을 상상해서 지적하지 마.

아래는 자동 검사 도구의 결과야.

[검사 결과 붙여넣기]

1. 위반을 같은 원인끼리 묶어줘. 증상이 몇 건이든 원인 단위로.
   | 원인 | 관련 위반 수 | 발생 위치 | 공통 컴포넌트 여부 | 근본 수정안 |
2. 공통 컴포넌트에서 나온 것과 개별 페이지 문제를 구분해줘.
   공통 컴포넌트부터 처리할 거야.
3. '검토 필요(needs review)' 항목은 통과로 처리하지 말고 따로 모아서,
   사람이 무엇을 확인해야 하는지 적어줘.
4. 내가 승인하면 원인 하나씩 수정하고,
   수정마다 어떤 위반들이 해소되는지 명시해줘.
5. 전부 끝나면 재검사에서 확인할 항목과, 자동 검사로는 확인할 수 없어
   직접 봐야 할 항목을 나눠서 알려줘.

제약
- 검사 도구가 지적하지 않은 부분까지 임의로 리팩터링하지 마.
- 위반을 숨기는 방식(aria-hidden 남용, 검사 제외 처리)으로
  해결하지 마.

이 프로젝트의 페이지 구조를 분석해
접근성 검사 대상 목록을 만들어줘.

1. 라우트를 전부 나열하고 템플릿 유형별로 분류해줘.
   같은 템플릿을 쓰는 페이지는 하나로 묶어줘.
2. 다음 다섯 그룹으로 표본을 제안해줘.
   - 공통 페이지: 홈, 로그인, 검색 결과처럼 모든 사용자가 지나는 곳
   - 핵심 과업 전 과정: [핵심 과업]의 시작부터 완료까지 모든 단계
   - 유형별 대표: 템플릿마다 하나씩, 콘텐츠가 가장 복잡한 것으로
   - 상태와 변형: 로그인 전후, 빈 목록, 오류 화면, 모바일 레이아웃
   - 무작위 2~3개: 위에서 뽑히지 않은 것 중에서
3. 표로 정리해줘.
   | 유형 | URL | 검사할 상태 | 이 표본을 고른 이유 |
4. 전체 라우트와 대조해서 어느 유형도 대표하지 못한 페이지가
   있는지 확인해줘.

이 목록은 다음 검사에서도 재사용할 거야.
페이지가 추가되면 어떤 기준으로 표본에 넣을지도 한 줄로 적어줘.

이 프로젝트에 접근성 자동 검사를 설정해줘.

시작 전에
우리 스택에 맞는 검사 도구 2개를 비교해줘.
비교 항목: 설치 난이도, 기존 테스트 환경과의 통합, 검사 범위,
유지보수 부담. 추천과 이유를 알려주고 내가 고르면 진행해줘.

설정할 것
1. 다음 페이지들에 대해 검사를 실행하는 테스트를 만들어줘:
   [검사 대상 목록]
2. 배포 전에 검사가 자동 실행되고,
   새 위반이 생기면 배포가 중단되게 해줘.
3. 기존 위반은 기준선으로 기록하고,
   기준선보다 늘어날 때만 실패로 처리해줘.
   기준선 파일은 버전 관리에 포함해줘.
4. 검사 결과를 위반별로 어떤 페이지의 어떤 요소에서 나왔는지
   알 수 있게 보고서로 남겨줘.
5. 조작해야 나타나는 화면(모달, 탭, 오류 상태)이 있으면
   그 상태를 만든 뒤 검사하는 테스트도 추가해줘.

검증
설정이 끝나면 일부러 위반을 하나 넣어서(alt 없는 img)
검사가 실제로 실패하는지 확인하고, 확인 후 되돌려줘.
한 번도 실패해본 적 없는 검사는 작동하는지 알 수 없어.

마지막으로 기준선을 낮춰가는 운영 방법을 세 줄로 정리해줘.

스크린리더로 [핵심 과업]을 처음부터 끝까지 해봤어.
겪은 일을 순서대로 적을게. 내가 들은 것과 겪은 것만 적었고,
원인은 짐작하지 않았어.

1. [예: 상품 목록에서 가격이 읽히지 않았다]
2. [예: 수량을 바꿨는데 아무 안내도 들리지 않았다]
3. [예: 결제 버튼에서 "버튼"이라고만 읽혔다]
4. [예: 오류가 났는데 포커스가 페이지 맨 위로 갔다]

각 항목에 대해
- 코드에서 원인으로 의심되는 곳을 찾아 파일과 줄로 알려줘.
- 원인이 여러 개 가능하면 가능성이 높은 순으로 보여줘.
- 수정안을 제시하되, 내가 승인하면 하나씩 고쳐줘.
- 고친 뒤 내가 스크린리더로 다시 확인할 항목을 알려줘.

마지막으로, 이 문제들이 다시 생기지 않게 할 규칙이 있으면
규칙 파일에 추가할 문장으로 제안해줘.

[동네 카페의 원데이 클래스 수강생 모집] 서비스를 만들려고 해.
코드는 아직 쓰지 말고, 기획을 한 장으로 정리해줘.

1. 이 서비스에 필요한 화면 목록 (한 페이지로 충분하면 그렇게 말해줘)
2. 사용자가 반드시 완료해야 하는 핵심 동선 한 가지
3. 각 화면에 들어갈 콘텐츠 목록 (제목, 문단, 표, 폼 필드 수준으로)
4. 사용자에게 받아야 하는 입력과 그 형식

내가 승인하면 다음 단계로 가자.

[아늑한 동네 카페] 분위기의 색 팔레트를 제안해줘.

- 본문 텍스트/배경, 강조 색, 버튼 색의 세 조합으로.
- 각 조합의 명도 대비 값을 함께 표로 보여줘.
- 본문 조합은 4.5:1, 큰 텍스트와 UI 요소는 3:1을 넘어야 해.
- 미달인 조합은 색상을 유지하고 명도만 조정한 대안을 함께 제안해줘.

글자 크기는 본문 16px 이상, 터치 대상은 44px 이상을 기본값으로 잡아줘.

원데이 클래스 모집 랜딩 페이지를 만들어줘.
정적 HTML과 CSS 한 파일로, 외부 라이브러리 없이.

담을 내용
- 클래스 소개: 제목, 설명, 강사
- 일정과 장소, 수강료
- 신청 폼: 이름, 연락처, 희망 날짜 선택, 문의 사항

사용자 조건
- 키보드만 사용하는 사용자가 페이지 진입부터 신청 완료까지
  막힘 없이 갈 수 있어야 해.
- 스크린리더 사용자가 클래스의 핵심 정보를
  무엇을, 언제, 어디서, 얼마에 순서로 들을 수 있어야 해.
- 본문 16px 이상, 명도 대비 4.5:1 이상, 터치 대상 44px 이상.
- 날짜 선택은 커스텀 달력 대신 네이티브 요소를 사용해줘.

완성 후 보고
1. 적용한 접근성 처리 목록
2. 제목 구조를 h1부터 들여쓰기로 표시한 개요
3. Tab 키 이동 순서
4. 사용한 색 조합과 각각의 대비 값

배포 전 점검이야. 이 프로젝트를 아래 목록으로 확인하고
항목마다 통과/미통과/사람 확인 필요로 표로 정리해줘. 수정은 아직 하지 마.

- 모든 클릭 요소가 button 또는 a인가
- 모든 이미지에 알맞은 alt가 있는가 (장식은 빈 alt)
- 모든 입력에 label이 연결되어 있는가
- 제목 구조가 h1부터 계단식인가
- lang과 title이 있는가
- 포커스 표시를 지운 CSS가 없는가
- 확대를 막는 뷰포트 설정이 없는가

이 프로젝트 전체를 접근성 관점에서 진단해줘.

유형별로 찾아줘: 가짜 버튼 / 무의미한 alt / 색 대비 /
키보드(포커스 표시·순서·함정) / 폼(label·오류) / 모달 /
모바일(뷰포트·제스처)

각 문제에 표기할 것
| 문제 | 위치 | 공통 컴포넌트 여부 | 심각도 | 핵심 동선 해당 |

그다음 같은 원인끼리 묶고,
"핵심 동선 × 공통 컴포넌트 × 차단"이 겹치는 것부터 정렬한
수리 계획을 세워줘. 한 단계는 한 원인으로 끊어줘.

지금은 진단만. 수정은 내가 승인한 뒤 하나씩 진행하자.

이 프로젝트의 페이지 구조를 분석해
접근성 검사 대상 목록을 만들어줘.

1. 페이지를 템플릿 유형별로 분류해줘.
2. 다섯 그룹으로 표본을 제안해줘: 공통 페이지 / 핵심 과업 전 과정 /
   유형별 대표 / 상태·변형(로그인 전후, 빈 목록, 오류) / 무작위 2~3개.
3. 표로 정리해줘: 유형, URL, 검사할 상태, 고른 이유.
4. 콘텐츠가 자주 바뀌는 페이지(공지, 배너, 상품 목록)를
   따로 표시해줘. 정기 검사에서 우선 대상이 될 거야.

이 목록은 다음 주기에도 재사용할 자산이야.
파일로 저장할 수 있게 정리해줘.