모두를 위한 웹을 만든다는 것, Accessibility

접근성은 별도의 기능을 추가하는 일이 아니라, HTML을 작성하고 UI를 구현하는 과정에서 함께 지켜야 하는 기본 조건에 가깝다.

개발자 입장에선 조금 번거롭고 실제 인터페이스의 겉면만 볼 땐 달라보이는게 없을 수 있어도, 누군가의 사용성을 크게 바꾼다.

 

인턴으로 일할 때도 접근성 요소들이 잘 지켜지지 않던 기존 코드를 발견을 종종했어서 이슈를 올려 한번 쭉 검토를 해보기도 했는데, 사실 아래 내용을 정리하면서 생각지도 못한 부분 (예를 들면 버튼만 탐색해야할 경우를 대비하여 삭제가 아닌 프로젝트 삭제로 라벨을 설정해야한다는 점)도 고려대상이라는 점을 새롭게 배웠다.

 

 

이 글에서는 MDN의 「HTML: 접근성의 좋은 기반」 문서를 바탕으로, 웹 개발 중 최소한으로 점검하면 좋은 접근성 항목들을 정리해보려고 한다.

요즘같은 세상엔 아래 리스트만 복붙해서 AI한테 주면 바로 교체해줄 것이다...

MDN은 접근성 있는 HTML의 출발점으로 “올바른 HTML 요소를 올바른 목적에 맞게 사용하는 것”을 강조한다. 버튼은 버튼으로, 링크는 링크로, 제목은 제목으로 작성하는 것만으로도 브라우저와 보조 기술이 제공하는 기본 접근성 기능을 활용할 수 있다.

참고 문서: MDN Web Docs, 「HTML: 접근성의 좋은 기반」
https://developer.mozilla.org/ko/docs/Learn_web_development/Core/Accessibility/HTML

1. 의미에 맞는 HTML 요소를 사용했는가

가장 먼저 확인할 것은 시맨틱 HTML이다.

화면상으로는 <div>나 <span>에 스타일을 입혀 버튼처럼 만들 수 있다. 하지만 브라우저와 스크린 리더는 그것을 버튼으로 이해하지 않는다. 반면 <button>은 기본적으로 포커스가 가능하고, 키보드로 조작할 수 있으며, 보조 기술에도 버튼이라는 의미를 전달한다.

체크할 항목은 간단하다.

• 클릭해서 동작을 실행하는 요소는 <button>인가
• 페이지 이동이나 외부 이동은 <a>로 작성했는가
• 제목은 시각적 크기만 키운 텍스트가 아니라 <h1>부터 <h6>로 표현했는가
• 문단, 목록, 섹션 구조가 의미에 맞게 작성되어 있는가

시맨틱 HTML은 접근성만을 위한 선택이 아니다. 개발자가 코드를 이해하기 쉬워지고, 브라우저 기본 동작을 활용할 수 있으며, 유지보수에도 유리하다.

 

2. 키보드만으로 조작할 수 있는가

마우스를 사용할 수 없는 사용자도 웹을 사용할 수 있어야 한다. 그래서 주요 UI는 키보드만으로 접근하고 조작할 수 있어야 한다.

버튼, 링크, input, select 같은 네이티브 HTML 요소는 기본적으로 키보드 접근성을 제공한다. Tab 키로 이동하고, 포커스된 버튼이나 링크를 키보드로 실행할 수 있다.

반대로 <div>로 만든 가짜 버튼은 문제가 생긴다. 포커스를 받게 하려면 tabindex를 추가해야 하고, 스크린 리더가 버튼으로 인식하게 하려면 role="button"을 붙여야 한다. 여기에 Enter 키나 Space 키 동작까지 직접 구현해야 한다.

가능하면 처음부터 알맞은 HTML 요소를 사용하는 편이 낫다. 브라우저가 이미 제공하는 기능을 다시 구현하지 않아도 되고, 예상하지 못한 접근성 문제도 줄일 수 있다.

점검할 때는 실제로 마우스를 쓰지 말고 Tab, Shift + Tab, Enter, Space, 방향키만으로 화면을 이동해보는 것이 좋다.

 

3. 버튼과 링크의 라벨이 명확한가

버튼과 링크의 텍스트는 혼자 읽혀도 의미가 통해야 한다.

“여기를 클릭하세요”, “자세히 보기”, “확인” 같은 문구는 화면 전체 맥락 안에서는 이해될 수 있다. 하지만 스크린 리더 사용자가 링크나 버튼 목록만 따로 탐색할 때는 목적을 알기 어렵다.

예를 들어 다음보다,

<a href="/accessibility">자세히 보기</a>

