☰ Categories

Accessibility Auditor

an Accessibility Auditor who is a web accessibility expert and experienced accessibility engineer.

CategoryDesign › Product design
TagsReviewingAnalyzingDeveloperChecklist
Prompt
I want you to act as an Accessibility Auditor who is a web accessibility expert and experienced accessibility engineer. I will provide you with the website link. I would like you to review and check compliance with WCAG 2.2 and Section 508. Focus on keyboard navigation, screen reader compatibility, and color contrast issues. Please write explanations behind the feedback and provide actionable suggestions.

What this prompt does

This role-play is for checking web accessibility issues and receiving actionable suggestions. It asks to review a website link, but does not specify using automated testing tools.

Model comparison

Claude best balances transparency, specificity, and length, while ChatGPT is accurate but verbose. Gemini offers rich examples but resembles an actual audit and includes inaccurate contrast figures.

ClaudeTop overall
45/ 50

+ Disclosed assumptions and gave concrete fixes by focus area.

- Gives limited treatment to Section 508 scope and assessment.

ChatGPT
42/ 50

+ Clearly disclosed the access failure and audit limitations.

- Somewhat long and repetitive for a non-empirical checklist.

Gemini
34/ 50

+ Links user impact to practical, implementation-level examples.

- Omits access limits and asserts issues and some incorrect ratios.

CriterionChatGPTClaudeGeminiLeader
Instruction following997Tie
Accuracy996Tie
Specificity898Claude +13%
Structure998Tie
Right length795Claude +29%

Scored 1–10 by gpt-5.6-sol with model names hidden (2026-09-24). This is an AI review, not a measurement.

Read full answers

We gave three models the same input and copied their answers unedited. Each ran in its CLI (an agent harness), and answers in the ChatGPT or Claude apps or on the web may differ. Outputs are in Korean.

Input used
[Pasted material]
https://www.greenmarket-mall.co.kr — 유기농 식료품 쇼핑몰입니다. 특히 회원가입 폼, 상품 검색/필터 UI, 결제 페이지의 접근성이 걱정됩니다.
gpt-5.6-luna (codex CLI · 에이전트 하네스) · Run on 2026-09-24

접근성 감사 결과

현재 https://www.greenmarket-mall.co.kr은 브라우저와 네트워크 조회 모두 DNS 해석 실패(ERR_NAME_NOT_RESOLVED)로 접속되지 않았습니다. 따라서 실제 DOM, 키보드 포커스, 스크린 리더 트리, 색상값을 확인할 수 없어 사이트의 WCAG 2.2/Section 508 준수 여부를 확정할 수 없습니다.

이는 WCAG 위반으로 단정할 사항은 아니지만, 운영 중인 쇼핑몰이라면 최우선으로 확인할 장애입니다.

적용 기준

  • WCAG 2.2 A/AA를 주 기준으로 점검
  • Section 508은 적용 대상인 경우 WCAG 2.0 A/AA를 참조합니다. 따라서 WCAG 2.2 감사 결과와 Section 508 결과는 완전히 동일하지 않습니다. Section 508 공식 기준
  • 일반 텍스트 대비: 최소 4.5:1
  • 큰 텍스트 대비: 최소 3:1
  • 키보드 사용, 포커스 표시, 오류 식별, 입력 라벨 제공이 핵심입니다. WCAG 2.2 기준

우선 확인할 항목

1. 회원가입 폼 — 높음

다음 사항을 확인하고 수정해야 합니다.

  • 모든 입력창에 시각적이고 프로그래밍 가능한 <label> 제공
  • placeholder를 label 대신 사용하지 않기
  • 필수 입력은 색상만이 아니라 필수 문구와 required로 표시
  • 오류 발생 시 입력창에 aria-invalid="true" 적용
  • 오류 메시지를 aria-describedby로 연결
  • 제출 후 오류 요약으로 포커스를 이동
  • 이메일, 이름, 전화번호, 주소에 적절한 autocomplete 값 제공
  • 비밀번호 규칙을 입력 전 안내하고, 오류 시 구체적인 수정 방법 제공
  • 라디오·체크박스 그룹은 <fieldset>과 <legend> 사용
  • 약관 동의 항목은 각 체크박스의 이름과 링크가 스크린 리더에서 구분되어야 함

입력 오류를 색상이나 테두리만으로 표시하면 저시력 사용자와 스크린 리더 사용자가 오류를 알기 어렵습니다. WCAG 2.2는 오류 식별과 라벨·지시사항 제공을 요구합니다. 3.3.1 오류 식별, 3.3.2 라벨 또는 지시사항

2. 상품 검색·필터 — 높음

  • 검색 아이콘만 있는 버튼에는 상품 검색 같은 접근 가능한 이름 제공
  • 필터 열기 버튼은 aria-expanded, aria-controls 상태 제공
  • 필터 패널이 대화상자라면 열릴 때 포커스를 내부로 이동하고 닫힌 뒤 원래 버튼으로 복귀
  • 체크박스·라디오 버튼은 상품명, 가격대, 브랜드 등 명확한 label 제공
  • 선택된 필터와 제거 버튼을 함께 읽을 수 있도록 구성
  • 필터 적용 후 결과 수를 aria-live 영역으로 알림
  • 결과가 동적으로 바뀌어도 키보드 포커스가 사라지거나 페이지 상단으로 튀지 않게 처리
  • 정렬·페이지네이션 버튼에 현재 상태와 페이지 번호 제공
  • “초록색 상품”, “인기 상품”처럼 색상만으로 필터 의미를 전달하지 않기

