글 · 이시온 · Studio Sion 파운더 · 13년차 프론트엔드 엔지니어
웹 접근성은 마크업에서 시작한다
화려한 인터랙션보다 먼저, 시맨틱 마크업이 서 있어야 합니다. 포털과 커머스에서 배운 접근성의 기본기.
화려한 인터랙션보다 먼저, 시맨틱 마크업이 서 있어야 합니다.
접근성이 뒤늦게 붙는 프로젝트에는 익숙한 실패 패턴이 있습니다. div로 화려한 인터랙션부터 만들어 배포하고, 나중에 접근성 이슈가 올라오면 그 위에 ARIA를 덧바르기 시작합니다. 그런데 열어 보면 키보드로 조작이 안 되고, 포커스가 사라지고, 스크린 리더는 제대로 된 이름과 구조를 읽지 못합니다. 결국 화면을 거의 다시 짭니다.
몇 번 겪고 나서 얻은 결론은 단순합니다. 접근성은 마지막에 뿌리는 소스가 아니라, 처음에 세우는 뼈대라는 것. 그 뼈대가 바로 시맨틱 마크업입니다.
네이티브 HTML은 접근성의 출발선을 만들어 준다
<button> 하나에는 우리가 직접 만들려면 꽤 많은 코드가 필요한 것들이 이미 들어 있습니다. 포커스를 받을 수 있고, 엔터와 스페이스로 눌리고, 스크린 리더가 “버튼”이라고 읽어 주고, 기본 포커스 스타일도 붙습니다.
물론 네이티브 요소를 쓴다고 접근성이 자동으로 완성되는 것은 아닙니다. 하지만 최소한 브라우저가 제공하는 기본 역할, 키보드 동작, 포커스 가능성이라는 출발선을 확보할 수 있습니다.
반면 <div onClick>으로 버튼을 만드는 순간, 그 모든 걸 손으로 다시 구현하겠다고 서명한 셈이 됩니다. 그리고 그중 일부는 반드시 빠지거나 틀립니다.
<!-- 이 div는 마우스로만 눌립니다. 키보드도, 스크린 리더도 이 존재를 버튼으로 알기 어렵습니다 -->
<div class="btn" onclick="submit()">저장</div><!-- 이 한 줄이 포커스·키보드·역할·기본 포커스 스타일의 출발선을 가져옵니다 -->
<button type="button" onclick="submit()">저장</button>접근성의 출발점은 대단한 추가 작업이 아닙니다. 플랫폼이 이미 준 것을 버리지 않는 일에서 시작합니다.
스크린 리더가 의존하는 것은 시각적 모양이 아니라 접근성 트리다
여기서 사고방식 하나가 자리를 잡으면 나머지가 전부 따라옵니다. 브라우저는 우리가 작성한 DOM을 바탕으로 접근성 트리(accessibility tree) 를 만듭니다. 각 요소의 역할(role), 이름(name), 상태(state)가 담긴 병렬 구조입니다. 스크린 리더를 비롯한 보조기술은 화면의 시각적 모양 자체보다, 이 접근성 트리에 담긴 정보를 주로 사용합니다.
물론 CSS도 접근성에 영향을 줍니다. display: none, visibility: hidden, 포커스 스타일 제거, DOM 순서와 시각적 순서의 불일치 같은 것들은 모두 접근성을 망가뜨릴 수 있습니다. 다만 핵심은 이것입니다. 사용자가 화면을 어떻게 “보는가”와 보조기술이 화면을 어떻게 “이해하는가”는 다를 수 있습니다.
시맨틱 요소는 접근성 트리를 올바른 역할로 채웁니다. <nav>는 내비게이션, <button>은 버튼, <h1>은 제목으로 전달됩니다. 반대로 div와 span만 쌓아 올린 마크업은 시각적으로는 완벽해 보여도, 보조기술에게는 의미 있는 구조가 부족한 화면이 될 수 있습니다.
그러니 우리가 하는 일은 눈을 위한 스타일링만이 아닙니다. 동시에 보조기술을 위한 구조화된 표현을 만드는 일입니다. 그 표현의 재료가 시맨틱 태그입니다.
ARIA는 토대가 아니라 간극을 메우는 도구다
접근성을 처음 챙길 때 흔한 오해가 “ARIA를 많이 붙이면 접근성이 좋아진다”는 것입니다. 실제 원칙은 정반대에 가깝습니다.
WAI-ARIA Authoring Practices Guide와 MDN이 반복해서 강조하는 방향은 단순합니다. 네이티브 HTML로 의미와 동작을 표현할 수 있다면, ARIA로 흉내 내지 말라는 것입니다.
핵심은 이겁니다. ARIA는 동작을 추가하지 않습니다.
role="button"을 div에 붙여도 그 div가 엔터나 스페이스에 반응하게 되지는 않습니다. 포커스 가능한 요소가 되는 것도 아닙니다. 바뀌는 건 보조기술에 전달되는 역할 정보뿐입니다.
그래서 아무 동작도 하지 않으면서 “버튼”이라고 읽히는 div는 사용자에게 거짓말을 하는 요소가 됩니다. 잘못된 ARIA는 없는 것보다 나쁠 수 있습니다.
필요한 의미와 동작을 가진 네이티브 요소가 있다면 그걸 먼저 써야 합니다. ARIA는 네이티브만으로 표현하기 어려운 간극, 예를 들어 라이브 리전, 커스텀 위젯의 확장 상태, 선택 상태, 탭 패턴 같은 복잡한 상호작용을 보완하는 도구입니다. 기반을 대체하는 물건이 아닙니다.
문서의 뼈대: 랜드마크와 제목 위계
많은 스크린 리더 사용자는 화면을 단순히 위에서 아래로만 훑지 않습니다. 제목, 랜드마크, 링크, 폼 컨트롤 목록을 이용해 원하는 영역으로 건너뜁니다.
<header>, <nav>, <main>, <aside>, <footer> 같은 랜드마크 요소는 “본문으로 바로 가기”, “내비게이션으로 가기” 같은 이동을 가능하게 합니다.
<header>…</header>
<nav aria-label="주요 메뉴">…</nav>
<main>
<h1>페이지 제목</h1>
<section>
<h2>섹션 제목</h2>
<h3>하위 항목</h3>
</section>
</main>
<footer>…</footer>div class="header"만 가득한 페이지에는 명확한 랜드마크가 부족합니다. 사용자가 반복되는 메뉴를 건너뛰고 본문으로 이동하기 어려워질 수 있습니다.
제목도 마찬가지입니다. <h1>부터 <h6>은 보조기술에게 문서의 목차 역할을 합니다. 그러니 단순히 글자를 크게 만들려고 제목 태그를 쓰거나, h2 다음에 h4로 단계를 건너뛰면 문서 구조가 어색해집니다.
제목은 크기가 아니라 구조로 골라야 합니다.
반복 영역을 건너뛰는 skip to content 링크를 페이지 상단에 두는 것도 같은 맥락입니다. 화면을 마우스로 보는 사람에게는 작아 보이는 장치일 수 있지만, 키보드와 보조기술 사용자에게는 페이지를 훨씬 빠르게 탐색하게 해주는 중요한 출입구가 됩니다.
폼과 요소의 의미: 레이블·링크·버튼
폼에서 가장 자주 무너지는 것이 레이블입니다.
<label for>를 쓰거나 label로 입력을 감싸 텍스트와 입력을 연결해야 합니다. 그래야 레이블을 눌렀을 때 입력에 포커스가 가고, 스크린 리더가 그 입력의 이름을 안정적으로 읽어 줍니다.
placeholder는 레이블이 아닙니다.
입력을 시작하면 사라지고, 대비가 낮은 경우가 많고, 보조기술이 항상 안정적인 이름으로 다루기 어렵습니다.
<!-- placeholder만 있으면 입력의 이름이 불안정해집니다 -->
<input type="email" placeholder="이메일" /><!-- 레이블이 입력의 이름을 항상 붙들고 있습니다 -->
<label for="email">이메일</label>
<input id="email" type="email" />type을 제대로 준 네이티브 <input>, <select>, <textarea>는 키보드 조작과 모바일 키패드 경험까지 함께 가져옵니다. 관련된 입력 묶음은 <fieldset>과 <legend>로, 에러 메시지는 aria-describedby로 입력과 연결할 수 있습니다.
링크와 버튼의 혼동도 접근성 문제로 곧장 이어집니다.
<a href>는 이동입니다. URL이 바뀌고, 뒤로가기가 동작하고, 새 탭으로 열 수 있습니다.
<button>은 그 자리에서 동작을 합니다. 모달을 열고, 폼을 제출하고, 메뉴를 펼치고, 값을 변경합니다.
링크를 버튼처럼 쓰거나 버튼을 링크처럼 쓰면 사용자의 기대와 보조기술의 의미가 모두 어긋납니다.
기준은 간단합니다.
어딘가로 가면 링크, 무언가를 하면 버튼.
모든 컨트롤의 3요소: 이름·역할·상태
지금까지의 이야기는 하나의 원칙으로 수렴합니다.
화면 위의 모든 인터랙티브 요소는 세 가지를 노출해야 합니다.
이름(name) — 이게 무엇인지
역할(role) — 어떤 종류의 컨트롤인지
상태/값(state/value) — 체크됨, 펼쳐짐, 선택됨, 비활성, 현재 값 등
네이티브 요소는 이 셋의 상당 부분을 알아서 채웁니다. 커스텀 위젯을 만든다면 이 셋을 직접, 그리고 정확히 채워야 합니다.
가장 흔히 빠지는 것이 “이름”입니다. 아이콘만 있는 버튼이 대표적입니다.
<!-- 스크린 리더에는 그냥 "버튼"으로만 읽힐 수 있습니다 -->
<button>
<svg>…</svg>
</button><!-- 접근 가능한 이름을 줍니다 -->
<button aria-label="장바구니 열기">
<svg aria-hidden="true" focusable="false">…</svg>
</button>무언가 이상하게 읽힌다면, 대개 이름·역할·상태 셋 중 하나가 비어 있거나 실제 동작과 어긋난 것입니다.
그다음에야 화려한 인터랙션이 올라간다
커스텀 드롭다운, 모달, 탭, 아코디언 같은 화려한 인터랙션은 접근성과 대립하지 않습니다. 다만 순서가 있습니다.
접근 가능한 인터랙션은 보통 이런 순서로 만들어집니다.
- 올바른 시맨틱 조각을 먼저 둔다.
- 필요한 동작을 키보드와 포인터 입력 모두에서 동작하게 만든다.
- WAI-ARIA Authoring Practices Guide(APG)의 패턴을 참고해 역할과 상태를 보완한다.
- 포커스 이동과 복귀를 관리한다.
- 마지막으로 시각적 폴리싱을 더한다.
예를 들어 모달이 열리면 포커스가 모달 안으로 들어가야 합니다. 탭 이동은 모달 안에 갇혀야 하고, 모달을 닫으면 포커스가 원래 열었던 버튼으로 돌아와야 합니다. 이 흐름이 없으면 시각적으로는 모달이 떠 있어도, 키보드 사용자에게는 화면이 망가진 것처럼 느껴질 수 있습니다.
실패 모드는 언제나 순서가 뒤집힌 경우입니다.
div로 시각적 인터랙션부터 완성합니다. 배포합니다. 뒤늦게 ARIA를 덧붙입니다. 그제야 키보드, 포커스, 스크린 리더 흐름이 전부 깨져 있다는 걸 발견합니다.
올바른 순서는 반대입니다.
마크업 → 동작 → ARIA로 간극 메우기 → 시각 폴리싱.
더 나은 길도 있습니다. 이런 패턴들을 이미 검증된 형태로 담고 있는 접근성 프리미티브를 사용하는 것입니다. Radix Primitives, React Aria 같은 도구는 어렵고 틀리기 쉬운 키보드 상호작용, 상태 표현, 포커스 관리의 상당 부분을 안정적으로 다룰 수 있게 도와줍니다.
접근성을 직접 구현할 수 있어야 하지만, 모든 바퀴를 매번 처음부터 다시 만들 필요는 없습니다.
왜 지금 더 중요한가
이건 이제 “좋으면 하는 것”의 영역을 벗어나고 있습니다.
국제표준인 WCAG의 네 원칙은 인식 가능(Perceivable), 운용 가능(Operable), 이해 가능(Understandable), 그리고 견고함(Robust) 입니다. 이 마지막 견고함은 현재와 미래의 사용자 에이전트, 특히 보조기술과 안정적으로 호환되어야 한다는 요구와 맞닿아 있습니다.
다시 말해 시맨틱 마크업은 취향의 문제가 아닙니다. 보조기술이 이해할 수 있는 견고한 구조를 만드는 일이고, 접근성 표준이 요구하는 방향과도 연결됩니다.
2026년 현재 W3C 권고안 기준으로는 WCAG 2.2가 최신 안정 표준입니다. WCAG 3.0은 아직 초안 단계에 있으며, 일반적인 법적 기준으로 바로 적용되는 단계는 아닙니다.
규제 지형도 강화되는 흐름입니다. EU는 유럽 접근성법(European Accessibility Act)의 주요 접근성 요구사항이 2025년 6월 28일부터 적용되기 시작했습니다. 미국도 ADA Title II를 통해 주·지방정부의 웹 콘텐츠와 모바일 앱 접근성을 규정하고 있으며, 기술 기준으로 WCAG 기반 요구사항을 채택하고 있습니다.
한국에서도 장애인차별금지법 제21조와 관련 시행령을 통해 웹사이트 접근성 보장이 정당한 편의 제공의 한 축으로 다뤄져 왔습니다. 또한 2026년 1월 22일부터 시행된 디지털포용법은 지능정보서비스와 지능정보제품의 접근성 보장, 정보통신접근성 품질인증 제도 등을 통해 접근성의 제도적 무게를 더 키우고 있습니다.
다만 적용 대상과 의무 수준은 서비스 유형과 법령별로 달라집니다. 그래서 특정 민간 사업자 범위를 단정하기보다는, 공공과 민간 전반에서 접근성 요구가 확대되는 흐름으로 이해하는 편이 안전합니다.
요컨대 접근성은 이제 선택적 배려가 아니라, 제품이 더 많은 사용자와 더 많은 환경에서 안정적으로 동작하기 위한 기본 요건에 가까워지고 있습니다.
마치며
좋은 접근성의 상당 부분은 특별한 기술이 아니라, 처음부터 올바른 요소를 올바른 자리에 쓰는 규율에서 옵니다.
시맨틱 마크업이 서 있으면 포커스, 키보드, 역할, 이름의 상당 부분이 브라우저와 플랫폼을 통해 자연스럽게 따라옵니다. 그 위에 화려한 인터랙션이 안전하게 올라갈 수 있습니다.
반대로 div로 시작해 나중에 ARIA로 덧대는 길은 언제나 더 비싸고 더 취약합니다.
그러니 화면을 만들 때 순서를 뒤집지 마세요.
인터랙션의 화려함은 나중에 얼마든지 더할 수 있습니다. 하지만 그 아래에 시맨틱 마크업이라는 뼈대가 서 있지 않으면 접근성은 결국 무너집니다.
접근성은 마크업에서 시작합니다.
(다른 글)