내 사이트에 WCAG 2.2를 적용하는 법, 실제 실패 사례 대부분을 막는 수정 방법, 누구나 할 수 있는 30분 수동 점검과 접근성·사용성의 관계를 알아봅니다.
자주 묻는 질문
WCAG 준수 웹사이트란 무엇인가요?
선택한 수준에서 웹 콘텐츠 접근성 지침(WCAG)의 성공 기준을 충족하는 사이트를 말합니다. 보통 WCAG 2.1 또는 2.2의 AA 수준을 목표로 합니다. AA에는 A와 AA의 모든 기준이 포함됩니다. WCAG를 참조하는 법률과 조달 정책 대부분은 AA를 요구합니다.
내 사이트에 WCAG 지침을 어떻게 적용해야 하나요?
먼저 W3C의 “How to Meet WCAG” 빠른 참조를 열고 A와 AA 수준으로 필터링하세요. 각 기준의 “Understanding” 페이지를 읽으면 의도를 쉬운 말로 알 수 있습니다. 모든 페이지를 일일이 검사하는 대신 홈, 콘텐츠 페이지, 양식, 결제 페이지 등 핵심 템플릿을 확인하세요.
접근성 오버레이나 플러그인만으로 사이트가 준수 상태가 되나요?
아닙니다. 도구 하나만으로 사이트를 준수 상태로 만들 수 없습니다. 툴바를 추가하는 오버레이는 기반 코드 문제를 해결하지 못하며, 많은 장애인 사용자와 접근성 전문가는 오히려 사용을 방해한다고 말합니다. HTML, 대비, 레이블, 키보드 지원을 직접 수정하세요.
사용성과 접근성은 어떻게 다른가요?
접근성은 장애가 있는 사람이 사이트를 인지하고 이해하고 탐색하며 이용할 수 있음을 뜻합니다. 사용성은 누구나 사이트를 쉽고 효율적으로 이용할 수 있는지를 말합니다. 명확한 레이블, 적절한 대비, 예측 가능한 탐색처럼 두 분야에 공통되는 요소는 장애가 있는 사람뿐 아니라 모든 방문자에게 도움이 됩니다.
자동 검사 도구가 접근성 문제를 모두 찾을 수 있나요?
아닙니다. WAVE, axe, Lighthouse 같은 도구는 대체 텍스트 누락, 낮은 대비, 레이블 누락을 찾지만, 대체 텍스트가 적절한지나 포커스 순서가 자연스러운지 등은 사람이 확인해야 합니다.
WCAG 준수 웹사이트는 웹 콘텐츠 접근성 지침을 선택한 수준에서 충족합니다. 거의 모든 사업체가 목표로 삼을 수준은 WCAG 2.2 AA입니다. 실제로 많은 사이트가 낮은 색상 대비, 이미지 대체 텍스트 누락, 레이블 없는 양식 입력란, 이름 없는 링크와 버튼, 키보드로 접근할 수 없는 요소 같은 몇 가지 공통 문제에서 실패합니다. 이런 문제를 고친 뒤 키보드와 스크린 리더로 테스트하면 실제 사용자가 겪는 문제의 상당 부분을 해결할 수 있습니다.
이 가이드에서는 WCAG를 복잡하게 느끼지 않고 읽는 법, 중요한 수정 사항, 직접 할 수 있는 30분 점검을 설명합니다.
WCAG의 구성
WCAG는 W3C가 발표하며 여러 층으로 구성됩니다.
네 가지 원칙: POUR라고 부르며 콘텐츠는 인지 가능(Perceivable), 운용 가능(Operable), 이해 가능(Understandable), 견고함(Robust)을 갖춰야 합니다.
지침: 각 원칙 아래 “텍스트 대안”, “키보드 접근성” 같은 주제가 있습니다.
성공 기준: 각 지침 아래 테스트할 수 있는 규칙이 있으며, 1.4.3 대비처럼 번호와 A, AA, AAA 수준이 지정되어 있습니다.
A는 최소 기준입니다. AA는 법률과 조달 요구사항에서 흔히 목표로 삼는 수준입니다. AAA는 더 엄격하며 사이트 전체에 요구되는 경우는 드뭅니다.
WCAG 2.2는 2023년 10월 W3C 권고안이 되었습니다. 최소 대상 크기, 가려지지 않는 포커스, 접근 가능한 인증 같은 기준을 추가했고, 더는 필요하지 않은 4.1.1 구문 분석 기준을 삭제했습니다.
내 사이트에 WCAG 적용하기
표준 문서처럼 읽히는 것은 실제로 표준이기 때문입니다. 다음 방법으로 실무에 적용할 수 있습니다.
W3C의 “How to Meet WCAG (Quick Reference)”를 엽니다.
수준을 A와 AA로만 필터링합니다.
각 기준에 연결된 “Understanding” 페이지를 읽습니다. 쉬운 설명과 적합한 사례 및 부적합한 사례를 볼 수 있습니다.
모든 페이지 대신 홈, 일반 콘텐츠 페이지, 블로그 게시물, 양식, 제품 또는 결제 페이지 같은 템플릿을 테스트합니다. 템플릿을 고치면 이를 이용해 만든 모든 페이지가 개선됩니다.
각 문제의 기준 번호와 해당 페이지, 수정 방법을 기록합니다.
실제 문제 대부분을 줄이는 수정 사항
1. 색상 대비(1.4.3 및 1.4.11)
일반 텍스트는 배경과의 대비가 최소 4.5:1이어야 합니다.
큰 텍스트(일반 굵기 약 24px 또는 굵은 글씨 18.66px 이상)는 최소 3:1이어야 합니다.
인터페이스 구성 요소와 정보 전달에 필요한 그래픽(버튼 테두리, 입력란 윤곽선, 정보를 나타내는 아이콘)은 최소 3:1이어야 합니다.
연한 회색 플레이스홀더 글씨와 옅은 브랜드 색상 위 흰색 글씨가 흔한 문제입니다. WebAIM 대비 검사기나 브라우저 개발자 도구로 확인하세요.
2. 이미지 대체 텍스트(1.1.1)
정보 전달이 중요한 이미지에는 요점을 설명하는 대체 텍스트를 넣습니다. 예: alt="보일러 필터를 교체하는 기술자".
장식용 이미지에는 빈 대체 텍스트 alt=""를 넣어 스크린 리더가 건너뛰게 합니다.
전단지 화면 캡처나 JPG 메뉴처럼 이미지로 된 텍스트는 동일한 내용을 실제 텍스트로도 제공해야 합니다.
집으로 이동하는 로고처럼 링크가 걸린 이미지에는 목적지를 설명합니다. 예: alt="Acme Plumbing 홈".
3. 양식 레이블과 오류(1.3.1, 3.3.1, 3.3.2)
모든 입력란에는 연결된 화면 표시 <label>이 필요합니다. 입력을 시작하면 사라지는 플레이스홀더는 레이블이 아닙니다.
오류 메시지는 무엇이 잘못됐고 어떻게 고칠지 텍스트로 알려야 합니다. 예: “지역 번호를 포함한 전화번호를 입력하세요.” 빨간 테두리만으로 표시하면 안 됩니다.
현재 위치를 보여주는 포커스 표시가 있어야 합니다. outline: none으로 브라우저 테두리를 제거하고 대체 표시를 제공하지 않는 경우가 흔한 실패입니다.
드롭다운 메뉴와 모달은 키보드로 열고 조작하고 닫을 수 있어야 합니다. 모달이 열린 동안에는 닫을 때까지 포커스가 모달 내부에 머물러야 합니다.
5. 이름이 있는 링크와 버튼(2.4.4, 4.1.2)
햄버거 메뉴, 검색 돋보기, 소셜 아이콘 등 아이콘만 있는 버튼에는 화면 텍스트, aria-label 또는 숨김 텍스트로 접근 가능한 이름을 제공해야 합니다.
“여기를 클릭”이나 “더 읽기” 링크만 가득한 페이지는 피하세요. 링크 문구에 목적지를 설명하거나 각 링크에 서로 다른 접근 가능한 이름을 지정합니다.
6. 구조와 제목(1.3.1, 2.4.6)
페이지 내용을 설명하는 <h1>은 페이지마다 하나만 둡니다.
글자 크기만을 위해 제목 수준을 고르지 말고 논리적인 순서(섹션에는 h2, 하위 내용에는 h3)를 사용합니다.
실제 목록, 헤더 셀이 있는 표, 랜드마크(<header>, <nav>, <main>, <footer>)를 사용합니다.
페이지 언어를 지정합니다. 예: <html lang="ko">.
7. 알아두면 좋은 WCAG 2.2 신규 기준
2.5.8 대상 크기(최소), AA: 클릭 대상은 최소 24×24 CSS 픽셀이어야 합니다. 더 작다면 주변에 충분한 간격을 둬야 합니다.
2.4.11 포커스 가려짐(최소), AA: 고정 헤더, 쿠키 배너, 채팅 위젯이 포커스된 요소를 완전히 가리지 않아야 합니다.
3.3.8 접근 가능한 인증(최소), AA: 대체 방법 없이 로그인할 때 퍼즐을 풀거나 정보를 기억하도록 요구하지 않습니다. 비밀번호 관리자와 붙여넣기를 허용합니다.
3.3.7 중복 입력, A: 같은 절차에서 이미 받은 정보를 다시 입력하게 하지 않습니다.
8. 미디어와 움직임
동영상에는 자막(1.2.2)이 필요합니다. 사전 녹화 영상의 중요한 시각 정보에는 음성 해설이나 텍스트 대안을 제공해야 합니다.
5초 넘게 자동으로 움직이는 요소는 멈출 방법이 있어야 합니다(2.2.2).
큰 애니메이션에는 prefers-reduced-motion 설정을 존중합니다.
30분 수동 점검
자동 도구는 문제의 일부만 찾습니다. 각 핵심 템플릿에 다음 점검을 추가하세요.
0~5분: 자동 검사. 브라우저 확장 프로그램 WAVE나 axe DevTools, 또는 Lighthouse의 접근성 검사를 실행합니다. 대체 텍스트와 레이블 누락, 대비 문제처럼 명확한 오류를 수정합니다.
5~15분: 키보드만 사용. 마우스를 치우고 페이지 맨 위에서 Tab 키로 이동합니다.
모든 순간에 포커스가 어디 있는지 보이나요?
메뉴를 열고 닫고, 모든 양식 필드를 사용하고 제출할 수 있나요?
“본문으로 건너뛰기” 링크가 있고 제대로 작동하나요?
고정 헤더나 배너 뒤로 포커스가 사라지나요?
15~25분: 스크린 리더. macOS와 iOS에 내장된 VoiceOver 또는 Windows에서 무료로 제공되는 NVDA를 사용합니다.
제목 목록만 들어도 페이지 내용이 파악되나요?
이미지와 버튼에 포커스를 옮겼을 때 문맥 없이도 의미를 알 수 있나요?
양식의 각 필드에 연결된 레이블과 오류가 읽히나요?
25~30분: 확대와 재배치. 브라우저 확대율을 200%, 이어서 400%로 설정합니다. 400%에서도 콘텐츠가 가로 스크롤 없이 한 열로 재배치되어야 하며 잘려 나가는 내용이 없어야 합니다(1.4.10 재배치).
사용성과 접근성이 겹치는 지점
“웹 사용성과 접근성”을 함께 찾는 데에는 이유가 있습니다. 거의 모든 접근성 개선은 사용성도 높여 줍니다.
접근성 개선
함께 도움을 받는 사람
충분한 대비
햇빛 아래 휴대전화를 보는 사람
눈에 보이는 레이블
급하게 양식을 작성하는 사람
자막
소리를 끄고 영상을 보는 사람
키보드 지원
고급 사용자, 트랙패드가 고장 난 사람
넓은 터치 대상
모든 모바일 사용자
명확한 오류 메시지
오타를 내는 모든 사람
오버레이, 접근성 선언문, 법률
오버레이: 한 줄로 준수 상태를 만들어 준다고 약속하는 위젯도 사이트의 기반 코드는 바꾸지 못합니다. 사이트 자체를 수정하세요.
접근성 선언문: 목표로 삼는 표준, 알려진 문제, 도움이나 대체 형식을 요청할 연락 방법을 짧은 페이지에 게시하세요.
법률 상황: 요구사항은 국가마다 다릅니다. 유럽 접근성법(EAA)은 2025년 6월부터 EU의 많은 제품과 서비스에 적용됩니다. 미국에서는 ADA가 웹사이트에 자주 적용되며 공공 부문 기관에는 별도 규정이 있는 경우가 많습니다. 자신의 상황에 대해서는 법률 자문을 받으세요.
점검 목록
[ ] 텍스트 대비 4.5:1, 큰 텍스트와 UI 요소 대비 3:1
[ ] 정보 이미지에는 대체 텍스트, 장식 이미지에는 빈 대체 텍스트
[ ] 모든 입력란에 눈에 보이고 연결된 레이블
[ ] 포커스가 보이는 상태로 사이트 전체를 키보드로 이용 가능
[ ] 아이콘 버튼에 접근 가능한 이름
[ ] 논리적인 제목과 랜드마크, 페이지 언어 지정
[ ] 터치 대상 최소 24×24 CSS 픽셀
[ ] 동영상 자막, 움직임을 멈추는 컨트롤
[ ] 400% 확대에서 콘텐츠 재배치
[ ] 접근성 선언문 게시
접근성은 검색에도 도움이 됩니다. 제목, 대체 텍스트, 설명적인 링크는 기본적인 온페이지 SEO 요소이기도 합니다. 자세한 내용은 온페이지 SEO 점검 목록을 참고하세요.
We.Inc는 편집 가능한 표준 HTML, CSS, React 코드로 사이트를 생성합니다. 따라서 직접 또는 채팅으로 요청해 레이블, 대체 텍스트, 대비를 수정할 수 있습니다. 어떤 도구를 쓰든 게시하기 전에 위의 수동 점검을 실행하세요.