KWCAG 2.2 웹 접근성 검사항목을 개발 단계에서 지키는 방법

공공 웹사이트의 접근성 인증은 33개 검사항목의 평균 준수율 95% 이상과 장애인 사용자 심사원의 과업 성공률 100%를 함께 요구한다. 오픈 직전에 한꺼번에 고치면 공통 컴포넌트와 화면 수백 개를 다시 열어야 하므로, 항목마다 지키는 단계를 미리 정해 두는 편이 싸다. 이 글은 KWCAG 2.2 검사항목을 설계·컴포넌트·PR 자동 검사·수동 검사 네 단계에 나눠 배치하는 방법을 정리한 것이다.

한눈에 보기

자동 검사는 규칙 위반을 매번 같은 기준으로 잡지만, "이 대체 텍스트가 그림의 의미를 전하는가" 같은 판단은 못 한다. 그래서 뒤 두 단계는 사람이 맡는다.

인증 심사는 무엇을 보는가

아래는 인증기관인 한국정보접근성인증평가원(wa.or.kr)이 공개한 심사 기준을 2026년 11월 7일에 확인한 내용이다. 인증의 법적 근거는 「디지털포용법」으로 바뀌어 있다.

전문가 심사: 33개 검사항목 모두를 평균 준수율 95% 이상으로 지켜야 한다. 항목별 준수율은 대부분 "준수한 페이지 수 / 심사 대상 페이지 수 × 100"으로, 자막은 "준수한 콘텐츠 수 / 멀티미디어 콘텐츠 수 × 100"으로 셈한다. 한 화면에서 한 번만 어겨도 그 페이지는 미준수다.

사용자 심사: 전맹, 저시력, 지체(상지) 또는 뇌병변 장애 유형별 심사원이 회원가입, 로그인, 게시물 읽기 같은 과업을 수행한다. 모든 장애 유형의 과업 성공률이 100%여야 하고, 과업마다 15분 안에 끝내야 한다. PC 웹은 센스리더, 조스(JAWS), NVDA 같은 화면낭독 프로그램으로, 모바일 웹은 VoiceOver와 TalkBack으로 확인한다.

재심사와 사후관리: 전문가 심사 8595% 미만, 사용자 심사 85100% 미만이면 업무일 10일 안에 고쳐 2차 심사를 받을 수 있다. 인증은 1년 유효하고, 인증 뒤 6개월 안에 사후 모니터링을 한 번 받는다. 인증 뒤 바뀐 페이지가 20%를 넘으면 갱신심사, 50%를 넘으면 신규심사로 전환된다.

10일은 공통 컴포넌트 결함을 고치고 회귀 테스트까지 돌리기에 짧다. 개발 단계에서 막아야 하는 이유다.

33개 항목을 개발 역할로 나누기

검사항목은 인식·운용·이해·견고의 네 원칙 아래 묶인다. 「디지털포용법 시행령」의 인증 기준 네 가지(동등하게 인식, 동등하게 운용, 쉽게 이해, 견고하게)가 이 원칙과 같다. 항목 이름은 인증기관 심사 기준표의 표기를 그대로 옮겼다.

표의 오른쪽 열이 이 글의 핵심이다. 항목마다 담당이 없으면 모두가 "퍼블리셔가 보겠지"라고 넘기고, 결국 심사 직전 한 사람이 33개를 혼자 본다.

1단계: 화면 설계에서 정할 것

설계 단계 결정은 화면 수만큼 복제된다. 여기서 틀리면 수정 비용도 화면 수만큼 든다.

할 일

