Communitygithub.com

humbleteam/accessibility-audit

Claude Code를 위한 WCAG 2.2 접근성 감사 스킬로, 심각도별로 정렬된 발견 사항과 성공 기준 인용을 제공합니다.

accessibility-audit란 무엇인가요?

이 스킬은 Claude Code에게 구조화된 WCAG 2.2 접근성 감사를 수행하는 방법을 알려줍니다. 스크린샷, URL, HTML/JSX 등 다양한 입력 유형을 처리하며, 각 입력 유형이 증명할 수 있는 것과 없는 것을 엄격히 구분합니다. 감사는 18가지 WCAG 2.2 성공 기준(SC)에 대한 사전 정의된 체크리스트를 통해 진행되며, P0(사용 차단)부터 P2(마찰)까지 심각도 수준으로 발견 사항을 분류합니다. 각 발견 사항은 관찰된 내용, 구체적인 수정 방법, 그리고 관련 SC 인용으로 구성되어 보고서로 출력됩니다. 이 스킬은 접근성 전문가 검토를 자동화하지만, 실제 장애인 사용자 테스트나 법적 준수 인증을 대체하지 않음을 명확히 합니다.

지원 대상✓Claude Code~Codex CLI~Cursor
npx skills add humbleteam/accessibility-audit

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

접근성 감사

1단계: 입력 식별

무엇이 제공되었는지 확인하기 전에 먼저 결정합니다:

  • 스크린샷 또는 이미지 - 스크린샷 전용 범위로 진행합니다(3단계 참조).
  • URL - 가져오기 도구를 사용할 수 있으면 페이지를 가져와 렌더링된 HTML을 진실 공급원으로 사용합니다. 페이지의 스크린샷도 사용할 수 있으면 둘 다 사용합니다. 가져오기 도구를 사용할 수 없으면 사용자에게 페이지 HTML을 붙여넣도록 요청하고 마크업을 추측하지 마십시오.
  • HTML, JSX 또는 기타 마크업/컴포넌트 스니펫 - 직접 읽어 진실 공급원으로 사용합니다.
  • 기타(일반 설명, 내보낸 이미지가 없는 Figma 링크, 모호한 "앱 확인") - 중단하고 스크린샷, URL 또는 마크업을 요청합니다. 볼 수 없는 UI를 추측하지 마십시오.

둘 이상의 입력 유형이 제공된 경우(예: URL과 그 상태 중 하나의 스크린샷), 둘 다 사용하여 더 넓은 범위에 대해 확인합니다.

2단계: 체크리스트 읽기

평가하기 전에 references/wcag22-checklist.md를 읽습니다. 이 감사가 확인하는 18가지 성공 기준(SC 번호, 이름, 수준, 스크린샷만으로 확인 가능 여부, 확인할 사항)이 각각 한 줄씩 나열되어 있습니다. 동일한 세션에서 두 번째 감사라도 매 감사마다 다시 읽어 기준이 조용히 기억에서 누락되지 않도록 합니다.

이 감사가 다루는 기준

SC이름수준
1.1.1비텍스트 콘텐츠A
1.3.1정보와 관계A
1.4.3명도 대비(최소)AA
1.4.4텍스트 크기 조정AA
1.4.10리플로우AA
1.4.11비텍스트 대비AA
2.1.1키보드A
2.1.2키보드 트랩 없음A
2.4.4링크 목적(맥락 내)A
2.4.6제목과 레이블AA
2.4.7포커스 표시AA
2.4.11포커스 가려짐 없음(최소) - WCAG 2.2 신규AA
2.5.8대상 크기(최소) - WCAG 2.2 신규AA
3.2.2입력 시A
3.3.1오류 식별A
3.3.2레이블 또는 지침A
3.3.8접근 가능한 인증(최소) - WCAG 2.2 신규AA
4.1.2이름, 역할, 값A

각 항목에서 확인할 사항은 references/wcag22-checklist.md를 참조하십시오.

3단계: 입력이 증명할 수 있는 것과 없는 것 구분

이것이 감사의 정직성을 유지하는 규칙입니다. 입력이 입증할 수 없는 기준에 대해 통과 또는 실패를 주장하지 마십시오.

스크린샷만으로 확인할 수 있는 것:

  • 1.4.3 명도 대비(최소) - 렌더링된 텍스트와 배경 색상을 측정합니다.
  • 1.4.11 비텍스트 대비 - 아이콘, 테두리, 표시되는 포커스 표시기를 측정합니다.
  • 2.4.6 제목과 레이블 - 제목과 양식 레이블이 시각적으로 존재하고 맥락에서 이해되는지 확인합니다.
  • 2.5.8 대상 크기 - 뷰포트 배율이 알려져 있거나 명시된 경우, 탭 가능한 요소 치수를 24x24 CSS px 최소값에 대해 측정합니다.
  • 3.3.2 레이블 또는 지침 - 입력이 필요한 항목 옆에 표시되는 지침이 있는지 확인합니다.

스크린샷만으로 확인할 수 없으며 "이 입력으로 확인 불가" 항목에 나열해야 하는 것:

  • 1.1.1 비텍스트 콘텐츠(대체 텍스트는 DOM에 있으며 픽셀에 없습니다).
  • 1.3.1 정보와 관계(의미 구조).
  • 2.1.1 / 2.1.2 키보드 동작 및 키보드 트랩.
  • 2.4.4 링크 목적(프로그래매틱 맥락에 의존하는 경우).
  • 2.4.7 / 2.4.11 포커스 표시(포커스 상태 스크린샷이 제공되지 않은 경우).
  • 3.2.2 입력 시, 3.3.1 오류 식별, 3.3.8 접근 가능한 인증 - 모두 상호작용이나 흐름이 필요하며 정적 이미지로는 불가능합니다.
  • 4.1.2 이름, 역할, 값(접근성 트리가 필요합니다).

