웹사이트를 접근성 있게 만드는 법: WCAG 2.2 입문 가이드

웹사이트를 접근성 있게 만들려면, 사람들이 마우스뿐 아니라 키보드, 스크린 리더, 확대 기능, 스위치 장치로도 사용할 수 있도록 만드세요. 버튼, 링크, 제목, 양식 레이블에는 실제 HTML 요소를 쓰고, 이미지에는 의미 있는 대체 텍스트를 주며, 텍스트 대비를 높게 유지하고 포커스가 보이도록 하세요. 목표는 WCAG 2.2 AA 수준입니다. 자동 검사 도구는 문제의 일부만 잡아내고, 10분간의 키보드와 스크린 리더 테스트가 나머지 대부분을 잡아냅니다.

실제로 "접근 가능하다"는 것의 의미

접근성은 사람에 관한 것입니다. 시각 장애가 있어 스크린 리더를 쓰는 사람, 떨림이 있어 키보드로 이동하는 사람, 저시력으로 200%까지 확대하는 사람, 햇빛 아래에서 읽는 사람, 일시적으로 손목을 다친 사람이 있습니다. 좋은 접근성은 대개 모든 사람에게 사이트를 더 좋게 만듭니다. 구조가 명확해지고, 글이 읽기 쉬워지고, 양식이 오류를 설명하게 됩니다.

기준이 되는 표준은 W3C의 웹 콘텐츠 접근성 가이드라인(WCAG)입니다. 2026년 9월 기준 현재 버전은 WCAG 2.2(2023년 10월 발표, 2024년 12월 업데이트)이며, WCAG 3은 초기 초안입니다. WCAG는 네 가지 원칙을 중심으로 구성되어 있습니다. 콘텐츠는 인지 가능하고, 조작 가능하고, 이해 가능하고, 견고해야 합니다. 그리고 세 가지 적합성 수준이 있습니다.

여러 곳의 법률이 WCAG를 참조합니다. 예를 들어 유럽 접근성법(European Accessibility Act)은 2025년 6월부터 EU의 많은 소비자 대상 디지털 서비스에 적용되고 있습니다. 어떤 규칙이 여러분에게 적용되는지는 사업 지역과 판매하는 것에 따라 다르므로, 확실하지 않다면 전문가와 상의하세요. 이 가이드는 실무적인 작업을 다룹니다.

선택지: 어떻게 도달할 것인가

대부분의 작은 사이트에는 앞의 두 가지면 충분합니다. AI에게 처음부터 접근성 있게 만들라고 말하고, 출시 전에 감사하세요.

가장 중요한 수정 사항

올바른 HTML 요소 사용하기

대부분의 접근성은 올바른 HTML을 쓰면 공짜로 얻습니다. <button>은 포커스를 받고, Enter와 Space로 작동하며, 버튼으로 읽힙니다. 클릭 핸들러가 붙은 <div>는 이 중 어느 것도 아닙니다. AI가 생성한 코드는 가끔 모든 것을 스타일링한 div로 만듭니다. 시맨틱 요소를 요청하세요.

• 동작에는 <button>, 이동에는 <a href>
• 페이지마다 <h1> 하나, 그다음 순서대로 <h2>, <h3> — 스크린 리더 사용자는 제목 사이를 이동합니다
• 랜드마크: <header>, <nav>, <main>, <footer>
• 모든 양식 필드에 연결된 <label>
• <html lang="ko">로 페이지 언어 지정

ARIA 속성은 기본 요소가 맞지 않을 때만 쓰세요. 예를 들어 맞춤형 탭 세트나 콤보박스의 경우입니다. 잘못된 ARIA는 아무것도 없는 것보다 나쁩니다.

키보드 접근과 보이는 포커스

