← 전체 카테고리
11

접근성 (a11y)

소수를 위한 배려가 아니라 품질의 문제입니다. 밝은 야외에서, 한 손에 짐을 든 채로도 쓸 수 있는가. 그리고 공공기관 프로젝트는 법적 의무입니다.

10개 용어10개 라이브 데모
마우스를 치우고 써보세요

가장 빠른 검수 방법입니다. Tab으로 이동 · Enter로 실행 · Esc로 닫기. 이것만으로 끝까지 갈 수 있으면 대부분 통과합니다.

01

접근성 · a11y

Accessibility

이런 상황에서 나옵니다

"접근성도 챙겨주세요" — 공공 프로젝트면 법적 의무입니다.

장애·나이·기기·환경과 관계없이 누구나 쓸 수 있게 만드는 것입니다. a11y는 accessibility의 a와 y 사이 글자가 11개라서 붙은 축약 표기입니다.

눈으로 보기 직접 눌러보세요
· 눈이 안 보이는 사람 → 스크린리더로 듣습니다
· 손이 불편한 사람 → 키보드만으로 조작합니다
· 색약인 사람 → 빨강/초록 구분이 어렵습니다
· 밝은 야외의 모든 사람 → 대비가 낮으면 안 보입니다
헷갈리는 지점

접근성은 소수를 위한 배려가 아니라 모두를 위한 품질입니다. 밝은 햇빛 아래, 한 손에 짐을 든 상태, 시끄러운 지하철에서도 쓸 수 있는가 — 이게 다 접근성입니다. 그리고 공공기관·공기업 프로젝트는 법적 의무라 지키지 않으면 납품이 반려됩니다.

실무에서 쓸 때

접근성은 나중에 붙이는 게 가장 비쌉니다. 구조를 다 만든 뒤 고치려면 거의 새로 만드는 수준이 됩니다. 처음부터 반영하세요.

이렇게 요청하세요

접근성을 처음부터 반영해주세요 — 시맨틱 마크업, 키보드 조작, 명도 대비 4.5:1, 이미지 대체 텍스트. 나중에 붙이면 구조를 다시 짜야 해서 훨씬 비쌉니다.

02

WCAG · KWCAG

Web Content Accessibility Guidelines

이런 상황에서 나옵니다

공공기관 입찰에서 "웹 접근성 인증마크"가 요구될 때.

국제 웹 접근성 지침입니다. A · AA · AAA 세 등급이 있고, 보통 AA를 목표로 합니다.

눈으로 보기 직접 눌러보세요
A최소 수준
AA실무 표준 · 대부분 여기
AAA최고 수준 · 전체 적용은 비현실적
헷갈리는 지점

한국에는 이를 기반으로 한 KWCAG(한국형 웹 콘텐츠 접근성 지침)가 있고, 공공기관은 웹 접근성 인증마크를 요구합니다. 이런 프로젝트를 수주했다면 초반부터 반영해야 합니다 — 나중에 고치려면 거의 새로 만드는 수준이 됩니다.

이렇게 요청하세요

WCAG 2.1 AA 등급을 목표로 진행하겠습니다. 공공기관 납품이면 KWCAG 기준과 웹 접근성 인증마크 심사까지 일정에 포함해야 하니, 필요 여부를 알려주세요.

03

스크린 리더

Screen Reader

이런 상황에서 나옵니다

"시각장애인도 쓸 수 있게 해주세요"

화면의 내용을 음성으로 읽어주는 보조 기술입니다. 시각장애인이 웹을 쓰는 주요 수단입니다.

눈으로 보기 직접 눌러보세요
화면에 보이는 것
🔍

스크린리더가 읽는 것
✗ 이름 없이 "버튼"
✓ "검색, 버튼"
헷갈리는 지점

스크린리더는 화면을 "보지" 않고 코드 순서대로 읽습니다. 그래서 시각적으로 예쁘게 배치해도 코드 순서가 뒤죽박죽이면 뜻이 통하지 않습니다. 아이폰의 VoiceOver, 안드로이드의 TalkBack으로 직접 켜서 자기 사이트를 들어보면 문제가 바로 드러납니다.

