웹 접근성(a11y) 기초, 프론트엔드 개발자가 꼭 알아야 할 이유

웹사이트를 만들 때 “모든 사용자”를 고려한다고 말하지만, 정말 모든 사용자가 여러분의 웹사이트를 이용할 수 있을까요? 2025년 WebAIM 조사에 따르면 상위 100만 개 웹사이트 중 94.8%가 기본적인 접근성 기준조차 충족하지 못하고 있습니다. 키보드만으로 내비게이션이 불가능하거나, 스크린 리더가 이미지를 읽지 못하거나, 버튼이 무엇을 하는 버튼인지 알 수 없는 상태로 배포되는 경우가 그만큼 많다는 뜻입니다.

웹 접근성(a11y, accessibility의 약어)은 장애인, 고령자를 포함한 모든 사용자가 웹 콘텐츠를 동등하게 인식하고 조작할 수 있도록 보장하는 것을 말합니다. 이 글에서는 프론트엔드 개발자가 반드시 알아야 할 접근성의 핵심 개념과 실전 적용법을 다룹니다.

웹 접근성이란 무엇이고, 왜 프론트엔드 개발자에게 중요할까?

웹 접근성은 시각, 청각, 운동, 인지 등 다양한 장애를 가진 사용자가 웹사이트를 제한 없이 이용할 수 있도록 만드는 것입니다. WHO에 따르면 전 세계 인구의 약 16%가 상당한 수준의 장애를 경험하고 있습니다. 이는 “특별한 소수”가 아니라 실제로 방대한 수의 사용자입니다.

프론트엔드 개발자에게 웹 접근성이 중요한 이유는 크게 세 가지입니다.

첫째, 법적 의무입니다. 한국은 장애인차별금지법과 지능정보화기본법에 따라 공공기관 웹사이트의 접근성 준수를 의무화하고 있으며, 한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2를 기준으로 품질 인증을 실시합니다. 미국은 ADA Title II에 따라 공공기관이 2026년 4월까지 WCAG 2.1 AA를 충족해야 하고, EU는 2025년 6월 유럽 접근성 법(EAA)이 발효되어 민간 서비스까지 적용 범위가 확대되었습니다.

둘째, 사용자 경험의 향상입니다. 접근성이 좋은 웹사이트는 장애가 없는 사용자에게도 더 편리합니다. 키보드 내비게이션, 명확한 포커스 표시, 충분한 색상 대비 등은 모든 사용자의 사용성을 높여줍니다.

셋째, SEO와의 연관성입니다. 시맨틱 HTML 사용, 대체 텍스트 제공, 논리적 문서 구조는 검색 엔진이 콘텐츠를 더 잘 이해하게 합니다. 접근성을 챙기면 검색 최적화는 자연스럽게 따라옵니다.

WCAG 2.2란 무엇이고, 왜 알아야 할까?

WCAG(Web Content Accessibility Guidelines)는 W3C가 제정한 국제 웹 접근성 표준입니다. 가장 최신 버전인 WCAG 2.2는 2023년 10월에 공식 발표되었고, 2025년에는 ISO/IEC 40500:2025로 국제 표준 인증까지 받았습니다. 한국의 KWCAG 2.2 역시 이 국제 표준을 바탕으로 4개 원칙, 14개 지침, 33개 검사 항목으로 구성되어 있습니다.

WCAG의 핵심은 POUR라고 불리는 4대 원칙입니다.

원칙	영문	의미
인식의 용이성	Perceivable	모든 정보와 UI를 사용자가 인식할 수 있어야 한다
운용의 용이성	Operable	UI와 내비게이션을 조작할 수 있어야 한다
이해의 용이성	Understandable	정보와 UI 조작 방법을 이해할 수 있어야 한다
견고성	Robust	다양한 보조 기술을 포함한 사용자 에이전트가 해석할 수 있어야 한다

WCAG 2.2는 기존 2.1 대비 9개의 새로운 성공 기준을 추가했습니다. 모바일 터치 타겟 최소 크기(24x24px), 포커스 가시성 강화, 인지 접근성 개선, 인증 과정 접근성 등이 핵심 변경 사항입니다. 법적 준수 기준으로는 Level AA가 전 세계적으로 권장됩니다.

지금 웹 접근성 현황은 어떨까?

