TorontoJS 5월 밋업 후기 – 웹 접근성, 지금도 괜찮을까?

💡 5월 15일, Super.com에서 열린 TorontoJS Tech Talk에 다녀왔다. 여러 발표 중 프론트엔드 개발자 Aleksei Veselovskii님의 세션 “Is It Accessible Now? My Beginner’s Journey to WCAG Certification” 이 특히 인상 깊었는데, 발표를 들으며 필자는 예전 회사에서 작업했던 부끄러운 접근성 관련 경험이 떠올랐다.

필자의 접근성

필자는 이전 직장에서 접근성을 고려한 작업을 해본 적이 있긴 있었다. 당시 요구사항은 단순했다.

키보드만으로 클릭 및 다음 동작으로 넘어갈 수 있도록 처리.

그래서 Tab 순서를 제어하거나, Enter/Space로 버튼을 작동하게 만드는 정도의 작업만 했다.
사실 그땐 이것만 해도 ‘접근성을 신경 썼다’고 여겼던 것 같다.
하지만 이번 새션에서 필자가 그 당시 미쳐 생각하지 못했던 부분들을 되돌아볼 수 있었다.

접근성 챙기기

스크린 리더 테스트 – 실제로 읽히는가?

접근성을 챙긴다는 것은 화면을 보지 못해도 ‘이해할 수 있도록’ 만드는 것이라고 하는데 이 말을 듣고 머리가 띵했다. 어떻게 화면을 보지 못하는데 이해할 수 있을까? 화자는 macOS에서 기본 제공되는 VoiceOver를 사용해, 자신의 웹페이지가 어떻게 읽히는지를 직접 테스트했다. 단순히 “보여주는” 것이 아닌, “읽히는 흐름” 을 따라가는 테스트였다.

예를 들어, 페이지 내의 버튼이나 링크가 스크린 리더에서 “버튼”으로 명확하게 인식되는가?
섹션의 제목이 H1~H6로 논리적인 구조를 가지고 있는가?
포커스를 이동하면서 스크린 리더가 현재 위치를 제대로 안내해주는가?

이 과정에서 중요했던 건 단순히 tabIndex를 다는 것이 아니라, 스크린 리더가 어떤 맥락에서 어떻게 안내하는지를 실제로 듣고 확인하는 것이었다.

aria-* 속성 활용 – 보이지 않는 의미 전달

아이콘 버튼이나 상태 메시지 같은 경우, 시각적인 정보만으론 부족하다. 화자는 다음과 같은 방식으로 aria-* 속성을 활용해 보이지 않는 의미를 전달했다.

아이콘 버튼에 설명 추가
```
// example

<button aria-label="Close">
   <svg aria-hidden="true" ... />
</button>
```
- 시각적으로는 아이콘만 보이지만, 스크린 리더는 “닫기”라고 읽음
- aria-hidden="true"는 아이콘 자체는 읽지 않게 하여 중복 제거
동적 메시지에 aria-live 적용
```
// example

<p id="status-message" aria-live="polite"></p>

<script lang="js">
  document.getElementById('status-message').textContent = 'Completed Submit!';
</script>
```
- 사용자가 form을 제출했을 때 화면에는 표시되지만, 스크린 리더가 이를 자동으로 읽지 않음
- aria-live 속성을 통해 변화된 콘텐츠를 음성으로 알려줌

시맨틱 구조로 의미를 드러내기

화자는 시맨틱 HTML을 통한 의미 전달을 매우 중요하게 여겼다.
스크린 리더 사용자 입장에서는 CSS 스타일보다 태그의 역할이 훨씬 중요하기때문.

잘못된 예	개선된 예
`<div onclick="..." role="button">`	`<button onClick="...">`
`<div>Login</div>`	`<h2>Login</h2>`
`<span>Menu</span>`	`<nav><ul><li>Menu</li></ul></nav>`

실제로 <div> 만을 쓰면 화면상으로는 같아도 보조 기술 사용자에게는 의미 없는 덩어리가 됩다고 한다.
반면 시맨틱 태그는 기기의 기본 기능(키보드 이동, 설명, 역할 정의 등)을 자동으로 지원한다.

키보드 내비게이션 – 흐름과 포커스 유지

접근성을 고려할 때 자주 놓치는 부분 중 하나가 포커스 이동 흐름이다. 화자는 다음과 같은 기준으로 개선했다.

tab 키 순서가 자연스러운 순서로 흐르는지
모달이나 팝업이 뜰 때, 포커스가 자동으로 이동하고 빠져나올 수 있는지
초점이 이동했을 때 사용자에게 시각적 피드백이 있는지

// example (when users focus on button, button's outline style)

 button:focus-visible {
   outline: 2px solid #1e90ff;
   outline-offset: 2px;
 }

이를 통해 키보드 유저에게 현재 위치를 명확히 알려주고, CSS를 통한 접근성 향상도 함께 고려한 점이 인상적이었다.
색상과 같은 디자인 영억은 프론트엔드 개발자 마음대로 할 수 있는 부분이 아니지만, 디자인팀과 논의할 수 있는 좋은 논쟁거리라 생각한다. :)

접근성 검사 도구 활용

기술적으로 완성도를 높이기 위해 다음과 같은 도구들을 사용했다고 한다.

axe DevTools : 자동으로 WCAG 위반 사항 탐지 + 해결 가이드 제시
Lighthouse (Chrome 내장) : 접근성 점수, 문제 영역을 시각적으로 피드백
- 가장 빠르게 접근성을 체크할 수 있는 방법
WAVE : 시각적인 오버레이를 통해 문제 영역 표시 (특히 heading 구조, contrast 문제에 유용)

이 도구들을 단순히 “점수 올리기용”으로 쓰는 게 아니라, 실제 사용성 개선의 피드백 루프로 활용한 점이 매우 실용적이었다.

마치며

화자의 접근 방식은 단순히 스펙을 만족시키는 데서 끝나지 않았다. “실제 사용자의 눈과 귀, 손이 되어 테스트하는 과정” 자체를 개발 프로세스에 녹여냈다는 점이 가장 인상 깊었다.

이런 태도는 코드 한 줄보다 더 큰 차이를 만든다고 느꼈다.