키보드 사용자는 마우스 없이 필터 상태를 확인하고 수정할 수 있어야 하며, 스크린 리더 사용자는 결과 변경 사실을 별도 안내받아야 합니다.

3. 결제 페이지 — 매우 높음

결제는 여러 단계가 연결된 핵심 프로세스이므로 한 단계라도 접근성이 부족하면 전체 구매 과정이 실패할 수 있습니다. Section 508도 다단계 과정 전체가 준수되어야 한다고 설명합니다. Section 508 적합성 요구사항

확인할 항목:

  • 배송지, 연락처, 결제수단에 명확한 label과 autocomplete 제공
  • 단계 표시에서 현재 단계가 스크린 리더에 전달되도록 aria-current="step" 사용
  • 결제 오류가 발생하면 오류 필드와 원인을 텍스트로 안내
  • 잘못된 필드로 포커스를 이동하거나 오류 요약 제공
  • 카드 결제 iframe에는 제목과 접근 가능한 필드 이름 제공
  • 약관, 배송비, 할인, 최종 결제 금액을 제출 전에 검토 가능하게 제공
  • 제출 버튼을 눌렀을 때 중복 결제를 방지하되, 로딩 상태를 스크린 리더에 알림
  • 세션 만료 시간을 충분히 제공하고 연장 기능 제공
  • 이전 단계로 돌아가도 입력값이 불필요하게 사라지지 않게 처리
  • 결제 완료 후 주문번호, 결제 결과, 다음 단계가 텍스트로 전달되도록 구성

WCAG 2.2의 3.3.4 오류 예방(법률·금융·데이터)는 결제와 같은 중요한 제출 전에 검토·확인·취소 기회를 요구합니다.

키보드 점검 기준

사이트 접속이 복구되면 다음 순서로 직접 점검해야 합니다.

  1. Tab만 사용해 처음부터 결제 완료까지 이동
  2. 모든 링크, 버튼, 입력창에 포커스가 보이는지 확인
  3. Enter, Space, 방향키, Esc로 메뉴·필터·대화상자 조작
  4. 열린 필터나 모달에서 포커스가 빠져나가지 않는지 확인
  5. 닫은 뒤 포커스가 올바른 버튼으로 돌아오는지 확인
  6. 고정 헤더·쿠키 배너·채팅 버튼이 포커스를 가리지 않는지 확인
  7. Shift+Tab으로 역방향 이동
  8. 마우스 없이 검색, 상품 선택, 장바구니, 결제까지 완료

WCAG 2.2는 모든 기능의 키보드 조작과 키보드 트랩 방지를 요구합니다. 2.1.1 키보드, 2.1.2 키보드 트랩 없음

스크린 리더 점검 기준

다음 환경에서 확인하는 것이 좋습니다.

  • Windows: NVDA + Chrome
  • macOS/iOS: VoiceOver + Safari
  • Android: TalkBack + Chrome

특히 다음을 확인해야 합니다.

  • 페이지 언어가 lang="ko"로 지정되어 있는지
  • 제목 구조가 h1 → h2 → h3 순서로 의미 있게 구성되는지
  • header, nav, main, footer 랜드마크가 있는지
  • 아이콘 버튼 이름이 읽히는지
  • 상품명, 가격, 할인율, 재고 상태가 함께 읽히는지
  • 장바구니 수량 변경 결과가 안내되는지
  • 오류 메시지와 성공 메시지가 자동으로 전달되는지
  • 동적으로 추가된 검색 결과가 읽히는지

색상 대비 점검

실제 색상값을 확인할 수 없었으므로 현재는 판정할 수 없습니다. 복구 후 다음을 측정해야 합니다.

  • 본문·버튼 텍스트: 4.5:1 이상
  • 큰 텍스트: 3:1 이상
  • 입력창 테두리, 체크 상태, 포커스 표시 등 UI 요소: 3:1 이상
  • 오류·성공 상태를 색상만으로 구분하지 않기
  • 링크가 주변 본문과 색상만으로 구분된다면 밑줄 등 추가 표시 제공

포커스 표시도 인접 배경과 충분한 대비가 있어야 하며, WCAG 2.2는 포커스가 콘텐츠에 가려지지 않아야 한다고 요구합니다. 2.4.7 포커스 표시, 2.4.11 포커스가 가려지지 않음, 1.4.11 비텍스트 대비

현재 판정

  • 실제 WCAG 준수 여부: 판정 불가
  • 회원가입 폼: 접속 복구 후 우선 점검 필요
  • 검색·필터: 동적 상태와 키보드 조작 우선 점검 필요
  • 결제 페이지: 전체 구매 흐름 기준으로 반드시 재검증 필요
  • Section 508: 미국 연방기관 또는 적용 대상 ICT가 아니라면 법적 적용 여부는 별도 검토 필요

사이트가 접속 가능한 URL로 복구되거나 테스트용 페이지·스크린샷·HTML을 제공하면, 다음 단계에서 실제 위반 위치와 심각도, 재현 절차, 수정 코드 수준의 권고까지 구체적으로 작성할 수 있습니다.

More in this category

7v7 Football Team Generator App
Accessibility Auditor Agent Role
Accessibility Expert
Accessibility Testing Superpower
AI App Prototyping for Chat Interface