아래가 더 낫다.

<a href="/accessibility">HTML 접근성 가이드 보기</a>

버튼도 마찬가지다.

<button>삭제</button>

만으로 부족하다면, 사용자가 무엇을 삭제하는지 알 수 있게 작성해야 한다.

<button>프로젝트 삭제</button>

화면에 같은 버튼이 여러 개 반복된다면, 시각적으로 보이지 않는 텍스트나 aria-label을 활용해 구분할 수도 있다. 다만 가능한 경우에는 보이는 텍스트 자체를 명확하게 쓰는 편이 좋다.

 

4. 입력 요소에 라벨이 연결되어 있는가

폼에서는 라벨 연결이 중요하다. 입력창 옆에 “이름”이라는 텍스트가 보인다고 해서, 스크린 리더가 그 입력창의 의미를 자동으로 이해하는 것은 아니다.

라벨과 input은 명확히 연결해야 한다.

<label for="email">이메일</label>
<input id="email" name="email" type="email" />

 

이렇게 작성하면 스크린 리더가 입력창의 목적을 함께 읽을 수 있고, 사용자는 라벨을 클릭해서도 입력창에 포커스할 수 있다.

placeholder만으로 라벨을 대체하는 것은 피하는 편이 좋다. placeholder는 입력을 시작하면 사라지고, 항상 접근성 이름으로 안정적으로 사용되기 어렵다. 입력값의 의미는 label로 제공하고, placeholder는 예시나 보조 설명 정도로 사용하는 것이 안전하다.

 

5. 데이터 테이블의 구조가 읽히는가

테이블은 눈으로 보면 구조를 쉽게 파악할 수 있다. 첫 번째 행이 헤더처럼 보이고, 각 열의 의미도 시각적으로 구분된다. 하지만 HTML 구조가 제대로 작성되어 있지 않으면 스크린 리더 사용자는 행과 열의 관계를 파악하기 어렵다.

테이블 헤더는 <th>로 정의하고, scope 속성으로 행 또는 열의 헤더인지 명시할 수 있다. <caption>은 테이블 내용을 빠르게 요약하는 역할을 한다.

기본적인 형태는 다음과 같다.

<table>
  <caption>사용자 권한 목록</caption>
  <thead>
    <tr>
      <th scope="col">이름</th>
      <th scope="col">역할</th>
      <th scope="col">상태</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Kim</td>
      <td>Admin</td>
      <td>Active</td>
    </tr>
  </tbody>
</table>

 

어드민 페이지나 대시보드처럼 테이블이 많은 화면에서는 이 부분이 중요하다. 정렬, 필터, 체크박스, 액션 버튼이 추가될수록 구조가 복잡해지기 때문이다. 화면상으로 보기 좋은 테이블을 만드는 것에서 끝내지 말고, 보조 기술이 행과 열의 관계를 이해할 수 있는지도 함께 확인해야 한다.

 

6. 이미지에 적절한 대체 텍스트가 있는가

이미지는 텍스트처럼 바로 읽히지 않는다. 이미지가 정보를 전달한다면, 그 정보는 대체 텍스트로 제공되어야 한다.

alt 값은 맥락에 따라 달라진다. 이미지 자체의 모든 시각 정보를 길게 설명하는 것이 아니라, 현재 문맥에서 사용자에게 필요한 정보를 전달하는 것이 중요하다.

예를 들어 프로필 이미지라면 이름만으로 충분할 수 있다.

<img src="profile.png" alt="김하은" />

반면 차트나 상태를 전달하는 이미지라면, 이미지가 담고 있는 핵심 정보가 설명되어야 한다.

<img src="chart.png" alt="지난 7일간 에러 발생 수가 3건에서 12건으로 증가한 그래프" />

장식용 이미지는 다르게 처리해야 한다. 의미 없는 장식 이미지를 스크린 리더가 읽으면 오히려 방해가 된다. 이런 경우에는 빈 alt=""를 넣거나 CSS background로 처리하는 편이 좋다.

<img src="decorative-line.png" alt="" />

alt를 아예 생략하면 일부 스크린 리더가 이미지 파일명이나 URL을 읽을 수 있다. 장식용 이미지라도 의도적으로 빈 alt를 제공하는 편이 안전하다.

 

7. 페이지 구조가 탐색 가능한가

페이지는 눈으로만 읽히는 구조가 아니다. 스크린 리더 사용자에게는 HTML의 순서와 구조가 곧 탐색 순서가 된다.

