[접근성연구·공공앱] KRDS가 앱까지 — 웹과 다른 점

공공 모바일앱 접근성 연구

〈디지털 접근성 연구 077〉 — 이 글은 규정이 아니라 하나의 연구 관점입니다. 인용 수치·기준은 출처와 함께, 미확정 영역은 그렇다고 밝혀 작성합니다.

들어가며

표준 여섯 편(071~~076)을 닫으며 한 가지를 예고했다. 표준의 무대가 웹에 머물지 않고 무인기로, 그리고 모바일 '앱'으로 넓어진다는 것이다. 이번 묶음(077~~079)은 그 새 무대 — 공공 모바일앱 — 를 다룬다.

먼저 짚어 둘 구분이 있다. 이 시리즈의 모바일 연구(015~028)는 사실 모바일 '웹'을 다뤘다. 스마트폰의 브라우저로 여는 웹 페이지였다. 그런데 공공 서비스는 점점 설치해서 쓰는 '네이티브 앱'으로도 들어왔다. 정부·지자체·공공기관의 앱이 늘었고, 사용자는 브라우저가 아니라 앱 아이콘을 눌러 서비스에 닿는다. 모바일 웹과 네이티브 앱은 같은 휴대폰 안에 있지만, 그 접근성의 작동 방식은 같지 않다.

이번 편은 그 차이의 뼈대를 본다. 범정부 통합 디자인시스템(KRDS)이 웹을 넘어 앱 UI까지 적용 범위를 넓혀 온 흐름과, 앱 접근성이 웹과 무엇이 다른지를 연구의 시선으로 정리한다. 세부 기준은 플랫폼(iOS/Android)과 관련 지침에 따라 다르므로, 정확한 적용은 늘 원문 확인이 안전하다.

1. KRDS가 앱까지 넓어진 흐름

1-1. 디자인시스템이 매체를 가로지른다

KRDS는 공공 디지털 서비스의 화면을 일관되게 만들기 위한 범정부 디자인시스템이다. 처음에는 웹을 주된 무대로 삼았지만, 공공 서비스가 앱으로 확장되면서 디자인시스템도 모바일 앱 UI까지 적용 범위를 넓혀 왔다. 버튼·입력·내비게이션 같은 구성요소를 웹과 앱에서 일관되게 다루려는 흐름이다.

이 확장의 의미는 단순하지 않다. 디자인시스템이 매체를 가로지른다는 것은, 웹에서 쌓은 접근성의 원칙이 앱에서도 이어질 토대가 생긴다는 뜻이다. 069편이 "웹과 무인기는 한 뿌리"라고 했듯, 웹과 앱도 같은 디자인 원칙 위에 설 수 있다. 다만 그 원칙을 실제로 구현하는 기술은 매체마다 다르다.

1-2. 같은 원칙, 다른 구현

071편에서 본 4대 원칙(인식·운용·이해·견고)은 앱에서도 유효하다. 앱의 정보도 인식할 수 있어야 하고, 조작할 수 있어야 하고, 이해할 수 있어야 하고, 보조기술과 견고하게 맞물려야 한다. 원칙은 같다. 그러나 그 원칙을 구현하는 방식은 웹과 앱이 다르다. 웹은 HTML과 ARIA로 의미를 전달하지만, 앱은 플랫폼이 제공하는 접근성 API로 의미를 전달한다. 같은 '대체 텍스트' 개념이라도, 웹의 alt 속성과 앱의 접근성 레이블은 다른 자리에서 작동한다.

4대 원칙(071편)	웹 구현	앱 구현
인식	alt·캡션	접근성 레이블
운용	키보드 초점	낭독기 포커스·제스처
이해	명확한 구조	일관된 앱 내비게이션
견고	ARIA·시맨틱	플랫폼 접근성 API

(관점) 원칙은 매체를 가리지 않습니다. 069편이 "웹과 무인기는 한 뿌리"라 했듯, 웹과 앱도 같은 원칙 위에 서되 구현하는 기술만 다릅니다.

2. 앱이 웹과 다른 점

2-1. 보조기술이 다르다