HTML, JSX 또는 가져온 페이지에서 마크업을 기준으로 18개 항목을 모두 직접 확인합니다: 대체 속성, 제목 및 랜드마크 구조, 레이블 연결, ARIA 역할 및 상태, tabindex 및 포커스 관리 코드, 대비를 계산하기 위해 해결할 수 있는 인라인 색상 값. CSS가 포함되지 않은 경우, 대비와 대상 크기는 계산된 값이 제공되지 않으면 여전히 "확인 불가"에 해당합니다.

4단계: 심각도 할당

  • P0 - 사용 차단 사용자가 작업을 전혀 완료할 수 없습니다. 기본 작업에 접근 가능한 이름 누락, 키보드 트랩, 텍스트를 읽을 수 없을 정도로 낮은 대비, 레이블이 전혀 없는 양식 컨트롤.
  • P1 - 사용 저하 작업은 가능하지만 더 어렵습니다. AA 임계값보다 낮지만 여전히 읽을 수 있는 대비, 표시되는 포커스 표시기 누락, 24x24 CSS px 최소값 미만의 대상, 주변 맥락이 없는 모호한 링크 텍스트("여기를 클릭").
  • P2 - 마찰 약간의 혼란 또는 비효율. 일관성 없는 제목 수준, 장식 요소의 낮은 대비, 중복된 지침.

5단계: 각 발견 사항 작성

모든 발견 사항은 다음 순서대로 세 부분이 필요합니다:

  1. 관찰됨 - 추론이 아닌 실제로 본 내용. ("'제출' 버튼은 #7A9CC6 배경에 흰색 텍스트(#FFFFFF)를 렌더링합니다.")
  2. 수정 - 일반적이지 않고 구체적으로. ("배경을 #3D5A80 이하로 어둡게 하여 흰색 텍스트와 4.5:1 비율에 도달하십시오.")
  3. 인용 - WCAG 2.2 SC <번호> (<이름>, 수준 <A/AA>).

출력 형식

정확히 다음 구조를 사용합니다:

# 접근성 감사: <검토된 이름 또는 URL>

**입력 유형:** 스크린샷 | URL | HTML/JSX
**범위:** <실제로 확인된 내용 한 줄>

## P0 - 사용 차단
1. **<짧은 제목>**
   - 관찰됨: <사실>
   - 수정: <구체적인 수정>
   - WCAG 2.2 SC <x.x.x> (<이름>, 수준 <A/AA>)

## P1 - 사용 저하
(동일 구조)

## P2 - 마찰
(동일 구조)

## 이 입력으로 확인 불가
- <SC 번호 및 이름> - <HTML / URL / 키보드 테스트 / 포커스 상태 스크린샷 필요>

## 범위 참고
이것은 WCAG 2.2에 대한 전문가 검토 통과일 뿐이며, 보조 기술을 사용하는 사람들을 대상으로 한 테스트나 법적 ADA 또는 섹션 508 준수 인증을 대체하지 않습니다.

발견 사항이 전혀 없는 심각도 섹션은 완전히 생략합니다. 문제가 존재함을 암시하는 제목 아래에 "문제 없음" 채우기를 넣지 마십시오. 입력이 스크린샷일 때는 항상 "이 입력으로 확인 불가"를 포함합니다. 감사가 HTML/JSX/URL을 처음부터 끝까지 다룬 경우에는 섹션을 생략하는 대신 "없음 - 전체 마크업 사용 가능"이라고 작성합니다. 항상 범위 참고를 포함합니다.

예외 사항

  • 하나의 스크린샷에 여러 화면 또는 상태 - 발견 사항을 화면 간에 병합하지 말고 동일한 보고서 내에서 각각 자체 ## 하위 제목 아래 감사합니다.
  • 사진, 그라데이션 또는 비디오 배경 위의 텍스트 - 통과로 추정하지 마십시오. 불확정 대비에 대해 P1 발견 사항을 제출하고 텍스트 색상에 대해 최악의 픽셀 영역을 테스트할 것을 권장합니다.
  • 표시 콘텐츠가 없는 컴포넌트(빈 상태, 로딩 스켈레톤) - 기록하고 채워진 상태가 사용 가능한지 문의합니다. 여러 기준(제목, 레이블, 링크 목적)은 빈 껍데기에서 판단할 수 없기 때문입니다.
  • 인라인 스타일 또는 해결되지 않은 CSS 변수가 있는 HTML/JSX - 계산된 값을 추정하지 말고 대비와 대상 크기를 확인 불가로 처리합니다.
  • "빠른 확인" 또는 "큰 것만" 요청 - 여전히 전체 기준 목록을 실행하지만 P0만 보고하고 범위 줄에 P1/P2가 확인되었지만 출력에서 억제되었음을 명시합니다.
  • 수정 후 동일한 화면의 두 번째 감사 - 전체 과정을 다시 실행합니다. 이전 발견 사항이 여전히 유효하다고 가정하지 마십시오.

피해야 할 실패 모드

  • 실제 색상에서 계산하지 않은 명도 대비 비율을 만들어 내지 마십시오.
  • 명백히 잘못된 것이 없어 보인다고 기준을 "통과"로 표시하지 마십시오. 확인되지 않았다면 "통과"가 아니라 "확인 불가"입니다.
  • 실제로 확인하지 않은 WCAG 성공 기준을 인용하지 마십시오.
  • 보고서를 더 좋게 보이게 하려고 P0 발견 사항을 P1으로 완화하지 마십시오.

관련 스킬