웹 접근성(Web Accessibility)의 진정한 정의
웹의 진정한 힘은 누구나 제한 없이 접근할 수 있는 보편성에 있습니다. 웹 접근성은 시각, 청각, 운동 장애인 등 다양한 신체적 조건의 이용자들이 보조기기(스크린 리더 등)를 통해 웹 페이지의 모든 정보에 동등하게 액세스할 수 있도록 개발 단계에서 설계 규범을 지키는 것입니다.
1. 대체 텍스트와 시각 정보화
가장 기본적이면서 중요한 부분은 이미지를 화면에 띄울 때 반드시 유의미한 설명이 적힌 alt 속성을 명시하는 것입니다. 스크린 리더는 시각장애인 사용자에게 이미지 파일 대신 이 대체 텍스트를 소리 내어 읽어줍니다.
2. 키보드 접근성과 포커스 표시
마우스 조작이 불가능한 사용자를 위해 탭(Tab) 키 조작만으로 사이트의 모든 메뉴와 링크에 순차적으로 접근 가능하도록 마크업 순서를 신경 써야 합니다. 또한 포커스가 위치한 지점이 화면에 뚜렷이 표시되도록 outline 스타일을 무턱대고 끄는(none) 디자인 코드를 지양해야 합니다.
3. 시맨틱 HTML(Semantic HTML) 활용
단순히 화면 분할을 위해 <div> 태그만으로 남발하는 구조는 접근성에 치명적입니다. 대신 <header>, <nav>, <main>, <footer> 등의 의미론적 태그를 사용하여 브라우저와 보조 엔진이 문서 구조를 명확히 이해하도록 보조해야 합니다.
접근성을 품질 기준으로 다루기
접근성은 배려 차원의 부가 기능이 아니라, 브라우저와 보조기기, 키보드 사용자 모두가 문서를 이해하게 만드는 기본 품질입니다. 사용자가 쉽게 탐색하고 읽을 수 있는 구조는 콘텐츠 사이트의 중요한 신뢰 신호가 됩니다.
접근성이 문서 구조와 사용성에도 중요한 이유
브라우저와 보조 기술은 사람처럼 화면을 추측하는 것이 아니라 HTML 구조, 제목 계층, 링크 텍스트, 이미지 대체 텍스트 같은 신호를 통해 문서를 이해합니다. 접근성이 좋은 페이지는 보조기기 사용자뿐 아니라 문서를 해석하는 도구에도 명확한 구조를 제공합니다. 반대로 버튼이 전부 아이콘만 있고 라벨이 없거나, 제목 순서가 뒤섞여 있거나, 이미지 설명이 비어 있으면 페이지의 의미가 약해집니다.
접근성은 외부 요소가 있는 콘텐츠 사이트의 사용자 경험과도 연결됩니다. 외부 위젯이 본문을 밀어내거나, 포커스 이동을 방해하거나, 모바일에서 버튼을 누르기 어렵게 만들면 사용자는 사이트 품질이 낮다고 느낄 수 있습니다.
바로 점검할 수 있는 항목
- 모든 버튼에 시각적 텍스트 또는
aria-label이 있는지 확인합니다. - 키보드 Tab 이동 시 현재 포커스 위치가 명확하게 보이도록 합니다.
- 본문 제목은
h1부터 순서대로 내려가며 문서 구조를 설명해야 합니다. - 링크 텍스트는 “바로가기”만 반복하지 말고 이동할 목적지를 설명해야 합니다.
- 색상만으로 상태를 구분하지 말고 텍스트, 아이콘, 테두리 등 다른 단서도 함께 제공합니다.
실무 점검표
| 영역 | 점검 방법 | 권장 기준 |
|---|---|---|
| 제목 구조 | 페이지마다 h1이 하나 있고 h2, h3가 순서대로 내려가는지 확인 | 건너뛰는 제목 단계 최소화 |
| 이미지 | 정보 전달 이미지에 의미 있는 alt가 있는지 확인 | 장식 이미지는 빈 alt, 콘텐츠 이미지는 설명 제공 |
| 키보드 | 마우스 없이 Tab, Enter, Escape로 주요 기능을 사용할 수 있는지 확인 | 메뉴, 모달, 폼 제출 가능 |
| 색 대비 | 본문, 버튼, 링크의 대비를 검사 | 작은 텍스트는 충분한 대비 확보 |
| 폼 | label과 input이 연결되어 있는지 확인 | 오류 메시지는 입력 필드와 가까이 표시 |
자주 발생하는 문제와 수정 예시
가장 흔한 문제는 클릭 가능한 요소가 의미 없는 div로 만들어지는 경우입니다. 화면에서는 버튼처럼 보여도 스크린 리더와 키보드 사용자에게는 버튼으로 인식되지 않을 수 있습니다. 이때는 실제 button 요소를 사용하고, 아이콘만 있다면 aria-label을 추가해야 합니다.
<button aria-label="메뉴 열기">
<MenuIcon />
</button>또 다른 문제는 카드 전체를 클릭 가능하게 만들면서 제목 링크와 겹치는 경우입니다. 이때는 제목을 명확한 링크로 두고, 카드 안의 다른 상호작용 요소와 충돌하지 않게 해야 합니다. 접근성은 별도의 장식 작업이 아니라 HTML을 본래 목적에 맞게 쓰는 일에서 시작됩니다.
콘텐츠 사이트에서 특히 중요한 접근성
블로그와 자료실형 사이트는 사용자가 글을 읽고 링크를 따라가며 정보를 탐색하는 구조입니다. 따라서 글 제목, 목차, 관련 글, 푸터 링크가 명확해야 합니다. “클릭”, “더보기” 같은 모호한 링크가 반복되면 보조기기 사용자는 링크 목록만 들었을 때 어디로 이동하는지 알기 어렵습니다.
또한 본문 안에 표를 넣을 때는 헤더 셀을 명확히 두고, 모바일에서 표 전체가 화면을 밀어내지 않도록 별도의 스크롤 영역을 제공해야 합니다. 접근성은 심미적인 완성도와 별개로, 사용자가 정보를 끝까지 읽을 수 있게 만드는 기본 조건입니다.
동적 영역을 배치할 때의 접근성 기준
외부 위젯이 들어가는 콘텐츠 사이트에서는 동적 영역도 접근성 기준에서 예외가 아닙니다. 외부 위젯이 본문 중간에 들어가더라도 문단을 갑자기 밀어내지 않아야 하고, 닫기 버튼이나 상호작용 요소가 있다면 키보드로 접근할 수 있어야 합니다. 외부 안내와 본문이 시각적으로 구분되지 않으면 사용자는 정보성 콘텐츠와 외부 안내를 혼동할 수 있습니다.
따라서 동적 영역에는 충분한 여백과 구분선을 두고, 본문 제목 바로 아래나 링크 목록 사이처럼 오해가 생기기 쉬운 위치는 피하는 것이 좋습니다. 접근성은 사용자 보호이면서 동시에 사이트 신뢰도를 지키는 장치입니다.
접근성 개선은 디자인을 포기하는 일이 아닙니다. 오히려 의미 있는 HTML과 명확한 상호작용 상태는 유지보수하기 쉬운 UI의 기반이 됩니다.
Frontend Note 실무 노트
접근성은 별도 기능이 아니라 HTML을 의미에 맞게 쓰는 일에서 시작합니다. 버튼은 버튼으로, 링크는 링크로, 제목은 문서 구조를 설명하는 순서로 사용해야 합니다. 시각적으로는 비슷해 보여도 스크린 리더와 키보드 사용자에게는 완전히 다른 경험이 됩니다.
콘텐츠 사이트에서는 링크 텍스트가 특히 중요합니다. “바로가기”, “더보기”만 반복하면 링크 목록을 듣는 사용자는 목적지를 알 수 없습니다. “React 공식 문서 보기”, “PageSpeed Insights 열기”처럼 목적지를 담아야 합니다. 표를 넣을 때는 헤더 셀을 명확히 두고 모바일에서는 표 영역만 가로 스크롤되도록 제한합니다.
<button aria-label="메뉴 열기">
<MenuIcon />
</button>
<a href="/resources">프론트엔드 자료실 보기</a>외부 위젯이 들어가는 사이트라면 접근성은 더 중요합니다. 외부 안내와 본문이 시각적으로 구분되지 않으면 사용자는 정보와 외부 안내를 혼동합니다. 동적 영역이 늦게 로드되며 문단을 밀면 읽기 흐름도 깨집니다. 외부 요소가 있더라도 콘텐츠 탐색, 키보드 이동, 본문 가독성은 유지되어야 합니다.
- 모든 버튼에 텍스트나 aria-label을 둔다.
- h1은 페이지마다 하나만 둔다.
- 링크 텍스트에 목적지를 포함한다.
- 폼 label과 input을 연결한다.
참고 자료와 업데이트 기준
Frontend Note의 글은 실무 적용 관점에서 작성하며, 관련 기술의 공식 문서와 브라우저 지원 현황이 바뀌면 내용을 다시 점검합니다. 특히 프레임워크 버전, API 정책, 성능 측정 방식은 시간이 지나며 달라질 수 있으므로 적용 전에는 최신 문서를 함께 확인하는 것을 권장합니다.
- MDN Web Docs에서 웹 표준과 브라우저 동작을 확인합니다.
- web.dev에서 성능, 접근성, 사용자 경험 기준을 확인합니다.
- React 공식 문서에서 React 관련 API와 권장 패턴을 확인합니다.
작은 팀에서 시작하는 접근성 루틴
접근성은 별도의 대형 프로젝트로 시작하면 오래 유지되기 어렵습니다. 작은 팀이라면 새 컴포넌트를 만들 때마다 버튼, 링크, 폼, 모달 네 가지만 먼저 점검해도 효과가 큽니다. 버튼은 실제 동작이 버튼인지 확인하고, 페이지 이동은 링크로 둡니다. 폼은 눈에 보이는 라벨과 코드상의 연결을 맞추고, 오류 메시지는 색상만으로 전달하지 않습니다. 모달은 열렸을 때 포커스가 내부로 이동하고 닫은 뒤 원래 버튼으로 돌아와야 합니다.
검수 방식은 자동 도구와 수동 확인을 함께 써야 합니다. Lighthouse나 axe는 빠르게 누락된 라벨과 대비 문제를 알려주지만, 키보드만으로 실제 주문, 검색, 문의 흐름을 끝낼 수 있는지는 사람이 확인해야 합니다. 특히 커스텀 셀렉트, 탭, 아코디언은 시각적으로는 정상이어도 보조 기술에서는 상태가 전달되지 않는 일이 많습니다. 접근성 문서는 법적 문구보다 컴포넌트 사용 규칙으로 남길 때 개발자에게 도움이 됩니다. Frontend Note의 기준도 이 방향에 맞춰 실제 코드와 점검 순서를 함께 적는 것입니다.