• 텍스트 색과 배경 색 조합을 디자인 토큰으로 고정하고, 조합마다 명도 대비를 계산해 둔다. WCAG 기준으로 일반 텍스트는 4.5:1, 큰 텍스트는 3:1 이상이다. 세부 예외는 지침 원문을 확인한다.
• 필수 입력 표시, 그래프 범례, 오류 상태를 색만으로 구분하지 않는다. 별표, 글자, 아이콘 모양을 같이 쓴다.
• 화면 설계서의 이미지마다 대체 텍스트 칸을 둔다. 기획자가 의미를 정해야 개발자가 "이미지"나 파일명을 넣지 않는다.
• 페이지마다 h1부터 이어지는 제목 구조를 정한다. 화면낭독 사용자는 제목 목록으로 페이지를 훑는다.
• 세션 만료처럼 시간 제한이 있는 화면을 목록으로 만들고, 만료 전 알림과 연장 버튼을 설계에 넣는다(응답시간 조절).
• 초점 표시 스타일을 디자인 시스템에 그린다. 디자인에 없으면 개발자가 outline: none만 남긴다.

산출물: 대비가 검증된 색 토큰표, 대체 텍스트가 채워진 화면 설계서, 시간 제한 화면 목록.

2단계: 공통 컴포넌트에 넣을 것

운용 원칙 15개 항목 대부분은 버튼, 폼, 모달, 탭, 드롭다운 같은 공통 컴포넌트에서 결정된다. 컴포넌트 하나를 고치면 수백 화면이 같이 고쳐진다.

할 일

• 클릭 가능한 요소는 button이나 a로 만든다. div에 onclick을 달면 키보드로 닿지 않는다.
• 모든 입력에 label을 연결하고, 오류는 입력 옆에 글자로 보여 주며 첫 오류 칸으로 초점을 옮긴다(레이블 제공, 오류 정정).
• 본문 바로가기 링크를 레이아웃 맨 앞에 두고, html에 lang="ko"를 넣는다(반복 영역 건너뛰기, 기본 언어 표시).
• 새 창이 열리는 링크와 자동으로 바뀌는 슬라이드에는 알림과 정지 버튼을 둔다(사용자 요구에 따른 실행, 정지 기능 제공).
• 모달은 열릴 때 안으로 초점을 옮기고, 닫히면 연 버튼으로 초점을 돌려준다.

<button type="button" id="open-terms" aria-haspopup="dialog">약관 전문 보기</button>
<dialog id="terms-dialog" aria-labelledby="terms-title">
  <h2 id="terms-title" tabindex="-1">이용약관</h2>
  <p>…</p>
  <form method="dialog"><button>닫기</button></form>
</dialog>

const opener = document.querySelector<HTMLButtonElement>('#open-terms')!;
const dialog = document.querySelector<HTMLDialogElement>('#terms-dialog')!;

opener.addEventListener('click', () => {
  dialog.showModal();                                // 바깥 콘텐츠는 조작 불가, Esc로 닫힘
  dialog.querySelector<HTMLElement>('#terms-title')?.focus();
});
dialog.addEventListener('close', () => opener.focus()); // 닫으면 연 버튼으로 초점 복귀

div로 만든 모달은 초점이 뒤 화면으로 빠져나가 화면낭독 사용자가 모달이 열린 줄 모른다. 네이티브 dialog의 showModal()이 이 문제를 줄여 준다.

3단계: PR마다 자동 검사

사람이 매번 보지 않아도 되는 규칙은 CI에 맡긴다.

정적 검사: React는 eslint-plugin-jsx-a11y, Svelte는 svelte-check의 a11y 경고로 대체 텍스트 누락, 클릭 요소의 키보드 처리 누락을 PR에서 잡는다. 경고를 기존 개수 이상 늘리지 않는 규칙을 둔다.

렌더링 결과 검사: 실제 화면을 띄워 axe-core로 검사한다. 대비, 레이블, 중복 id, ARIA 속성 오류처럼 DOM과 계산된 스타일로 판정할 수 있는 항목을 잡는다.

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

const paths = ['/', '/notice', '/apply/step1'];

for (const path of paths) {
  test(`접근성 자동 검사: ${path}`, async ({ page }) => {
    await page.goto(path);
    const results = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
      .analyze();
    // 필요한 필드만 골라 실패 메시지를 짧게 만든다
    const found = results.violations.map((v) => `${v.id} (${v.impact}) ×${v.nodes.length}`);
    expect(found).toEqual([]);
  });
}