마우스로 할 수 있는 모든 것은 키보드만으로도 작동해야 합니다(WCAG 2.1.1). Tab 키로 페이지를 이동해 보세요. 모든 링크, 버튼, 입력란이 논리적인 순서로 닿을 수 있어야 하고, 항상 포커스가 어디에 있는지 보여야 합니다(2.4.7 포커스 보임). WCAG 2.2는 포커스된 요소가 고정 헤더나 쿠키 배너 뒤에 완전히 가려지면 안 된다는 규칙을 추가했습니다(2.4.11, AA 수준).

흔한 실패 사례: 마우스를 올릴 때만 열리는 메뉴, 포커스를 가두지 않거나 Escape로 닫을 수 없는 모달, 그리고 대체할 것 없이 CSS에 outline: none을 둔 경우입니다.

텍스트 대체 수단

의미 있는 모든 이미지에는 맥락에서 무엇을 보여 주는지 설명하는 대체 텍스트가 필요합니다("image1.jpg"가 아니라 "시식 메뉴를 담는 셰프"). 장식용 이미지에는 스크린 리더가 건너뛰도록 빈 alt=""를 주세요. 아이콘만 있는 버튼에는 접근 가능한 이름이 필요합니다("닫기", "검색"). 동영상에는 자막이, 오디오에는 대본이 필요합니다.

색과 대비

WCAG 2.2 AA는 일반 텍스트에 최소 4.5:1, 큰 텍스트에 3:1의 대비 비율을 요구합니다(1.4.3). 입력란 테두리나 의미 있는 아이콘 같은 인터페이스 요소에는 3:1을 요구합니다(1.4.11). 연한 회색 플레이스홀더 텍스트와 옅은 버튼이 흔한 실패 사례입니다. 또한 의미를 색으로만 전달하지 마세요. 잘못된 입력란의 빨간 테두리에는 오류 메시지도 있어야 합니다.

크기 조정과 리플로우

200%로 확대해도 텍스트를 쓸 수 있어야 하며(1.4.4), 콘텐츠는 가로 스크롤 없이 320 CSS 픽셀 너비에서도 작동해야 합니다(1.4.10). 제대로 된 반응형 레이아웃이 이 대부분을 해결합니다.

대상 크기, 양식과 오류

• 대상 크기: WCAG 2.2 AA는 포인터 대상이 최소 24 x 24 CSS 픽셀이거나, 더 작은 대상 주변에 충분한 간격을 요구합니다(2.5.8). 휴대폰에서는 클수록 친절합니다.
• 양식: 플레이스홀더만이 아닌 보이는 레이블, 명확한 안내, 무엇이 잘못되었고 어떻게 고치는지 알려 주는 오류 메시지를 필드 바로 옆에 두세요.
• 로그인: 대안 없이 퍼즐을 풀게 하거나 코드를 옮겨 적게 하지 마세요. 비밀번호 관리자와 붙여 넣기를 허용하세요(3.3.8 접근 가능한 인증).

잘 통하는 프롬프트

WCAG 2.2 AA 수준을 충족하도록 이 사이트를 만들어 주세요. 시맨틱 HTML 랜드마크, 페이지마다 h1 하나와 순서대로 된 제목, 실제 button과 link 요소, 모든 양식 필드의 레이블, 보이는 포커스 스타일, 최소 4.5:1의 텍스트 대비, 의미 있는 이미지의 대체 텍스트와 장식용 이미지의 alt="", 그리고 html lang 설정을 포함해 주세요.

/signup과 /checkout 페이지의 접근성을 감사해 주세요. 키보드만으로 사용할 수 있는지, 포커스 순서, 보이는 포커스, 레이블, 오류 메시지, 대비, 아이콘 버튼의 스크린 리더 이름을 확인하세요. 각 문제를 WCAG 기준과 함께 나열한 뒤, 시각 디자인을 필요 이상으로 바꾸지 않고 수정해 주세요.

모바일 메뉴를 키보드로 사용할 수 없습니다. aria-expanded가 있는 버튼으로 만들고, 열릴 때 포커스를 메뉴 안으로 옮기고, Escape로 닫으면 포커스를 버튼으로 돌려보내 주세요.

단계별로 따라 하기

