오늘은 프론트엔드 개발자라면 면접이든 실무에서든 한 번쯤 들어봤을 **웹 접근성(A11y)**에 대해 이야기해볼게. accessibility에서 'a'와 'y' 사이에 11글자가 있다고 해서 A11y라고 부르는데, 생각보다 많은 주니어들이 "바쁜데 이것까지 챙겨야 하나요?" 하고 넘어가더라고. 내가 9년 동안 실무에서 구르며 느낀 건, 접근성은 단순한 '배려'가 아니라 서비스의 '품질'이자 개발자의 '실력'을 증명하는 강력한 무기라는 점이야.
1. 시맨틱 마크업만 잘해도 절반은 간다
접근성의 기본은 거창한 기술이 아니라 우리가 매일 쓰는 HTML 태그에서 시작해. 화면의 버튼을 만들 때 <div>에 클릭 이벤트를 다는 게 편할 수 있지만, 스크린 리더를 쓰는 시각 장애인 사용자는 그 요소를 버튼으로 인식하지 못하거든.
<div>대신<button>태그 사용하기- 이미지에는 반드시 구체적인
alt속성 채워 넣기 - 제목은 순서에 맞게
<h1>부터<h6>까지 단계별로 쓰기 이렇게 시맨틱 마크업을 제대로 지키는 것만으로도 스크린 리더가 페이지를 올바르게 읽을 수 있고, 덤으로 검색 엔진 최적화(SEO) 점수까지 챙길 수 있어.
2. WAI-ARIA는 마법의 약이 아니야
HTML 태그만으로 복잡한 UI(예: 탭 메뉴, 모달 창)의 역할을 설명하기 어려울 때 사용하는 게 바로 WAI-ARIA 표준이야. role, aria-label, aria-expanded 같은 속성들이 대표적이지.
실무에서 흔히 하는 실수가 뭐냐면, aria-* 속성을 남발하는 거야. 하지만 접근성 진영의 대원칙은 **"ARIA를 쓰지 않는 것이, 잘못된 ARIA를 쓰는 것보다 낫다"**거든. 네이티브 HTML 태그가 제공하는 기본 기능을 최우선으로 쓰고, 정말 표현이 불가능할 때만 보조적으로 ARIA를 적용하는 습관을 들여봐.
3. 실무에서 바로 써먹는 접근성 테스트 꿀팁
"내가 만든 화면이 접근성을 잘 지켰는지 어떻게 확인하죠?"라는 질문을 정말 많이 받아. 9년차인 나도 매번 수동으로 검사하진 않아. 실무에서는 도구의 도움을 많이 받거든.
- Lighthouse: 크롬 개발자 도구에 기본 탑재된 툴로, 접근성 점수와 개선 가이드를 한눈에 보여줘.
- axe DevTools: 접근성 진단에 특화된 브라우저 익스텐션인데, 에러의 위치와 해결 방법을 아주 구체적으로 알려줘서 강력 추천해.
- 키보드 테스트: 마우스 없이
Tab키와Enter,Space키만으로 네가 만든 웹사이트의 모든 기능을 사용할 수 있는지 직접 테스트해봐. 이것만 해도 치명적인 접근성 오류는 대부분 잡아낼 수 있어.
💡 핵심 정리
- 시맨틱 마크업: 올바른 HTML 태그 사용이 접근성의 가장 기본이자 핵심이다.
- WAI-ARIA의 올바른 사용: 네이티브 태그를 우선하고, ARIA는 보조 수단으로만 최소한으로 사용하자.
- 도구 활용:
Lighthouse와axe DevTools를 활용해 개발 단계에서 수시로 체크하자. 처음에는 접근성을 챙기는 게 귀찮고 일감이 늘어나는 것처럼 느껴질 수 있어. 하지만 사용자를 차별하지 않는 코드를 짜는 개발자가 결국 큰 규모의 서비스도 안정적으로 이끌 수 있거든. 오늘부터 네가 만드는 토이 프로젝트에Tab키를 눌러 이동하는 것부터 가볍게 시작해보는 건 어떨까?