웹 접근성이란? WCAG와 포용적 디자인 설명

웹 접근성은 장애가 있는 사람도 웹사이트와 앱을 사용할 수 있도록 만드는 것입니다. 시각 장애가 있어 스크린 리더를 쓰는 사람, 마우스를 쓸 수 없는 사람, 저시력이나 색맹이 있는 사람, 청각 장애가 있는 사람, 인지 또는 학습 장애가 있는 사람 모두가 포함됩니다. 실제로는 이미지의 대체 텍스트, 충분한 색상 대비, 올바른 레이블이 있는 폼, 키보드만으로 모든 것이 작동하는 것 같은 요소를 뜻합니다. 이에 대한 국제 표준은 W3C의 웹 콘텐츠 접근성 지침인 WCAG입니다.

접근성은 흔히 a11y라고 줄여 씁니다. 'a'로 시작해서, 가운데 11글자가 있고, 'y'로 끝나기 때문입니다.

AI로 만들 때 접근성이 중요한 이유

AI 빌더는 보기에 맞는 앱을 만드는 데 능숙합니다. 접근성은 대부분 스크린샷에서 보이지 않는 것에 관한 것입니다. 버튼이 정말 버튼인지, 입력란에 스크린 리더가 읽을 수 있는 레이블이 있는지, Tab 키로 메뉴에 도달할 수 있는지 같은 것입니다.

그래서 다음을 확인하는 것이 중요합니다:

• 놓치기 쉽습니다. 직접 스타일을 입힌 드롭다운은 완벽해 보여도 마우스 없이는 전혀 사용할 수 없을 수 있습니다. 테스트하지 않으면 알아채기 어렵습니다.
• 처음에 제대로 하는 편이 저렴합니다. 첫 프롬프트에서 접근 가능한 컴포넌트를 요청하는 것은 거의 비용이 들지 않습니다. 완성된 앱에 나중에 적용하려면 모든 화면을 손대야 합니다.
• 모두에게 도움이 됩니다. 자막은 시끄러운 곳에 있는 사람을 돕고, 좋은 대비는 햇빛 아래 휴대폰을 보는 사람을 돕고, 명확한 레이블은 누구나 폼을 더 빨리 채우도록 돕습니다.
• SEO와 겹칩니다. 올바른 제목, 설명적인 링크, 대체 텍스트는 검색엔진이 페이지를 이해하는 데도 도움이 됩니다. AI로 만든 웹사이트를 위한 SEO를 참고하세요.
• 법적으로 요구될 수 있습니다. 어디에서 운영하고 누구에게 서비스하는지에 따라, 접근성은 법적 의무가 될 수 있습니다.

일상 속 비유

건물의 입구를 생각해보세요.

계단은 많은 사람에게 잘 작동합니다. 경사로는 휠체어 사용자에게 작동하며, 유모차를 끄는 부모, 손수레를 끄는 배달원, 캐리어를 든 여행객에게도 도움이 됩니다. 자동문, 명확한 표지판, 엘리베이터 버튼의 점자, 좋은 조명은 각각 누군가의 장벽을 없앱니다.

웹 접근성은 디지털 공간에서도 같은 개념입니다. 앱의 경사로, 표지판, 난간입니다. 그리고 건물과 마찬가지로, 설계도에 경사로를 넣는 것이 콘크리트가 굳은 뒤에 추가하는 것보다 훨씬 쉽습니다.

WCAG 요약

WCAG는 W3C의 웹 접근성 이니셔티브(WAI)가 발행합니다. 현재 버전은 WCAG 2.2이며, 2023년 10월에 처음 발행되었습니다. 하위 호환성이 있어서, WCAG 2.2를 충족하는 콘텐츠는 2.1과 2.0도 충족합니다. W3C는 최신 버전 사용을 권장합니다. WCAG 2.2는 국제 표준인 ISO/IEC 40500:2025로도 승인되었습니다. 매우 다른 WCAG 3은 초기 초안 단계이며, 완성된 표준이 아닙니다.

WCAG는 네 가지 원칙으로 구성되며, 흔히 POUR로 기억합니다:

각 지침에는 세 가지 등급의 검증 가능한 성공 기준이 있습니다:

• A 등급 — 최소 기준입니다. 이를 실패하면 일부 사람들이 완전히 막힙니다.
• AA 등급 — 표준 목표이며, 대부분의 법률과 정책이 가리키는 등급입니다.
• AAA 등급 — 가장 높은 등급입니다. 일부 영역에서 목표로 삼을 만하지만, 일부 콘텐츠는 충족할 수 없으므로 W3C는 전체 사이트에 이를 요구하도록 권장하지 않습니다.

