접근성 검증을 프로세스 기본값으로 만들기

사실 이건 피할 수 있었던 사고였다. 한 서비스에서 검정색 배경 위에 검정색 텍스트가 놓이면서 아무것도 안 보이는 상황이 발생했다. 화면을 켜도 아무것도 읽을 수 없다. 시각장애인뿐 아니라 일반 사용자도 (밝기 문제, 화면 글레어 상황 등) 피해를 본다. 이렇게 되면 단순 디자인 리뷰나 QA 테스트 리스트로는 막을 수 없는 문제가 되어버린다.

수동 감사가 충분하지 않은 이유

우리 팀은 지금까지 디자인 가이드라인에 "명암비를 충분히 유지하세요"라고 적어만 놨다. 디자인 리뷰어가 눈으로 "충분히 읽혀 보이나?"를 판단했다. 하지만 이건 주관적이고, 피로하고, 스케일이 안 된다.

특히 팀이 빨라지면서 모든 컬러 조합을 일일이 검증할 여유가 없어진다. 한 기능에 10개의 버튼, 5개의 배경-텍스트 조합이 있다면? 100개 화면이라면? 손으로 하나씩 체크하다 보면 반드시 빠진다. 게다가 어떤 조합이 WCAG AA 기준을 만족하는지 정확히 계산하는 건 디자이너나 개발자 대부분 모른다.

흔한 상황:
• 새로 추가된 색상 토큰이 기존 배경색과 조합되면서 명암비 부족
• "어 이건 리뷰에서 봤는데?" → 다른 화면/테마/라이트 모드에선 안 봤던 것
• "색상 이쁜데 명암비 기준 때문에 못 쓸 수도?"라며 미뤄지는 결정

WCAG 자동감사를 default에 넣기

이번에 결정한 건 간단하다. 디자인 완료 체크리스트에 "WCAG AA 명암비 검증 통과"를 기본값으로 추가하기. 아니, 정확히는 문서화하기. 이미 우리 도구에 자동으로 명암비를 계산하는 스크립트가 있었는데, 그걸 "선택 사항"이 아니라 "필수 프로세스"로 격상시킨 것.

이렇게 하면 뭐가 달라지나?

"default 검증"이라고 표현한 이유가 이거다. 추가 작업이 아니라, 체크리스트의 한 줄이 되는 것. 디자인을 완료했으면 이 검증을 "통과"한 상태여야만 다음 스테이지로 간다.

여기서 배운 것들

1. 접근성은 선택이 아니다. 많은 팀이 "접근성은 좋은 것"처럼 다룬다. 나중에 여유 생기면 한다. 하지만 명암비 부족이나 키보드 네비게이션 미지원은 실제로 사용자를 배제한다. 그리고 한 번 배포되면 모든 사용자가 그 "좋은 것"을 못 쓴다.

2. 인간의 기억과 일관성을 믿지 말고, 도구와 프로세스에 위임하라. "개발자가 신경 써야 해"라고 하면, 첫 달은 신경 쓴다. 그 다음부턴 휴먼에러다. 자동화하고 기본값에 넣으면, 신경 쓸 필요가 없다. 그냥 도구가 실패 알림을 준다.

3. "좋은 의도"는 충분하지 않다. 우리도 "명암비 중요"를 알고 있었다. 하지만 "알기"와 "모든 디자인에서 검증되기"는 다르다. 특히 팀이 성장하고 일이 많아질수록, 문서화된 의도는 버려진다. 명문화 + 자동화 + 문화가 함께 움직일 때 비로소 바뀐다.

이번 변경은 큼직큼직한 기능 추가는 아니다. 하지만 사소한 문서 한 줄이 조직 내 기본값을 바꾼다는 걸 또 한 번 느꼈다. 작은 것부터 체계화하면 팀 전체의 품질이 올라간다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 책상조명 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.