웹 접근성은 이렇게 지킵니다 — 모두가 쓰는 사이트

접근성을 왜 처음부터 챙기나요, 나중에 붙이면 안 되나요?

붙일 수는 있지만, 거의 항상 더 비싸고 더 어설픕니다. 접근성은 색 몇 개 바꾸고 라벨 몇 개 더하는 표면 작업이 아니라 마크업 구조 자체에서 결정됩니다. 처음에 div만 쌓아 화면을 그려 두면, 나중에 키보드 동작과 스크린리더 안내를 얹기 위해 같은 화면을 다시 짜야 합니다. 그래서 우리 개발 파트는 화면 디자인을 코드로 옮기는 첫 단계에서, "이 요소를 마우스 없이 어떻게 쓰는가"를 같이 정합니다. 접근성을 뒤에 붙이는 게 아니라, 골격을 세울 때 함께 세웁니다.

이렇게 하면 추가 비용도 거의 들지 않습니다. 처음부터 button을 button으로, 메뉴를 nav로 쓰면 키보드·스크린리더 동작이 표준에서 따라오기 때문입니다. 우리가 프런트엔드를 짜는 전체 방식은 프런트엔드는 이렇게 만듭니다에서 정리했습니다.

가장 먼저 챙기는 건 무엇인가요?

시맨틱 HTML입니다. 화면의 각 부분에 의미에 맞는 태그를 씁니다. 머리말은 header, 주 메뉴는 nav, 본문은 main, 꼬리말은 footer, 누르면 동작하는 것은 button, 다른 곳으로 가는 것은 a로 만듭니다. 제목은 h1부터 순서대로 내려가며 단계를 건너뛰지 않습니다. 이렇게만 해도 스크린리더는 "여기는 메뉴, 여기는 본문, 이건 버튼"이라고 사용자에게 알려 줄 수 있고, 키보드 사용자는 표준 동작을 그대로 받습니다.

반대로 클릭 이벤트를 붙인 div는 화면엔 버튼처럼 보여도 키보드로 누를 수 없고 스크린리더에는 그냥 글자 덩어리입니다. 그래서 우리는 "보이는 것"과 "의미"가 일치하도록 태그를 고릅니다. 의미가 맞으면 동작의 절반은 브라우저가 알아서 해 줍니다.

마우스를 못 쓰는 사람은 어떻게 사이트를 쓰나요?

키보드로 씁니다. Tab으로 다음 요소로 이동하고, Enter나 Space로 누르고, Esc로 닫습니다. 그래서 우리는 만든 화면을 마우스를 치우고 Tab만으로 처음부터 끝까지 통과해 봅니다. 메뉴 열기, 폼 작성, 팝업 닫기까지 마우스 없이 모두 되어야 합격입니다.

이때 두 가지를 꼭 지킵니다. 첫째, 포커스 표시를 지우지 않습니다. 지금 키보드 초점이 어디 있는지 보이는 테두리는 키보드 사용자의 마우스 커서와 같습니다. 디자인상 거슬린다는 이유로 outline을 없애 버리면 사용자는 자기가 어디 있는지 모른 채 헤맵니다. 우리는 없애는 대신 브랜드에 맞는 또렷한 포커스 스타일로 다시 그립니다. 둘째, 본문을 건너뛰는 길을 둡니다 — 페이지 맨 위의 '본문 바로가기' 링크가 그것으로, 반복되는 메뉴를 매번 Tab으로 지나치지 않아도 되게 합니다.

색과 글자는 어떻게 다루나요?

먼저 색 대비를 맞춥니다. 글자색과 배경색의 명암 차이가 충분하지 않으면, 저시력 사용자뿐 아니라 밝은 야외에서 화면을 보는 사람도 글을 못 읽습니다. 우리는 본문 글자에 4.5:1 이상, 큰 제목에 3:1 이상의 대비를 기준으로 두고 도구로 측정합니다. 연한 회색 위의 더 연한 회색 같은 '예뻐 보이지만 안 읽히는' 조합은 거릅니다.

그리고 색에만 의미를 싣지 않습니다. 빨간 글자만으로 "오류"라고 표시하면 색을 구분하기 어려운 사용자는 그 의미를 놓칩니다. 그래서 색에는 항상 아이콘이나 글자를 같이 붙입니다. 사용자가 글자 크기를 키워도 레이아웃이 깨지지 않도록 상대 단위로 짜는 것도 같은 맥락입니다.

이미지와 화면 안내(스크린리더)는 어떻게 처리하나요?

스크린리더는 화면을 소리로 읽어 주는 도구입니다. 그래서 의미를 전하는 이미지에는 대체텍스트(alt)를 답니다. 무엇을 보여 주는 그림인지 한 줄로 적어, 화면을 못 보는 사용자도 같은 정보를 받게 합니다. 반대로 순수하게 장식용인 이미지는 alt를 빈 값으로 두어 스크린리더가 건너뛰게 합니다 — 의미 없는 파일명을 줄줄이 읽어 주는 것이 더 방해되기 때문입니다.

아이콘만 있는 버튼(예: 햄버거 메뉴, 닫기 X)에는 화면에 글자가 없어도 스크린리더가 읽을 이름을 줍니다. 또 검색 결과 개수처럼 동적으로 바뀌는 안내는 사용자가 들을 수 있게 처리합니다. 핵심은 "눈으로 보이는 정보는 소리로도 전달된다"입니다.

ARIA는 많이 붙일수록 좋은 거 아닌가요?