웹에서 화면 낭독은 주로 데스크톱의 스크린리더나 모바일 브라우저의 낭독 기능으로 이뤄진다. 앱에서는 플랫폼에 내장된 화면 낭독기가 그 자리에 선다. iOS의 VoiceOver, Android의 TalkBack이 대표적이다. 사용자는 손가락으로 화면을 쓸어 넘기며 요소를 하나씩 듣고, 두 번 두드려 실행한다. 웹의 키보드 탭 이동(047~049편)과 닮았지만, 입력은 키보드가 아니라 제스처다.

그래서 앱 접근성은 '이 요소가 VoiceOver/TalkBack에 어떻게 읽히는가'를 중심에 둔다. 버튼이 '버튼'으로 읽히는지, 이미지에 레이블이 붙어 있는지, 읽는 순서가 화면의 논리적 순서와 맞는지 — 이것이 앱 접근성의 핵심 질문이다.

2-2. 조작과 제스처가 다르다

웹은 마우스·키보드·터치를 두루 받지만, 앱은 터치와 제스처가 기본이다. 그런데 화면 낭독기를 켜면 제스처의 의미가 달라진다. 평소 한 번 두드리는 동작이, 낭독기에서는 '선택'이 되고 실행은 두 번 두드리기가 된다. 복잡한 제스처(여러 손가락, 길게 누르기, 끌기)는 낭독기 사용자에게 어려울 수 있어, 대안 경로가 필요하다. 이 시리즈가 키보드 편에서 말한 '하나의 입력만 강제하지 않는다'는 원리가, 앱에서는 제스처 대안으로 나타난다.

다른 점	웹	앱(낭독기 켤 때)
낭독 도구	스크린리더·브라우저	VoiceOver·TalkBack
한 번 두드림	즉시 실행	선택(실행은 두 번)
복잡 제스처	키보드 대안	대안 경로 필요
읽는 순서	DOM·tabindex	화면 논리 순서

(한계) iOS·Android의 제스처 동작은 플랫폼 버전에 따라 다릅니다. 위 정리는 대표적 동작이며, 정확한 기준은 각 플랫폼 문서 확인이 안전합니다.

3. 플랫폼이 절반을 떠받친다

3-1. 플랫폼 접근성 설정

앱 접근성의 한 가지 특징은, 플랫폼(운영체제)이 많은 부분을 떠받친다는 점이다. iOS와 Android는 글자 크기 조정, 색 반전, 대비 강화, 모션 줄이기 같은 접근성 설정을 시스템 차원에서 제공한다. 잘 만든 앱은 이 시스템 설정을 따라간다 — 사용자가 글자를 키우면 앱의 글자도 커지고, 모션을 줄이면 앱의 애니메이션도 절제된다.

이것은 웹과 다른 강점이자 책임이다. 웹에서는 브라우저와 사용자 설정에 기대는 부분이 있지만, 앱에서는 플랫폼 설정을 따르는지가 더 직접적으로 드러난다. 시스템 글자 크기를 무시하고 고정 크기로 만든 앱은, 저시력 사용자(029~043편)가 시스템에서 글자를 키워도 소용이 없다.

3-2. 그래서 점검의 출발점도 다르다

웹 점검이 HTML·ARIA·CSS를 보는 데서 출발한다면, 앱 점검은 '플랫폼 낭독기를 켜고 시스템 설정을 바꿔 보는' 데서 출발한다. VoiceOver/TalkBack을 켜 보고, 시스템 글자 크기를 최대로 올려 보고, 색 반전을 켜 보는 것. 같은 '조건을 빌려 보는' 점검(070편)이지만, 빌리는 도구가 플랫폼에 내장된 기능이라는 점이 다르다. 이 구체적인 점검 방법은 079편에서 따로 다룬다.

플랫폼 설정	떠받치는 것	무시하면
시스템 글자 크기	키우면 앱 글자도 확대	저시력 사용자 소외(029~043편)
색 반전·대비 강화	가독성 보정	대비 부족 그대로
모션 줄이기	애니메이션 절제	전정기관 부담
낭독기 연동	요소 레이블 전달	빈 버튼으로 읽힘

(관점) 앱은 플랫폼이 절반을 떠받칩니다. 잘 만든 앱은 시스템 설정을 따라가고, 점검은 그 연동 여부를 확인하는 데서 출발합니다(079편).

4. 웹과 앱은 한 뿌리, 다른 가지

