요약 3천만 원 이하 공공기관 위탁 홈페이지에서 웹 접근성(WA) 품질 인증이 막판에 발목을 잡는 이유는 단 하나입니다. 개발이 끝난 뒤 접근성을 '패치'하려 하기 때문입니다. KWCAG 2.2 기준 33개 항목은 마크업 구조와 UX 흐름에 깊이 얽혀 있어, 사후 수정은 사실상 재개발에 가깝습니다. 이 글은 와이어프레임(스토리보드) 단계에서 텍스트 대체·키보드 경로·스크린 리더 흐름을 미리 명세해, 추가 예산 없이 심사를 한 번에 통과하는 설계 프로세스를 다룹니다.
오픈 D-7. 클라이언트 검수까지 마쳤는데 웹 접근성 인증기관에서 예비 점검 결과가 날아옵니다. "이미지 버튼 대체 텍스트 오류 23건, 키보드 포커스 미표시 11건, 색상 대비 미달 9건." 개발자는 마크업을 통째로 뜯어야 한다는 걸 직감합니다. 재심사 수수료만 150만 원이 추가로 나가고, 오픈은 3주 밀립니다.
이 장면이 낯설지 않은 이유는 국내 웹사이트 평균 접근성 점수가 66.7점(과기정통부·NIA, 2024년 웹 접근성 실태조사)에 불과하다는 사실과 정확히 맞닿아 있습니다. 대부분의 사이트가 '완성 후 패치' 방식으로 개발되기 때문입니다.
해법은 간단합니다. 와이어프레임을 그리는 순간부터 접근성 명세를 함께 작성하는 것입니다. 이를 '쉬프트 레프트(Shift-Left)' 전략이라고 부릅니다. 개발 단계로 넘어가기 전에 오류를 원천 차단하면, 수정 공수는 제로에 가깝습니다.
KWCAG 2.2가 공공 영역에 완전히 정착한 지금, 심사 항목은 기존 24개에서 33개로 늘었습니다. 추가된 9개 항목 중 실무에서 가장 많이 걸리는 세 가지는 다음과 같습니다.
심사 수수료도 항목 확대에 따라 평균 30% 이상 인상됐습니다. 1차 불합격 시 재심사 비용이 약 150만~200만 원 추가로 발생한다는 뜻입니다. 3천만 원 고정 예산에서 이 비용은 개발사 순익을 직격합니다.
아래 다섯 가지 시나리오는 스토리보드(기획서)를 작성할 때 각 화면 옆에 병기하는 방식으로 활용합니다. 개발자에게 넘기기 전에 이 명세가 완성되어 있으면, 별도의 접근성 수정 스프린트가 필요 없습니다.
판단 기준: 본문 텍스트와 배경의 명도 대비 최소 4.5:1 이상.
와이어프레임 명세 방법: 피그마(Figma)에서 컬러 에셋을 확정할 때, A11y 플러그인으로 대비 수치를 통과한 색상만 팔레트에 등록합니다. 이후 어떤 화면에서도 해당 팔레트 밖의 색상을 쓰지 못하도록 디자인 시스템 규칙으로 고정합니다.
흔한 실수: 오류 메시지를 '빨간 글씨'로만 표시하는 경우. 색맹 사용자는 이를 인식하지 못합니다. 와이어프레임에 [오류] 아이콘 + 텍스트 병기 형태로 명시해야 합니다.
판단 기준: 마우스 없이 Tab 키만으로 전체 콘텐츠에 접근 가능하고, 현재 위치가 시각적으로 명확히 구별되어야 합니다.
와이어프레임 명세 방법: 스토리보드의 각 화면에 탭 순서를 ①②③ 숫자로 직접 표기합니다. 버튼·링크·입력창의 Focus 상태 디자인(테두리 최소 2px 이상 또는 고대비 아웃라인)을 별도 상태 컴포넌트로 정의합니다.
특히 주의할 화면: 모달 팝업. 팝업이 열리면 포커스가 팝업 내부에 갇혀야(Focus Trap) 하고, 닫히면 팝업을 연 버튼으로 돌아와야 합니다. 이 흐름을 와이어프레임에 화살표로 명시하지 않으면, 개발 단계에서 반드시 누락됩니다.
판단 기준: 화면에 보이는 텍스트와 aria-label, title 등 보조기기용 속성이 100% 일치해야 합니다.
와이어프레임 명세 방법: 기획서에 '접근성 속성 매핑표'를 한 페이지 추가합니다. 예를 들어 검색창 옆 돋보기 아이콘 버튼의 경우, 시각적 표시는 아이콘이지만 속성값은 반드시 "검색"이어야 합니다. "돋보기"로 들어가는 실수가 실무에서 가장 빈번합니다.
| 화면 위치 | 시각적 레이블 | aria-label 명세 |
|---|---|---|
| GNB 검색 버튼 | 돋보기 아이콘 | 검색 |
| 로그인 폼 제출 | 로그인 | 로그인 |
| 파일 첨부 | 📎 아이콘 | 파일 첨부하기 |
이 표를 개발자에게 함께 전달하면, 마크업 단계에서 속성 불일치가 발생하지 않습니다.
판단 기준: 드래그·스와이프 등 복잡한 제스처가 필수인 UI에는 단일 클릭/탭으로 동일 기능을 수행하는 대안이 있어야 합니다.
와이어프레임 명세 방법:
[파일 찾기] 버튼을 화면에 항상 노출◀ ▶ 화살표 버튼 필수 설계[+] [-] 버튼 병기이 항목은 KWCAG 2.2 신설 항목이라 인식이 낮아 놓치기 쉽습니다. 모바일 반응형 와이어프레임을 그릴 때 제스처 인터랙션이 등장하는 순간, 바로 대안 UI를 함께 설계하는 습관이 필요합니다.
판단 기준: 스크린 리더 사용자가 반복 내비게이션을 건너뛸 수 있어야 하고, 페이지마다 고유한 타이틀이 있어야 합니다.
와이어프레임 명세 방법: 스토리보드 첫 페이지(공통 UI 정의 페이지)에 다음 두 가지를 선언합니다.
<body> 바로 아래 '본문 바로가기' 링크를 렌더링 (시각적으로는 숨기되 스크린 리더에는 노출)<title> 태그 구조 규칙: [상세 메뉴명] | [대메뉴명] | [기관명] 순서로 CMS가 자동 조합하도록 개발 규칙 확정이 두 가지는 개발 착수 전에 결정되어야 합니다. 개발 후 수정하면 전체 페이지 템플릿을 건드려야 합니다.
3천만 원 예산에서 웹 접근성 인증 수수료를 '나중에 찾는' 구조는 위험합니다. 킥오프 시점에 다음 순서로 예산을 배분하면 후반부 자금 부족을 막을 수 있습니다.
① 계약 직후: 인증기관 심사 수수료 약 150만~200만 원을 별도 항목으로 선 확정합니다. 외주 파트너 대금과 섞이면 나중에 집행이 꼬입니다.
② 디자인 단계: 컬러 가이드와 포커스 스타일셋을 확정하고, 대표 페이지 20~30개를 추려 접근성 기준 디자인 검수를 진행합니다. 전체 페이지를 검수할 필요는 없습니다. 인증 심사도 대표성 있는 핵심 페이지 약 20개를 기준으로 진행됩니다.
③ QA 단계: 무료 자가진단 도구(OpenWA, K-WA, Lighthouse)로 기계적 오류(대체 텍스트 누락 등)를 100% 제거한 뒤, 키보드만으로 전 페이지를 이용하는 시뮬레이션을 필수로 수행합니다. 마우스를 완전히 치우고 Tab·Enter·Space·방향키만으로 사이트를 처음부터 끝까지 이용해보는 것입니다.
실무 팁: 일부 대행사가 도입하는 '접근성 위젯 오버레이(Overlay)' 스크립트—아이콘 클릭 시 글자 크기나 대비를 조절해주는 플러그인—는 국가공인 WA 품질 인증 심사를 통과하지 못합니다. 심사는 HTML 원천 코드를 스크린 리더로 직접 읽어 판정하기 때문입니다.
3천만 원 이하 소액 사업이라도 과업지시서(또는 제안서)에 다음 문구를 명시하면, 개발 파트너가 초기부터 방어적 고품질 코딩을 진행합니다.
"본 사업의 결과물은 KWCAG 2.2 기준 국가공인 웹 접근성 품질마크를 획득한 상태로 최종 납품하며, 미획득 시 재개발 비용은 개발사가 부담한다."
이 조항이 없으면 개발사는 '합격 여부는 발주처 책임'이라는 인식으로 접근성을 후순위로 둡니다. 조항이 있으면 와이어프레임 검토 단계부터 개발사가 먼저 접근성 이슈를 제기합니다.
Q1. KWCAG 2.2 심사는 언제부터 의무 적용인가요? KWCAG 2.2는 2026년 현재 공공기관 웹 접근성 품질 인증 심사의 공식 기준으로 완전히 정착했습니다. 신규 구축 사이트뿐 아니라 갱신 심사도 동일하게 33개 항목이 적용됩니다.
Q2. 웹 접근성 인증을 받지 않으면 어떤 불이익이 있나요? 장애인차별금지법 및 지능정보화기본법에 따라 공공기관 웹 접근성 준수는 법적 의무입니다. 위반 시 최대 3천만 원 이하의 과태료가 부과될 수 있으며, 사업 최종 검수 조건에 WA 마크 획득이 포함된 경우 납품 자체가 거부될 수 있습니다.
Q3. 심사 대상 페이지는 전체 페이지인가요? 아닙니다. 인증기관은 기관의 핵심 서비스와 주요 콘텐츠가 위치한 대표 페이지 약 20개를 선정해 심사합니다. 따라서 전체 페이지보다 핵심 20개에 집중적으로 접근성을 적용하는 전략적 접근이 효율적입니다.
Q4. 자가진단 도구에서 통과했는데 실제 심사에서 불합격하는 이유는 무엇인가요?
Lighthouse 등 자동화 도구는 기계적으로 감지 가능한 오류(대체 텍스트 누락, 색상 대비 수치 등)만 잡습니다. 키보드 포커스 흐름, 스크린 리더 낭독 순서, 레이블과 네임 일치 여부 등은 사람이 직접 사용해봐야 발견되는 항목입니다. 자가진단 후 반드시 키보드 시뮬레이션을 병행해야 합니다.
Q5. 설계 단계 접근성 명세를 에이전시에 요청하면 추가 비용이 발생하나요? 설계 단계에서 명세를 작성하는 공수는 개발 후 수정하는 공수보다 훨씬 적습니다. 처음부터 접근성 명세를 포함한 스토리보드를 작성하는 에이전시라면 추가 비용 없이 진행 가능합니다. 오히려 사후 패치와 재심사 비용이 없어지므로 전체 프로젝트 비용은 줄어듭니다.
웹 접근성 품질 인증은 '개발이 끝난 뒤 처리하는 행정 절차'가 아닙니다. 와이어프레임의 첫 줄을 그을 때부터 텍스트 대체, 키보드 탭 순서, 스크린 리더 흐름을 함께 설계해야 비로소 추가 예산 없이 원패스가 가능합니다.
에이달(ADALL)은 공공기관 위탁 홈페이지 구축 시 스토리보드 단계부터 KWCAG 2.2 기준 접근성 명세를 병기하는 설계 프로세스를 적용합니다. 제한된 예산 안에서 WA 인증 획득까지 책임지는 구조가 필요하다면, 프로젝트 문의를 남겨주세요.
📞 02-2664-8631 | ✉️ master@adall.co.kr
무료 컨설팅 받아보고 싶다면?
무료 컨설팅 신청하기