이렇게 요청하세요

스크린리더로 읽었을 때 순서가 자연스러운지 확인해주세요. CSS로만 위치를 옮긴 요소는 코드 순서가 시각 순서와 달라 뜻이 통하지 않을 수 있습니다.

04

대체 텍스트

Alt Text

이런 상황에서 나옵니다

"이미지에 alt 넣어주세요" — 그런데 모든 이미지에 넣으면 안 됩니다.

이미지를 글로 설명한 텍스트입니다. 이미지가 안 보이거나 스크린리더를 쓸 때 대신 전달됩니다.

눈으로 보기 직접 눌러보세요

alt="이미지1.jpg" / alt="사진"

✓ 정보 이미지

alt="7월 매출이 전월 대비 12% 증가한 막대그래프"

✓ 장식 이미지

alt="" (비워두면 건너뜀)

헷갈리는 지점

모든 이미지에 넣는 게 아닙니다. 장식용 이미지는 오히려 비워둬야 스크린리더가 건너뜁니다. 정보를 담은 이미지에만 넣고, "이미지"·"사진" 같은 말은 빼고 내용만 씁니다. 검색 노출(SEO)에도 도움이 됩니다.

이렇게 요청하세요

정보를 담은 이미지에만 대체 텍스트를 넣고, 장식용 이미지는 alt=""로 비워서 스크린리더가 건너뛰게 해주세요. 텍스트에 "이미지", "사진" 같은 말은 넣지 말아주세요.

05

시맨틱 마크업

Semantic Markup

이런 상황에서 나옵니다

퍼블리싱 검수에서 가장 먼저 확인해야 할 항목.

의미에 맞는 태그를 쓰는 것입니다. 제목은 제목 태그로, 버튼은 버튼 태그로 만드는 것입니다.

눈으로 보기 직접 눌러보세요
✗ div로 만든 버튼

보이기는 같음 · Tab으로 이동 불가 · Enter로 실행 불가 · 스크린리더가 "버튼"이라 못 읽음

✓ button 태그

키보드 조작·포커스·스크린리더 인식이 전부 자동으로 됨

헷갈리는 지점

모든 걸 div로 만들면 겉보기엔 똑같지만 접근성이 완전히 무너집니다. div로 만든 버튼은 키보드로 누를 수 없고 스크린리더도 버튼으로 인식하지 못합니다. 퍼블리싱 검수에서 확인해야 할 핵심 항목입니다.

이렇게 요청하세요

버튼은 div가 아니라 button 태그로, 제목은 h1~h6으로 만들어주세요. div로 만들면 키보드 조작과 스크린리더 인식이 안 됩니다.

06

ARIA

Accessible Rich Internet Applications

이런 상황에서 나옵니다

"aria 속성 넣어주세요" — 다만 안 쓰는 게 최선인 경우가 많습니다.

보조 기술에 역할·상태·속성을 알려주는 추가 표시입니다. aria-label, aria-expanded 같은 것들입니다.

눈으로 보기 직접 눌러보세요
aria-label — 화면엔 없지만 읽히는 이름
aria-expanded — 펼침/접힘 상태
aria-selected — 선택 여부
role — 이 요소의 역할

이 사이트의 카테고리 버튼과 탭에도 실제로 들어가 있습니다.

헷갈리는 지점

ARIA의 첫 번째 규칙은 "ARIA를 쓰지 않는 것"입니다. 올바른 HTML 태그로 해결되면 그게 낫고, 어쩔 수 없을 때만 ARIA를 씁니다. 잘못 쓴 ARIA는 아예 안 쓴 것보다 나쁩니다.

이렇게 요청하세요

기본 HTML 태그로 해결되는 건 ARIA 없이 만들어주세요. 아이콘 버튼처럼 이름이 없는 경우에만 aria-label을 쓰고, 아코디언은 aria-expanded로 펼침 상태를 알려주세요.

07

포커스 링

Focus Ring · 포커스 인디케이터

이런 상황에서 나옵니다

"이 파란 테두리 지워주세요" — 접근성을 없애달라는 요청과 같습니다.

