wcag-audit-patterns

wcag-audit-patterns 스킬 개요

wcag-audit-patterns 스킬이 하는 일

wcag-audit-patterns 스킬은 WCAG 2.2 접근성 감사를 체계적으로 수행하고, 발견한 문제를 실제 수정 가이드로 연결해 주는 구조화된 프롬프트 프레임워크입니다. 단순히 “접근성 체크해줘” 수준의 일반적인 프롬프트가 아니라, UX audit, QA, 디자인 리뷰, 엔지니어링 핸드오프, 컴플라이언스 준비까지 염두에 두고 더 실무적인 결과를 원하는 사용자에게 특히 잘 맞습니다.

누가 사용하면 좋은가

다음과 같은 작업이 필요하다면 wcag-audit-patterns를 쓰는 편이 좋습니다.

• 페이지, 사용자 플로우, 컴포넌트를 WCAG 2.2 기준으로 검토해야 할 때
• 자동화 도구의 결과와 수동 검증을 함께 묶어야 할 때
• 영향도와 적합성 수준에 따라 이슈 우선순위를 정해야 할 때
• 개발자와 디자이너가 바로 실행할 수 있는 수정 가이드를 만들어야 할 때

접근성 전문가, UX 감사 담당자, 프로덕트 디자이너, 프론트엔드 엔지니어, 그리고 ADA, Section 508, VPAT 관련 준비를 하는 팀에 잘 맞습니다.

사용자가 실제로 해결하려는 핵심 문제

대부분의 사용자는 WCAG 이론 강의를 원하는 것이 아닙니다. 실제로 필요한 것은 다음 질문에 반복 가능하게 답하는 방식입니다.

• 무엇이 깨져 있을 가능성이 높은가
• 무엇을 사람이 직접 확인해야 하는가
• 어느 정도 심각도로 분류해야 하는가
• 두루뭉술하지 않게 어떻게 고쳐야 하는가

바로 이런 지점에서 wcag-audit-patterns skill이 유용합니다. 이 스킬은 WCAG 레벨, POUR 원칙, 자주 발생하는 위반 패턴, 그리고 수정 중심의 정리 방식에 맞춰 감사 구조를 잡아 줍니다.

일반적인 프롬프트와 다른 점

일반적인 접근성 프롬프트는 대체로 폭넓고 추상적인 조언을 내놓는 경우가 많습니다. 반면 wcag-audit-patterns는 모델이 다음과 같은 방식으로 보게 만들고 싶을 때 더 유용합니다.

• 잘 알려진 감사 관점으로 페이지나 기능을 점검하기
• 출시 차단급 이슈와 상대적으로 낮은 심각도의 이슈를 구분하기
• 발견 사항을 익숙한 WCAG 문제 범주에 매핑하기
• “접근성을 개선하세요”가 아니라 실제 수정 패턴을 제안하기

포함 범위와 아닌 범위

이 스킬은 감사 추론과 이슈 패턴 커버리지 측면에서는 강점이 있습니다. 하지만 턴키형 도구 체인으로 보기는 어렵습니다. 저장소에는 SKILL.md만 있고, 보조 스크립트, 규칙 파일, 참고 문서는 제공되지 않기 때문입니다.

즉, wcag-audit-patterns for UX Audit는 완전한 자동 스캐너나 법적 인증 워크플로우라기보다, 감사 방향을 잡아 주는 가이드형 프레임워크로 보는 것이 맞습니다.

wcag-audit-patterns 스킬 사용 방법

wcag-audit-patterns 설치 맥락

업스트림 스킬은 SKILL.md 안에 자체 설치 명령을 따로 제공하지 않습니다. 따라서 wshobson/agents 저장소에서 스킬을 불러오는 일반적인 방법을 사용하면 됩니다. 환경이 Skills CLI를 지원한다면 보통 다음 패턴을 사용합니다.

npx skills add https://github.com/wshobson/agents --skill wcag-audit-patterns

로컬 clone에서 스킬을 불러오는 구성이라면 다음 경로를 지정하면 됩니다.

plugins/accessibility-compliance/skills/wcag-audit-patterns

먼저 읽어야 할 파일