흔한 오해인데, 정반대입니다. ARIA의 첫 번째 규칙은 "쓸 수 있는 시맨틱 HTML이 있으면 ARIA를 쓰지 말 것"입니다. button·nav·label 같은 표준 요소는 키보드 동작과 스크린리더 안내를 이미 내장하고 있습니다. 같은 일을 div에 role과 aria-*로 흉내 내려면 그 모든 동작을 직접 다시 만들어야 하고, 한 곳이라도 어긋나면 화면엔 멀쩡해 보여도 스크린리더에는 깨진 안내가 전달됩니다. 잘못 붙인 ARIA는 없느니만 못합니다.

그래서 우리는 표준 요소를 기본값으로 쓰고, 표준으로 도저히 표현할 수 없는 위젯(복잡한 탭, 커스텀 콤보박스 등)에만 ARIA를 최소한으로 보탭니다. 보탤 때도 키보드 동작을 함께 구현하고 실제 스크린리더로 확인합니다. ARIA는 양이 아니라 정확도의 문제입니다.

폼은 왜 따로 신경 쓰나요?

폼은 사용자가 실제로 행동하는 지점 — 문의, 신청, 결제가 모두 폼에서 일어나기 때문입니다. 여기서 접근성이 무너지면 매출이 직접 샙니다. 우리는 모든 입력칸에 연결된 라벨을 붙입니다. 칸 안에 흐릿하게 떠 있는 안내문(placeholder)은 입력을 시작하면 사라져 라벨을 대신할 수 없습니다. 라벨은 칸 밖에 따로 두고, 클릭하면 해당 칸으로 초점이 가도록 묶습니다.

오류가 났을 때는 어느 칸이 왜 틀렸는지를 글자로, 그리고 스크린리더가 읽을 수 있는 방식으로 알려 줍니다. "다시 확인하세요"가 아니라 "이메일에 @가 빠졌습니다"처럼 구체적으로요. 접근성 있는 폼은 결국 모든 사용자에게 더 쉬운 폼입니다. 이 폼이 빠르게 뜨고 매끄럽게 도는 것까지가 사용자 경험이라, 웹 성능은 이렇게 끌어올립니다와도 직접 이어집니다.

말로 풀어 쓴 이 원칙들은 코드에서 보면 더 분명합니다. 우리가 입력칸 하나를 마크업할 때 기본으로 잡는 골격은 이렇습니다.

<!-- 라벨은 칸 밖에, for/id 로 묶는다 (placeholder는 라벨이 아니다) -->
<label for="email">이메일</label>
<input id="email" name="email" type="email"
       autocomplete="email" required
       aria-describedby="email-err">

<!-- 오류는 색이 아니라 글자로, 스크린리더가 읽도록 live 영역에 -->
<p id="email-err" role="alert" hidden>
  이메일에 @가 빠졌습니다.
</p>

<!-- 아이콘만 있는 버튼엔 보이지 않는 이름을 준다 -->
<button type="button" aria-label="메뉴 열기">
  <svg aria-hidden="true">…</svg>
</button>

그리고 화면을 넘기기 전, 마우스를 치우고 Tab만으로 한 바퀴 돌면서 초점이 어디 있는지 눈으로 확인합니다.

$ 키보드 점검: Tab 순서 = 본문 바로가기 → 로고 → 메뉴 → 문의 폼 → 보내기
$ ✓ 모든 입력칸에 연결된 <label> 존재 · placeholder만 쓴 칸 0개
$ ✓ 본문 대비 4.5:1 이상 · 아이콘 버튼 aria-label 누락 0

움직임과 애니메이션은 어떻게 다루나요?

움직임은 분위기를 살리지만, 어떤 사용자에게는 어지럼증이나 멀미를 유발합니다. 그래서 우리는 사용자의 운영체제 설정을 존중합니다. 기기에서 '동작 줄이기(reduced motion)'를 켜 둔 사용자에게는 화면이 휙휙 날아오거나 시차로 흐르는 효과를 자동으로 줄이거나 끕니다. 같은 사이트가, 움직임을 즐기는 사람에겐 생동감 있게, 그렇지 않은 사람에겐 차분하게 동작하는 셈입니다.

또 깜빡임이 빠른 효과는 피하고, 자동으로 움직이는 슬라이드에는 멈춤 수단을 둡니다. 인터랙션이 '있는 것' 자체가 목적이 아니라, 모든 사람이 불편 없이 쓰는 게 먼저입니다.

접근성을 지키면 우리(회사)에게도 이득이 있나요?

분명히 있습니다. 세 방향입니다. 첫째 SEO·AI — 의미에 맞는 제목 구조, 이미지 대체텍스트, 명확한 링크 텍스트는 스크린리더에 좋은 동시에 검색엔진과 AI 크롤러에도 똑같이 읽기 좋은 구조입니다. 접근성을 위해 정리한 HTML이 그대로 검색·AI 인용의 토대가 됩니다. 둘째 신뢰 — 키보드로도, 큰 글자로도, 느린 환경에서도 끝까지 되는 사이트는 "꼼꼼한 회사"라는 인상을 줍니다. 셋째 법적 측면 — 장애인차별금지법과 한국형 웹 접근성 지침(KWCAG)이 일정 범위의 사업자에게 적용되며, 처음부터 기준을 맞춰 두면 분쟁·민원 위험을 줄입니다.

정리하면 접근성은 비용이 아니라, 더 많은 사용자와 더 좋은 검색 노출과 더 낮은 위험을 한 번에 가져가는 작업입니다. 우리가 일하는 전체 방식은 우리는 이렇게 합니다에서, 제작과 함께 이를 어떻게 녹이는지는 홈페이지 제작에서 확인할 수 있습니다. 지금 사이트의 접근성이 궁금하다면 무료 진단으로 시작하세요.