[Web] 웹 액세서빌러티(A11y): 모두를 위한 접근성 높은 인터페이스 구축

프론트엔드 개발자의 역할은 단순히 화려한 화면을 만드는 것이 아니라, '정보를 평등하게 전달하는 것'입니다. 우리가 만든 웹사이트가 시각 장애인 사용자의 스크린 리더에서 어떻게 읽힐지, 혹은 마우스를 쓸 수 없는 사용자가 키보드만으로 모든 버튼을 누를 수 있을지 고민해 본 적이 있나요?

웹 접근성을 뜻하는 A11y는 'Accessibility'의 첫 글자 'A'와 마지막 글자 'y' 사이에 11개의 글자가 있다는 의미에서 파생되었습니다. 오늘은 누구나 소외되지 않고 웹을 이용할 수 있게 만드는 구체적인 실무 전략을 알아보겠습니다.

---

1. 시맨틱 마크업: 웹의 뼈대를 의미 있게 세우기

가장 기본적이면서도 강력한 접근성 향상 방법은 시맨틱 태그(Semantic Tags)를 사용하는 것입니다.

1.1 왜 만 쓰면 안 되는가?

스크린 리더는 HTML 구조를 분석해 사용자에게 페이지의 맥락을 설명합니다. 모든 요소를 <div>나 <span>으로 만들면, 브라우저는 어디가 메뉴이고 어디가 본문인지 알 수 없습니다.

• <header>: 페이지나 섹션의 머리말
• <nav>: 네비게이션 링크 모음
• <main>: 문서의 핵심 콘텐츠 (페이지당 한 번만 사용)
• <article>: 독립적으로 배포 가능한 콘텐츠 (블로그 포스트, 뉴스 기사 등)
• <footer>: 페이지 하단 정보

시맨틱 태그를 잘 쓰면 검색 로봇(SEO)도 페이지를 더 잘 이해하게 되어 검색 결과 노출에 유리해집니다.

---

2. WAI-ARIA: HTML의 한계를 넘어서는 보조 기술

때로는 표준 HTML 태그만으로 UI의 복잡한 상태를 설명하기 어려울 때가 있습니다. 이때 사용하는 것이 WAI-ARIA(Accessible Rich Internet Applications) 속성입니다.

2.1 자주 쓰이는 ARIA 속성

• aria-label: 텍스트 없이 아이콘만 있는 버튼(예: 닫기 'X' 버튼)에 "닫기"라는 설명을 붙여줍니다.
• aria-expanded: 아코디언 메뉴나 드롭다운이 현재 펼쳐져 있는지(true) 닫혀 있는지(false) 알려줍니다.
• aria-live: 화면의 일부가 실시간으로 바뀔 때(예: 알림 메시지) 스크린 리더가 즉시 읽어주도록 설정합니다.
• role: <div>로 만든 탭 메뉴에 role="tablist" 같은 역할을 부여하여 브라우저가 이를 탭으로 인식하게 합니다.

주의 사항: "No ARIA is better than Bad ARIA"라는 격언이 있습니다. 가능하면 HTML5 표준 태그를 먼저 쓰고, 보조적인 수단으로만 ARIA를 사용해야 합니다.

---

3. 키보드 접근성: 마우스 없이 자유로운 탐색

어떤 사용자는 마우스 대신 키보드의 Tab 키와 Enter 키만으로 웹을 서핑합니다.

3.1 포커스 관리 (Focus Management)

모든 인터랙티브 요소(버튼, 링크, 입력창)는 키보드로 접근 가능해야 합니다.

• :focus 스타일: 포커스가 갔을 때 시각적으로 명확하게 표시되게 하세요. outline: none으로 이 표시를 지우는 것은 접근성에 치명적입니다.
• Tab 순서: tabindex 속성을 이용해 논리적인 순서대로 초점이 이동하게 하세요.
• 키보드 트랩 방지: 모달 창이 열렸을 때, Tab 키를 눌러도 초점이 모달 뒤쪽 배경으로 나가지 않도록 가두는 로직이 필요합니다.

---

4. 시각적 접근성: 색상 대비와 대체 텍스트

4.1 텍스트와 배경의 명도 대비

저시력자나 고령자를 위해 텍스트와 배경색 사이에는 충분한 대비가 있어야 합니다. WCAG(Web Content Accessibility Guidelines) 기준에 따르면 일반 텍스트는 최소 4.5:1 이상의 대비를 권장합니다.

4.2 alt 속성의 올바른 사용

이미지에는 반드시 alt 속성을 넣으세요.

• 정보성 이미지: 그림이 설명하는 내용을 짧고 명확하게 적습니다.
• 장식용 이미지: 내용 전달이 필요 없는 이미지는 alt=""로 비워두어 스크린 리더가 무시하게 만드세요.

---

5. 실무 접근성 테스트 방법

설계가 끝났다면 반드시 직접 테스트해 보아야 합니다.

1. 키보드 테스트: 마우스를 뽑고 Tab 키만으로 모든 기능을 쓸 수 있는지 확인하세요.
2. Lighthouse 검사: 크롬 개발자 도구의 Lighthouse 탭에서 'Accessibility' 점수를 확인하세요.
3. 스크린 리더 체험: Mac의 VoiceOver나 Windows의 NVDA를 켜고 내 사이트가 어떻게 들리는지 직접 들어보세요.

---

6. 결론: 접근성은 모두를 이롭게 합니다

버스를 탈 때 휠체어 경사로가 있으면 유모차를 끄는 사람도 편리하듯, 웹 접근성이 좋은 사이트는 모든 사용자에게 더 나은 경험을 제공합니다.

오늘의 요약:

• 시맨틱 태그를 사용하여 의미 있는 구조를 만드세요.
• WAI-ARIA로 부족한 맥락을 보충하세요.
• 키보드만으로 모든 조작이 가능하게 설계하세요.
• 대체 텍스트와 색상 대비로 시각적 장벽을 낮추세요.