☰ 분류

접근성에서 먼저 볼 것을 짚는 프롬프트

어느 기준·법이 적용되는지는 단정하지 않습니다. 직접 테스트할 것을 따로 뺍니다.

분류디자인 › 화면·제품 설계
태그체크리스트검토분석
프롬프트 (영어 본문 · 답은 한국어로 옵니다)
Check this screen for accessibility problems I can fix.

⚠️ ***This is not a compliance audit and does not substitute for testing with assistive technology or for a professional review.*** **Do not state which standard or legal requirement applies** — those differ by country, sector, and date. Write `[confirm the applicable standard]`.

**Go through what my description can actually tell you:**
1. **Can it be done without a mouse?** ***Every action, in a sensible order, with the focus visible***
2. **Does anything rely on colour alone** — ***error states, status, required fields, chart series***
3. **Do images and icons carry meaning?** ***Then they need text.* **And a decorative one needs to be marked as decorative, not described**
4. **Is anything conveyed only by position or shape?**
5. **Time limits** — ***anything that disappears, auto-advances, or times out***
6. **Motion** — ***anything that moves, and whether it can be turned off***
7. **Form fields** — ***labels that persist, errors tied to the field, and what a screen reader would announce***
8. **Language and reading level** — the most overlooked one

**Then:**
- ***What I must test rather than reason about*** — **contrast ratios, screen reader output, zoom to 200%, actual keyboard order**
- **What to fix first** — ordered by how many people it blocks, not by how easy it is
- ***What my description does not let you check***

⚠️ ***You cannot see the screen. Work only from what I described*** — **do not assume a layout, a component, or a platform convention I did not state.** Where my description is not enough, **say what you would need to see.**
붙여 넣으면 맨 아래에 채울 칸(화면 설명 · 플랫폼)이 나옵니다

어떤 프롬프트인가

접근성 점검을 글로 하면 대비율이나 스크린리더 출력처럼 실제로 돌려봐야 아는 것을 추론으로 답하게 된다. 이 프롬프트는 그것들을 "직접 테스트할 것"으로 분리하고, 설명만으로 판단 가능한 것 — 마우스 없이 되는가, 색으로만 알리는가, 시간 제한이 있는가 — 부터 낸다. 적용 기준과 법은 나라·업종·시점마다 달라 단정하지 않는다.

모델 비교

ChatGPT가 가장 충실하고 신중하다. Gemini는 구체적이지만 장황하고 추정이 많으며, [C]는 답변이 없어 평가 최하위다.

ChatGPT종합 1위
45/ 50

+ 확정과 확인 필요 사항을 구분하며 요구 항목을 빠짐없이 다뤘다.

- 일부 결제 흐름을 추정했고 우선순위의 사용자 규모 근거가 약하다.

Gemini
39/ 50

+ 화면 요소별 문제와 구현 수준의 수정안을 구체화했다.

- 과도하게 길고 미확인 구현을 단정하며 일부 권고도 논쟁적이다.

기준ChatGPTGemini앞선 모델
지시 준수108ChatGPT +25%
정확성97ChatGPT +29%
구체성99동점
구성·가독성99동점
분량 적정성86ChatGPT +33%

gpt-5.6-sol가 모델 이름을 가린 채 1~10점으로 채점했습니다 (2026-09-25). 측정값이 아니라 AI 심사 결과입니다.

답 전문 보기

같은 입력을 세 모델에 넣어 받은 답을 그대로 옮겼습니다. 각 CLI(에이전트 하네스)에서 실행했습니다. ChatGPT·Claude 앱이나 웹에서는 답이 다를 수 있습니다.

넣은 입력
화면 설명: 결제 체크아웃 페이지입니다. 상단에 3단계 진행 표시줄(배송지 입력 → 결제수단 선택 → 주문확인)이 있고, 결제수단은 카드/계좌이체/카카오페이 중 하나를 라디오 버튼으로 고르게 되어 있습니다. 카드를 선택했을 때만 카드번호, 유효기간, CVC 입력 필드가 아래에 나타납니다. 결제 실패 시 입력 필드 테두리가 빨간색으로 바뀌면서 필드 위에 작은 빨간 글씨로 오류 메시지가 뜨고, 맨 아래 '결제하기' 버튼은 필수 항목을 다 채우기 전까지 회색으로 비활성화되어 있습니다. 주문 요약 카드에는 할인 전 가격은 취소선, 할인 후 가격은 굵은 빨간 글씨로 표시됩니다.

플랫폼: 반응형 웹 서비스, React + Tailwind CSS로 구현, 모바일 브라우저(사파리/크롬)와 데스크톱 크롬에서 주로 접속
gpt-5.6-luna (codex CLI · 에이전트 하네스) · 실행일 2026-09-24

