WCAG 도입 개요 및 적용 검토

WCAG(웹 콘텐츠 접근성 가이드라인)이란?

WCAG(Web Content Accessibility Guidelines) 는 웹 콘텐츠가 누구에게나 접근 가능해지도록 만들기 위해 W3C(World Wide Web Consortium)가 제정한 국제 표준 가이드라인이다.

즉, 시각/청각/운동 능력/인지적 제약이 있는 사용자도 동등하게 웹 서비스를 사용할 수 있도록 만드는 기준

WCAG 검토가 왜 필요한가?

글로벌 SaaS 서비스에서 웹 접근성은 선택사항이 아닌 필수이다. 특히 특정 솔루션·엔터프라이즈 서비스의 경우, 정부기관·금융권·공공기관을 포함한 B2B 고객들과 계약을 진행할 때 벤더 검증 과정에서 접근성에 대한 컴플라이언스 요구가 등장한다고 한다. (WCAG 준수 보고서, VPAT, A11y 테스팅 로그 등...)

대표적인 기준은 다음과 같으며 미국 시장과 EU시장은 WCAG 2.1 AA가 준수 계약 족건이 되는 경우가 다수라고 한다.

WCAG의 원칙과 준수 레벨

WCAG는 1999년 1.0 버전을 시작으로, 2025년 현재 WCAG 2.2 표준 버전 까지 나와 있으며 WCAG 3.0은 Draft 단계에 있다. W3C에서는 최신 표준 버전 적용을 권고한다.

