개념
이 레슨의 경계선
WCAG 성공 기준 자체는 모듈 49 레슨 5, 데스크톱 스크린 리더(NVDA) 조작과 검증 시나리오는 모듈 49 레슨 6에서 이미 다뤘다. 이 레슨은 그 둘을 반복하지 않고, 모바일 플랫폼에만 있는 것 — 터치 제스처 체계, 플랫폼 접근성 API와 도구, 터치 대상 크기, 동적 글꼴 크기, 회전·확대 — 만 다룬다. 기준을 판정하는 사고방식이 필요하면 레슨 5로, 스크린 리더로 화면을 읽어 나가는 감각이 필요하면 레슨 6으로 먼저 돌아간다.
모바일이 별도 레슨을 갖는 이유는 간단하다. 데스크톱 스크린 리더는 키보드 위에서 동작하지만 모바일은 터치 제스처가 통째로 바뀐 세계 위에서 동작한다. TalkBack을 켜는 순간 한 번 탭하면 선택만 되고 두 번 탭해야 눌린다. 이 차이가 검증 절차 전체를 바꾼다.
TalkBack — 제스처 체계부터 익힌다
Android의 기본 스크린 리더다. 켜기 전에 반드시 끄는 법 을 먼저 익힌다 — 설정에서 끄거나 접근성 단축키(양쪽 볼륨 키 길게 누르기)를 미리 켜 둔다. 모르고 켰다가 기기를 못 다루는 것이 첫 실습의 단골 사고다. 핵심 제스처는 공식 문서 기준으로 이렇다.
| 동작 | 제스처 |
|---|---|
| 다음 항목 / 이전 항목 | 오른쪽으로 쓸기 / 왼쪽으로 쓸기 |
| 선택한 항목 실행 | 두 번 탭 |
| 화면 탐색(터치해서 탐색) | 손가락을 화면에 대고 끌면 닿는 항목을 읽어 준다 |
| 스크롤 | 두 손가락으로 쓸기 |
| 읽기 제어(다음/이전) | 위로 쓸고 아래로 / 아래로 쓸고 위로 |
| TalkBack 메뉴 | 세 손가락 탭(멀티터치 지원 기기), 구형 기기는 아래로 쓴 뒤 오른쪽으로 |
문서가 말하는 핵심 원칙 하나를 기억한다. TalkBack이 켜지면 대부분의 한 손가락 제스처가 두 손가락 제스처로 바뀐다. 스크롤이 두 손가락인 이유가 그것이다. 이 원칙을 알면 "스크롤이 안 돼요"라는 오해를 하지 않는다.
읽기 제어(reading controls) 가 검증에 특히 유용하다. 위·아래 쓸기로 읽기 단위를 제목·링크·컨트롤 등으로 바꿔 가며 탐색할 수 있어 제목만 훑어 구조를 확인하거나 컨트롤만 순회해 조작 가능한 요소를 세는 작업이 빨라진다. 데스크톱의 단일 문자 탐색(모듈 49 레슨 6)에 대응하는 기능이다.
VoiceOver — 같은 목적, 다른 손가락
iOS의 기본 스크린 리더다. 이동·실행의 기본은 TalkBack과 닮았지만 손가락 개수와 특수 제스처가 다르다.
| 동작 | 제스처 |
|---|---|
| 다음 항목 / 이전 항목 | 오른쪽으로 쓸기 / 왼쪽으로 쓸기 |
| 선택한 항목 실행 | 두 번 탭 |
| 페이지 스크롤 | 세 손가락 으로 쓸기 |
| 뒤로 가기 · 취소 | 두 손가락 스크럽 (두 손가락으로 빠르게 좌우로 Z 모양 그리기) |
| 설정·탐색 단위 변경 | 로터(rotor) — 두 손가락을 다이얼 돌리듯 회전 |
여기서 QA가 반드시 챙길 두 가지가 있다.
- 두 손가락 스크럽이 동작하는가. iOS 사용자에게 이것은 "뒤로 가기"다. 커스텀 화면·모달에서 먹지 않으면 사용자가 빠져나갈 길을 잃는다
- 로터에 필요한 항목이 있는가. 로터는 제목·링크 같은 탐색 단위를 제공하는데, 앱이 역할을 제대로 노출하지 않으면 목록 자체가 빈다. 로터가 비어 있다 = 구조 정보가 없다 는 진단 신호다
두 스크린 리더의 결과가 다르면 둘 다 적는다. 같은 화면이 TalkBack에서는 읽히고 VoiceOver에서는 안 읽히는 일은 흔하다. 구현이 플랫폼별로 갈리기 때문이다. 리포트에는 항상 플랫폼·OS 버전·스크린 리더 버전 을 함께 적는다.
스크린 리더보다 먼저 — 도구로 트리를 본다
사람이 듣기 전에 기계가 먼저 볼 수 있는 것이 많다. 순서를 이렇게 잡으면 시간이 절약된다.
Android
- Accessibility Scanner — 화면을 한 장 찍듯 검사해 레이블 누락, 터치 대상 크기 부족, 명암비 부족, 항목 겹침을 한 번에 지적한다. 1차 훑기 로 쓴다
- 접근성 서비스(accessibility service) — TalkBack도 이 구조 위에서 돈다. 앱이 각 뷰에
contentDescription·역할·상태를 노출하면 접근성 서비스가 그 트리를 받아 읽는다. 즉 화면에 그려진 것이 아니라 앱이 노출한 것 이 읽힌다 — "보이는데 안 읽힌다"의 원인은 거의 항상 여기다 adb로 트리를 덤프해 눈으로 확인할 수도 있다
# 현재 화면의 UI 트리를 XML로 덤프해서 본다 (content-desc 채워졌는지 확인)
adb shell uiautomator dump /sdcard/ui.xml && adb pull /sdcard/ui.xml
grep -o 'content-desc="[^"]*"' ui.xml | sort | uniq -c | sort -rn | head -20빈 content-desc 가 많은 화면이 곧 결함 후보다. 레슨 5에서 본 것처럼 접근성 레이블은 자동화 로케이터와 같은 자산 이라, 이 결과는 자동화 팀에도 그대로 쓸모가 있다.
iOS
- Accessibility Inspector(Xcode 포함) — 시뮬레이터나 연결된 기기의 요소를 선택해 레이블·값·traits·힌트 를 직접 확인하고, 감사(audit) 기능으로 대비·터치 대상·레이블 누락을 한 번에 점검한다
- Inspector에 보이는 값이 곧 VoiceOver가 읽을 값이라 "왜 이렇게 읽히지?"의 답이 여기 있다
레이블·traits·포커스 순서 — 플랫폼 API 수준에서 본다
판정 기준을 API 이름으로 쥐고 있어야 개발자와 대화가 된다.
| 검증 항목 | Android | iOS | 무엇이 잘못되면 결함인가 |
|---|---|---|---|
| 이름(레이블) | contentDescription | accessibilityLabel | 아이콘 버튼이 "버튼"으로만 읽힘, 파일명이 읽힘, 장식 이미지가 읽힘 |
| 역할·상태 | 위젯 종류와 상태 정보 | accessibilityTraits | 버튼인데 traits가 없어 "실행 가능"이 안 알려짐, 선택 상태가 안 읽힘 |
| 값 | 위젯의 값 | accessibilityValue | 슬라이더·스위치의 현재 값이 안 읽힘 |
| 추가 설명 | 도움말 텍스트 | accessibilityHint | 힌트에 이름이 중복돼 두 번 읽힘 |
| 포커스 순서 | 뷰 계층과 순회 순서 | accessibilityElements 순서 | 시각적 순서와 낭독 순서가 다름 |
| 장식 요소 제외 | 중요도를 "아니오"로 | isAccessibilityElement = false | 의미 없는 구분선·배경이 하나하나 읽힘 |
| 묶기 | 컨테이너 단위 노출 | 컨테이너를 하나의 요소로 | 카드 하나가 7개 조각으로 쪼개져 읽힘 |
마지막 두 행이 모바일에서 특히 많이 터진다. 목록 카드 하나가 이미지·제목·부제·가격·배지로 쪼개져 각각 포커스를 받으면, 화면상 멀쩡해도 항목 하나를 넘기는 데 다섯 번을 쓸어야 한다. "카드 하나 = 포커스 하나 = 한 번의 낭독" 이 되어야 하는지 제품팀과 합의하고 검증한다.
포커스 순서 판정은 단순하다. 맨 위 왼쪽에서 시작해 오른쪽으로 계속 쓸며 끝까지 간 뒤 낭독된 순서를 그대로 적는다. 그 목록이 시각적 순서와 다르거나, 화면 밖 요소가 끼거나, 닫힌 모달 뒤의 요소가 읽히면 결함이다. 모달·바텀시트가 떴을 때 뒤 화면으로 포커스가 새는지 는 반드시 본다 — 모바일에서 가장 흔한 포커스 결함이다.
터치 대상 최소 크기
수치가 플랫폼마다 다르고, 둘 다 알아야 한다.
- Material Design(Android) — 터치 대상은 최소 48 × 48dp. 문서는 이 크기가 화면 크기와 무관하게 물리적으로 약 9mm에 해당한다고 설명한다
- Apple Human Interface Guidelines(iOS) — 모든 컨트롤의 최소 탭 영역 44 × 44pt
두 문서가 공통으로 강조하는 것이 더 중요하다. 터치 대상은 그려진 모양보다 클 수 있다. 아이콘이 24 × 24dp로 보여도 주변 패딩을 포함해 48 × 48dp의 터치 영역을 가지면 기준을 만족한다. 그래서 눈으로 보고 "작다"고 판정하면 안 되고, Accessibility Scanner·Accessibility Inspector로 실제 영역을 확인하거나 개발자에게 히트 영역을 물어야 한다.
자주 놓치는 지점 세 가지.
- 간격. 크기를 만족해도 대상끼리 붙어 있으면 오탭이 난다. "삭제"와 "수정"이 나란히 붙은 목록이 전형이다
- 텍스트 링크. 본문 중간의 링크는 높이가 글자 높이뿐이라 기준 미달이기 쉽다
- 작은 화면 + 큰 글꼴. 글꼴을 키우면 버튼이 밀려 터치 영역이 잘린다 — 바로 다음 주제다
WCAG의 대상 크기 성공 기준은 별도 수치를 쓴다. 기준 판정은 모듈 49 레슨 5를 따르고, 여기서는 플랫폼 디자인 가이드 수치를 제품 기준으로 쓴다 는 점만 구분한다.
동적 글꼴 크기와 레이아웃 붕괴
사용자는 시스템 설정에서 글꼴을 키운다. iOS에서는 Dynamic Type, Android에서는 글꼴 크기·화면 크기 설정이다. 이 설정은 실제 사용률이 매우 높은 접근성 기능 이고, 동시에 가장 자주 레이아웃을 깨뜨리는 기능이다.
검증 절차를 고정한다.
1. 기본 배율에서 화면을 캡처한다 (기준선)
2. 설정에서 글꼴 크기를 최대로 올린다
- iOS: 설정 → 손쉬운 사용 → 디스플레이 및 텍스트 크기 → 더 큰 텍스트(더 큰 손쉬운 사용 크기 켜기)
- Android: 설정 → 접근성 → 글꼴 크기 / 화면 크기
3. 같은 화면들을 다시 돌며 확인한다
- 글자가 잘리는가(말줄임이 아니라 물리적 잘림)
- 버튼 안의 글자가 버튼 밖으로 나가는가
- 두 줄이 되어야 할 텍스트가 한 줄로 눌려 겹치는가
- 하단 고정 버튼이 화면 밖으로 밀려 누를 수 없게 되는가
- 스크롤이 생겨야 하는데 생기지 않는가
4. 가로 모드에서 2~3을 반복한다
5. 글꼴 최대 + 화면 확대(디스플레이 크기) 조합에서 한 번 더 한다4번 조합에서 결함이 쏟아진다. 세로 기준으로만 만든 화면은 가로에서 여백이 사라지는데, 거기에 큰 글꼴이 겹치면 확인 버튼이 화면 밖으로 밀려 진행이 불가능해지는 상태가 만들어진다. 접근성 결함이면서 동시에 기능 차단(blocker)이다.
화면 회전 도 별도 검증 항목이다. 회전 시 입력 중이던 값이 유지되는지, 포커스가 어디로 가는지, 스크린 리더가 화면 변경을 알리는지를 본다. 회전을 막아 둔 앱이라면 그 결정이 의도된 것인지 확인한다 — 화면 고정은 특정 사용자에게 장벽이 된다. 화면 확대(돋보기) 상태에서 고정 요소가 화면을 가리는지, 가로 스크롤이 생겨 읽기가 불가능해지는지도 함께 본다.
결함 리포트 — 낭독된 문자열을 그대로 인용한다
모듈 49 레슨 6의 원칙을 모바일 형식으로 옮긴다. 달라지는 것은 제스처와 플랫폼 정보 가 들어간다는 점이다.
제목: [접근성] 주문 목록 카드가 5개 요소로 쪼개져 낭독됨 (TalkBack)
환경: Galaxy S23 / Android 14 / TalkBack (버전 기재)
재현: 주문 내역 탭 진입 → 오른쪽으로 쓸기 반복
낭독된 순서: "이미지" → "치킨" → "2026년 9월 20일" → "18,000" → "배송완료"
기대: 카드 하나가 한 번에 "치킨, 18,000원, 배송완료, 2026년 9월 20일, 버튼" 으로 읽힘
영향: 항목 하나를 지나는 데 5회 스와이프. 20개 목록이면 100회
관련 API: 카드 컨테이너를 하나의 접근성 요소로 묶고 장식 이미지는 제외"이미지"처럼 실제 낭독된 문자열을 따옴표로 그대로 적는 것이 핵심이다. 개발자가 어느 뷰인지 바로 찾는다.
실무에서 왜 필요한가
국내 공공기관 앱과 금융 앱은 접근성이 계약 조건이거나 감리 항목 인 경우가 많다. 그런데 대부분의 팀은 웹 점검 도구만 돌리고 앱은 손을 놓는다. 자동 검사의 범위가 좁고 나머지는 사람이 직접 통과시켜 봐야 하기 때문이다. 그 일을 할 수 있는 사람이 팀에 한 명 있느냐로 결과가 갈린다.
실무적으로 더 큰 이유는 접근성 결함의 상당수가 일반 사용자에게도 결함이라는 점 이다. 글꼴을 키웠더니 확인 버튼이 화면 밖으로 나가는 문제는 시력이 약한 사용자만의 문제가 아니라 큰 글꼴을 쓰는 모든 사용자의 문제다. 터치 대상이 붙어 있어 오탭이 나는 문제도 마찬가지다. 접근성 검증을 돌리면 일반 UX 결함이 덤으로 쏟아진다 — 이 논리가 접근성 작업을 팀에 설득하는 가장 현실적인 근거다.
채용시장에서의 위치
모바일 접근성을 실제로 검증해 본 QA는 드물다. 그래서 "TalkBack으로 결제 플로우를 끝까지 통과시켜 봤고, 카드 묶기와 포커스 누수 결함을 이렇게 보고했다"는 한 문단이 면접에서 눈에 띈다. 공공·금융 앱 조직에서는 이 경험이 곧 채용 사유가 되기도 한다. 도구 이름과 수치(48dp / 44pt), 자동 검사가 못 잡는 영역까지 말할 수 있으면 준비가 끝난 것이다.