설명만으로 판단하면, 가장 큰 위험은 키보드 사용자와 스크린 리더 사용자가 현재 단계·오류·동적으로 나타난 필드를 충분히 알 수 있는지입니다. 실제 화면과 코드 없이는 확정할 수 없는 항목은 별도로 표시하겠습니다.

1. 마우스 없이 모든 작업이 가능한가

사용자는 다음 순서로 완료할 수 있어야 합니다.

  1. 배송지 입력 단계의 모든 필드에 키보드로 이동
  2. 다음 단계로 이동
  3. 결제수단 라디오 그룹에 진입
  4. 방향키 또는 Tab으로 카드·계좌이체·카카오페이 선택
  5. 카드 선택 시 나타나는 카드번호·유효기간·CVC 필드로 자연스럽게 이동
  6. 오류가 발생하면 오류 위치로 이동하고 내용을 확인
  7. 주문확인 단계로 이동
  8. 결제하기 버튼에 도달해 실행
  9. 결제 실패 후 다시 입력하거나 재시도

확인할 문제:

  • 3단계 표시줄이 단순 텍스트인지, 현재 단계가 스크린 리더에도 전달되는지
  • 라디오 버튼을 키보드로 선택할 수 있는지
  • 카드 선택 후 새 필드가 나타날 때 포커스가 사라지거나 예상하지 못한 곳으로 이동하지 않는지
  • 결제 실패 후 포커스가 어디로 가는지
  • 비활성화된 결제하기 버튼까지 키보드로 도달할 수 없는 경우, 사용자가 왜 진행할 수 없는지 알 수 있는지
  • 모든 포커스에 충분히 눈에 띄는 표시가 있는지

disabled 상태의 버튼은 키보드 포커스를 받지 않고 이유도 알려주지 않을 수 있습니다. 필수 항목이 빠졌을 때 버튼을 계속 사용할 수 있게 하고 제출 시 오류를 안내하는 방식, 또는 현재 버튼이 비활성화된 이유를 별도로 제공하는 방식을 검토할 수 있습니다.

2. 색상에만 의존하는 정보

다음은 색상 외 단서가 필요합니다.

  • 결제 실패: 빨간 테두리와 빨간 글씨만으로 표시하지 말고, 오류 메시지와 오류 상태를 텍스트·프로그램 정보로도 연결
  • 필수 필드: 색상이나 별표만 사용하지 말고 필드 레이블 또는 안내문으로 명시
  • 할인 가격: 취소선과 굵은 빨간색만으로 의미를 전달하지 말고 할인 전 가격, 할인 후 가격 같은 텍스트를 제공
  • 진행 단계: 색상으로만 현재 단계나 완료 단계를 구분하지 말고 현재 상태를 텍스트로 제공

라디오 버튼의 선택 상태도 색상만 바뀌는 방식이면 안 됩니다. 실제 선택 상태, 테두리·아이콘·텍스트 등 다른 단서가 함께 있어야 합니다.

3. 이미지와 아이콘

설명에는 이미지나 아이콘이 언급되지 않았습니다. 따라서 존재 여부와 대체 텍스트 품질은 판단할 수 없습니다.

확인할 것:

  • 카드·계좌이체·카카오페이 로고가 있다면 로고 자체가 의미를 전달하는지, 적절한 이름이 제공되는지
  • 장식용 아이콘은 스크린 리더가 읽지 않도록 처리했는지
  • 오류 아이콘이 있다면 오류 메시지의 유일한 전달 수단으로 쓰이지 않는지
  • 버튼 안 아이콘이 있다면 버튼의 목적을 텍스트로도 알 수 있는지

4. 위치나 모양에만 의존하는 정보

현재 단계가 “위에서 몇 번째인지”, “빨간 테두리인지”, “굵게 보이는지”만으로 전달되면 부족합니다.

다음과 같은 표현이 함께 필요합니다.

  • 현재 단계: 결제수단 선택
  • 완료된 단계: 배송지 입력
  • 오류: 카드번호를 확인하세요
  • 할인 전 가격, 할인 후 가격

단계 표시줄이 클릭 가능한 탐색 요소라면 각 단계가 버튼인지 링크인지, 현재 단계인지, 이동 가능한지 명확해야 합니다. 단순 진행 표시라면 사용자가 위치를 알 수 있는 상태 설명이 필요합니다.

5. 시간 제한

설명에는 자동으로 사라지는 메시지, 자동 진행, 세션 만료, 결제 제한 시간이 언급되지 않았습니다.

다만 다음을 확인해야 합니다.

  • 결제 실패 메시지가 일정 시간 후 사라지는지
  • 결제 처리 중 일정 시간이 지나 자동으로 취소되는지
  • 결제수단 선택이나 단계가 자동으로 이동하는지
  • 세션 만료 전에 경고와 연장 방법이 제공되는지

사라지는 오류라면 사용자가 다시 확인할 수 있어야 합니다.

6. 움직임

