웹 접근성(Web Accessibility)은
장애가 있는 사용자도 웹 콘텐츠를 문제없이 접근하고 사용할 수 있도록 만드는 기술과 설계다.
예전에는 “나랑 상관없지”라고 생각했지만,
지금은 공공기관, 대기업, 심지어 스타트업까지
접근성을 지키지 않으면 리스크가 생기는 시대다.
이번 글에서는 프론트엔드 개발자가 실무에서 웹 접근성을 고려할 수 있는 실질적인 방법들을 정리해봤다.
✅ 왜 웹 접근성이 중요한가?
- 👨🦯 시각 장애인, 색각 이상자, 노년층도 웹을 사용함
- 🧑⚖️ 공공기관, 금융 사이트는 법적 의무 대상
- 🧪 SEO에도 긍정적인 영향
- 💡 사용자 경험(UX)의 극단적 확장이 바로 접근성
✅ 기본 중의 기본
1️⃣ 이미지엔 alt 속성
<img src="product.jpg" alt="삼성 갤럭시 S23 핸드폰 전면 이미지" />- 스크린 리더는 alt 값을 읽어줌
- 단순 장식일 경우
alt=""로 비워두기
2️⃣ 버튼은 button 태그로
<button onClick={doSomething}>저장하기</button>❌ <div onClick>은 스크린 리더에서 "무응답 요소"로 인식될 수 있음
✅ role="button" + tabIndex=0으로도 대응 가능하지만, button 태그가 가장 안전
3️⃣ 폼 요소는 label과 연결
<label for="email">이메일 주소</label>
<input id="email" name="email" />- 스크린 리더는 label을 먼저 읽어줌
label없이 placeholder만 있는 입력은 매우 불친절
4️⃣ 키보드만으로도 조작 가능해야
- 모든 인터랙션은 Tab → Enter / Space로 접근 가능해야 함
tabIndex="-1"로는 포커스 이동 불가tabIndex="0"이상이 되어야 Tab으로 접근 가능
🎯 실무에서 자주 쓰는 ARIA 속성
| 속성 | 역할 |
|---|---|
aria-label | 시각적으로 보이지 않지만, 스크린 리더에게 설명 제공 |
aria-hidden="true" | 해당 요소를 스크린 리더에서 무시하게 함 |
aria-live="polite" | 동적 변화 영역을 사용자에게 자동 읽어주기 |
role="dialog" | 모달 컴포넌트에 사용 (스크린 리더에 알림) |
✅ 실무 적용 예시
1️⃣ 접근성 좋은 모달 컴포넌트
<div role="dialog" aria-modal="true" aria-labelledby="modalTitle">
<h2 id="modalTitle">회원가입 완료</h2>
<p>이제 로그인이 가능합니다.</p>
<button onClick={closeModal}>닫기</button>
</div>role="dialog"→ 모달임을 알림aria-labelledby→ 타이틀을 읽음aria-modal="true"→ 모달이 떠 있을 때 백그라운드는 접근 불가
🔎 접근성 테스트 툴
- ✅ Chrome DevTools > Lighthouse > Accessibility
- ✅ axe DevTools 크롬 확장
- ✅ VoiceOver (macOS 내장 스크린 리더)
- ✅ NVDA (Windows용 스크린 리더)
📝 내가 느낀 점
처음엔 alt, label 정도만 챙기면 된다고 생각했는데,
접근성 검사 도구로 페이지를 돌려보면 정말 많은 부분이 지적된다.
접근성은 “눈에 안 보이는 UX”라는 말처럼,
디자인보다도 개발자가 더 책임지고 챙겨야 하는 부분이라는 걸 깨달았다.
이제는 마크업 짤 때 기본적으로 role, aria, tabIndex를 습관적으로 넣고 있다.
🫶 "접근성은 일부 사용자를 위한 기능이 아니라, 모두를 위한 기본값이다."
개발자로 취업을 준비 중 이며, 열심히 공부 중 입니다!