마우스 없이 쓰는 사람들

웹을 마우스 없이 쓰는 사람들이 있어요. 손 대신 키보드만으로 화면을 오가는 사람, 화면을 보는 대신 화면낭독기 — 화면 내용을 음성으로 읽어주는 프로그램 — 로 듣는 사람. 공공 서비스는 이분들도 당연히 쓸 수 있어야 해요. 그래서 공공 웹에는 접근성이라는 요구가 법으로 정해져 있어요.

그런데 접근성이 깨지는 방식은 생각보다 조용해요.

화면은 빨간데, 낭독기는 조용해요

회원가입 폼에서 이메일을 잘못 입력했다고 해볼게요. 입력창 테두리가 빨개지고 아래에 "이메일 형식이 아닙니다"가 떠요. 눈으로 보는 사람에게는 완벽한 안내죠.

그런데 낭독기 사용자에게는 아무 일도 일어나지 않을 수 있어요. 빨간 테두리는 눈을 위한 신호일 뿐이고, 낭독기에는 별도의 신호(개발자들은 ARIA라고 불러요)를 따로 보내야 하거든요. 눈을 위한 신호와 귀를 위한 신호를 개발자가 각각 챙겨야 하는데, 바쁘면 한쪽을 빠뜨려요. 그렇게 "화면은 빨간데 낭독기는 조용한" 폼이 만들어져요.

이건 개발자가 나빠서가 아니에요. 두 신호를 따로 관리하는 구조 자체가 사고를 부르는 거예요.

빠뜨릴 수 없는 구조로 만들었어요

그래서 krdscn/ui의 폼 부품은 두 신호를 한 몸으로 묶었어요. 부품을 쓰는 개발자는 에러 문구 한 줄만 넘기면 돼요.

<TextInput error="이메일 형식이 아닙니다" />

이 한 줄이면 눈을 위한 빨간 테두리, 귀를 위한 즉시 낭독, 입력창과 에러 문구의 연결까지 전부 자동으로 처리돼요.

한 발 더 나가서, 빨간 테두리가 켜지는 조건 자체를 "낭독기용 신호가 켜져 있는가"에서 가져오게 만들었어요. 눈의 신호가 귀의 신호에서 파생되니, 화면만 빨갛고 낭독기는 모르는 상태가 구조적으로 불가능해져요.

// 빨간 테두리는 별도 관리가 아니라 접근성 신호(aria-invalid)에서 파생돼요
"aria-invalid:border-krds-danger-50"

키보드 사용자도 마찬가지예요. 선택지 사이를 방향키로 오가고, 스위치를 스페이스로 켜고 끄고, 긴 목록에서 글자를 치면 해당 항목으로 건너뛰는 — 이런 키보드 동작은 국제 표준 패턴이 정해져 있고, 검증된 부품(Radix)이 이미 구현해둔 것을 그대로 물려받았어요. 마우스 없이 폼 전체를 채우고 제출하는 데 걸림돌이 없게요.

물론 한계도 있어요. "필수 항목" 별표 표시를 자동으로 챙겨주는 기능은 아직 없어서, 개선 과제로 남겨뒀어요.

시리즈를 마치며

돌아보면 이 시리즈의 모든 결정이 같은 문장으로 모여요. 좋은 기본값은 배려를 노력에서 구조로 바꿔요. 검증된 것 위에 얹은 것도, 색 사전을 두 층으로 나눈 것도, 문서가 어긋나면 빌드가 깨지게 한 것도 — 전부 "사람이 매번 잘하기"에 기대지 않고 "잘할 수밖에 없는 구조"를 만드는 일이었어요.

가이드는 있는데 코드가 없어서 시작한 프로젝트가 여기까지 왔어요. 전체 컴포넌트와 예제는 krdscn-ui.smlee.info에서, 소스와 이슈는 GitHub에서 볼 수 있어요. 읽어주셔서 고마워요.