확대를 막아달라는 요청에 세 겹을 걸었다가 두 겹을 걷어냈습니다

매장 카운터에 놓인 태블릿에서 화면이 자꾸 확대된다는 요청이 들어왔습니다. 프랜차이즈 ERP 의 점주 웹은 주 사용처가 그 태블릿이고, 손이 자주 스치는 자리라 의도치 않은 확대가 실제로 거슬립니다. 요청은 구체적이었고 정당해 보였습니다.

그래서 확대를 막는 코드를 세 겹으로 걸었습니다. 그리고 같은 날 그중 두 겹을 다시 걷어냈습니다. 되돌린 이유는 기준 위반을 발견해서가 아니라, 근거로 적어둔 문장이 실측이 아니라 추정이었기 때문입니다.

확대를 막는 데 세 겹이 필요했습니다

막는 방법은 하나가 아니었습니다. 최종적으로 걸린 것은 세 겹입니다.

viewport 메타 태그에서 최대 배율과 사용자 확대를 함께 잠그는 설정

CSS 의 touch-action: manipulation 선언

특정 모바일 OS 용으로 제스처 시작·변경 이벤트를 가로채 기본 동작을 막는 스크립트

세 겹이 필요했다는 것 자체가 신호였습니다. 한 겹으로 안 막히니까 겹을 늘린 것인데, 안 막히는 데에는 이유가 있습니다. 확대를 막는 데 코드가 세 군데 필요하다는 것은, 브라우저가 그걸 쉽게 허용하지 않는다는 뜻이기도 합니다.

다 짜고 나서야 무엇을 깎았는지 확인했습니다

확대 차단은 WCAG 1.4.4 Resize text (AA) 에 바로 걸립니다. 텍스트를 200% 까지 확대해도 내용과 기능이 유지돼야 한다는 기준입니다. 접근성 검사도구 axe 에도 확대·축소를 막으면 안 된다는 규칙이 따로 있습니다.

세 번째 겹은 성격이 더 나빴습니다. iOS 는 오래전부터 user-scalable=no 를 의도적으로 무시합니다. 즉 제스처 이벤트를 가로채는 코드는 플랫폼이 일부러 막아둔 우회로를 다시 뚫는 코드였습니다.

플랫폼이 표준 설정을 의도적으로 무시하기 시작했다면, 그 설정을 쓰지 말라는 뜻입니다. 다른 길로 뚫으라는 뜻이 아닙니다.

되돌린 진짜 이유는 저울이 안 맞았다는 것입니다

기준에 걸린다는 사실만으로 되돌린 것은 아닙니다. 결정적이었던 것은 근거였습니다. 애초에 근거로 적어둔 문장은 「확대되면 하단탭이 밀린다」였는데, 다시 읽어보니 제가 겪은 게 아니라 추정이었습니다.

겪은 문제를 막는 것과 겪을 것 같은 문제를 막는 것은 값이 다릅니다. 접근성을 깎는 대가로 얻는 것이 겪어본 적 없는 부작용의 예방이라면, 그 거래는 애초에 성립하지 않습니다.

근거를 적어둔 덕분에 물을 수 있었던 것이기도 합니다. 「하단탭이 밀린다」를 근거란에 적어두지 않았다면, 나중에 이걸 제가 본 적 있는지 되물을 방법이 없습니다.

네 갈래를 놓고 다시 골랐습니다

흐름은 A 로 시작해 C 로 착지했습니다. 남긴 것은 touch-action: manipulation 한 줄입니다. 더블탭 확대만 꺼지고 핀치 확대는 살아 있어 기준 위반이 아닙니다. 덤으로 터치 반응이 300ms 빨라집니다.

실제로 거슬리는 것은 대개 더블탭이지 핀치가 아닙니다. 손이 스쳐서 화면이 확대되는 상황은 대부분 두 번 두드린 것으로 인식된 경우입니다. 요청 전체를 구현하지 않고 거슬리는 동작 하나만 골라 끄면, 체감 문제는 잡히고 확대 수단은 남습니다.

같은 날 반대편에서 같은 결론이 나왔습니다

같은 날 별건으로 진행한 작업이 하나 더 있었습니다. 읽는 텍스트에서 흐린 회색 단계를 여덟 곳 걷어내는 일입니다. 대비가 2.5:1 수준이라 태블릿을 비스듬히 보는 카운터 환경에서 특히 안 읽혔습니다.

