[접근성연구·공공앱] 앱 접근성이 사각지대인 이유

시장 관찰

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

들어가며

앞 편(077)에서 앱 접근성이 웹과 같은 4대 원칙 위에 서되, 그 원칙을 구현하는 기술은 다르다고 봤다. 의미는 플랫폼 API로, 낭독은 VoiceOver·TalkBack으로, 설정은 시스템 접근성 설정으로 전해진다고 했다. 그 차이를 알고 나면 자연스러운 의문이 따라온다. 앱이 웹과 같은 뿌리라면, 왜 앱 접근성은 웹보다 점검이 덜 이뤄지는가.

이번 편은 그 물음을 시장 관찰의 시선으로 본다. 결론부터 말하면, 앱이 사각지대에 놓이는 것은 앱이 덜 중요해서가 아니다. 오히려 사용자는 점점 더 앱으로 공공 서비스에 닿는다. 그런데도 접근성 진단의 도구와 관행이 웹에 집중되어 있어, 같은 기관의 서비스라도 앱 쪽이 점검에서 뒤처지는 현상이 관찰된다.

이 글은 특정 앱이나 기관의 점검 실태를 단정하지 않는다. 점검 환경의 구조적 차이가 왜 앱을 사각지대로 만드는지, 그 일반화된 패턴을 관찰한다. 구체적인 점검 방법은 다음 편(079)에서 따로 다룬다.

1. 도구의 무게중심이 웹에 있다

1-1. 웹에는 자동 점검 도구가 풍부하다

072편에서 봤듯, 웹 접근성에는 자동 점검 도구가 여럿 있다. 페이지의 HTML을 훑어 대체 텍스트 누락, 대비 부족, 레이블 없는 입력 같은 문제를 기계적으로 잡아내는 도구들이다. 브라우저 확장으로 깔아 한 번에 검사하고, 검사 결과를 목록으로 받을 수 있다. 웹의 의미가 HTML·ARIA라는 '읽을 수 있는 텍스트 구조'에 담기기 때문에, 도구가 그 구조를 파싱해 자동으로 점검할 여지가 크다.

이 풍부함은 웹 접근성 점검을 비교적 쉽게 만들었다. 전문 지식이 깊지 않아도 도구를 돌려 1차 문제 목록을 얻을 수 있고, 그 목록이 점검의 출발점이 된다. 웹 접근성이 제도와 관행 속에 비교적 일찍 자리잡은 데는, 이 점검 도구의 접근성도 한몫했다.

1-2. 앱은 그 자동화가 약하다

앱은 사정이 다르다. 앱의 의미는 HTML 텍스트가 아니라 컴파일된 화면 안에서 플랫폼 접근성 API를 통해 전달된다(077편). 외부에서 'HTML을 긁어 분석하듯' 앱 화면을 자동으로 훑기가 웹보다 까다롭다. 플랫폼이 검사 도구(예: 애플 Accessibility Inspector, 안드로이드 Accessibility Scanner)를 제공하기는 하지만, 이는 보통 개발 환경이나 실제 기기에서 앱을 실행한 상태로 작동한다. 웹처럼 'URL만 넣으면 검사되는' 방식과는 거리가 있다.

그래서 앱 점검은 웹보다 손이 더 간다. 기기에서 앱을 띄우고, 화면 낭독기를 켜고, 검사 도구를 연결하고, 화면을 하나씩 옮겨 가며 본다. 자동화로 한 번에 끝나는 부분이 적고, 사람이 직접 짚어야 하는 부분이 많다. 점검의 문턱이 높다는 것 — 이것이 앱을 사각지대로 미는 첫 번째 구조적 이유다.

점검 환경	웹	앱
의미 담는 곳	HTML·ARIA 텍스트	컴파일 화면·플랫폼 API
자동 검사	URL만 넣으면 검사	기기 실행 상태 필요
도구 예	브라우저 확장 다수	Inspector·Scanner
점검 문턱	낮음	높음(손품 多)

(관점) 앱의 의미가 '읽을 수 있는 텍스트 구조'에 담기지 않아 자동화가 약합니다. 이 문턱 차이가 앱을 사각지대로 미는 첫 번째 구조적 이유입니다.

2. 같은 기관, 다른 점검 수준

2-1. 웹은 챙기고 앱은 놓친다