다음 파일부터 확인하세요.

• plugins/accessibility-compliance/skills/wcag-audit-patterns/SKILL.md

이 스킬 경로에는 보조 폴더나 참고 문서가 없기 때문에, 실제로 쓸 만한 가이드는 거의 이 파일 하나에 담겨 있습니다. 도입 판단이 빠르다는 장점은 있지만, 다른 곳에 숨겨진 구현 디테일이 더 있을 것이라고 기대하면 안 됩니다.

스킬이 잘 작동하려면 어떤 입력이 필요한가

wcag-audit-patterns usage의 결과 품질은 입력 품질에 크게 좌우됩니다. 가능하면 다음 정보를 함께 주세요.

• 감사 대상 URL, 화면, 또는 컴포넌트
• 페이지의 목적과 주요 사용자 작업
• 목표 적합성 수준, 보통 WCAG 2.2 AA
• 디바이스 또는 뷰포트 맥락
• 관련이 있다면 React, custom widgets, modal system, design system components 같은 기술 스택 정보
• screenshots, HTML snippets, audit logs, axe output, user flow steps 같은 근거 자료

이런 정보가 없으면 모델은 흔한 패턴을 기준으로 추정하게 되고, 맥락 의존적인 실패 사례를 놓칠 수 있습니다.

실제 감사를 위한 좋은 프롬프트 형태

강한 호출 방식은 “이 사이트 접근성 감사해줘”가 아닙니다. 다음처럼 구체적으로 주는 편이 훨씬 낫습니다.

• 어떤 페이지나 기능인지 명시하기
• 적용 기준과 적합성 수준 밝히기
• 자동 점검 후보와 수동 확인 항목을 분리해서 요청하기
• 이슈 우선순위화를 요구하기
• 각 발견 사항에 연결된 수정 단계를 요청하기

예시 프롬프트 구조:

“Use wcag-audit-patterns to audit our checkout page against WCAG 2.2 AA. Focus on keyboard access, form labels, error handling, focus order, and color contrast. I’ve attached screenshots plus the HTML for the payment section. Separate likely issues from items requiring manual verification. For each issue, provide severity, likely WCAG area, user impact, and a concrete fix.”

막연한 목표를 완전한 프롬프트로 바꾸기

목표가 “우리 modal 좀 봐줘” 수준이라면, 다음 정보까지 확장해서 넣는 것이 좋습니다.

• modal의 목적
• 여닫는 방식
• focus가 내부에 고정되는지
• forms, tables, custom controls를 포함하는지
• 모바일과 데스크톱에서 동작이 다른지

이렇게 해야 결과가 좋아집니다. 심각한 WCAG 이슈는 정적인 마크업만이 아니라 실제 상호작용 흐름에 의해 결정되는 경우가 많기 때문입니다.

UX Audit을 위한 wcag-audit-patterns 추천 워크플로우

실무적으로는 다음 흐름이 효율적입니다.

1. 페이지 유형에 맞는 pre-audit checklist를 먼저 요청합니다.
2. 가능하다면 자동화 스캐너는 별도로 실행합니다.
3. 그 출력 결과, screenshots, code snippets를 스킬에 넣습니다.
4. 자동화로 확정할 수 없는 항목에 대해 manual verification steps를 요청합니다.
5. blocker, serious, moderate 이슈로 그룹화한 remediation plan을 요청합니다.
6. 수정된 코드나 업데이트된 screenshots로 스킬을 다시 실행합니다.

이 워크플로우를 따르면 단발성 프롬프트보다 wcag-audit-patterns에서 훨씬 더 많은 가치를 끌어낼 수 있습니다.

이 스킬이 특히 잘하는 것

원본 내용은 특히 다음 요소를 강하게 강조합니다.

• WCAG conformance levels
• POUR framework
• 영향도 기준의 common violations
• remediation-oriented audit output

그래서 특히 다음 용도에서 도움이 큽니다.

• 1차 감사 구조 잡기
• 흔한 접근성 결함의 우선순위 정리
• 개발자가 바로 활용할 수 있는 수정 가이드 생성
• forms, custom widgets 같은 인터랙티브 UI 패턴 검토

