이 글은 누구를 위한 것인가
- 접근성 이슈를 "나중에 해결할 것"으로 미뤄왔던 디자이너·개발자
- WCAG 기준이 바뀌었다는 말을 들었지만 구체적으로 무엇이 달라졌는지 모르는 분
- 스크린리더 사용자가 실제로 어떻게 웹을 이용하는지 경험해보고 싶은 분
들어가며
2025년 6월, EU의 **EAA(European Accessibility Act)**가 전면 시행됐다. 유럽에 서비스를 제공하는 모든 기업은 웹사이트와 앱의 접근성 기준을 준수해야 한다. 위반 시 과태료와 영업 제한이 따른다.
국내도 마찬가지다. 장애인차별금지법에 따라 일정 규모 이상의 웹사이트는 웹 접근성 기준을 지켜야 하고, 미준수 시 소송과 과태료 대상이 된다.
법적 의무를 떠나서, 접근성은 더 많은 사람이 우리 서비스를 쓸 수 있게 하는 것이다. 전 세계 인구의 약 15%인 10억 명 이상이 어떤 형태로든 장애를 가지고 있다. 이들이 우리 서비스에서 떠나고 있다는 것을 알고 있는가?
1. 스크린리더 사용자는 어떻게 웹을 경험하는가
접근성을 이해하는 가장 빠른 방법은 스크린리더를 직접 써보는 것이다. Mac의 VoiceOver(Command + F5)를 켜고 눈을 감은 채로 아무 쇼핑몰이나 접속해보자. 30초도 안 되어 좌절감을 느낄 것이다.
스크린리더 사용자가 겪는 흔한 문제들
이미지 위에서 멈췄는데 "이미지"라고만 읽힌다.
→ alt 텍스트가 없거나 파일명만 있음
버튼 위에서 "버튼"이라고만 읽힌다.
→ 버튼에 레이블이 없음. "닫기 버튼"인지 "제출 버튼"인지 알 수 없음
팝업이 열렸는데 포커스가 팝업 안으로 이동하지 않는다.
→ 모달 포커스 관리가 없음. 팝업 뒤 배경을 계속 읽음
"링크"라고만 읽히는 링크가 수십 개 있다.
→ "자세히 보기" 링크가 어떤 페이지로 가는지 알 수 없음
이런 문제들은 코드 몇 줄로 해결 가능한데, 처음에 신경 쓰지 않아서 쌓이게 된다.
2. WCAG 2.2의 핵심 변경 사항
WCAG(Web Content Accessibility Guidelines) 2.2는 2023년 10월에 공식 발표됐다. 2.1 대비 주요 변경사항을 보자.
새롭게 추가된 기준 중 실무에서 중요한 것
| 기준 | 내용 | 실무 적용 |
|---|---|---|
| 2.4.11 Focus Not Obscured | 포커스된 요소가 다른 요소(예: sticky 헤더)에 완전히 가려지면 안 됨 | sticky 헤더 높이만큼 스크롤 오프셋 조정 |
| 2.5.7 Dragging Movements | 드래그가 필요한 기능은 클릭으로도 사용 가능해야 함 | 드래그 UI에 대안 인터랙션 제공 |
| 2.5.8 Target Size | 클릭 가능한 요소 최소 크기 24×24px (권장 44×44px) | 모바일 터치 영역 설계 시 적용 |
| 3.2.6 Consistent Help | 도움말 기능이 있다면 일관된 위치에 표시 | 사이트 전체 헬프 아이콘 위치 통일 |
| 3.3.7 Redundant Entry | 이미 입력한 정보를 다시 입력하게 하지 않음 | 배송지 = 청구지 체크박스 등 |
| 3.3.8 Accessible Authentication | 인지 기능 테스트(CAPTCHA)만으로 인증하면 안 됨 | CAPTCHA + 대안 수단 제공 |
3. 컴포넌트별 접근성 체크리스트
버튼 (Button)
<!-- 잘못된 예 -->
<div class="btn" onclick="handleClick()">확인</div>
<!-- 올바른 예 -->
<button type="button" onclick="handleClick()">확인</button>
<!-- 아이콘만 있는 버튼 -->
<button type="button" aria-label="닫기">
<svg aria-hidden="true">...</svg>
</button>
<div>대신<button>사용 (키보드 접근 자동 지원)- 아이콘만 있는 버튼에
aria-label필수 - 비활성화 상태에
disabled속성 사용
폼 (Form)
<!-- 잘못된 예 -->
<input type="text" placeholder="이름을 입력하세요">
<!-- 올바른 예 -->
<label for="name">이름 <span aria-hidden="true">*</span><span class="sr-only">(필수)</span></label>
<input type="text" id="name" required aria-required="true"
aria-describedby="name-error">
<p id="name-error" role="alert" hidden>이름을 입력해주세요.</p>
- 모든 입력 필드에
<label>연결 placeholder는 레이블 대체 불가 (입력 시 사라지므로)- 오류 메시지는
role="alert"로 스크린리더에 즉시 전달
모달 (Modal)
function openModal(modalId) {
const modal = document.getElementById(modalId);
const previousFocus = document.activeElement;
modal.removeAttribute('hidden');
modal.setAttribute('aria-modal', 'true');
// 모달 안의 첫 번째 포커스 가능 요소로 이동
const firstFocusable = modal.querySelector('button, [href], input, select, textarea');
firstFocusable?.focus();
// 모달 닫을 때 원래 포커스 위치로 복원
modal.addEventListener('close', () => previousFocus.focus(), { once: true });
}
- 모달 열릴 때 포커스 이동 필수
- 모달 안에서 Tab 키가 빠져나가지 않도록 포커스 트랩
- Escape 키로 닫기 가능
- 닫힐 때 원래 위치로 포커스 복원
4. Headless UI 라이브러리 활용하기
접근성을 처음부터 제대로 구현하는 것은 시간이 많이 걸린다. Headless UI 라이브러리는 ARIA 패턴을 내장하고 있어서, 스타일만 추가하면 접근성이 보장된 컴포넌트를 빠르게 만들 수 있다.
| 라이브러리 | 특징 | 사용 기술 |
|---|---|---|
| Radix UI | 완전한 접근성 내장, 비스타일드 | React |
| Headless UI (Tailwind) | Tailwind CSS와 찰떡 조합 | React, Vue |
| Ark UI | 최신 ARIA 패턴 지원 | React, Vue, Solid |
| React Aria (Adobe) | 가장 완벽한 접근성 | React |
이 중 Radix UI가 가장 널리 사용된다. 드롭다운, 다이얼로그, 슬라이더, 탭 등 복잡한 컴포넌트도 접근성이 완벽하게 내장되어 있다.
5. axe-core로 자동 접근성 테스트 구축
사람이 모든 접근성 문제를 수동으로 확인할 수는 없다. axe-core 기반의 자동화 테스트를 CI 파이프라인에 통합하면 주요 접근성 오류를 자동으로 잡아낼 수 있다.
// Storybook에서 axe-core 테스트
import { axe } from 'jest-axe';
import { render } from '@testing-library/react';
test('Button 컴포넌트 접근성', async () => {
const { container } = render(<Button>제출하기</Button>);
const results = await axe(container);
expect(results).toHaveNoViolations();
});
axe-core는 WCAG 2.1/2.2 기준의 약 30~40%를 자동으로 검출한다. 나머지는 수동 테스트가 필요하지만, 이것만으로도 명백한 오류 대부분을 걸러낼 수 있다.
6. 접근성 개선으로 전환율이 오른 사례들
접근성은 의무적으로 지키는 것이 아니라 비즈니스 기회이기도 하다.
- Tesco UK: 접근성 개선 후 온라인 매출 35% 증가
- Legal & General (영국 보험사): 접근성 재설계 후 웹 트래픽 50% 증가, 유지 비용 감소
- 정부24 (국내): 접근성 개선 후 고령 사용자 민원 30% 감소
이 수치들이 보여주는 것은, 접근성을 개선하면 장애인 사용자만 이득을 보는 것이 아니라는 점이다. 노인, 일시적 부상자, 느린 네트워크 사용자, 밝은 햇빛 아래 화면을 보는 사람 모두가 접근성이 좋은 UI에서 더 편안함을 느낀다.
맺으며
접근성은 사후에 붙이는 기능이 아니라 설계 단계에서 내재화해야 하는 품질 기준이다. 나중에 고치려면 비용이 3~4배 든다는 것이 업계 공통된 경험이다.
지금 당장 시작할 수 있는 것은 간단하다. 브라우저에서 Tab 키만 눌러보자. 우리 서비스가 키보드만으로 완전히 사용 가능한가? 모든 버튼에 마우스를 올리지 않고도 접근 가능한가? 이 기본적인 확인부터 시작하면 된다.