WCAG에는 4대원칙 POUR와 준수레벨(Level A/AA/AAA)이 있는데 내용은 다음과 같다. (https://www.w3.org/WAI/WCAG22/quickref/?versions=2.1 참고하여 작성)

WCAG의 4대원칙

Perceivable (인지·지각 가능) 정보를 알아볼 수 있어야 함

• 대체텍스트
  → 이미지를 삽입할 때, 시각 장애인 사용자를 위해 “대체 텍스트(alt 텍스트)”를 입력해 두어야 함. 이 텍스트는 스크린 리더(화면 낭독 프로그램)가 읽어주기 때문에 이미지를 볼 수 없는 사람도 이미지의 의미를 알 수 있음
• 시간 기반 미디어
  → 비디오에는 자막·수화통역, 오디오에는 텍스트로 볼 수 있는 스크립트 제공 필요.
• 적응 가능
  → 콘텐츠가 한 가지 형태에 고정되지 않고, 사용자의 필요나 사용하는 기기에 따라 재구성 될 수 있어야 함
  (스크린 리더와 같은 보조기술 적용, 모바일·태블릿·데스크탑 화면 크기에 따라 레이아웃 변환)
• 충분한 색 대비
  → 시각적, 청각적 요소들이 서로 겹쳐서 중요한 정보가 가려지거나 묻히지 않도록 설계
  (텍스트와 배경간의 명암 대비를 충분히 확보해야 함)
  

Operable (조작 가능) 키보드 등 다양한 방식으로 조작 가능

• 키보드 접근 가능
  → 마우스가 아닌 키보드만으로 모든 메뉴와 버튼을 이동 및 클릭할 수 있어야 함
• 충분한 시간
  → 사용자가 콘텐츠를 읽고 사용하는데 충분한 시간을 제공해야 함
  (로그인 세션 타임이 너무 짧게 설정되어 만료되지 않도록, 캐러셀이 너무 빠르게 움직이지 않도록)
• 발작 및 신체반응
  → 번쩍임으로 인한 간질 발작, 어지러움, 메스꺼움 유발 금지
• 탐색 가능
  → 사용자가 탐색하고, 콘텐츠를 찾고 현재 위치를 파악할수 있는 방법 제공
  (제목 제공, 포커스 순서 좌→우, 상→하, 주요 탐색 메뉴가 일관된 위치에 제공 - BreadCrumb)
• 입력 양식
  → 키보드 뿐만 아니라 터치·음성·마우스 제스쳐 등 외의 상호작용 방식에도 웹 콘텐츠가 적절히 반응하고 조작할 수 있도록 구현
  

Understandable (이해 가능) UI 사용 방식이 직관적이어야 함

• 가독성
  → 스크린 리더가 텍스트를 읽을 수 있게, 글씨 크기 고려, 가능한 쉬운 언어 사용, 어려운 용어는 풀어 설명해야함
• 예측 가능성
  → 일관된 경험을 제공하여 혼란을 최소화, 탐색 메뉴/로고/검색창의 동일한 상대적 위치 구현, 장바구니 아이콘과 제출버튼이 같지 안도록 등등..
• 입력 지원
  → 사용자가 실수를 피하고 수정할 수 있도록 도와야함
  (입력 필드 레이블 제공, placeholder 제공, 필수 항목 표시, validation message 등등..)
  

Robust (견고한) 보조기술과 호환되어야 함

• 호환성
  → 호환성 극대화를 위해 시맨틱 HTML, ARIA 준수, HTML 구조를 제대로 지켜서 작성하면, 화면 낭독 프로그램이나 검색 엔진이 내용을 정확히 파악할 수 있음

준수 레벨(글로벌 SaaS라면 WCAG 2.1 AA가 사실상 표준)

WCAG 2.2도입 전략

프로젝트 초기 도입

WCAG는 프로젝트 초기부터 도입해야 한다. 접근성은 UI·UX·ARIA 구조·컴포넌트·DOM 구조·컬러 전부 얽혀있기 때문에 나중에 덧붙이면 비싸고 복잡하며 리스크가 커지기 때문이다.

WCAG는 "디자인→ 코드→ 테스트" 전 과정에 영향을 주어 처음부터 넣으면 자연스럽지만, 나중에 붙이면 전면 공사가 되어버려 비용이 급증 하게 된다.

컴포넌트를 만들기 전에 접근성을 설계해야 함

나중에 하면? 버튼 수백개에 aria-label, tabIndex 수정해야함 → 지옥

기초 반영

시맨틱 HTML / ARIA / 키보드 흐름
Design System 적용(UI 컴포넌트)

• 단순히 <div>, <span> 대신 섹션 제목에 <h1>~<h6>, 목록에는 <ul>,<ol>, 네비게이션에는 <nav>을 사용한다.
  버튼 기능이 있는 요소에는 role="button"을 추가하는 대신 네이테브 <button>태그 사용을 권장한다.

• 스크린 리더는 이 시맨틱 태그를 기반으로 콘텐츠의 구조와 역할을 파악하기 때문에 별도 ARIA 속성 없이도 기본적인 접근성 확보 가능

• ARIA란? 시맨틱으로 표현이 불가능하거나 부족한 복잡한 UI에 접근성 속성을 부여하는것을 적용. (role="dialog", aria-modal="true" 등 ...)

• 마우스 없이 키보드로만으로 모든 컨텐츠에 접근하고 상호작용 할 수 있도록 보장 적용. 시맨틱 HTML태그 사용하면 자동으로 부여 됨 (tanindex="0" 등...)

정적 분석

코드 레벨 사전 검증
Biome Rule 추가(따로 옵션 추가없이도 {"recommended": true} 사용하면 AA 레벨까지 커버 가능)

Biome 옵션을 보면 LEVEL A/AA 기준으로 적용해야하는 옵션들이 존재한다.

biome.json 설정 예시

"linter": {
   "enabled": true,
   "rules": {
     "recommended": false,
     "a11y": {
       // recommended로 level AA까지 커버 가능
       "recommended": false,
       // 그 외 웹 접근성 규칙들 적용...
     }
   }
 }

런타임 체크(선택) 실제 렌더링 검증

@axe-core/react 라이브러리 사용하여 런타임에서 접근성 검사를 수행, 정적 분석으로 확인이 어려웠던 부분 추가 검토 가능. 콘솔창에서 아래 세가지 요소를 띄워주게 됨

Element: 문제가 되는 특정 DOM 요소 표시
HTML: HTML코드 스니펫으로 요소, 내용 등 구조 파악
FIX: 위반 사항을 해결하기 위한 기술적인 정보 표시

브라우저 단 검증(선택) Lighthouse + Axe + Wave UI System 수준 품질

CI 자동화(후순위) 배포 전 검증 axe CLI / Playwright etc...

결론

웹 접근성은 한 번에 끝내는 작업이 아니라, 개발 프로세스에 자연스럽게 녹여야 하는 품질 기준이며, 아래 두 조합으로 가는것이 현재 최선의 전략으로 보인다.

• Biome 환경에서 정적 분석 진행
• 이 후 axe-core로 동적 검증 진행