금융 프론트엔드에서 접근성이 필수인 이유 — 전자금융 접근성 실무 가이드

HANUI·
접근성금융KWCAGReactHANUI프론트엔드

금융 앱을 쓸 때 "앱인가, 웹인가?" 구분이 안 되는 경험 해본 적 있어요?

그 자연스러움 뒤에는 접근성이라는 보이지 않는 설계가 있어요. 금융 서비스에서 접근성은 선택이 아니라 법적 의무이고, 프론트엔드 개발자가 가장 앞줄에서 책임져야 하는 영역이에요.

전자금융 접근성, 왜 필수인가

법적 근거

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를 만든 이유 중 하나이기도 하고요.

"앱인가, 웹인가?" 구분이 안 되는 자연스러운 경험. 그 뒤에는 모든 사용자가 동일하게 사용할 수 있는 접근성 설계가 있어야 해요.


관련 링크

시리즈

HANUI

KRDS 기반 React 컴포넌트 라이브러리. 공공 웹 개발을 더 쉽게.