2025년 WebAIM Million 보고서는 상위 100만 개 웹사이트 홈페이지의 접근성을 분석한 결과를 공개했습니다. 핵심 수치를 정리하면 다음과 같습니다.

항목	수치
WCAG 2.2 AA 기준 미달 비율	94.8%
페이지당 평균 접근성 오류	51개
전체 오류 중 6가지 유형이 차지하는 비율	96%
대비 부족 텍스트가 있는 페이지	79.1%
대체 텍스트 누락 이미지가 있는 페이지	55.5%

특히 주목할 점은, 가장 빈번한 6가지 오류만 해결해도 전체 접근성 문제의 대부분이 사라진다는 것입니다. 그 6가지는 낮은 색상 대비, 이미지 대체 텍스트 누락, 빈 링크, 폼 입력 레이블 누락, 빈 버튼, 문서 언어 미지정입니다. 모두 프론트엔드 개발자가 코드 작성 단계에서 바로 해결할 수 있는 문제들입니다.

프론트엔드 개발자가 바로 적용할 수 있는 접근성 실전 가이드

시맨틱 HTML이 접근성의 출발점인 이유는?

접근성의 첫 번째 규칙은 올바른 HTML 요소를 사용하는 것입니다. 시맨틱 HTML은 브라우저와 스크린 리더에게 콘텐츠의 의미와 구조를 정확히 전달합니다.

html

<!-- 잘못된 예: div로 모든 걸 만드는 경우 -->
<div class="header">
  <div class="nav">
    <div class="nav-item" onclick="goHome()">홈</div>
    <div class="nav-item" onclick="goAbout()">소개</div>
  </div>
</div>

<!-- 올바른 예: 시맨틱 HTML 사용 -->
<header>
  <nav aria-label="주 메뉴">
    <a href="/">홈</a>
    <a href="/about">소개</a>
  </nav>
</header>

<header>, <nav>, <main>, <footer>, <section>, <article> 같은 시맨틱 태그를 사용하면 스크린 리더 사용자가 페이지 구조를 파악하고 원하는 섹션으로 빠르게 이동할 수 있습니다. <div>와 <span>만으로 구성된 페이지에서는 이것이 불가능합니다.

ARIA 속성은 어떻게 써야 할까?

ARIA(Accessible Rich Internet Applications)는 HTML만으로 접근성 정보를 전달하기 어려울 때 보조적으로 사용하는 속성입니다. 하지만 여기서 중요한 사실이 있습니다. WebAIM 2025 조사에 따르면 ARIA를 사용한 페이지의 평균 오류 수는 57개인 반면, ARIA를 사용하지 않은 페이지는 27개에 불과했습니다. ARIA 자체가 문제가 아니라, 잘못 사용된 ARIA가 오히려 접근성을 해치는 것입니다.

ARIA 사용의 첫 번째 규칙은 네이티브 HTML로 해결 가능하면 ARIA를 쓰지 않는 것입니다.

html

<!-- ARIA 없이 네이티브 HTML로 해결 -->
<button type="button">메뉴 열기</button>

<!-- ARIA가 필요한 경우: 커스텀 UI 컴포넌트 -->
<div 
  role="button" 
  tabindex="0" 
  aria-expanded="false"
  aria-controls="dropdown-menu"
  onkeydown="handleKeyPress(event)"
>
  카테고리 선택
</div>
<ul id="dropdown-menu" role="menu" hidden>
  <li role="menuitem">프론트엔드</li>
  <li role="menuitem">백엔드</li>
</ul>

가장 자주 쓰이는 ARIA 속성 세 가지를 정리하면 다음과 같습니다.

속성	용도	사용 예시
aria-label	시각적 텍스트가 없는 요소에 이름 부여	아이콘 버튼, 검색 입력란
aria-expanded	열림/닫힘 상태 전달	아코디언, 드롭다운 메뉴
aria-live	동적으로 변하는 콘텐츠를 스크린 리더에 알림	토스트 알림, 실시간 검색 결과

키보드 접근성은 어떻게 보장할까?

모든 인터랙티브 요소는 키보드만으로 접근 가능해야 합니다. 마우스를 사용할 수 없는 사용자, 운동 장애가 있는 사용자, 그리고 파워 유저 모두에게 키보드 접근성은 필수입니다.

