접근성은 특별한 기능이 아니에요
스크린 리더 사용자만의 문제가 아닙니다. 모두를 위한 기본기, 그 시작점을 정리합니다.
"접근성"이라는 단어를 들으면 어떤 이미지가 떠오르나요. 스크린 리더, 시각 장애, 법적 의무 같은 키워드가 먼저 떠오르고, 자연스럽게 "나중에 시간 나면"이라는 결론에 닿곤 합니다. 저도 그랬어요.
그런데 어느 날 손목을 다쳐서 마우스를 못 잡게 됐습니다. 키보드만으로 내가 만든 페이지를 써보니, Tab 키를 눌러도 포커스가 어디 있는지 안 보이고, <div>로 만든 버튼은 Enter를 아무리 눌러도 반응이 없었어요. 접근성은 '누군가를 위한 것'이 아니라 '지금 내가 필요한 것'이었습니다.
생각보다 넓은 사용자
장애는 영구적인 것만이 아닙니다. W3C WAI는 접근성이 필요한 상황을 세 가지로 나눠요.
영구적 장애 는 시각, 청각, 이동성, 인지 등 지속되는 상태입니다. 일시적 장애 는 팔 골절, 안과 수술 후 회복기처럼 한동안 특정 기능이 제한되는 경우고요.
그리고 상황적 장애 가 있어요. 햇빛 아래에서 화면이 안 보이거나, 시끄러운 카페에서 영상 자막이 필요하거나, 한 손에 아기를 안고 있어서 터치만 가능한 순간들이요.
이 세 가지를 합치면 사용자 범위가 생각보다 훨씬 넓어집니다. 접근성은 특수한 소수를 위한 배려가 아니라, 누구나 언제든 해당될 수 있는 기본 품질이에요.
Perceivable(인지) - 정보와 UI를 사용자가 인식할 수 있어야 합니다.
Operable(조작) - 인터페이스를 조작하고 탐색할 수 있어야 합니다.
Understandable(이해) - 정보와 UI의 동작을 이해할 수 있어야 합니다.
Robust(견고) - 다양한 보조 기술이 해석할 수 있을 만큼 견고해야 합니다.
출발점은 시맨틱 HTML
접근성을 개선하는 가장 빠른 방법은 뭘까요. ARIA를 외우는 것도 아니고, 스크린 리더를 설치하는 것도 아닙니다. 그냥 HTML 태그를 의미에 맞게 쓰는 것 이에요.
대표적인 안티패턴이 <div onclick>입니다. 겉으로는 클릭이 되니까 잘 만든 것 같지만, 브라우저가 공짜로 제공하는 것들을 전부 날려버려요.
위 예제에서 Tab 키를 눌러보세요. <div> 버튼은 포커스조차 잡히지 않지만, <button>은 자연스럽게 포커스가 이동해요. 키보드 동작, 포커스 링, 보조 기술 호환 - 이 모든 게 태그 하나를 바꾸는 것만으로 따라와요.
같은 논리가 폼에도 적용돼요. <label>과 <input>을 for/id로 연결하면 라벨 클릭 시 입력 필드에 포커스가 잡히고, 스크린 리더가 "이름 입력란"처럼 맥락을 안내해요. 이미지에는 alt 텍스트를, 페이지 구획에는 <nav>, <main>, <footer> 같은 랜드마크 태그를 쓰는 것도 마찬가지고요. 특별한 기술이 아니라 HTML이 원래 의도한 사용법이에요.
두 번째 축, 키보드와 포커스
마우스 없이 키보드만으로 페이지를 탐색할 수 있는지 - 이건 접근성의 두 번째 기둥이에요. Tab 이동, Enter 실행, Esc로 닫기까지 흐름이 끊기지 않아야 합니다.
가장 흔한 실수는 포커스 스타일을 없애버리는 거예요. outline: none을 전역에 깔아놓으면 시각적으로 깔끔해 보이지만, 키보드 사용자는 지금 어디에 있는지 알 수가 없습니다.
:focus-visible은 키보드로 포커스했을 때만 스타일을 보여주고, 마우스 클릭 시에는 숨겨줍니다. 디자이너와 접근성, 양쪽 모두 만족하는 방법이에요.
커스텀 모달이나 드롭다운을 만들 때는 포커스 트랩 도 신경 써야 합니다. 모달이 열린 상태에서 Tab이 모달 바깥으로 빠져나가면, 사용자가 뒤에 가려진 콘텐츠와 상호작용하게 되거든요.
색, 대비, 동적 콘텐츠
정보를 색으로만 구분하는 건 위험해요. "빨간 항목이 에러입니다"라고 안내하면, 색각 이상인 사용자는 어떤 항목인지 알 수 없어요. 색 옆에 아이콘이나 텍스트 레이블을 함께 두는 게 안전합니다.
텍스트와 배경의 명도 대비는 WCAG 기준으로 일반 텍스트 4.5:1, 큰 텍스트 3:1 이상이어야 해요. 밝은 회색 배경에 연한 회색 텍스트 - 디자인적으로 세련돼 보여도, 밝은 환경이나 저시력 사용자에게는 읽히지 않는 글이 되거든요.
동적으로 바뀌는 콘텐츠도 짚어야 해요. 비동기 요청 후 "저장 완료!" 같은 토스트가 뜨는데, 이걸 스크린 리더가 인지하려면 aria-live="polite" 영역 안에서 텍스트가 갱신돼야 해요. 이 한 줄이 없으면 시각적으로만 알림이 뜨고 보조 기술에는 아무 일도 일어나지 않아요.
CSS를 다룰 때도 접근성은 빠지지 않아요. 텍스트가 잘리거나 줄바꿈이 깨지는 문제도 결국 "읽을 수 있는가"라는 질문이고, 이건 시각 디자인과 접근성이 만나는 지점이에요.
무리 없이 시작하는 법
접근성 전체를 한 번에 적용하려고 하면 압도당합니다. 기존 페이지 하나를 골라서, 이 세 단계만 밟아보세요.
Tab 한 번 눌러보기
지금 만들고 있는 페이지에서 마우스를 놓고 Tab만으로 탐색합니다. 포커스가 보이지 않거나, 클릭 가능한 요소에 도달하지 못하면 그게 첫 번째 수정 대상이에요.
Lighthouse 접근성 점수 확인
Chrome DevTools의 Lighthouse 탭에서 Accessibility 카테고리만 돌려보세요. 점수보다 중요한 건 아래에 뜨는 구체적인 항목들입니다. alt 누락, 대비 부족, label 미연결 같은 것들이 하나씩 나와요.
axe DevTools로 한 단계 더
브라우저 확장 프로그램 axe DevTools를 설치하면 Lighthouse보다 세밀한 접근성 검사를 할 수 있습니다. 어떤 요소가 어떤 기준을 위반하는지 코드 레벨로 짚어줘요.
이 세 단계를 반복하다 보면, 새 컴포넌트를 만들 때 자연스럽게 시맨틱 태그부터 고르게 됩니다. 습관이 되면 추가 비용이 거의 없어요.
아는 것과 쓰는 것 사이
접근성의 핵심 원칙 대부분은 어렵지 않습니다. <div> 대신 <button>을 쓰고, outline을 지우지 않는 것. 거기에 색만으로 정보를 전달하지 않는 습관까지 더하면, 알고 보면 HTML이 원래 의도한 사용법을 따르는 것뿐이에요.
문제는 "안다"와 "쓴다" 사이의 거리예요. 바쁜 일정 속에서 빠르게 <div onClick>을 치는 게 당장은 편하죠. 하지만 그 작은 선택이 쌓이면, 어느 순간 키보드로 탐색할 수 없고 스크린 리더가 읽을 수 없는 페이지가 됩니다.
오늘 딱 하나만 해보세요. 지금 작업 중인 컴포넌트에서 <div> + onClick 조합을 찾아 <button>으로 바꿔보는 거예요. 그 한 줄이 생각보다 많은 걸 바꿔줍니다.