구글이 좋아하는 시맨틱 구조 강화
처음 aria-label이라는 속성을 알았을 때 반응이 "이게 뭐 대수냐"였다. 그냥 텍스트 하나 더 붙이는 거잖아. 그런데 현장에서 스크린 리더 테스트를 직접 해보고 나서 생각이 완전히 뒤집혔다. 화면을 보지 않고 소리만으로 웹페이지를 탐색하는 경험은 충격적이었다. "버튼, 버튼, 버튼" 이렇게만 읽히는 화면에서 사용자가 느끼는 답답함은 마치 불 꺼진 지하 주차장에서 내 차를 찾는 것과 다르지 않았다.
ARIA가 뭔지, WAI-ARIA부터 이해하자
ARIA는 Accessible Rich Internet Applications의 약자다. WAI-ARIA라고 하면 Web Accessibility Initiative에서 만든 스펙을 말한다. 쉽게 말하면 HTML 요소에 의미와 역할, 상태 정보를 추가로 달아주는 속성 묶음이다. HTML만으로는 전달하기 어려운 맥락 정보를 스크린 리더나 보조 기술에 전달하는 다리 역할을 한다.
가장 많이 쓰는 ARIA 속성 세 가지가 있다. aria-label, aria-labelledby, aria-describedby다. 이 중 aria-label이 가장 직접적이고 자주 사용된다. 요소에 사람이 읽을 수 있는 이름을 직접 붙여주는 방식이다.
aria-label이 없으면 생기는 현실적인 문제
아이콘 버튼을 생각해 보자. 검색 버튼, 좋아요 버튼, 공유 버튼. 화면에는 아이콘만 보인다. 마우스를 쓰는 사람은 아이콘 모양으로 기능을 유추한다. 그런데 스크린 리더 사용자에게는 그냥 "버튼"이다. 무슨 버튼인지 알 수 없다. 더 심한 경우는 이미지로 만든 버튼인데 alt 텍스트조차 없는 경우다. 스크린 리더가 파일명을 그대로 읽어버린다. "icon-search-v2-final-수정.png 버튼" 이런 식으로.
<!-- 잘못된 방법: 스크린 리더가 의미를 알 수 없음 -->
<button>
<img src="search-icon.svg">
</button>
<!-- 올바른 방법: aria-label로 목적 명시 -->
<button aria-label="검색">
<img src="search-icon.svg" alt="">
</button>
이미지에 alt=""를 빈 값으로 두는 건 의도적인 처리다. aria-label이 이미 버튼 전체의 레이블 역할을 하기 때문에 이미지 자체는 장식적 요소로 취급하면 된다. 중복 읽힘을 방지하는 방법이다.
네비게이션 영역에서 aria-label을 쓰는 방법
한 페이지에 nav 태그가 여러 개 있을 때가 문제다. 헤더 네비게이션, 사이드바 네비게이션, 푸터 네비게이션. 스크린 리더는 이것들을 구분하지 못하고 그냥 "내비게이션"이라고만 읽는다. 마치 건물 안내판에 "화장실", "화장실", "화장실"만 써있고 어느 층 어느 방향인지 없는 것과 같다. aria-label로 각 내비게이션의 역할을 명확히 해줘야 한다.
<!-- 여러 nav 영역을 구분하는 올바른 방법 -->
<header>
<nav aria-label="주요 메뉴">
<ul>
<li><a href="/">홈</a></li>
<li><a href="/blog">블로그</a></li>
<li><a href="/contact">연락처</a></li>
</ul>
</nav>
</header>
<aside>
<nav aria-label="카테고리">
<ul>
<li><a href="/category/html">HTML</a></li>
<li><a href="/category/css">CSS</a></li>
<li><a href="/category/js">JavaScript</a></li>
</ul>
</nav>
</aside>
<footer>
<nav aria-label="사이트 하단 링크">
<ul>
<li><a href="/privacy">개인정보처리방침</a></li>
<li><a href="/terms">이용약관</a></li>
</ul>
</nav>
</footer>
폼 요소와 aria-label: 레이블 없는 입력 필드의 함정
폼 설계 작업을 하다 보면 디자인상 이유로 label 태그를 숨기고 placeholder만 사용하는 경우가 많다. placeholder는 사용자가 입력을 시작하면 사라진다. 스크린 리더 사용자는 입력 중에 이 필드가 무엇인지 다시 확인할 방법이 없다. 이럴 때 aria-label이 구원투수가 된다.
<!-- 레이블 없이 placeholder만 사용하는 잘못된 방법 -->
<input type="email" placeholder="이메일 주소를 입력하세요">
<!-- aria-label로 명시적 레이블 제공 -->
<input
type="email"
aria-label="이메일 주소"
placeholder="example@email.com"
>
<!-- 가장 이상적인 방법: label 태그 연결 (SEO와 접근성 모두 최적) -->
<label for="user-email">이메일 주소</label>
<input
type="email"
id="user-email"
name="email"
placeholder="example@email.com"
>
label 태그를 직접 연결하는 게 가장 좋은 방법이다. 구글 크롤러도 label-input 연결 구조를 명확한 시맨틱 신호로 인식한다. aria-label은 label 사용이 어려운 상황에서의 차선책이다.
aria-labelledby: 기존 텍스트를 레이블로 재활용하는 방법
페이지에 이미 존재하는 텍스트를 레이블로 쓰고 싶을 때가 있다. 그럴 때는 aria-label보다 aria-labelledby가 더 적합하다. aria-label은 새 텍스트를 직접 지정하고, aria-labelledby는 이미 페이지에 있는 요소의 텍스트를 참조한다.
<section aria-labelledby="section-title">
<h2 id="section-title">최신 기술 아티클</h2>
<p>이 섹션은 id가 section-title인 h2의 텍스트를 레이블로 사용합니다.</p>
</section>
<!-- 여러 id를 공백으로 연결하면 합쳐서 읽힘 -->
<div aria-labelledby="modal-title modal-subtitle">
<h2 id="modal-title">구독 신청</h2>
<p id="modal-subtitle">매주 월요일 아침에 받아보는 개발 뉴스레터</p>
</div>
구글이 시맨틱 구조를 왜 좋아하는가
구글의 검색 알고리즘은 페이지의 콘텐츠를 이해하고 분류하려 한다. 이 과정에서 구조적 신호가 결정적인 역할을 한다. 예를 들어 nav 태그 안에 있는 링크들은 메인 콘텐츠 링크와 다르게 취급된다. aside 안의 내용은 주요 콘텐츠와 구분된다. aria 속성들은 이 구조적 의미를 더욱 명확하게 만들어준다.
실제 테스트 결과를 보면 aria-label로 구조화된 페이지는 구글 Search Console에서 구조화 데이터 관련 경고가 줄어드는 경향이 있다. 접근성 점수가 높은 페이지는 Core Web Vitals 평가에서도 유리한 면이 있다. 모두 연결된 고리다.
현장에서 느낀 장단점과 주의사항
aria-label을 처음 도입할 때 가장 많이 했던 실수는 과잉 사용이었다. 모든 요소에 aria-label을 붙이면 오히려 스크린 리더가 중복 정보로 혼란스러워진다. 예를 들어 이미 텍스트가 있는 버튼에 aria-label을 따로 달면 텍스트와 aria-label이 따로따로 읽히는 경우가 생긴다. ARIA 사용의 첫 번째 원칙은 "HTML이 충분하면 ARIA를 추가하지 마라"다.
<!-- 이렇게 하면 안 됨: 텍스트가 있는 버튼에 불필요한 aria-label 추가 -->
<button aria-label="제출하기">제출하기</button>
<!-- 이렇게 해야 함: 텍스트가 명확하면 aria-label 불필요 -->
<button>제출하기</button>
<!-- aria-label이 꼭 필요한 경우: 텍스트 없이 아이콘만 있을 때 -->
<button aria-label="메뉴 열기">
<svg aria-hidden="true" focusable="false" width="24" height="24">
<!-- 햄버거 메뉴 아이콘 SVG 패스 -->
<rect x="2" y="5" width="20" height="2"></rect>
<rect x="2" y="11" width="20" height="2"></rect>
<rect x="2" y="17" width="20" height="2"></rect>
</svg>
</button>
SVG 아이콘에 aria-hidden="true"와 focusable="false"를 함께 쓰는 것도 중요하다. SVG 자체가 포커스를 받거나 스크린 리더에 읽히지 않도록 하는 처리다. IE11 시절에는 SVG가 Tab 포커스를 받는 버그가 있어서 focusable="false"가 필수였는데, 이제는 브라우저 지원이 좋아졌지만 습관처럼 쓰는 게 안전하다.
마무리: aria-label은 배려가 아니라 커뮤니케이션이다
개발 일을 오래 하다 보면 코드가 결국 사람과 사람 사이의 소통이라는 걸 느끼게 된다. 내가 만드는 코드는 기계만 읽는 게 아니라, 그 기계를 통해 사람이 정보를 얻는다. 스크린 리더 사용자, 키보드 사용자, 저시력 사용자. 이들이 내 페이지에서 길을 잃지 않도록 하는 것이 aria-label이 하는 일이다. 이걸 배려라고 표현하면 마치 특별한 선물처럼 들리지만, 사실은 커뮤니케이션의 기본이다. 식당 메뉴판에 글씨를 읽을 수 있게 쓰는 것처럼, 당연히 해야 하는 일이다.
처음에는 aria-label이 그냥 속성 하나 더 붙이는 귀찮은 작업이었다. 그런데 직접 스크린 리더로 내가 만든 페이지를 탐색해 보고 나서 관점이 바뀌었다. 화면을 보지 않고 소리만으로 탐색할 때 aria-label이 없는 버튼은 아무 의미 없는 소음이었다. 반면 aria-label이 제대로 달린 페이지는 눈을 감고도 구조가 머릿속에 그려졌다. 그 경험 하나가 나를 바꿔놓았다. 이제는 새 컴포넌트를 만들 때 아이콘 버튼이면 자동으로 aria-label을 먼저 생각한다. 습관이 됐다.
구글 SEO 관점에서도 효과는 분명했다. aria-label과 시맨틱 구조를 정리한 이후 Search Console에서 크롤링 오류가 줄었고, 구조화 데이터 경고도 감소했다. 페이지 이해도가 높아지면 구글이 더 정확하게 페이지를 분류하고, 그 결과로 관련 검색어에서 순위가 오른다. 접근성과 SEO는 같은 목표를 향한 두 개의 길이 아니라, 원래부터 하나의 길이었다. 그 길을 제대로 가고 있는지 체크하는 도구가 바로 스크린 리더 테스트와 Lighthouse다. 이 두 가지를 배포 전 체크리스트에 넣는 것만으로도 개발 품질이 눈에 띄게 달라진다는 것을 확신을 가지고 말할 수 있다. 10년이 넘는 현장 경험이 그 증거다.
aria-label을 처음 배우는 분들께 한 가지만 당부하자면, 과잉 사용을 경계하라는 것이다. 의미 있는 HTML 구조가 먼저고, aria는 HTML이 부족할 때 보완하는 도구다. 이 우선순위를 헷갈리면 오히려 접근성이 나빠지는 역설이 생긴다. 도구는 올바르게 써야 효과가 있다. 그리고 올바르게 쓰면 정말 강력한 도구가 된다.
출처 및 참고 경로
- WAI-ARIA 1.2 공식 스펙: https://www.w3.org/TR/wai-aria-1.2/
- MDN aria-label 문서: https://developer.mozilla.org/ko/docs/Web/Accessibility/ARIA/Attributes/aria-label
- WebAIM ARIA 가이드: https://webaim.org/techniques/aria/
- Google 접근성 개발자 가이드: https://developers.google.com/web/fundamentals/accessibility/semantics-aria
- ARIA 올바른 사용법 (W3C): https://www.w3.org/TR/using-aria/
- 스크린 리더 NVDA 무료 다운로드: https://www.nvaccess.org/