금융 프론트엔드에서 접근성이 필수인 이유 — 전자금융 접근성 실무 가이드
접근성 시리즈
(5편)금융 앱을 쓸 때 "앱인가, 웹인가?" 구분이 안 되는 경험 해본 적 있어요?
그 자연스러움 뒤에는 접근성이라는 보이지 않는 설계가 있어요. 금융 서비스에서 접근성은 선택이 아니라 법적 의무이고, 프론트엔드 개발자가 가장 앞줄에서 책임져야 하는 영역이에요.
전자금융 접근성, 왜 필수인가
법적 근거
2023년부터 시행된 장애인차별금지법 시행령 개정으로, 금융기관의 웹/앱 서비스는 KWCAG 2.2 준수가 의무예요.
| 구분 | 내용 |
|---|---|
| 대상 | 은행, 증권, 보험, 카드사 등 전자금융업자 |
| 기준 | 한국형 웹 콘텐츠 접근성 지침 2.2 (KWCAG 2.2) |
| 제재 | 미준수 시 시정명령, 과태료, 소송 리스크 |
| 인증 | 웹접근성 품질인증마크 (연간 갱신) |
공공기관 SI에서는 이미 KWCAG가 필수였지만, 금융권은 더 까다로워요. 사용자가 실제 돈을 움직이는 서비스니까, 접근성 문제가 곧 금융 사고로 이어질 수 있거든요.
실제 사례 — 스크린 리더로 이체를 못 하면?
시각장애인 사용자가 스크린 리더로 모바일 뱅킹을 사용한다고 생각해보세요.
이건 이론이 아니에요. 금융감독원에 실제로 접수되는 민원 유형이에요.
프론트엔드 개발자가 챙겨야 할 접근성 체크리스트
20년간 금융권 프로젝트를 하면서 정리한 실무 체크리스트예요.
1. 포커스 관리 — 금융 서비스의 핵심
HANUI의 Modal 컴포넌트는 이걸 자동으로 해줘요:
- 열릴 때 첫 번째 포커스 가능한 요소로 포커스 이동
Esc로 닫기- 닫힐 때 트리거 요소로 포커스 복귀
- 외부 스크롤 잠금
2. 금액 입력 — 숫자만의 함정
금융 서비스에서 type="number"를 쓰면 안 되는 이유:
- 마우스 스크롤로 금액이 변경될 수 있음 (1000만원이 1억이 될 수 있어요)
- 스크린 리더에서 불필요한 증감 버튼이 노출됨
- 로케일에 따라 소수점 구분자가 달라짐
3. 에러 상태 — "빨간색"만으로는 부족해
HANUI의 FormField는 status="error" 하나만 주면 나머지를 자동으로 처리해요:
aria-invalid자동 추가role="alert"로 스크린 리더가 즉시 읽음- 아이콘 + 색상 + 텍스트 3중 표현 (색각 이상 사용자 대응)
4. 라이브 리전 — 잔액 변동, 타이머
aria-live="assertive": 즉시 읽어야 하는 정보 (OTP 만료, 에러)aria-live="polite": 현재 읽고 있는 내용이 끝나면 읽을 정보 (잔액 변동)
5. 키보드 네비게이션 — Tab 순서가 곧 사용 흐름
실수하기 쉬운 포인트:
tabIndex양수값 사용 금지 (0 또는 -1만)display: none대신 숨긴 요소에 포커스가 가는 경우- 동적으로 추가된 요소의 Tab 순서
HANUI에서 접근성을 어떻게 해결했는가
개발자가 신경 쓸 게 없게 만들기
접근성의 가장 큰 적은 바쁜 일정이에요. "나중에 하자"가 영원히 안 되거든요.
그래서 HANUI는 "접근성을 챙기려고 노력하지 않아도 되는" 구조로 만들었어요.
개발자는 placeholder만 넣었는데, ARIA 속성은 전부 자동이에요.
접근성 경고 시스템
HANUI 컴포넌트는 개발 환경에서 접근성 문제를 경고해요:
빌드 때가 아니라 코딩하는 순간 잡아주니까, 검수 때 몰아서 고치는 일이 없어져요.
금융 접근성 테스트 도구
실무에서 쓰는 도구들이에요:
| 도구 | 용도 | 추천도 |
|---|---|---|
| axe DevTools | 자동 접근성 검사 | ★★★★★ |
| WAVE | 시각적 접근성 리포트 | ★★★★ |
| VoiceOver (Mac) | 스크린 리더 테스트 | ★★★★★ |
| NVDA (Windows) | 스크린 리더 테스트 | ★★★★★ |
| Lighthouse | 접근성 점수 | ★★★ |
| Colour Contrast Analyser | 명도 대비 검사 | ★★★★ |
가장 중요한 건 VoiceOver/NVDA로 직접 써보는 거예요. 자동 검사 도구는 전체 문제의 30%만 잡아요.
마무리
금융 프론트엔드에서 접근성은 "추가 작업"이 아니에요. 기본 스펙이에요.
디자인 시스템 레벨에서 접근성을 해결하면, 개발자가 매번 신경 쓰지 않아도 자연스럽게 접근성이 보장돼요. 그게 HANUI를 만든 이유 중 하나이기도 하고요.
"앱인가, 웹인가?" 구분이 안 되는 자연스러운 경험. 그 뒤에는 모든 사용자가 동일하게 사용할 수 있는 접근성 설계가 있어야 해요.
관련 링크
시리즈
- 이전 편: KWCAG 2.2 웹접근성 자동 적용
HANUI
KRDS 기반 React 컴포넌트 라이브러리. 공공 웹 개발을 더 쉽게.