키보드로 이동했을 때 지금 어디에 있는지 보여주는 테두리입니다.

눈으로 보기 직접 눌러보세요

테두리가 보여야 정상입니다. 이게 없으면 키보드 사용자는 자기 위치를 알 수 없습니다.

헷갈리는 지점

"이 파란 테두리 지워주세요"는 접근성을 없애달라는 요청과 같습니다. 지우지 말고 브랜드에 맞는 스타일로 다시 그려주세요. 마우스로 클릭할 때만 안 보이게 하는 방법(:focus-visible)도 있습니다 — 개발자에게 이 단어를 말하면 통합니다.

이렇게 요청하세요

포커스 링을 제거하는 대신 :focus-visible을 써주세요. 마우스 클릭 시에는 안 보이고 키보드 Tab 이동 시에만 보입니다. 스타일은 브랜드 색으로 바꿔도 됩니다.

08

탭 오더

Tab Order

이런 상황에서 나옵니다

Tab 키를 눌렀는데 엉뚱한 곳으로 튈 때.

Tab 키를 눌렀을 때 포커스가 이동하는 순서입니다.

눈으로 보기 직접 눌러보세요

Tab을 눌러 1 → 2 → 3 순서로 이동하는지 확인해보세요.

헷갈리는 지점

시각적 순서와 코드 순서가 어긋나면 탭 순서가 엉뚱해집니다. 디자인에서 요소를 옮겼는데 개발에서 위치만 CSS로 이동시킨 경우 자주 발생합니다. Tab 키를 처음부터 끝까지 눌러보는 것만으로 검수가 됩니다.

이렇게 요청하세요

Tab 순서가 화면에 보이는 순서와 일치하게 해주세요. CSS로 위치만 옮긴 요소가 있으면 코드 순서도 함께 맞춰주세요. tabindex에 양수를 쓰지 말아주세요.

09

키보드 내비게이션

Keyboard Navigation

이런 상황에서 나옵니다

접근성 검수를 가장 빠르게 하는 방법. 마우스를 치우세요.

마우스 없이 키보드만으로 모든 기능을 쓸 수 있게 만드는 것입니다.

눈으로 보기 직접 눌러보세요
Tab / Shift+Tab다음 / 이전
Enter / Space실행
Esc닫기 — 가장 자주 누락됨
화살표목록·탭 안에서 이동
헷갈리는 지점

검수 방법이 아주 간단합니다 — 마우스를 치우고 써보세요. Tab(이동) · Enter/Space(실행) · Esc(닫기) · 화살표(선택)만으로 끝까지 갈 수 있어야 합니다. 특히 모달을 Esc로 닫을 수 있는지는 가장 자주 빠지는 항목입니다.

이렇게 요청하세요

키보드만으로 전체 기능을 쓸 수 있게 해주세요. 특히 모달·드로어·드롭다운을 Esc로 닫을 수 있어야 하고, 닫은 뒤 포커스가 원래 열었던 버튼으로 돌아와야 합니다.

10

색만으로 구분하지 않기

Not Color Alone

이런 상황에서 나옵니다

"재고 있음은 초록, 품절은 빨강으로 해주세요" — 그것만으로는 부족합니다.

정보를 색깔 하나에만 의존해서 전달하지 않는 원칙입니다.

눈으로 보기 직접 눌러보세요
✗ 색만 사용
● 재고 있음   ● 품절
✓ 색 + 아이콘 + 글자
✓ 재고 있음   ✕ 품절
헷갈리는 지점

한국 남성의 약 5~6%가 색각 이상입니다. 빨강/초록으로만 성공·실패를 표시하면 이들에게는 똑같은 회색으로 보입니다. 아이콘·글자·모양을 함께 써야 합니다. 그래프의 선 색만 다르게 하는 것도 같은 문제입니다.

이렇게 요청하세요

상태를 색으로만 구분하지 말고 아이콘과 글자를 함께 넣어주세요 — "✓ 재고 있음" / "✕ 품절"처럼요. 색각 이상인 사용자는 빨강·초록을 구분하기 어렵습니다.