4-1. 원칙을 옮기되, 방법은 새로 배운다

웹에서 익힌 접근성의 눈은 앱으로 옮겨진다. 대체 정보, 조작 대안, 충분한 대비, 논리적 순서 — 이 원칙들은 매체를 가리지 않는다. 그러나 그 원칙을 구현하고 점검하는 방법은 앱에서 새로 배워야 한다. 웹의 alt가 앱의 접근성 레이블로, 웹의 키보드 초점이 앱의 낭독기 포커스로, 웹의 CSS 미디어쿼리가 앱의 시스템 설정 연동으로 — 같은 개념이 다른 옷을 입는다.

4-2. 다음 편으로 — 왜 앱은 덜 점검되나

앱 접근성이 웹과 같은 뿌리라면, 한 가지 의문이 남는다. 그런데도 왜 앱은 웹보다 점검이 덜 이뤄지는가. 대부분의 접근성 진단과 도구가 웹에 집중되어 있어, 앱이 사각지대에 놓이는 현상이 있다. 다음 편에서는 이 '앱 접근성의 사각지대'를 관찰의 시선으로 살핀다.

같은 개념	웹의 옷	앱의 옷
대체 정보	alt 속성	접근성 레이블
초점 이동	키보드 초점	낭독기 포커스
설정 반응	CSS 미디어쿼리	시스템 설정 연동
점검 도구	풍부(웹 집중)	부족(078편)

(관점) 원칙은 옮겨지되 방법은 새로 배웁니다. 같은 개념이 다른 옷을 입는 것 — 다음 편(078)은 왜 앱의 옷이 덜 점검되는지를 관찰합니다.

한 장 요약

구분	웹에서	앱에서
의미 전달	HTML·ARIA 속성	플랫폼 접근성 API·레이블
화면 낭독	스크린리더·브라우저 낭독	VoiceOver(iOS)·TalkBack(Android)
조작	마우스·키보드·터치	터치·제스처(낭독기 시 변형)
설정 연동	브라우저·사용자 설정	시스템 글자크기·대비·모션
점검 출발	HTML/ARIA/CSS 검사	낭독기 켜기·시스템 설정 바꾸기

※ 위 표는 연구 관점의 요약입니다. 앱 접근성의 세부 기준은 플랫폼(iOS/Android)·KRDS·관련 지침 원문에 따라 다를 수 있습니다.

맺으며

공공 서비스는 웹을 넘어 앱으로 들어왔고, 디자인시스템도 그 흐름을 따라 앱까지 범위를 넓혔다. 앱 접근성은 웹과 같은 4대 원칙 위에 서지만, 그 원칙을 구현하는 기술은 다르다. 의미는 ARIA가 아니라 플랫폼 API로, 낭독은 브라우저가 아니라 VoiceOver·TalkBack으로, 설정은 CSS가 아니라 시스템 접근성 설정으로 전해진다. 같은 개념이 다른 옷을 입는 것이다.

그래서 웹에서 익힌 접근성의 눈은 앱으로 옮겨지되, 그 구체적 방법은 앱에서 새로 배워야 한다. 다음 편에서는 이 새 무대가 왜 웹보다 점검이 덜 이뤄지는지 — 앱 접근성이 사각지대에 놓이는 현상을 관찰한다.

다음 편 예고 (078): 〈앱 접근성이 사각지대인 이유〉 — 시장 관찰. 대부분의 접근성 진단이 웹에 집중되어 앱이 점검 사각지대에 놓이는 현상을 관찰의 시선으로 살펴본다.

참고한 공개 자료(출처):

범정부 통합 디자인시스템(KRDS) 공식 소개 — 웹·모바일 앱 적용 범위
한국지능정보사회진흥원(NIA), 「모바일 애플리케이션 접근성 지침」 관련 자료
애플 「iOS 접근성(VoiceOver)」·구글 「Android 접근성(TalkBack)」 공개 문서
이 시리즈 모바일 연구 편(015~028)의 정리

※ 위 자료의 항목·기준은 플랫폼 버전·개정에 따라 달라질 수 있으며, 본문의 정리는 연구 관점의 요약입니다. 정확한 적용 기준은 각 출처의 원문 확인이 안전합니다.