<header>, <nav>, <main>, <article>, <footer> 같은 시맨틱 요소를 사용하면 브라우저와 보조 기술에 페이지 구조를 전달할 수 있다. CSS로 시각적 위치를 바꿀 수 있더라도, HTML 문서 자체의 순서는 논리적으로 작성되어야 한다.

점검할 항목은 다음과 같다.

• 페이지에 하나의 주요 <main> 영역이 있는가
• 네비게이션은 <nav>로 구분되어 있는가
• 제목 단계가 건너뛰지 않고 논리적으로 이어지는가
• HTML 순서와 실제 읽기 순서가 어긋나지 않는가
• 모달이나 드롭다운을 열었을 때 포커스 흐름이 자연스러운가

레이아웃을 만들기 위해 <table>을 사용하는 방식은 피해야 한다. 테이블은 데이터를 표현하기 위한 요소다. 레이아웃 목적이라면 flex, grid 같은 CSS를 사용하는 편이 낫다.

 

8. 상호작용 요소 사이에 충분한 여백이 있는가

접근성은 스크린 리더만의 문제가 아니다. 버튼이나 링크가 너무 가까이 붙어 있으면 손 떨림이 있거나 정밀한 조작이 어려운 사용자가 실수로 다른 요소를 누를 수 있다.

확인할 부분은 다음과 같다.

• 버튼과 링크가 너무 촘촘하게 붙어 있지 않은가
• 클릭 가능한 영역이 텍스트 크기에만 의존하지 않는가
• 아이콘 버튼의 터치 영역이 충분한가
• 체크박스나 라디오 버튼은 라벨까지 클릭 가능한가

라벨과 input을 연결하면 라벨 클릭으로도 폼 요소를 선택할 수 있다. 작은 차이처럼 보이지만 실제 사용성에는 꽤 큰 영향을 준다.

 

9. tabindex를 불필요하게 사용하지 않았는가

tabindex="0"은 원래 포커스되지 않는 요소를 키보드 탭 순서에 포함할 때 사용할 수 있다. tabindex="-1"은 탭으로는 접근되지 않지만 JavaScript로 포커스를 이동시킬 때 사용할 수 있다.

반면 양수 tabindex로 탭 순서를 강제로 바꾸는 방식은 대부분의 경우 혼란을 만든다. 포커스 순서가 화면의 흐름과 다르면 키보드 사용자는 현재 위치를 예측하기 어렵다.

가능하면 DOM 순서 자체를 논리적으로 작성하고, 탭 순서를 억지로 조정하지 않는 편이 좋다.

 

10. 화면에 보이는 의미와 보조 기술이 읽는 의미가 같은가

마지막으로 확인할 것은 시각적 표현과 보조 기술이 읽는 정보가 크게 어긋나지 않는지다.

화면에는 버튼처럼 보이지만 실제로는 <div>일 수 있다. 제목처럼 보이지만 <span>일 수 있다. 테이블처럼 보이지만 헤더가 없을 수 있다. 아이콘만 있는 버튼인데 접근성 이름이 없을 수도 있다.

접근성을 점검할 때는 화면만 보지 말고 다음 방식으로 확인해보면 좋다.

• 키보드만으로 전체 화면을 이동해보기
• 브라우저 개발자 도구의 Accessibility Tree 확인하기
• 스크린 리더로 주요 흐름 읽어보기
• Lighthouse나 axe 같은 도구로 기본 오류 확인하기

자동화 도구가 모든 문제를 잡아주지는 못한다. 그래도 라벨 누락, 버튼 이름 누락, 색 대비 문제, 잘못된 ARIA 사용 같은 기본적인 문제를 빠르게 확인하는 데 도움이 된다.

 

체크리스트

웹 접근성을 지키기 위해 처음부터 거창한 구현이 필요한 것은 아니다. 최소한 아래 항목만 꾸준히 점검해도 많은 문제를 줄일 수 있다.

• 의미에 맞는 HTML 요소를 사용했는가
• 키보드만으로 이동하고 조작할 수 있는가
• 버튼과 링크의 라벨이 명확한가
• 입력 요소에 라벨이 연결되어 있는가
• 데이터 테이블에 헤더와 캡션이 있는가
• 이미지에 적절한 대체 텍스트가 있는가
• 페이지 구조가 논리적으로 탐색 가능한가
• 상호작용 요소 사이에 충분한 여백이 있는가
• tabindex를 불필요하게 사용하지 않았는가
• 화면에 보이는 의미와 보조 기술이 읽는 의미가 일치하는가

+ 인상깊게 읽은 글

https://www.americaneagle.com/insights/blog/post/intro-to-web-accessibility-the-important-facts-beginners-should-know

Intro to Web Accessibility: The Important Facts Beginners Should Know