1. 자동 검사를 실행하세요. Chrome 개발자 도구의 Lighthouse 접근성 섹션이나 axe 브라우저 확장 프로그램을 주요 페이지마다 실행하세요. 보고된 것은 모두 고치세요.
2. 마우스를 치우세요. 각 페이지를 Tab으로 이동하면서 핵심 작업(가입, 검색, 결제)을 모두 완료해 보세요. 닿을 수 없거나, 포커스가 보이지 않거나, 빠져나갈 수 없는 부분을 적어 두세요.
3. 200%로 확대하고 창을 휴대폰 너비로 좁혀 보세요. 잘려 나가거나 가로 스크롤이 필요한 것이 없어야 합니다.
4. 10분간 스크린 리더를 써 보세요. Mac과 iPhone의 VoiceOver, Android의 TalkBack, 또는 Windows의 NVDA(무료)를 쓰세요. 제목, 링크, 양식 필드를 들어 보세요. 이름 없는 "버튼"이나 "링크, 여기를 클릭"은 고쳐야 할 것입니다.
5. 대비를 확인하세요. 대비 검사 도구로 텍스트, 버튼, 입력란의 대비를 확인하세요.
6. 고친 뒤 같은 작업을 다시 테스트하세요.
7. 접근성 설명 페이지를 게시하세요. 어떤 기준을 목표로 하는지, 문제를 어떻게 신고하는지 적고, 신고에 답하세요.

흔한 실수

• 코드를 고치는 대신 오버레이 위젯에 의존하기.
• 지저분해 보인다는 이유로 포커스 윤곽선 제거하기, 대체 없이.
• 플레이스홀더 텍스트를 유일한 레이블로 쓰기. 사람이 입력을 시작하면 사라지고, 대비도 낮은 경우가 많습니다.
• "여기를 클릭"과 "더 보기" 링크. 맥락이 없으면 스크린 리더 사용자는 똑같은 링크 목록을 듣게 됩니다.
• 키워드로 채운 대체 텍스트. 대체 텍스트는 사람을 위한 것입니다. 이미지를 설명하세요.
• 한 번만 테스트하기. 새로운 기능마다 키보드 접근이 깨질 수 있습니다. 출시 전 테스트에 키보드 점검을 추가하세요.

접근성 체크리스트

• 주요 페이지에서 자동 검사(Lighthouse 또는 axe) 통과
• 모든 작업을 키보드만으로 완료할 수 있음
• 포커스는 항상 보이며 고정 요소 뒤에 가려지지 않음
• 시맨틱 제목, 랜드마크, 버튼, 링크; lang 설정됨
• 의미 있는 대체 텍스트; 장식용 이미지는 alt=""; 동영상에 자막
• 텍스트 대비 4.5:1 이상(큰 텍스트는 3:1 이상); UI 요소는 3:1 이상
• 200% 확대와 320px 너비에서 작동함
• 모든 양식 필드에 보이는 레이블과 명확한 오류 메시지가 있음
• 문제를 신고할 방법이 있는 접근성 설명 페이지가 있음

이 개념의 배경은 웹 접근성이란 무엇인가에서 읽어 보세요. 접근성 있는 디자인과 좋은 디자인은 많이 겹칩니다. 시각적인 측면은 AI로 보기 좋은 앱을 디자인하는 법에서 다룹니다.

Mythex에서의 접근성

Mythex는 여러분이 요청하는 기준에 맞춰 만들므로, 첫 프롬프트와 후속 요청에 "WCAG 2.2 AA"를 넣으세요. Preview의 휴대폰 크기 프레임으로 작은 화면을 확인할 수 있지만(Preview and Code), 키보드, 확대, 스크린 리더 테스트는 게시된 URL이나 별도 탭에서 연 미리보기에서 가장 잘 작동합니다. 에이전트에게 페이지를 감사하고, 발견된 것을 고치고, 그다음 수정 사항을 직접 테스트하도록 요청하세요. 자동 검사는 시작일 뿐, 최종 승인이 아닙니다.

자주 묻는 질문