핵심 체크 포인트는 세 가지입니다. Tab 키로 모든 인터랙티브 요소를 순서대로 이동할 수 있는지, Enter 또는 Space 키로 해당 요소를 활성화할 수 있는지, 그리고 현재 포커스 위치가 시각적으로 명확히 보이는지입니다.

css

/* 포커스 스타일을 제거하면 안 됩니다 */
/* 잘못된 예 */
*:focus {
  outline: none;
}

/* 올바른 예: 포커스 스타일을 커스텀하되 제거하지 않음 */
:focus-visible {
  outline: 2px solid #007acc;
  outline-offset: 2px;
}

outline: none은 접근성에서 가장 흔한 실수 중 하나입니다. CSS 리셋 파일에 이 코드가 포함되어 있지 않은지 반드시 확인하세요.

색상 대비와 이미지 대체 텍스트, 얼마나 중요할까?

색상 대비 부족은 전체 접근성 오류의 가장 큰 비중을 차지합니다. WCAG 2.2 AA 기준으로 일반 텍스트는 4.5:1 이상, 큰 텍스트(18px bold 이상 또는 24px 이상)는 3:1 이상의 명도 대비를 충족해야 합니다.

이미지 대체 텍스트(alt)는 스크린 리더 사용자가 이미지의 내용을 이해할 수 있게 해주는 핵심 요소입니다. 모든 의미 있는 이미지에는 구체적인 alt 텍스트를, 장식용 이미지에는 빈 alt(alt="")를 지정해야 합니다.

html

<!-- 잘못된 예 -->
<img src="chart.png" alt="이미지">
<img src="chart.png">

<!-- 올바른 예: 구체적인 대체 텍스트 -->
<img src="chart.png" alt="2025년 프레임워크별 만족도 비교 차트, React 85%, Vue 82%, Svelte 90%">

<!-- 장식용 이미지: 빈 alt -->
<img src="decorative-line.png" alt="">

접근성 점검 도구로 바로 테스트해 보세요

접근성은 코드를 작성하면서 동시에 점검하는 것이 가장 효율적입니다. 프론트엔드 개발 환경에서 바로 사용할 수 있는 도구를 소개합니다.

도구	유형	특징
Lighthouse	브라우저 내장	Chrome DevTools에서 바로 실행, 접근성 점수 제공
axe DevTools	브라우저 확장	WCAG 기준 위반 항목을 구체적으로 표시
WAVE	웹 서비스 / 확장	페이지에 오류를 시각적으로 오버레이해서 표시
eslint-plugin-jsx-a11y	ESLint 플러그인	React 개발 시 코드 작성 단계에서 접근성 경고

React를 사용한다면 eslint-plugin-jsx-a11y를 프로젝트에 설치하는 것을 권장합니다. 이미지에 alt가 없거나, <a> 태그에 href가 없거나, 인터랙티브 요소에 키보드 이벤트가 빠진 경우를 코딩 단계에서 바로 잡아줍니다.

FAQ

마무리: 접근성은 선택이 아니라 기본 역량입니다

웹 접근성은 특별한 기술이 아닙니다. 시맨틱 HTML을 올바르게 사용하고, 이미지에 alt 텍스트를 넣고, 키보드 내비게이션을 보장하고, 충분한 색상 대비를 유지하는 것만으로도 대부분의 접근성 문제를 해결할 수 있습니다. 실제로 가장 흔한 6가지 오류만 없애도 전체 문제의 96%가 사라집니다.

접근성은 프로젝트 마지막에 추가하는 것이 아니라, 코드의 첫 줄부터 함께하는 것입니다. 오늘 작성하는 코드에서 <div> 대신 <button>을 쓰는 것부터 시작해 보세요.

참고 자료:

• WCAG 2.2 Overview – W3C WAI
• WebAIM Million 2025 Report
• MDN Web Docs – ARIA
• 한국형 웹 콘텐츠 접근성 지침 2.2
• Lighthouse 접근성 점검 가이드

관련 글:

• 웹 성능 최적화 입문: Lighthouse 점수 높이는 법
• 2026년 주목해야 할 프론트엔드 트렌드 5가지
• React vs Vue vs Svelte 2026, 입문자라면 뭘 배워야 할까?