웹 접근성 점수, 70에서 91로 올린 개선 기록

"접근성은 중요하지만, 나중에 하지 뭐…" 라는 생각을 하고 서비스 오픈을 앞두던 도중 서비스의 접근성 점수를 확인해보니 Lighthouse 기준으로 70점대에 머물러 있었습니다. 기능적으로는 문제가 없어 보였지만, 접근성은 모든 사용자가 서비스를 원활히 이용할 수 있도록 하는 데 중요한 기준이기 때문에 무시할 수는 없었어요. 특히 검색엔진 최적화(SEO), 법적 기준, 그리고 사용자 다양성을 고려하면 접근성은 더 이상 선택이 아닌 필수라고 생각했어요.

문제

먼저 Lighthouse 접근성 리포트를 분석해보면서 문제 항목들을 정리해봤어요. 주요 이슈는 다음과 같았어요:

• 대체 텍스트(alt)가 누락된 이미지
• 텍스트 대비 부족으로 인해 가독성이 떨어지는 경우
• 버튼이나 링크에 이름이 없어서 스크린리더가 읽지 못하는 문제
• 폼 요소에 label이 명확히 연결되지 않은 구조
• 헤딩(h 태그)의 계층 구조가 어색하게 구성되어 있는 부분

이런 항목들은 화면에는 잘 드러나지 않지만, 보조 기술을 사용하는 사용자에게는 큰 장벽이 될 수 있다고 판단했어요.

개선

• 이미지에 alt 속성 추가 모든 이미지에 의미 있는 대체 텍스트를 추가했어요. 단순 장식용 이미지는 alt=""로 처리해서 스크린리더가 생략할 수 있도록 했고요, 정보 전달이 필요한 이미지는 간단하게 내용을 설명해줬어요.

• 버튼에 텍스트 혹은 aria-label 부여 아이콘만 있는 버튼은 시각적으로는 잘 보이지만, 스크린리더는 읽을 수 없기 때문에 aria-label을 사용해서 기능을 설명해줬어요.

<button aria-label="메뉴 열기">
  <Icon />
</button>

• 색상 대비 조정 디자인에 크게 영향을 주지 않는 한해서 WCAG 기준에 따라 텍스트와 배경의 대비 비율을 맞췄어요.

✔️ 시맨틱 태그 정리 페이지 구조에 맞게 시맨틱 태그를 적용했어요. 콘텐츠 영역엔 <main>, 내비게이션에는 <nav>, 사이드 영역<aside> 구역별로 <section>이나 <article>을 사용했어요. 헤딩도 h1부터 h6까지 자연스러운 계층을 유지하도록 재정비했어요.

• 폼 요소에 label 연결 input, select, textarea 요소에 빠짐없이 label을 연결했어요. 시각적으로 라벨을 숨겨야 할 경우엔 aria-label 속성을 활용했어요.

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

Lighthouse 재측정 결과

이 모든 작업을 반영하고 나서 Lighthouse로 다시 점검해봤어요. 개선 전에는 접근성 점수가 70점대였는데, 수정 후에는 91점까지 상승했어요. 사용자의 입장에서 더 명확하고 접근성 높은 인터페이스가 되었다는 점에서 의미 있는 결과였어요.

마무리하며

접근성은 처음엔 어렵게 느껴질 수 있지만, 기본적인 항목들만 잘 지켜도 큰 변화를 만들 수 있다는 걸 이번 경험을 통해 느꼈어요. 사용자의 다양성을 고려한다는 점에서도 의미가 있었고, 앞으로도 UI를 설계할 때 접근성을 기본 요소로 두고 개발하려고 해요. 해당 페이지 뿐아니라 모노레포 환경에서 사용하는 공통 컴포넌트에도 적용하여 서비스 전체 접근성을 높였어요.