설명에는 움직이는 요소가 없습니다. 카드 필드가 펼쳐질 때 애니메이션이 적용되는지, 결제 처리 중 로딩 애니메이션이 있는지는 확인할 수 없습니다.

움직임이 있다면:

  • 정보 확인이나 조작을 방해하지 않는지
  • 사용자가 줄이거나 끌 수 있는지
  • 로딩 상태가 애니메이션만으로 전달되지 않는지
  • 필드가 열릴 때 포커스가 갑자기 이동하지 않는지

7. 폼 필드와 오류

확인 및 수정이 필요한 부분입니다.

  • 카드번호, 유효기간, CVC에 항상 보이는 레이블이 있는가
  • 플레이스홀더만 레이블 역할을 하지 않는가
  • 필수 여부가 각 필드에 명확한가
  • 오류 메시지가 해당 필드와 프로그램적으로 연결되는가
  • 오류 메시지를 스크린 리더가 입력 필드와 함께 또는 즉시 들을 수 있는가
  • 오류가 여러 개일 때 첫 오류로 이동할 수 있는가
  • 입력 형식과 예시가 제공되는가
  • 카드 선택을 해제했을 때 카드 필드가 사라져도 입력값과 오류 상태가 혼란을 일으키지 않는가

예를 들어 스크린 리더는 다음처럼 들을 수 있어야 합니다.

카드번호, 필수, 편집창, 오류: 카드번호를 확인하세요.

단순히 빨간 테두리와 필드 위의 시각적 문구만으로는 충분하지 않을 수 있습니다. 오류가 발생하면 aria-invalid와 오류 메시지 연결 여부를 코드에서 확인해야 합니다.

라디오 그룹에도 그룹 이름이 필요합니다. 예를 들면:

결제수단, 라디오 그룹, 카드 선택됨, 3개 중 1개

8. 언어와 읽기 수준

결제 과정은 짧고 직접적인 문장을 사용해야 합니다.

  • 유효기간처럼 사용자가 이해할 수 있는 용어 사용
  • CVC가 무엇인지 필요한 경우 짧은 설명 제공
  • 오류 메시지는 “입력이 잘못되었습니다”보다 구체적으로 작성
  • 결제 실패 원인과 사용자가 할 일을 분리해 안내
  • 할인 가격에 실제 의미가 드러나는 레이블 제공
  • 한글 화면이라면 스크린 리더가 한국어로 읽도록 문서와 구성 요소의 언어 설정 확인
  • 영어 약어와 브랜드명은 읽기 방식이 어색하지 않은지 확인

예: 카드 정보를 확인해 주세요. 카드번호 16자리를 입력하세요.

직접 테스트해야 하는 것

설명만으로는 다음을 판단할 수 없습니다.

  • 실제 대비 비율
  • 실제 스크린 리더 출력
  • 200% 확대 시 잘림·겹침·가로 스크롤 발생 여부
  • 실제 키보드 이동 순서
  • 포커스 표시의 가시성
  • 오류 메시지와 필드의 실제 연결
  • 동적으로 나타나는 필드의 포커스 및 안내
  • 모바일 브라우저에서 가상 키보드와 자동완성 동작
  • 터치 대상의 크기와 간격
  • 결제 처리 중 상태와 중복 제출 방지
  • 세션 만료나 타임아웃 동작

최소한 키보드만으로 전체 결제 흐름을 실행하고, 스크린 리더를 켠 상태에서 단계·라디오 그룹·오류·결제 상태를 확인해야 합니다. 추가 판단이 필요하면 [confirm the applicable standard].

우선순위

  1. 오류 메시지를 해당 입력 필드와 연결하고, 오류 발생 후 포커스와 스크린 리더 안내를 보장
  2. 모든 필드와 라디오 그룹에 지속적인 레이블과 프로그램 정보를 제공
  3. 키보드만으로 단계 선택, 결제수단 선택, 동적 카드 입력, 제출과 재시도를 완료할 수 있게 수정
  4. 빨간색·굵기·취소선·위치에만 의존하지 않도록 상태와 가격 의미를 텍스트로 추가
  5. 비활성화된 결제하기 버튼 때문에 사용자가 막히지 않도록 누락된 필수 항목과 해결 방법 제공
  6. 포커스 표시, 확대, 모바일 입력, 시간 제한과 움직임을 실제 기기에서 검증

추가로 보려면 실제 화면 캡처, 키보드 이동 순서, 오류 발생 시 동작, 단계 표시줄의 구현 방식, 사용 중인 아이콘·로고, 그리고 해당 React 컴포넌트의 접근성 관련 코드를 확인해야 합니다.

같은 분류의 프롬프트

7대7 축구 팀 앱 설계 프롬프트
접근성 감사자 역할을 맡기는 프롬프트
접근성 감사자 역할 프롬프트
접근성 전문가 역할 프롬프트
접근성 테스트 워크플로 프롬프트