관찰되는 한 가지 패턴은, 같은 기관이 운영하는 웹과 앱 사이에 점검 수준의 차이가 생긴다는 것이다. 기관의 웹사이트는 접근성 점검을 거치고 개선이 이뤄지는데, 같은 기관의 앱은 그만큼의 점검을 받지 못하는 경우가 있다. 웹 접근성은 제도와 관행 속에 비교적 또렷이 자리잡았지만, 앱 접근성은 상대적으로 뒤에 놓이는 현상이다.

이 차이는 사용자에게 그대로 전해진다. 화면 낭독기를 쓰는 사용자가 기관 웹에서는 무리 없이 신청을 끝냈는데, 같은 기관 앱에서는 레이블 없는 버튼에 막혀 멈추는 일이 생긴다. 같은 서비스, 같은 기관인데 매체에 따라 갈 수 있는 길과 막히는 길이 갈린다. 이 시리즈가 거듭 본 '완주의 멈춤'이, 이번엔 웹과 앱 사이의 격차로 나타난다.

2-2. 앱으로 옮겨 가는 사용자들

사각지대가 더 문제인 것은, 사용자가 점점 앱으로 옮겨 가기 때문이다. 공공 서비스의 알림, 신청, 인증이 앱을 중심으로 재편되는 흐름이 있다. 어떤 서비스는 앱이 주된 통로가 되고, 웹은 보조가 되기도 한다. 그렇다면 접근성의 무게중심도 앱으로 옮겨 가야 하는데, 점검의 무게중심은 여전히 웹에 머무는 어긋남이 생긴다.

이 어긋남은 시간이 갈수록 벌어질 수 있다. 사용자가 많이 쓰는 곳일수록 점검이 촘촘해야 하는데(이 시리즈가 거듭 둔 '권리·안전·빈도' 우선순위), 정작 사용 빈도가 높아지는 앱이 점검에서 뒤처진다면, 우선순위가 뒤집힌 셈이다.

어긋남	사용자 쪽	점검 쪽
무게중심	앱으로 이동	여전히 웹
빈도	앱이 주된 통로	앱이 뒤처짐
같은 기관	웹은 통과	앱은 막힘
결과	매체별 길/막힘 갈림	우선순위 역전

(관점) 많이 쓰는 곳일수록 점검이 촘촘해야 하는데, 빈도가 높아지는 앱이 뒤처지면 '권리·안전·빈도' 우선순위가 뒤집힌 셈입니다.

3. 사각지대가 만드는 전형적 결함

3-1. 레이블 없는 요소

앱이 점검을 덜 받을 때 가장 흔히 남는 결함은 '레이블 없는 요소'다. 아이콘만으로 된 버튼, 이미지로 만든 컨트롤에 접근성 레이블이 붙지 않으면, 화면 낭독기는 그것을 '버튼'이라고만 읽거나 아무 이름 없이 지나친다. 눈으로 보는 사용자에겐 명백한 '검색' 아이콘이, 낭독기 사용자에겐 정체불명의 요소가 된다. 077편이 말한 '같은 대체 텍스트 개념이 다른 자리에서 작동한다'는 것의 뒷면이다 — 그 자리를 비워 두면 웹의 alt 누락과 똑같은 벽이 앱에 생긴다.

3-2. 읽는 순서와 초점의 엉킴

또 하나 흔한 결함은 읽는 순서와 초점의 엉킴이다. 화면 낭독기는 요소를 일정한 순서로 읽어 나가는데, 그 순서가 화면의 논리적 흐름과 어긋나면 사용자는 길을 잃는다. 위에서 아래로 읽혀야 할 화면이 갑자기 구석으로 튀거나, 떠 있는 팝업을 건너뛰고 뒤 배경을 읽는 식이다. 이 시리즈의 키보드 편(047~049)이 말한 '초점이 보여야 하고, 순서가 논리적이어야 한다'는 원리가, 앱에서는 낭독기 초점의 순서 문제로 다시 나타난다. 점검을 거치지 않으면 이런 엉킴이 그대로 남는다.

전형 결함	눈으로 볼 때	낭독기로 들을 때
레이블 없는 버튼	명백한 검색 아이콘	"버튼"·정체불명
읽는 순서 엉킴	위→아래 자연스러움	구석으로 튐
초점 엉킴	팝업이 또렷이 보임	배경부터 읽힘
대안 없는 제스처	끌기로 조작	실행 경로 없음

(인용) 077편의 '대체 텍스트 개념이 다른 자리에서 작동한다'의 뒷면 — 그 자리를 비우면 웹의 alt 누락과 똑같은 벽이 앱에 생깁니다(047~049편).

