← 전체 글로 돌아가기

웹 개발

혼자 개발할 때 접근성 문제 디버깅하기

웹 페이지의 접근성 문제를 디버깅할 때 확인해야 할 순서를 정리했습니다.

혼자 개발할 때 처음부터 정답을 맞히려고 하면 오히려 확인 시간이 길어진다. 작은 단계로 나눠서 하나씩 확인하는 게 훨씬 빠르다.

먼저 문제를 정확히 파악하기

처음 보이는 증상이 뭔지 명확히 하자. 스크린리더가 텍스트를 읽지 못하는 건지, 키보드 네비게이션이 안 되는 건지, 색상만으로 정보를 전달하는 건지. 구체적으로 뭐가 문제인지 알아야 원인을 좁힐 수 있다.

원인을 나누는 기준

문제를 크게 보면 모든 파일이 의심스러워진다. 문제를 작게 나누자:

  • HTML 구조의 문제인가? (시맨틱 태그, aria 속성)
  • CSS 때문인가? (색상 명도, focus 스타일)
  • JavaScript 동작 때문인가? (이벤트 바인딩, 상태 업데이트)
npm run build

로컬과 운영 환경의 차이도 확인한다. 로컬에서는 괜찮은데 배포 후에 접근성 문제가 나타나는 경우도 있다.

확인 방법

로그를 보고, 응답을 보고, 설정을 본다. 스크린리더를 직접 써보거나, 브라우저의 접근성 검사 도구를 쓴다. 에러가 있으면 콘솔에 뭐가 나타나는지 기록한다.

명령으로 확인하기

작은 변화를 관찰하는 게 중요하다. 한 가지만 수정한 후 테스트하고, 결과를 해석한다. 같은 증상이 다시 나타나는지, 아니면 사라졌는지 확인한다.

마지막 점검

수정 후 실제 배포 환경에서도 같은 방식으로 확인한다. 로컬에서만 테스트하면 운영에서 다시 문제가 날 수 있다.

비슷한 문제가 다시 생기면, 먼저 현재 값을 기록하고 이전 기록과 비교하면 된다. 작은 기록들이 모이면 다음 확인이 훨씬 빨라진다.