보조 텍스트 하한 단계까지만 올렸습니다. 전부 검게 바꾸면 위계가 사라져 훑어 읽기가 더 어려워집니다.

가장 나빴던 자리는 빈 화면 설명문이었습니다. 목록에 아무것도 없을 때 사용자가 읽을 유일한 문장이, 화면에서 가장 흐린 글씨였습니다. 보조로 분류된 텍스트가 정작 가장 중요한 순간에 유일한 안내가 되는 경우가 있습니다.

같은 회색을 쓰던 아이콘은 그대로 뒀습니다. 글자와 모양은 대비 기준이 다르고, 일괄 치환으로 접근성을 해결하려 들면 의도한 시각 위계가 같이 무너집니다. 비활성 하단탭 라벨도 활성 상태와 색상 계열 자체가 달라, 대비를 올려도 구분이 유지됐습니다.

두 작업을 붙여놓고 보니 같은 문제였습니다. 확대는 화면이 안 읽힐 때 쓰는 도구입니다. 읽히면 안 씁니다. 「확대가 거슬린다」는 요청의 뿌리가 「글씨가 작다」인 경우가 있고, 요청을 그대로 구현하면 뿌리는 남고 접근성만 깎입니다.

지운 자리에 이유를 남겼습니다

두 겹을 걷어낸 뒤, 전역 스타일 주석에 다시 막지 말 것이라고 남겼습니다. 하지 않기로 한 결정은 코드에 흔적이 없습니다. 몇 달 뒤 같은 요청이 다시 오면, 그때의 저는 왜 안 막았는지 모른 채 다시 막습니다.

철회는 코드를 지우는 것으로 끝나지 않습니다. 지운 자리에 이유를 남겨야 끝납니다.

접근성을 깎는 요청이 들어왔을 때

같은 종류의 요청을 다시 받으면 아래 순서로 봅니다.

요청 문장을 증상으로 읽고, 반대편에 원인이 있는지 먼저 확인합니다

접근성을 깎는 쪽의 근거가 실측인지 추정인지 문장으로 적어 구분합니다

플랫폼이 표준 설정을 무시하기 시작했다면 우회로가 아니라 폐기된 이유를 읽습니다

요청 전체가 아니라 실제로 거슬리는 동작 하나만 골라 끕니다

다르게 푼 이유를 요청자에게 설명하고, 지운 자리에 주석으로 남깁니다

이 원칙이 안 통하는 자리도 있습니다

키오스크나 전시용 단말처럼 진짜로 확대를 잠가야 하는 화면이 있습니다. 불특정 다수가 만지고 되돌리는 방법을 안내할 수 없는 자리라면 잠그는 쪽이 맞습니다. 다만 그런 화면은 애초에 글씨를 크게 설계합니다. 잠그는 대가를 글씨 크기로 미리 지불한 것입니다.

더블탭을 실제 기능으로 쓰는 화면에서는 남긴 한 줄도 그냥 걸면 안 됩니다. 지도나 이미지 편집처럼 두 번 두드리는 동작에 기능이 걸려 있으면 그 기능이 같이 죽습니다. 이번에 무해했던 것은 그 화면의 더블탭에 기능이 없었기 때문입니다.

실측 근거를 요구하는 원칙도 어디에나 맞지는 않습니다. 데이터 유실이나 보안처럼 되돌릴 수 없는 사고는 겪기 전에 막는 쪽이 맞습니다. 이 글의 원칙은 되돌릴 수 있는 불편과 접근성을 같은 저울에 올릴 때의 이야기입니다.

글씨가 작다는 말이 나오면 글씨를 키웁니다

사용자 요청을 그대로 구현하지 않고 다르게 풀었으므로, 왜 그렇게 했는지 설명하는 비용이 따로 들었습니다. 설명 없이 조용히 다르게 만들면 신뢰가 깎입니다. 확대를 막아달라는 요청에는 더블탭만 껐다는 답을, 글씨 이야기에는 대비를 올렸다는 답을 같이 돌려줬습니다.

접근성을 깎는 쪽으로 요청을 푸는 판단은 실측 근거가 있을 때만 성립합니다. 근거가 추정이면, 깎지 않는 쪽으로 푸는 방법이 대개 하나 더 남아 있습니다.