일본 오피스의 직원(파트너)이 버그를 제보했다.
'어드민 페이지의 청(請)이 일본에서 사용하는 한자와 다르다.'
우리 팀은 갸우뚱했다.
'어떤 게 다르다는 거지?'
이내 차이를 알 수 있었다. 청 한자에 들어가는 푸를 청이 '青'였다.
어드민 페이지는 시스템 기본 폰트를 쓰고 있었다. 그렇다면 일본 브라우저에서 접속하면 자동으로 그 언어에 맞게 폰트가 다운로드되어야 하는 것 아닌가? 생각했다. 하지만 놀랍게도 어드민 페이지는 HTML Attribute로 언어를 고정하고 있었다.
<html lang="ko">
...크롬 브라우저 편집기로 lang을 "ja"로 바꾸니까 일본의 청이 제대로 렌더링됐다. 기본 폰트가 바뀐 것이다!
어드민 페이지는 Nuxt와 Next로 빌드되어있었는데, Nuxt는 lang 설정이 아예 없었고, Next는 lang 설정이 "ko"로 고정되어 있었다.
그래서 접속하는 병원의 국가에 따라 동적으로 lang을 주입하도록 바꿔야 했다.
내일 예의 '청'을 사용하는 페이지를 출시할 예정이라 마음이 급해졌다.
뭔가 더 나은 방법이 있을 수도 있었겠지만, 일단 빠르게 변경해보았다.
Nuxt 프로젝트에서는 모든 페이지에서 실행되는 default.vue에 HTML Attribute를 설정하는 코드를 추가했다.
// /layout/default.vue
// ...
head() {
return {
htmlAttrs: {
lang: this.country === 'JP' ? 'ja' : 'ko'
}
}
},
// ...Next 프로젝트에서도 모든 페이지에 기본적으로 실행되는 _document.tsx 파일에 고객의 언어에 맞는 lang 값을 넣어줬다.
// /pages/_document.tsx
// ...
<Html lang={language}>
// ...간단하게 알아보니, HTML Attribute lang은 웹 접근성에 중요한 요소 중 하나였다.
스크린 리더(컴퓨터 화면 낭독 소프트웨어)는 lang 값에 따라 어떻게 웹 사이트를 읽을지 결정한다고 한다.
어드민 페이지를 개발하다보면 웹 접근성을 챙기기 어려운 경우가 많았다. 하지만 전혀 생각지도 못한 곳에서 버그가 생겨서 자극이 됐다. 쉽게 챙길 수 있는 것은 챙겨보자. image의 alt 같은 것처럼 말이다. (lint나 warning이 있었으면 좋았을까...?)
참고 문헌
- https://developer.mozilla.org/ko/docs/Web/HTML/Global_attributes/lang
- 한국형 웹 콘텐츠 접근성 지침 2.1
'일반' 카테고리의 다른 글
| Exclusive 타입, 역직렬화 그리고 소통 (0) | 2022.12.18 |
|---|---|
| Back to the basic, 에러 메시지를 자세히 살피자 (0) | 2022.10.29 |
| 가독성에 관하여 (0) | 2022.10.18 |
| 오늘의 교훈: 빠르게 실패하고 구글링을 통해 공식문서 읽기 (0) | 2022.10.13 |
| 처음으로 API를 mocking하여 단위 테스트를 작성한 날 (0) | 2022.10.12 |