4. 사각지대를 줄이려면

4-1. 점검을 웹과 앱 양쪽으로

사각지대를 줄이는 출발점은 단순하다. 점검의 범위에 앱을 함께 넣는 것이다. 기관이 웹과 앱을 같이 운영한다면, 접근성 점검도 두 매체를 함께 보는 것이 자연스럽다. 웹만 점검하고 앱을 빼면, 사용자가 실제로 더 자주 쓰는 통로가 점검 밖에 놓인다. '사용자가 거치는 경로 전체'를 본다는 원칙(073편의 검사 범위)은 매체를 가로질러서도 적용된다.

4-2. 자동화가 약한 만큼, 사람의 점검으로

앱은 자동 점검이 약한 만큼, 사람이 직접 빌려 보는 점검이 더 중요해진다. 070편이 말한 '조건을 빌려 보기'가 앱에서는 플랫폼 낭독기와 시스템 설정을 켜 보는 일로 나타난다. 도구가 한 번에 끝내 주지 않으니, 화면 낭독기를 켜고 직접 화면을 넘겨 보며 레이블·순서·대안을 확인하는 손품이 필요하다. 그 구체적인 방법은 다음 편에서 정리한다.

사각지대 줄이기	무엇을	근거
범위에 앱 포함	웹·앱 함께 점검	경로 전체(073편)
사람 점검 강화	낭독기·설정 켜 보기	조건 빌리기(070편)
빈도 반영	많이 쓰는 통로 우선	권리·안전·빈도
방법 학습	앱 점검법 익히기	079편에서

(관점) 자동화가 한 번에 끝내 주지 않으니, 화면 낭독기를 켜고 직접 넘겨 보며 레이블·순서·대안을 확인하는 손품 — 그 구체적 방법은 다음 편(079)에서 정리합니다.

한 장 요약

관찰	웹과의 차이	왜 사각지대인가
점검 도구	웹은 자동 점검 풍부	앱은 자동화 약해 손품 필요
점검 수준	웹은 챙기고 앱은 놓침	제도·관행이 웹 중심
사용 흐름	사용자가 앱으로 이동	빈도 높은데 점검은 뒤처짐
전형 결함	레이블·순서·초점 엉킴	점검 없으면 그대로 남음

※ 위 표는 관찰의 정리입니다. 앱·웹 점검 환경의 차이는 도구·플랫폼에 따라 다르며, 본문은 일반화된 관점입니다.

맺으며

앱 접근성이 사각지대에 놓이는 것은, 앱이 덜 중요해서가 아니다. 사용자는 점점 앱으로 공공 서비스에 닿는데, 접근성 진단의 도구와 관행은 여전히 웹에 무게가 실려 있다. 웹은 자동 점검 도구가 풍부해 점검의 문턱이 낮지만, 앱은 자동화가 약해 사람이 직접 짚어야 할 부분이 많다. 그 문턱의 차이가, 같은 기관의 서비스라도 앱 쪽 접근성을 뒤처지게 만든다.

그 결과 레이블 없는 요소, 엉킨 읽는 순서, 튀는 초점 같은 전형적 결함이 앱에 남는다. 모두 웹에서라면 점검 도구가 1차로 잡아냈을 문제들이다. 사각지대를 줄이는 길은 점검의 범위에 앱을 함께 넣고, 자동화가 약한 만큼 사람이 직접 빌려 보는 점검을 더하는 것이다. 다음 편에서는 그 '직접 빌려 보는 점검' — 화면 낭독기와 시스템 설정을 켜고 앱을 스스로 살피는 방법을 정리한다.

다음 편 예고 (079): 〈앱은 어떻게 점검하나〉 — 앱 접근성 점검 관점. 화면 낭독기(VoiceOver/TalkBack)와 제스처·초점 순서를 빌려, 앱을 스스로 점검하는 방법을 정리한다.

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

한국지능정보사회진흥원(NIA), 「모바일 애플리케이션 접근성」 실태·지침 관련 자료
애플·구글 플랫폼 접근성 검사 도구(Accessibility Inspector / Scanner) 공개 문서
「장애인차별금지 및 권리구제 등에 관한 법률」 정보접근 관련 조항
이 시리즈 저시력·키보드 연구 편(점검 관점)의 정리

※ 위 자료의 항목·기준은 개정에 따라 달라질 수 있으며, 본문의 관찰은 일반화된 연구 관점의 재구성입니다. 정확한 적용 기준은 각 출처의 원문 확인이 안전합니다.