개념
이 레슨이 다루지 않는 것
접근성은 이 커리큘럼에서 이미 두 곳이 맡고 있다. WCAG 2.2 의 성공 기준과 판정 절차는 레슨 s5-m49-l05, 스크린 리더로 확인하는 절차는 s5-m49-l06(데스크톱)과 s5-m52-l06(모바일) 이다. NVDA 를 어떻게 조작하고 대체 텍스트를 어떻게 판정하는지는 거기서 다룬다. 이 레슨은 그 내용을 반복하지 않는다.
여기서 다루는 것은 국내에서만 성립하는 층 이다. 한국에서 웹 접근성은 "좋은 실천"이 아니라 법령이 부과한 의무 이고, 공공 발주에서는 인증이 산출물로 걸리는 계약 항목 이다. 그래서 QA 가 해야 하는 일은 기준을 아는 것이 아니라 의무를 검수에서 판정 가능한 문장으로 옮기고, 판정에 쓸 증거를 설계하는 것 이다. 절차·검수조서 자체는 모듈 56 레슨 3 이 맡고, 여기서는 기술 규격 쪽 — 무엇을 어떻게 확인해 합격으로 볼 것인가 — 만 본다.
의무의 층 구조
국내 웹 접근성 의무는 두 법률과 하나의 국가표준이 만든다. 조문 번호는 국가법령정보센터에서 직접 확인해 인용한다. 아래는 이 레슨 작성 시점에 조회·대조한 범위다.
| 층 | 문서 | 성격 | QA 가 얻는 것 |
|---|---|---|---|
| 법률 | 「장애인차별금지 및 권리구제 등에 관한 법률」 제21조(정보통신·의사소통 등에서의 정당한 편의제공 의무) | 차별 금지와 정당한 편의 제공 의무 | "왜 해야 하는가"의 근거. 위반은 차별로 다뤄진다 |
| 시행령 | 같은 법 시행령 제14조 | 정당한 편의의 내용과 단계적 적용 범위(의무자 유형별 적용 시기) | "우리 기관·기업이 대상인가"의 근거 |
| 법률 | 「지능정보화 기본법」 제46조(장애인·고령자 등의 정보 접근 및 이용 보장), 제47조(정보통신접근성 품질인증) | 접근성 보장 의무와 품질인증 제도 | 인증 제도의 근거 |
| 국가표준 | KS X OT0003 「한국형 웹 콘텐츠 접근성 지침」 | 무엇을 지켜야 하는지의 검사항목 | 실제 판정 기준 |
국가표준은 한국지능정보사회진흥원(NIA)이 국제표준(WCAG) 개정을 반영해 갱신해 왔다. NIA 보도자료에서 확인되는 최근 개정은 2022년 12월 28일 이고, 개정판의 구성은 원칙(principle) · 지침(guideline) · 검사항목(requirement) 3단계, 4원칙 14지침 33검사항목 이다. 개정 전 24개 검사항목에 9개가 추가된 형태로, WCAG 2.1/2.2 의 개정 내용을 반영했다.
판번호와 시행일은 반드시 다시 확인한다. 국가표준은 개정되고, 개정 시점에 검사항목 수가 바뀐다. e나라 표준인증(
standard.go.kr)이나 표준 판매처에서 현행 판의 제정·개정 이력을 조회하고, 사업 문서에는 조회한 날짜와 함께 적는다. 제안서에 "KWCAG 2.1 기준"이라고 적힌 채로 착수해 검수 때 판번호로 다투는 일이 실제로 일어난다.
시행령 제14조의 의무자 유형별 단계적 적용 시기 는 표 형태로 되어 있고 유형이 많다. 우리 사업의 발주 기관·사업자가 어느 유형에 해당하는지는 시행령 별표를 직접 보고 판정한다 — 2차 자료의 요약표는 오래된 경우가 많다. 이 레슨은 유형별 적용 시기를 옮겨 적지 않는다(원문 확인).
정보통신접근성 품질인증
품질인증은 접근성 준수 여부를 지정된 기관이 심사해 인증마크를 부여하는 제도다. 근거는 「지능정보화 기본법」 제47조 이고, 신청 서식은 같은 법 시행규칙의 별지 서식 (정보통신접근성 품질인증 신청서 — 웹사이트 / 이동통신단말장치에 설치되는 응용 소프트웨어)으로 존재한다. 확인된 사실은 다음과 같다.
- 인증기관은 과학기술정보통신부장관이 지정 한다. 법 제47조가 지정 근거를 두고, 지정받으려는 자가 신청하는 구조다
- 지정 인증기관으로 확인되는 곳은 한국웹접근성인증평가원, 한국디지털접근성진흥원, 웹와치 다. 현재 지정 현황은 과기정통부·인증기관 공지에서 다시 확인한다
- 유효기간은 1년 이다
- 인증 대상은 웹사이트와 모바일 앱을 포함한다. 그 밖의 대상(키오스크 등)의 포함 여부와 근거 조문은 원문 확인 대상이다
심사 절차의 소요 기간·수수료·보완 절차 세부는 인증기관마다 공지가 다르므로 기관 공지를 직접 확인 한다. 다만 QA 가 일정을 잡을 때 전제할 것 두 가지는 확실하다. 인증은 신청 후 즉시 나오지 않고, 보완 요구가 오면 재심사가 따른다. 그리고 유효기간이 1년이므로 사업 종료 후 갱신 책임이 누구에게 있는지가 계약에 적혀 있어야 한다.
검수 기준 문장으로 옮기기
여기가 이 레슨의 본론이다. 발주 문서에는 보통 이렇게 적혀 있다.
"웹 접근성 지침을 준수하여 개발하고, 정보통신접근성 품질인증을 획득한다."
"주요 웹 브라우저에서 정상 동작하여야 한다."두 문장 모두 판정할 수 없다. QA 가 할 일은 이것을 다음 형태로 바꾸는 것이다. 모듈 41(금융 IT)에서 규제 조문을 "조문 → 통제 → 증거"로 옮긴 것과 같은 구조다.
[근거] 무엇이 요구하는가 (법령·표준·계약 조항)
[대상] 어디에 적용되는가 (화면 범위·표본 기준)
[판정 문장] 무엇을 어떻게 확인하면 합격인가 (측정 가능한 문장)
[방법] 누가 어떤 도구·절차로 확인하는가
[증거] 무엇을 남기는가 (보고서·캡처·로그·심사 결과)접근성 검사항목 하나를 이 형태로 옮기면 이렇게 된다.
| 칸 | 예 |
|---|---|
| 근거 | KS X OT0003 검사항목 — 텍스트 아닌 콘텐츠의 대체 텍스트 제공 (판번호·조회일 명시) |
| 대상 | 전체 화면 중 표본 30화면. 표본 기준: 대국민 서비스 주요 흐름 전 화면 + 업무 화면 중 기능군별 2개 |
| 판정 문장 | 표본 화면의 의미 있는 이미지 전부에 대체 텍스트가 있고, 그 내용이 이미지가 전달하는 정보와 일치한다. 장식용 이미지는 보조기술에 노출되지 않는다 |
| 방법 | 자동 도구로 누락 탐지 → 누락 아닌 항목의 내용 적절성은 수동 검토(검토자 2인, 불일치 시 3인째 판정) |
| 증거 | 도구 리포트(원본 파일), 수동 검토 시트(화면 ID·이미지 위치·판정·사유), 재검 이력 |
이 표의 힘은 "방법"과 "증거" 칸 에서 나온다. 접근성 결함은 검수 자리에서 "이건 문제 아니다"라는 반론이 가장 자주 나오는 영역인데, 판정 절차와 판정자가 미리 합의돼 있으면 논쟁이 짧아진다.
브라우저 지원 범위 — 웹 표준 쪽
"주요 브라우저 정상 동작"도 같은 방식으로 바꾼다. 여기서 정해야 하는 것은 세 가지다.
1. 대상 브라우저와 버전 하한
예) 최신 안정 버전 및 직전 1개 버전, 특정 브라우저는 운영체제 내장 버전 기준
근거: 기관 접속 통계(최근 3개월) — 없으면 발주처에 요청, 그래도 없으면 합의로 고정
2. 등급
A(전 기능 동작·레이아웃 동일) / B(전 기능 동작·경미한 시각 차이 허용) / C(핵심 흐름만 보장)
브라우저별로 등급을 배정한다. 전부 A 는 현실적이지 않다
3. 판정 방법
A 등급 브라우저에서 핵심 흐름 전수 + 화면 표본 비교
B·C 는 핵심 흐름만. 확인 결과는 브라우저·버전·확인일과 함께 기록등급을 나누지 않으면 사용률 0.3% 브라우저의 픽셀 어긋남이 검수 지적으로 올라온다. 등급을 정해 두면 그 항목은 "B 등급에서 허용된 시각 차이"로 종결된다. 접속 통계가 없다고 미루지 말고 합의로 고정 한다 — 기준이 없는 것보다 임의의 기준이라도 문서에 있는 편이 낫다.
오래된 공공 시스템을 개편하는 사업에는 비표준 기술 제거 확인 이 더 붙는다. 플러그인 기반 요소, 특정 브라우저 전용 API, 문서 모드를 강제하는 메타 태그 같은 잔재가 남아 있으면 특정 환경에서만 동작하는 화면이 생긴다. 소스 검색으로 후보를 뽑고, 후보가 있는 화면만 대상 브라우저 전체에서 확인하는 것이 비용이 적다.
자동 점검과 수동 점검의 분업
접근성 점검에서 가장 흔한 실패는 자동 도구 결과를 준수 근거로 제출하는 것 이다. 자동 도구는 기계가 판정할 수 있는 것만 판정한다. 분업의 원칙은 단순하다.
| 구분 | 자동 도구가 할 수 있는 일 | 수동 점검이 해야 하는 일 |
|---|---|---|
| 대체 텍스트 | 속성의 존재/부재 탐지 | 내용이 이미지의 의미와 맞는가, 장식 이미지가 올바르게 숨겨졌는가 |
| 제목·레이블 | 요소의 유무, 중복 | 내용이 기능을 설명하는가 |
| 색 대비 | 대비 비율 계산 | 배경 이미지 위 텍스트, 상태별 색상, 실제 렌더링 결과 |
| 키보드 접근 | 일부 패턴 탐지 | 전 기능의 키보드 조작 가능 여부, 초점 이동 순서, 초점 표시, 함정 없음 |
| 동적 콘텐츠 | 정적 마크업 일부 | 변경 알림 전달, 모달 초점 관리, 시간 제한 조절 |
| 콘텐츠 이해 | 거의 불가 | 표의 구조, 오류 안내의 구체성, 반복 영역 건너뛰기의 실제 효용 |
운용 원칙은 이렇다 — 자동 도구는 전 화면에 돌려 명백한 누락을 걷어내고, 수동 점검은 표본 화면에 집중한다. 자동 도구로 걸러지는 결함은 수가 많지만 고치기 쉽고, 수동 점검에서 나오는 결함은 수가 적지만 설계를 건드린다. 그래서 수동 점검을 뒤로 미루면 고칠 수 없는 시점에 발견된다. 설계 단계에서 주요 화면 3~5개를 먼저 수동 점검하는 것이 전체 비용을 가장 크게 줄인다.
도구 선택은 이 레슨의 범위가 아니지만 두 가지는 정해 둔다. 리포트 원본 파일을 증거로 보관 하고(캡처만 남기면 재현이 안 된다), 도구 버전과 점검 일시를 기록 한다.
인증이 산출물로 걸렸을 때 — 일정 역산
발주 문서에 "품질인증 획득"이 산출물로 적혀 있으면, 그 시점은 검수일보다 앞이어야 한다. 역산의 뼈대는 이렇다.
검수일
← 인증서 발급·제출
← 최종 심사 (보완 후 재심사가 있을 수 있음)
← 보완 조치 + 재확인
← 1차 심사
← 인증 신청 (기관 서식·수수료·대상 화면 목록 준비)
← 사전 자체 점검 완료 (자동 전수 + 수동 표본, 결함 조치 완료)
← 수동 점검 1차 (설계 영향이 있는 결함을 여기서 잡는다)맨 아래 두 줄의 위치가 이 역산의 핵심이다. 사전 자체 점검을 인증 신청 직전에 처음 하면, 설계를 건드려야 하는 결함이 그 시점에 나온다. 그러면 조치가 개발 일정과 충돌하고, 결국 인증이 검수일 뒤로 밀린다. 자체 점검은 개발 완료를 기다리지 않고 화면이 나오는 대로 시작한다.
계약 측면에서 QA 가 착수 시점에 확인해 둘 것은 세 가지다. 인증 대상 범위 (전체 사이트인가, 특정 서비스인가, 모바일 앱이 포함되는가), 비용과 신청 주체 (수행사인가 발주처인가), 유효기간 1년 이후의 갱신 책임 이다. 세 번째는 검수 이후의 일이라 사업 중에는 아무도 묻지 않다가 1년 뒤 분쟁이 된다.
실무에서 왜 필요한가
접근성이 검수에서 문제가 되는 이유는 기술적으로 어려워서가 아니라 판정 기준이 늦게 정해지기 때문 이다. 개발은 "지침을 준수해 개발했다"고 말하고, 발주처는 "이 화면은 스크린 리더로 읽히지 않는다"고 말한다. 두 문장은 서로를 반박하지 못한다. 근거와 대상과 판정 문장과 방법이 없기 때문이다. 이 레슨의 다섯 칸짜리 표를 착수 시점에 만들어 두면 그 대화가 항목별 판정으로 바뀐다.
법령 근거를 정확히 아는 것도 실무적 이유가 있다. 접근성 요구는 종종 "권장 사항 아니냐"는 반론을 받는데, 국내에서는 차별 금지 법률이 근거 라는 점이 대화의 출발선을 바꾼다. 반대로 QA 가 조문 번호를 틀리게 인용하면 나머지 주장의 신뢰도까지 같이 떨어진다. 그래서 이 레슨은 확인한 것만 조문 번호를 붙였고, 시행령 별표의 단계적 적용 시기처럼 직접 대조하지 않은 것은 원문 확인 으로 남겼다. 이 규율을 그대로 따라 쓰는 것이 안전하다.