Lighthouse로 만난 접근성 이슈 하나씩 뽀개기

이미지를 누르면 기다려짐 github로 이동합니다 (틈새홍보)

 

드디어 끝이보이는 기다려짐...! (그러나 끝나지않은...)

요즘은 리팩토링, 최적화 등 마무리작업을 진행중이다.

나는 접근성과 SEO을 개선하기 위해 Lighthouse를 요 몇일사이 열심히 돌려보았고

그 과정에서 만난 여러가지 이슈들을 오늘 소개해보고 나의 문제해결 과정을 정리해보고자 한다!

 

 

접근성 구조와 Landmark

이젠 시맨틱하게 마크업을 해야한다는것은 너무 잘알고있다.

그런데 Landmark라는 개념은 초면이였다. 그래서 또 찾아보았다.

페이지의 주요 영역을 시맨틱태그 or Aria role로 구분해
스크린단위가 영역단위로 탐색할수있게 해주는 것을 의미한다.

 

주요 랜드마크 종류는 HTML 태그로 이렇게 표현한다.

• <header> ⭐️⭐️⭐️ 페이지 상단 헤더
• <nav> ⭐️⭐️⭐️ 내비게이션 메뉴
• <main> ⭐️⭐️⭐️ 주요 콘텐츠 영역
• <aside> 사이드바
• <footer> ⭐️⭐️ 하단 푸터
• <section>, <article> 콘텐츠 구역

 

⭐️⭐️⭐️는 필수급이니 빠트리지않고 적어주는것이 좋다

더 자세하게 알고싶다면 아래 아티클을 참고 해보시라요

 

https://velog.io/@sejinkim/HTML-랜드마크-역할을-사용하여-접근성-향상시키기

[번역] HTML 랜드마크 역할을 사용하여 접근성 향상시키기

 

 

 

브랜드컬러도 좋지만 4.5:1 명암비는 한번쯤은 고려해보자

기다려짐은 초반 기획부터 헬스케어 서비스이기 때문에 사용자의 건강을 고려한단 의미로 다크모드만 제공되고 있다

거기서 디자인 아이덴티티를 더해 열정(붉은계열) + 운동기구,쇠느낌(네이비)를 브랜드컬러로 결정하게 되었는데

디자인 의사결정을 혼자서 하다보니 접근성에 맞는지도 확인하지 않고 작업을 했던것이였다.

기다려짐의 홈화면 비교

 

위 화면은 서비스 홈화면인데 하단 오렌지색상 버튼이 WCAG가 정한 4.5:1 명암비에 맞지않아

부랴부랴 버튼색상을 화이트로 다 바꿔야하는 번거로운 작업이 일어났다

프론트는 물론 피그마나 랜딩페이지, 하다못해 리드미에 들어간 이미지들도 모두 바꿔야하는...ㅠ

뭐 그런 수고스러움은 그렇다 치더라도 명암비에 맞추고나니
확실히 눈이 좀 더 편안해진것같은 느낌적인 느낌(?)이 들기도 한다

 

덕분에 명암비를 쉽게 맞출수있는 피그마 플러그인 Stark도 알게되었고

만약 명암비에 맞지않는다하더라도 비슷한 색상을 추천해주는 사이트도 알게되어 북마크 해두었다.

아래에 해당사이트들 링크걸어두었으니 필요한사람은 줍줍 해가라능

 

https://www.getstark.co/

Stark: The suite of integrated accessibility tools for your product design and development team

 

https://app.contrast-finder.org/?lang=ko

Contrast Finder, 웹 접근성 기준(WCAG)에 적합하도록 명암이 충분히 대비되는 색의 조합 검색

 

 

 

모바일에서 아이콘과 폰트 최소사이즈 정도는 숙지하자

접근성이슈는 아니지만 pc에서 모바일화면을 작업할때는 체감되지않던 아이콘,폰트들이
실제 디바이스에서 실행해보면 사이즈가 많이 작다는것을 알게되었다.
이럴땐 그냥 사람들이 많이 이용하고 잘운영되고 있는 사이트들을 벤치마킹 하는것이 짱인거같다.

⭐️그리고 반드시 디바이스에서 디버깅 해보아야한다⭐️

 

또한 아이콘은 터치영역까지 고려해서 작업해야한다는점..! (최소 48px) 이건 WCAG에서 권고하는 부분이다!

 

 

 

영원히 해결하지 못할것같았던 MUI Modal의 Focus 접근성 이슈

 

사건의 전말은 이렇다. 어느날 어느 페이지의 모달 디버깅을 하던 도중 아래와 같은 콘솔에러를 만났다

Blocked aria-hidden on an element because its descendant retained focus.
Element with focus: <button>
Ancestor with aria-hidden: <div#root>

 

MUI Modal은 열릴 때 배경 콘텐츠를 비활성화하기 위해 #root에 aria-hidden="true"를 자동으로 붙인다.
문제는 버튼을 클릭하면 그 버튼에 포커스가 생기는데, 모달이 열리면서 aria-hidden이 적용되는 시점에
포커스된 버튼이 아직 #root 안에 남아 있다는 거다.

버튼 클릭 → 버튼에 포커스 생성 → 모달 열림 → #root에 aria-hidden 적용 →
포커스된 버튼이 aria-hidden 영역 안에 남아있음 → 에러

UI는 멀쩡하게 동작하지만 스크린리더 기준으로는 포커스 탐색이 깨진 상태였던것...

 

이거 하나를 해결하기 위해 온갖 방법(구글링,gpt,claude 등) 다 동원해봐도 계속 해결되지않아
접근성 모든이슈를 포기하고 있다가 요몇일 다시 해야겠단 생각이 들어
claude와 함께 다시 머리를 맡대어 문제해결을 드디어 해버렸다...!

 

<button
onClick={(e) => {
  e.currentTarget.blur(); // 포커스 제거
  setTimeout(() => {
    setIsOpenDialog(true);  // 모달 오픈
  }, 0);
}}
>
  삭제
</button>

모달을 열기전에 버튼 포커스를 blur()로 포커스를 명시적으로 제거시키면 되는 간단한 문제였던것이다

또한 간헐적으로 이슈가 일어나고 있어서 setTimeout으로 모달오픈을 타이밍을 맞추어

다음 task로 미루면 안정적으로 문제 해결을 할수 있었다. (고마워 클로드💕)

 

마무리

처음에는 Lighthouse 접근성 점수가 70점대가 나온 게 이제는 90점대가 나온다..!

접근성 이슈들을 하나씩 해결해 나가다 보니, 단순히 점수를 맞추는 작업이 아니라
사용자가 어떤 흐름으로 화면을 탐색하고, 어디에서 멈추고,
어떻게 인터랙션하는지를 확인하는 과정에 가깝다는 생각이 들었다.

랜드마크 구조, 명암비, 터치 영역, 포커스 흐름까지 결국은 모두 UIUX를 안정적으로 만들기 위한 요소들이었다.

이번 작업을 통해 접근성은 UI를 구현하면서 자연스럽게 함께 고려해야 하는 기준이라는 것을 조금은 체감하게 된 것 같다.