적용 기준과 목표 레벨, 테스트 환경, 서비스가 가진 기능을 선택하면 기획·디자인·퍼블리싱 담당이 함께 관리할 수 있는 접근성 검토 목록을 만듭니다. 항목마다 실무 질문과 확인 방법, 완료 근거 예시를 제공하고 상태·메모·근거 URL을 기록할 수 있습니다. 결과는 이 브라우저에만 저장되며 Markdown 또는 CSV로 내보내 전달합니다.
입력한 프로젝트 정보와 체크 상태는 이 브라우저에만 저장됩니다. 다른 기기와 동기화되지 않으므로 중요한 결과는 Markdown 또는 CSV로 보관하세요.
이 체크리스트는 내부 사전 검토 기록입니다. 국내 웹 접근성 품질인증은 표본 페이지 선정, 항목별 준수율 산정, 전문가 심사와 사용자 심사를 포함하는 별도 절차이며 이 도구가 대신하지 않습니다. 모든 항목을 통과로 표시했더라도 인증 통과나 준수율 100%로 보고하지 마세요.
웹접근성 체크리스트는 출시 직전 QA에서 갑자기 꺼내는 문서가 아닙니다. 대체 텍스트의 작성 책임, 색상 시스템, 키보드 인터랙션, 오류 안내와 인증 방식처럼 구조를 바꾸는 항목은 기획과 설계 단계에서 결정해야 수정 비용이 낮습니다. 프로젝트를 시작할 때 기준과 담당을 정하고, 디자인 리뷰와 구현 QA에서 같은 목록을 업데이트하는 방식이 효율적입니다.
첫 단계는 적용 기준을 정하는 것입니다. 국내 웹 프로젝트에서 KWCAG 2.2를 기준으로 사전 점검할지, 국제 기준인 WCAG 2.2의 A 또는 AA를 목표로 할지 팀 안에서 명시해야 합니다. 두 기준은 공통된 원칙이 많지만 번호와 구성, 일부 세부 항목이 같지 않습니다. 따라서 하나를 다른 하나의 단순 번역본으로 취급하면 누락이나 잘못된 완료 판단이 생길 수 있습니다.
KWCAG 2.2는 국내 웹 콘텐츠 접근성 표준으로 4개 원칙, 14개 지침, 33개 검사항목을 제시합니다. A·AA·AAA 등급을 사용하지 않습니다. 국내 웹 접근성 품질인증 전문가 심사의 항목도 33개지만, 체크리스트에서 한 번 통과를 선택했다고 실제 인증 준수율이 되는 것은 아닙니다. 인증은 선정된 표본 페이지와 콘텐츠를 기준으로 별도 산정하며 사용자 심사도 포함합니다.
WCAG 2.2는 성공 기준을 A, AA, AAA로 나눕니다. Level AA를 목표로 하면 AA 항목만 고르는 것이 아니라 A와 AA를 모두 포함해야 합니다. 이 도구는 A 31개와 AA 24개, 합쳐서 55개를 생성하고 실무에서 목표로 삼는 일이 드문 AAA는 제외합니다. WCAG 2.2에서 삭제된 4.1.1 Parsing도 포함하지 않습니다.
기준 선택이 곧 법적 의무나 인증 범위를 결정하는 것은 아닙니다. 조직의 계약 조건, 발주 규격, 정책과 최신 심사 기준을 별도로 확인해야 합니다.
접근성은 사용자의 이용 가능성을 다루는 품질 기준입니다. 사이트 운영 주체가 민간인지 공공인지에 따라 적용 법령, 발주 조건, 인증 필요성은 달라질 수 있지만 버튼이 키보드로 동작해야 하는지, 이미지에 적절한 대체 텍스트가 필요한지 같은 기술 검토 항목을 임의로 제거할 근거는 되지 않습니다.
그래서 이 도구의 운영 유형 선택은 보고서의 프로젝트 정보와 안내 문구에만 반영합니다. 공공·품질인증 준비를 고르면 공식 심사를 대체하지 않는다는 경고를 더 분명히 보여줍니다. 실제 항목의 적용 가능성은 사이트가 영상, 인증, 시간 제한, 드래그 같은 기능을 갖는지에 따라 판단합니다.
WCAG A는 기본적인 접근 장벽을 다루지만, 일반적인 제품 품질 목표로는 AA를 권장합니다. AA를 선택하면 텍스트 명도대비, 리플로, 텍스트 간격, 비텍스트 명도대비, 가려지지 않는 초점, 최소 타겟 크기 같은 항목이 추가됩니다. 다만 목표 레벨은 계약이나 정책에 따라 정해야 하므로 도구가 대신 결정하지 않습니다.
레벨을 A에서 AA로 올리면 이미 기록한 A 항목의 상태와 메모는 그대로 두고 AA 항목만 미검토로 추가됩니다. 반대로 AA에서 A로 내리면 기록이 남은 AA 항목이 사라지므로 몇 개가 삭제되는지 먼저 확인합니다. KWCAG 2.2 모드에서는 레벨을 선택하지 않습니다. 33개 전체를 만든 뒤 실제 기능에 따라 해당 없음 여부를 검토합니다.
모든 사이트에 녹화 영상, 실시간 방송, 로그인, 시간 제한, 드래그 기능이 있는 것은 아닙니다. 정적인 체크리스트는 이런 항목을 전부 보여주거나 반대로 너무 일찍 제외합니다. 기능 질문은 적용되지 않을 가능성이 높은 항목을 표시해 검토 순서를 줄이는 장치입니다.
하지만 선택 결과만으로 항목을 삭제하면 안 됩니다. 예를 들어 팀이 자동 재생 콘텐츠가 없다고 답했어도 광고, 외부 위젯, 운영 단계의 캐러셀이 추가될 수 있습니다. 그래서 이 도구는 해당 없음 후보만 표시하고 최종 판단은 사용자가 이유를 확인한 뒤 선택하도록 합니다. 키보드 사용 보장, 이름·역할·값, 웹 애플리케이션 접근성처럼 범위가 넓은 항목은 어떤 답변에서도 후보가 되지 않습니다.
기획 담당은 오류 문구, 시간 제한, 인증, 중복 입력, 도움 정보 같은 절차를 정의합니다. 디자인 담당은 색, 대비, 초점 표현, 타겟 크기와 색 이외의 단서를 설계합니다. 퍼블리싱·개발 담당은 의미 구조, 키보드 동작, ARIA 상태와 실제 인터랙션을 구현합니다.
한 항목에 역할이 여러 개 붙는 것은 책임이 불명확해서가 아닙니다. 접근성 문제는 한 단계에서만 해결되지 않기 때문입니다. 예를 들어 폼 레이블은 기획자가 이름을 정하고, 디자이너가 시각적 라벨을 배치하며, 개발자가 입력 요소와 연결해야 합니다. 팀에서는 역할 태그를 작업을 넘기는 순서로 사용하고 최종 검토 책임자를 별도로 합의하는 것이 좋습니다.
검토 진행률은 팀이 몇 개 항목을 살펴봤는지 보여주는 작업 관리 수치입니다. 접근성 준수율이나 공식 합격 가능성이 아닙니다. 통과는 현재 프로젝트 범위와 확인한 화면에서 문제를 발견하지 못했다는 기록일 뿐, 모든 페이지와 보조기술 조합에서 완전한 준수를 보장하지 않습니다.
이슈는 실패 선언이 아니라 수정 작업의 시작점입니다. 메모에 영향 화면, 재현 방법, 수정 담당과 재검수 조건을 남기면 체크리스트가 단순 보고용 표가 아니라 실행 가능한 백로그가 됩니다. 해당 없음에는 적용되지 않는 이유를 적어 나중에 기능이 추가됐을 때 다시 판단할 수 있게 해야 합니다.
진행률의 분모는 전체 항목에서 해당 없음을 뺀 수입니다. 모든 항목을 해당 없음으로 두면 100%가 되는 대신 검토할 항목이 없다고 표시합니다. 분모가 없는데 완료처럼 보이는 숫자를 만들지 않기 위해서입니다.
자동 검사기는 마크업 누락, 일부 대비 값, 특정 속성과 구조를 빠르게 찾는 데 유용합니다. 하지만 대체 텍스트가 상황에 적절한지, 초점 순서가 사용 흐름과 맞는지, 오류 설명이 이해 가능한지, 색 외 단서가 충분한지는 사람의 판단이 필요합니다.
권장 순서는 이렇습니다. 기획 단계에서 서비스 기능과 절차 관련 항목을 분류하고, 디자인 리뷰에서 명도대비·색각 구분·타겟 크기·초점 표현을 확인합니다. 구현 중에는 HTML 구조와 키보드 동작을 검사하고, 확대·리플로·텍스트 간격을 실제 렌더링으로 확인합니다. 그다음 스크린리더와 키보드만 사용한 주요 과업 테스트를 수행하고, 발견한 이슈를 수정한 뒤 다른 화면에 같은 패턴이 없는지 회귀 검수합니다.
Kitfolio의 개별 검사 도구는 이 중 디자인 리뷰와 구현 검사 단계를 돕습니다. 체크리스트는 각 도구의 결과를 자동으로 가져오지 않습니다. 검사한 범위와 수정 링크를 메모나 근거 URL에 직접 남겨야 나중에 무엇을 근거로 통과했는지 확인할 수 있습니다.
Markdown은 GitHub Issue, 저장소 문서, Notion 본문처럼 사람이 읽고 리뷰하는 문서에 적합합니다. 축별 제목과 항목별 상태·메모가 계층적으로 정리됩니다. CSV는 스프레드시트에서 담당별로 필터링하거나 이슈 수를 집계할 때 유용하며, 한국어 Excel에서 깨지지 않도록 UTF-8 BOM을 붙여 내보냅니다.
두 형식 모두 화면 필터와 상관없이 현재 체크리스트 전체를 포함합니다. 받는 사람이 빠진 항목을 알 수 없기 때문입니다. 중요한 프로젝트라면 브라우저 저장만 믿지 말고 정기적으로 파일을 내려받아 보관하세요. 브라우저 데이터 삭제나 다른 기기 사용 시 로컬 상태는 복원되지 않습니다.
이 도구는 심사 준비 범위를 정리하는 데 사용할 수 있지만 품질인증 심사표 자체가 아닙니다. 공식 심사는 페이지 표본 선정, 콘텐츠 단위 판정, 항목별 준수율 산정, 사용자 심사 등 별도 절차를 사용합니다. 심사를 준비한다면 신청 시점의 최신 표준심사 지침과 인증기관 안내를 확인해야 합니다.
체크리스트에서 모든 항목을 통과로 표시했더라도 이를 인증 통과나 준수율 100%로 보고하지 마세요. 내부 문서에는 사전 검토 완료와 검사 범위, 사용한 브라우저·보조기술, 날짜를 함께 기록하는 표현이 정확합니다.
프로젝트 착수 시점에는 기준·목표·주요 기능·역할을 정합니다. 와이어프레임 리뷰에서 정보 구조, 오류 절차, 인증, 시간 제한을 확인하고, UI 리뷰에서 색·대비·포커스·타겟과 상태 표현을 확인합니다. 구현 QA에서는 키보드, 의미 구조, 이름·역할·값, 상태 메시지를 확인하고, 출시 전에는 주요 과업을 실제 브라우저와 보조기술로 반복합니다. 출시 후에는 신규 컴포넌트와 운영 콘텐츠가 추가될 때 관련 항목을 다시 엽니다.
접근성은 한 번 완료하고 닫는 인증 스티커가 아니라 제품 변경과 함께 유지해야 하는 품질 조건입니다. 체크리스트의 가장 중요한 값도 완벽해 보이는 숫자가 아니라, 누가 무엇을 언제 다시 확인할지 남기는 데 있습니다.
후보 9개는 목록에서 사라지지 않고 배지만 붙습니다. 영상이나 캐러셀이 운영 중에 추가될 수 있으므로 실제 화면을 본 뒤 직접 해당 없음을 선택해야 분모에서 빠집니다. 키보드 사용 보장처럼 범위가 넓은 항목은 어떤 응답에서도 후보가 되지 않습니다.
AA 목표는 A를 포함하므로 다시 만들 필요가 없습니다. 반대로 AA에서 A로 내리면 기록이 남은 AA 항목이 몇 개 삭제되는지 먼저 확인 대화상자로 알려줍니다.
30%는 작업 진행 상황이지 준수율이 아닙니다. 내보낸 Markdown에는 축별 제목 아래 상태·메모·근거·공식 출처가 항목마다 들어가므로 이슈 3건을 그대로 수정 백로그로 옮길 수 있습니다.
이 도구가 무엇인지, 누구에게·어떻게·왜 필요한지 한눈에 정리했습니다.
웹접근성 체크리스트 빌더는 KWCAG 2.2 또는 WCAG 2.2 기준을 프로젝트에서 실행할 수 있는 검토 항목으로 구성하고, 역할·진행 상태·메모·근거를 관리해 Markdown이나 CSV로 내보내는 브라우저 도구입니다.
프로젝트 착수부터 출시 전 QA까지 접근성 업무를 나눠야 하는 PM, 서비스 기획자, 디자이너, 퍼블리셔, 프론트엔드 개발자와 QA 담당자에게 적합합니다.
적용 기준, WCAG 목표 레벨, 테스트 환경과 서비스 기능을 선택하면 항목이 생성됩니다. 각 항목에서 상태와 메모·근거를 기록하고 역할이나 검사 축으로 필터링한 뒤 문서로 내보냅니다.
기준 번호만 있는 긴 목록을 역할과 실행 단계에 맞게 바꾸고, 프로젝트에 없는 기능을 해당 없음 후보로 확인하며, 검토 이력과 이슈를 한 형식으로 전달할 수 있기 때문입니다.