자동으로 해주지 않는 것

이 스킬에는 다음이 포함되어 있지 않습니다.

• browser automation
• code analyzers
• 별도 파일로 제공되는 재사용 체크리스트
• legal sign-off logic
• 제품 특화 의사결정 규칙

즉, wcag-audit-patterns install 자체는 단순하지만, 높은 신뢰도의 컴플라이언스 작업을 하려면 여전히 별도의 scanner, 테스트 프로세스, 또는 사람 검토가 필요합니다.

가치가 큰 입력 자료 예시

특히 유용한 아티팩트는 다음과 같습니다.

• axe, Lighthouse, 또는 유사한 scan output
• 문제가 있는 control의 DOM snippets
• focus state가 보이는 screenshots
• keyboard interaction steps
• form validation behavior
• menus, dialogs, carousels 같은 동적 UI 상태에 대한 video 또는 notes

이런 입력이 있어야 스킬이 “실제 위반 가능성이 높은 문제”와 “검증이 더 필요한 항목”을 더 잘 구분할 수 있습니다.

결과 품질을 높이는 실전 프롬프트 패턴

다음과 같은 출력 형식을 요청해 보세요.

• “audit findings table with severity, impact, fix”
• “manual verification checklist by component”
• “top 10 blockers before release”
• “developer remediation tasks with acceptance criteria”
• “design review notes for WCAG 2.2 AA”

이런 출력 형태는 열린 요약문보다 훨씬 실행 가능성이 높습니다.

wcag-audit-patterns 스킬 FAQ

wcag-audit-patterns는 입문자에게도 괜찮은가

네, 다만 내가 무엇을 검토하는지, 즉 페이지나 제품 맥락은 이미 알고 있는 경우에 더 적합합니다. 이 스킬은 WCAG 2.2, 적합성 수준, 자주 등장하는 이슈 범주를 기준으로 구조를 잘 잡아 줍니다. 하지만 완전한 접근성 교육 과정은 아니므로, 경계 사례나 공식 해석이 필요한 상황에서는 외부 참고 자료가 여전히 필요할 수 있습니다.

일반적인 접근성 프롬프트보다 더 나은가

감사 작업이라면 대체로 그렇습니다. wcag-audit-patterns guide의 핵심 가치는 숨겨진 데이터가 아니라 감사 프레이밍에 있습니다. 특히 severity, manual checks, remediation까지 함께 요구할 때 모델이 더 체계적인 방식으로 발견 사항을 정리하도록 도와줍니다.

자동화 스캐너를 대체하나

아니요. 대체가 아니라 보완입니다. 자동화 도구는 WCAG 범위의 일부만 잡아낼 수 있고, 이 스킬은 더 넓은 검토 구조를 잡고 keyboard use, semantics, labels, focus management, interaction quality 같은 항목에 대해 수동 점검 포인트를 제안하는 데 더 강합니다.

법무 또는 조달 컴플라이언스 작업에도 적합한가

준비 작업을 지원하는 용도로는 적합합니다. 특히 ADA, Section 508, VPAT 관련 검토 전에 유용할 수 있습니다. 다만 이를 법적 인증으로 간주해서는 안 됩니다. 컴플라이언스 주장의 유일한 근거로 쓰기보다는, 증거 정리와 remediation 계획 수립용으로 활용하는 것이 맞습니다.

언제 wcag-audit-patterns를 쓰지 말아야 하나

다음이 필요하다면 다른 도구를 고려하는 편이 낫습니다.

• 코드 레벨 linter 또는 CI integration
• 공식적인 법률 해석
• 저장소 안에 완비된 접근성 지식 베이스
• 웹 WCAG 감사 패턴을 넘어서는 전문적인 native app 가이드

이 스킬은 엔드투엔드 컴플라이언스 자동화보다는 웹 중심의 감사 추론에 가장 효과적입니다.

전체 페이지가 아니라 컴포넌트에도 쓸 수 있나

네. 오히려 컴포넌트 단위에서 더 유용한 경우가 많습니다. markup, interaction sequence, screenshots, expected behavior를 더 밀도 있게 제공할 수 있기 때문입니다. 좋은 후보는 modals, tabs, menus, forms, tables, custom controls 등입니다.

