적합성 평가와 WCAG-EM

목표 수준과 다섯 가지 적합성 요구사항

Target Level and the Five Conformance Requirements

평가의 첫 결정은 목표 적합성 수준입니다. 사실상의 세계 표준이자 대부분 법률의 기준은 Level AA(A 포함)이며, AAA는 전체 사이트 요구가 아니라 선별 적용이 권장됩니다. 목표 수준은 검사할 성공 기준의 집합을 결정합니다 — WCAG 2.2 기준 A 32개 + AA 24개.

An evaluation's first decision is the target conformance level. Level AA (which includes A) is the de facto global standard and the basis of most laws; AAA is recommended selectively, not site-wide. The target level determines the set of success criteria to test — in WCAG 2.2, 32 at A plus 24 at AA.

WCAG 적합성 주장에는 다섯 가지 요구사항이 있습니다: ① 적합성 수준 — 목표 수준의 모든 SC를 충족(또는 적합한 대체 버전 제공), ② 전체 페이지 — 페이지 일부만의 적합성은 불가(위젯 하나라도 실패하면 페이지가 실패), ③ 완전한 프로세스 — 결제처럼 여러 페이지로 이어지는 과업은 모든 단계가 적합해야, ④ 접근성 지원 방식의 기술 사용, ⑤ 비간섭 — 적합하지 않은 기술이 있어도 나머지 콘텐츠의 이용을 방해(키보드 트랩, 자동재생, 섬광 등)하지 않아야 합니다.

A WCAG conformance claim has five requirements: ① conformance level — all SCs at the target level satisfied (or a conforming alternate version provided); ② full pages — no partial-page conformance (one failing widget fails the page); ③ complete processes — multi-page tasks like checkout must conform at every step; ④ accessibility-supported ways of using technologies; ⑤ non-interference — non-conforming technology must not block use of the rest (keyboard traps, autoplay, flashing).

WCAG-EM — 5단계 평가 방법론

WCAG-EM — The Five-Step Evaluation Methodology

WCAG-EM(Website Accessibility Conformance Evaluation Methodology)은 W3C가 발행한 사이트 단위 적합성 평가 절차입니다(비규범 노트). 5단계: ① 평가 범위 정의(대상 사이트 경계, 목표 수준, 접근성 지원 기준선 — 지원한다고 가정할 브라우저·AT 조합), ② 사이트 탐색(공통 페이지, 핵심 기능, 다양한 페이지 유형·기술 파악), ③ 대표 표본 선정(구조화 표본 + 무작위 표본 — 전수 검사가 불가능한 큰 사이트의 현실적 해법), ④ 표본 평가(적합성 요구사항에 따라 SC별 판정, 실패 기록), ⑤ 결과 보고(판정 근거, 점수화는 선택).

WCAG-EM (Website Accessibility Conformance Evaluation Methodology) is the W3C's procedure for site-level conformance evaluation (a non-normative note). Five steps: ① define the evaluation scope (site boundary, target level, accessibility-support baseline — the browser/AT combinations assumed supported); ② explore the site (common pages, essential functionality, the variety of page types and technologies); ③ select a representative sample (structured plus random — the realistic answer when auditing every page is impossible); ④ audit the sample (judge each SC per the conformance requirements, record failures); ⑤ report findings (with evidence; scoring optional).

핵심 개념은 3단계의 표본 추출입니다: 홈·로그인·검색 같은 공통 페이지와 핵심 프로세스는 반드시 포함하고, 페이지 유형·템플릿·기술별 대표를 고른 뒤, 무작위 표본을 더해 선택 편향을 통제합니다. 무작위 표본에서 구조화 표본에 없는 유형의 실패가 나오면 표본이 대표성을 잃었다는 신호입니다.

The heart is step 3's sampling: always include common pages (home, login, search) and essential processes, pick representatives per page type, template, and technology, then add a random sample to control selection bias. Failures in the random sample of kinds absent from the structured sample signal the sample lost representativeness.

성공 기준·실패 판정

Assigning Success Criteria and Failures

발견한 이슈는 올바른 성공 기준에 할당해야 합니다 — 같은 증상도 원인에 따라 SC가 다릅니다. 예: '버튼을 키보드로 조작 불가'는 2.1.1(키보드)이지만, '포커스는 가나 보이지 않음'은 2.4.7(포커스 표시), '이름이 없어 스크린 리더가 읽지 못함'은 4.1.2(이름·역할·값)입니다. WCAG의 문서화된 실패(Failure) 기법(F 번호)은 특정 SC를 확실히 위반하는 패턴의 목록으로, 판정의 근거로 인용할 수 있습니다.

Found issues must be assigned to the right success criterion — the same symptom maps to different SCs by cause. 'Button not keyboard-operable' is 2.1.1 (Keyboard); 'focus moves but is invisible' is 2.4.7 (Focus Visible); 'no accessible name so screen readers announce nothing' is 4.1.2 (Name, Role, Value). WCAG's documented Failures (F-numbers) list patterns that definitively violate specific SCs and can be cited as evidence.

판정 시 주의: 성공 기준은 '충족/미충족/해당 없음'으로 판정하며, 해당 콘텐츠가 없으면 N/A입니다(예: 오디오가 없는 페이지의 1.2.x). 하나의 결함이 여러 SC를 동시에 위반할 수 있고, 반대로 나쁜 UX라도 어떤 SC도 위반하지 않으면 적합성 실패는 아닙니다 — 이 경우 '모범 사례 권고'로 구분해 보고하는 것이 정직한 감사입니다.

Judgment cautions: each SC is judged satisfied / not satisfied / not applicable — N/A when the content type is absent (1.2.x on a page with no audio). One defect can violate several SCs at once; conversely, bad UX that violates no SC is not a conformance failure — honest audits report it separately as a best-practice recommendation.

가이드라인의 한계와 QA 통합

Guideline Limitations and QA Integration

WCAG 적합이 곧 '모두에게 사용 가능'은 아닙니다. BoK가 명시하는 한계: 인지 장애·저시력 사용자의 요구 중 상당수는 AA 기준으로 완전히 담보되지 않고, 테스트 가능성을 위해 기준이 보수적으로 좁게 정의된 영역이 있으며, 신기술·네이티브 앱 영역은 커버리지가 얕습니다. 그래서 적합성 평가와 별개로 사용성 테스트와 장애인 사용자 피드백이 필요합니다.

WCAG conformance is not 'usable by everyone.' Limitations the BoK names: many needs of users with cognitive disabilities and low vision aren't fully guaranteed at AA; some criteria are defined narrowly and conservatively for testability; coverage of new technologies and native apps is thin. Hence usability testing and feedback from disabled users are needed alongside conformance evaluation.

평가를 일회성 감사로 끝내지 않으려면 QA 프로세스에 통합해야 합니다: 요구사항 단계에서 접근성 수용 기준(acceptance criteria) 명시, 디자인 리뷰 체크리스트, PR 단위 자동 검사, 릴리스 전 수동 스모크 테스트(키보드·스크린 리더 핵심 경로), 주기적 WCAG-EM 감사와 회귀 추적. '완료 정의(Definition of Done)'에 접근성을 포함하는 것이 구조적 해법입니다.

To keep evaluation from being a one-off audit, integrate it into QA: accessibility acceptance criteria at the requirements stage, design review checklists, automated checks per PR, pre-release manual smoke tests (keyboard and screen reader on critical paths), and periodic WCAG-EM audits with regression tracking. Putting accessibility in the Definition of Done is the structural fix.