검사 대상 경로는 심사 대상이 될 대표 화면(메인, 목록, 상세, 입력, 로그인)으로 고른다. 모달이나 탭처럼 열어야 보이는 상태는 클릭한 뒤 한 번 더 analyze()한다.

Lighthouse 접근성 점수는 추세를 보는 데 쓴다. 100점이어도 인증 통과를 뜻하지 않는다. 자동 도구가 판정하는 항목은 33개 중 일부이고, 판정하는 항목도 "있는가"까지만 본다. 성능 지표를 같은 CI에 함께 걸고 있다면 Web Performance 최적화: INP·LCP·CLS 실전 분석의 측정 방식과 묶어 운영할 수 있다.

4단계: 사람이 확인해야 하는 것

자동 검사가 통과한 화면도 사용자 심사에서 떨어진다. 사람이 봐야 하는 항목은 정해져 있다.

절차: QA 단계에서 사용자 심사와 같은 과업 목록을 만든다. 각 과업을 NVDA나 센스리더와 키보드만으로 15분 안에 끝내는지 재고, 모바일 웹은 VoiceOver와 TalkBack 두 가지로 반복한다. 끝내지 못한 과업은 원인 화면과 항목 이름을 붙여 공통 컴포넌트 담당에게 돌려보낸다.

접근성을 비기능 요구사항의 하나로 정의하고 검수 기준을 정하는 방법은 공공 SI 비기능 요구사항 정의와 검증 기준 설계에서 다뤘다. 이 글의 과업 목록이 그 검수 기준의 실행 절차가 된다.

자주 하는 실수

오픈 한 달 전에 처음 점검한다. 2차 심사 수정 기간은 업무일 10일이고, 공통 컴포넌트 수정은 전 화면 회귀 테스트를 부른다.

alt를 파일명이나 "이미지"로 채운다. 자동 검사는 통과하지만 전문가 심사의 적절한 대체 텍스트 제공에서 미준수가 된다.

초점 표시를 outline: none으로 지운다. 디자인이 깔끔해 보이는 대가로 키보드 사용자는 자기 위치를 잃고, 초점 이동과 표시 항목을 어긴다.

axe 결과 0건을 인증 준비 완료로 본다. 링크 텍스트, 초점 순서, 과업 완료는 사람만 판정한다.

인증 뒤 콘텐츠 운영을 놓친다. 운영자가 올린 배너와 게시물의 대체 텍스트가 빠지면 사후 모니터링에서 걸리고, 변경 페이지가 20%를 넘으면 갱신심사로 넘어간다.

점검표

• 33개 검사항목마다 책임 역할(디자인·퍼블리싱·컴포넌트·운영)이 표에 적혀 있다.
• 색 토큰의 텍스트·배경 조합마다 명도 대비 값이 기록되어 있다.
• 화면 설계서의 모든 의미 있는 이미지에 대체 텍스트가 정해져 있다.
• 모든 클릭 요소가 button 또는 a이고 Tab으로 닿는다.
• 초점 표시 스타일이 디자인 시스템에 있고 어떤 화면에서도 지워지지 않는다.
• 모달을 닫으면 초점이 연 버튼으로 돌아간다.
• 폼 오류가 글자로 표시되고 첫 오류 칸으로 초점이 옮겨진다.
• PR마다 정적 a11y 검사와 Playwright + axe-core 검사가 돌고, 위반이 있으면 실패한다.
• 사용자 심사와 같은 과업 목록을 화면낭독 프로그램과 키보드만으로 15분 안에 끝냈다.
• 인증 뒤 콘텐츠 등록 화면에 대체 텍스트 입력이 필수로 되어 있다.

KWCAG 2.2 인증은 심사 직전의 일괄 점검으로는 맞추기 어렵고, 33개 항목을 설계·컴포넌트·자동 검사·수동 검사 단계에 나눠 맡겨 두었을 때 개발 과정에서 자연스럽게 지켜진다.