wcag-audit-patterns 스킬을 더 잘 활용하는 방법

감사 대상을 더 좁게 잡기

가장 큰 개선 포인트는 범위 통제입니다. “대시보드 전체를 감사해줘” 대신 다음처럼 요청해 보세요.

• 하나의 page template
• sign-up 또는 checkout 같은 하나의 journey
• date pickers 또는 dialogs 같은 하나의 component family

범위를 좁힐수록 발견 사항과 수정 가이드의 신뢰도가 올라갑니다.

설명만 하지 말고 근거를 함께 주기

wcag-audit-patterns는 근거 자료를 붙였을 때 훨씬 더 잘 작동합니다. 좋은 입력 예시는 다음과 같습니다.

• 영향받는 영역의 HTML
• visible labels와 focus states가 보이는 screenshots
• rule names가 포함된 scanner output
• keyboard behavior에 대한 notes
• 가능하다면 screen reader observations

근거가 있어야 추측이 줄고, 수정안도 더 구체적으로 나옵니다.

수동 점검을 명시적으로 요청하기

자주 발생하는 실패 패턴 중 하나는 첫 결과를 완성본으로 여기는 것입니다. 중요한 WCAG 이슈 중 상당수는 사람의 확인이 필요합니다. 스킬에 다음을 분리해서 제시하라고 요청하세요.

• likely detectable issues
• assumptions
• manual checks still required

이렇게 해야 결과의 신뢰성이 높아집니다.

acceptance criteria까지 포함해 remediation을 요청하기

“어떻게 고칠까”에서 멈추지 마세요. 다음까지 요청하는 것이 좋습니다.

• 구현 변경 사항
• 왜 사용자에게 중요한지
• QA용 acceptance criteria
• 주의해야 할 regressions

이렇게 해야 결과물이 디자이너, 엔지니어, QA 리뷰어 모두가 바로 활용할 수 있는 수준으로 바뀝니다.

우선순위 품질 높이기

모든 항목이 똑같이 중요하게 돌아온다면, 다음 기준으로 다시 정렬해 달라고 요청하세요.

• user impact
• task blockage
• legal/compliance risk
• ease of remediation
• frequency across templates

특히 백로그 정리나 릴리스 트리아지 워크플로우에서 wcag-audit-patterns skill을 사용할 때 매우 유용합니다.

수정 후 before-and-after 맥락으로 다시 실행하기

이 스킬의 진가는 두 번째 패스에서 더 잘 드러납니다. 다음을 함께 제공하세요.

• original finding
• revised markup 또는 screenshot
• 무엇이 바뀌었는지
• 아직 불확실한 점이 무엇인지

그런 다음 수정이 문제를 완전히 해결했는지, 아니면 새로운 접근성 리스크를 만들었는지 물어보면 됩니다.

팀 내부 기준과 함께 쓰기

팀에 design system rules, coding standards, accessibility definitions of done가 있다면 프롬프트에 함께 포함하세요. 저장소 자체는 매우 가벼운 편이므로, 이런 로컬 기준을 덧붙이는 것이 wcag-audit-patterns usage를 일반론이 아니라 팀 맞춤형으로 만드는 가장 좋은 방법입니다.

과도하게 확신하는 출력 경계하기

이 스킬은 유용하지만, 특히 코드나 인터랙션 맥락이 없을 때 확신을 지나치게 크게 표현할 수 있습니다. 어떤 발견 사항이 runtime behavior에 의존한다면, confidence level을 표시하게 하고 브라우저 또는 assistive tech로 무엇을 검증해야 하는지도 함께 적게 하세요.

반복 가능한 감사 템플릿을 만드는 데 활용하기

실무에서 wcag-audit-patterns를 개선하는 가장 좋은 방법 중 하나는, 잘 작동한 프롬프트를 사내 템플릿으로 바꾸는 것입니다.

• page audit template
• component audit template
• remediation handoff template
• regression verification template

저장소 자체에는 추가 지원 파일이 없더라도, 이렇게 하면 팀 차원의 일관성을 확보할 수 있습니다.