WCAG 2.2는 2.1에 성공 기준 9개를 추가했습니다. 여기에는 AA 등급의 **대상 크기(최소)**가 포함되며, 클릭 가능한 대상은 예외가 있지만 일반적으로 최소 24×24 CSS 픽셀이어야 합니다. 또한 **접근 가능한 인증(최소)**도 있는데, 이는 기억력이나 퍼즐에 의존하는 로그인 단계를 제한합니다. 예를 들어 비밀번호를 붙여넣지 못하게 한 채 다시 입력하도록 하는 경우입니다. 또한 오래된 “파싱(Parsing)” 기준은 더 이상 필요 없어 제거되었습니다.

실제 예시: 회원가입 폼

AI가 만들 법한 회원가입 폼과, 접근성 점검에서 발견되는 것들을 보겠습니다:

이 수정들 중 어느 것도 폼의 모양을 크게 바꾸지 않습니다. 하지만 모두 일부 사람들이 그것을 사용할 수 있는지 여부를 바꿉니다.

주요 용어 설명

흔한 오해

• “접근성은 시각 장애인에게만 중요하다.” 시각, 운동, 청각, 언어, 인지 장애뿐 아니라 팔이 부러진 것처럼 일시적인 상황도 포함합니다.
• “접근 가능한 사이트는 밋밋해 보인다.” 접근성은 대비, 포커스 스타일, 글자 크기 같은 몇 가지를 제약하지만, 보기 좋은 접근 가능한 사이트가 일반적이며 예외가 아닙니다.
• “자동 검사기가 100점이라고 하면 끝이다.” 자동 도구는 일부 문제만 잡습니다. 대체 텍스트가 실제로 의미 있는지, 또는 스크린 리더로 흐름이 이해되는지는 사람이 확인해야 합니다.
• “오버레이 위젯이 우리를 규정 준수하게 만든다.” 위에 덧붙인 도구 모음은 코드의 누락된 레이블이나 깨진 키보드 접근을 고칠 수 없습니다. 원본을 고치세요.
• “장애가 있는 사용자가 없다.” 여러분이 모를 뿐일 수 있습니다. 많은 장애는 겉으로 보이지 않으며, 장벽을 만난 사람들은 보통 그냥 떠납니다.

AI 빌더에 요청할 내용

• “이것을 WCAG 2.2 AA 등급에 맞게 만들어줘.”
• “시맨틱 HTML을 사용해줘. 실제 버튼, 링크, 순서대로 된 제목, 모든 폼 필드의 레이블을 넣어줘.”
• “모든 상호작용 요소가 키보드만으로 작동하고 보이는 포커스 스타일을 갖도록 해줘.”
• “모든 텍스트와 아이콘 색상의 대비를 확인해줘. 일반 텍스트는 4.5:1, 큰 텍스트와 아이콘은 3:1이어야 해.”
• “의미 있는 이미지에는 의미 있는 대체 텍스트를, 장식용 이미지에는 빈 대체 텍스트를 넣어줘.”
• “폼 오류는 색상만이 아니라 필드와 연결된 텍스트로 보여줘.”
• “애니메이션은 사용자의 동작 줄이기 설정을 따르도록 해줘.”
• “자동 접근성 검사를 실행하고, 검사가 확인할 수 없는 항목을 목록으로 알려줘. 그래야 내가 직접 확인할 수 있어.”

그다음 직접 테스트하세요. 마우스를 치우고 Tab, Shift+Tab, Enter, Space만으로 주요 흐름을 완료해보세요. 휴대폰의 내장 스크린 리더로 메인 페이지를 들어보세요. 브라우저를 200%로 확대해서 무언가 깨지는지 확인하세요.

Mythex에서의 접근성

Mythex에는 전용 접근성 검사기가 없으므로, 접근성을 프롬프트와 테스트의 일부로 다루세요. 첫 프롬프트부터 WCAG 2.2 AA를 요청하고, 미리보기에서 키보드로 결과를 확인하고, 게시하기 전에 /test를 사용해 에이전트가 주요 흐름을 클릭하며 확인하도록 하세요(앱 테스트 참고). SEO 레시피도 시맨틱 제목과 의미 있는 대체 텍스트를 요청하는데, 이는 두 목표 모두에 도움이 됩니다.

실습용 체크리스트는 웹사이트를 접근 가능하게 만드는 방법을 참고하세요. 디자인은 AI로 보기 좋은 앱을 디자인하는 방법을, 출시 전에는 출시 전 앱을 테스트하는 방법을 읽어보세요. 가장 권위 있는 자료는 W3C의 WCAG 개요입니다.

자주 묻는 질문