접근성 검사 기준

Q. 스크린리더, 그거 사용자가 돈 주고 사야 하는 거 아닌가요?

아니요. 스크린리더는 대부분 이미 사용자의 기기 안에 무료로 들어 있습니다. 아이폰·맥에는 VoiceOver, 안드로이드에는 TalkBack, 윈도우에는 내레이터(Narrator)가 기본 내장되어 있고, 설정에서 켜기만 하면 됩니다. 윈도우용 무료 오픈소스 NVDA도 실사용자가 많습니다. (JAWS처럼 기업·기관에서 주로 쓰는 유료 제품도 있지만, 이건 선택지 중 하나일 뿐 "필수 구매품"이 아닙니다.)

즉 시각장애인이 아이폰을 사면, 그 안에 스크린리더가 이미 켜질 준비가 되어 있는 겁니다. 앱스토어에서 따로 결제하는 물건이 아니에요. 그래서 "사용자가 비싼 장비를 안 사서" 웹사이트를 못 쓰는 게 아니라, "이미 손에 쥔 무료 도구가 읽어낼 수 있는 방식으로 사이트가 안 만들어져서" 못 쓰는 경우가 대부분입니다.

Q. 스크린리더가 알아서 화면을 읽어주는 거 아닌가요? 왜 우리가 따로 작업해야 하죠?

스크린리더는 화면을 "눈으로 보고" 읽는 게 아니라, HTML 코드의 구조를 읽습니다. 사람은 화면을 보고 "저건 버튼이구나", "저건 중요한 제목이구나"를 눈으로 바로 판단하지만, 스크린리더는 코드에 그렇게 "표시"되어 있어야만 알 수 있습니다.

예를 들어 이미지에 대체텍스트(alt)가 없으면 스크린리더는 그 이미지를 그냥 "이미지" 또는 파일명(IMG_20260814.jpg)으로 읽어버립니다. 버튼처럼 디자인만 해놓고 실제로 버튼이라는 표시가 코드에 없으면, 스크린리더는 그게 눌러야 하는 버튼인지조차 모르고 그냥 지나칩니다.

e.g. <div onclick> — 시각적으로는 버튼처럼 보이지만, 코드상으로는 버튼으로 선언되지 않은 경우

즉 화면상으로는 완벽하게 예쁜 사이트라도, 스크린리더 입장에서는 아무 정보도 없는 텅 빈 페이지일 수 있습니다. 웹접근성 작업이란 결국 이 구조를 스크린리더(그리고 다른 모든 보조기기)가 이해할 수 있는 형태로 "번역"해 두는 작업입니다.

Q. 그럼 점자 스크린/점자 키보드를 쓰는 분들은요? 사이트가 점자를 따로 지원해야 하나요?

아니요, 별도 지원이 필요 없습니다 — 그리고 이게 진짜 핵심입니다. 점자 디스플레이(점자정보단말기)는 독립적으로 작동하는 기기가 아니라, 스크린리더에 연결되는 주변기기입니다. 스크린리더가 코드에서 읽어낸 것과 완전히 똑같은 정보(요소의 이름·역할·값)를 점자 변환 엔진이 그대로 받아서 점자로 바꿔 출력할 뿐입니다.

다시 말해 시맨틱 HTML과 ARIA 구조를 제대로 지키면, 점자 지원은 개발자가 아무것도 더 하지 않아도 자동으로 따라옵니다. "음성용 작업"과 "점자용 작업"이 따로 있는 게 아니라, 구조를 한 번 제대로 만들어 두면 음성이든 점자든 그 위에 붙는 출력 방식일 뿐이라는 뜻이에요.

참고로 국내 등록 시각장애인 중 점자를 읽을 수 있는 분은 약 9.6%에 불과합니다(90% 이상은 점자를 모릅니다). 그래서 핵심은 "점자 전용 기능"을 따로 만드는 게 아니라, 구조를 정확히 갖추면 음성이든 점자든 스위치 기기든 어떤 보조기기가 붙어도 다 통한다는 사실입니다.

그리고 이 지점이 중요합니다 — 점자정보단말기(400~500만원대 전용기기, 점자 입력용 키보드 + 실시간으로 핀이 오르내리는 점자 디스플레이가 한 몸에 있는 장비)를 마련하는 비용 부담은 사용자·복지제도의 몫이지, 사이트가 짊어질 몫이 아닙니다. 사이트/개발자가 할 일은 딱 하나, 표준 구조를 정확히 갖추는 것뿐입니다. 그 이후 그 정보를 음성으로 바꾸든(무료 스크린리더) 점자로 바꾸든(고가의 전용기기) 은 전적으로 사용자 쪽 소프트웨어·하드웨어의 역할이며, 사이트가 "점자를 직접 만들어 보내는" 것이 아닙니다.

Q. 법적으로 꼭 해야 하는 건가요? 국내에도 인증마크가 있나요?

네, 실제로 존재합니다. 국내에는 "웹접근성 품질인증마크"(WA마크) 제도가 있고, 인증기관은 한국정보접근성인증평가원·웹와치·한국디지털접근성진흥원 등입니다. 공공기관은 지능정보화기본법에 따라 웹접근성 지침(현행 KWCAG 2.2, 4대 원칙·14개 지침·33개 검사항목) 준수가 법적 의무입니다.

다만 "지침을 지키는 것"과 "제3자 인증서를 취득하는 것"은 별개입니다 — 인증 취득 자체는 의무가 아니라서, 실제로는 지침을 완전히 준수하는 곳이 많지 않습니다. WIA A11Y는 WCAG 2.2 AA 핵심 성공기준을 포함해 EPUB만 60개 이상의 세부 항목으로 KS X 6201 + EPUB Accessibility 1.1 + EU EAA + PDF/UA까지 한 번에 검사합니다. 다만 KWCAG 33개 항목 중 키보드 조작·포인터 입력·폼 오류·도움말처럼 "동적 상호작용"을 요구하는 항목들은 정적 파일(EPUB/PDF) 검사 특성상 구조적으로 판정하기 어려운 부분이 있어, 이 부분은 웹사이트(HTML) 검사의 axe-core 엔진 쪽에서 보완합니다 (포맷별 상세 항목은 위 "검사 기준" 섹션 참고).

즉 "국가가 요구하는 법정 최소선"과 "자동화 도구가 잡아내는 기술적 세부 규칙" 사이의 간극을, 여러 국제표준을 함께 매핑해서 메우는 방식입니다.

Q. 이거 지금 당장 급한 건가요, 나중에 여유 될 때 해도 되나요?

전 세계적으로 빠르게 강화되는 흐름입니다. 유럽은 2025년 6월부터 유럽접근성법(EAA)이 시행되어, 대상 사업자가 위반 시 매출의 최대 4%에 달하는 과징금을 물 수 있습니다. 미국에서는 웹접근성 관련 소송이 2025년에만 전년 대비 27% 증가(3,117건)했고, 디지털 접근성 소프트웨어 시장 자체도 매년 커지는 중입니다.

즉 "여유 있을 때 하면 되는 선택 사항"이라기보다, 먼저 대응해 둔 쪽이 유리해지는 흐름에 가깝습니다. 특히 공공기관 납품이나 전자출판물을 다루는 경우라면 더더욱 그렇습니다.

🇰🇷 국내 법률 (5개)

• 📕 장애인차별금지법 제21조 — 전자출판물 동등 접근 제공 의무
• 📘 지능정보화기본법 제46조 — 정보 서비스 접근성 보장
• 📗 디지털포용법 제19조 — 디지털취약계층 접근성 (2026.1.22 시행)
• 📙 도서관법 제7조 — 모든 국민 공평한 도서관서비스
• 📓 장애인복지법 제22조 — 점자·음성도서 의사소통 보조

🌍 국제 표준 + 선제 대응

• 🔷 EPUB 3.3 (W3C, 2025) — 최신 전자출판 표준
• 🔷 EPUB Accessibility 1.1 (W3C, 2024.10)
• 🔷 WCAG 2.2 Level AA (W3C, 2024) — 웹 접근성 최신
• 🔷 WAI-ARIA 1.2 (W3C, 2023) + DPUB-ARIA 1.1
• 🔷 EU EAA (2019/882, 2025.6 시행) — 유럽 접근성법
• 🟢 KS X 6201-1 (2022) — 한국 전자책 접근성 저작지침
• 🟢 KS X 6201-2 (2024) — 적합성 수준별 기준
• 🟡 PDF/UA-1 (ISO 14289-1) — PDF 접근성 국제표준
• 🟣 ACE by DAISY — 국제데이지컨소시엄 검증 도구
• 🟣 ONIX 접근성 코드 — 국제 유통 메타데이터 호환

개체 목차 (이미지/표 별도 nav) 각주 양방향 링크 자동 생성 Section+ARIA 자동 래핑 시맨틱 태그 자동 변환 (b→strong) figure+figcaption 자동 래핑 다국어 접근성 요약 (127개 언어) 명도대비 4.5:1 자동 검사 3D 수어 아바타 연동 (WIA Talk) 점자 디스플레이 최적화 (WIA Braille) 햅틱 피드백 메타데이터 (WIA Haptic) 섬네일 224×314px/DPI=139 (납품 규격) EPUB 200MB 이하 용량 게이트

감점 기준

심각도별 항목 수

🆓 무료 배지 (85점 이상 자동 발급)

결과 페이지에서 즉시 발급, 결제·신청 절차 없음

• 등급별 배지 이미지 (A Premium / A+ Platinum)
• 임베드 코드 자동 생성 (사이트에 바로 삽입)
• 실제 검사 기록을 보여주는 검증 페이지 링크

💎 정식 인증 (연 $699~$999)

가격 보기 →

• 인증번호: WIA-A11Y-YYYYMMDD-XXXXX
• EPUB 메타데이터 삽입용 certifierCredential URL
• PDF 인증서 다운로드 (제출·납품용)
• WIA 디렉토리 등재
• 정기 재검사 (월간/무제한)