로그인

모바일 앱 접근성: iOS 및 Android를 위한 WCAG 2.2 요구 사항

13 min read
모바일Ios안드로이드

WCAG 2.2는 웹사이트를 훨씬 넘어 확장됩니다. 그 성공 기준은 터치 대상, 인증, 제스처, 포커스 가시성을 포괄하며, 네이티브 iOS 및 Android 앱에도 직접적으로 적용됩니다. 이 가이드는 모든 관련 요구 사항을 하나하나 분해하고, 각 플랫폼이 이를 어떻게 구현하는지, 그리고 준수와 포용성을 유지하기 위해 여러분의 팀이 무엇을 해야 하는지를 설명합니다.

장애가 있는 성인 중 72% 이상이 스마트폰을 보유하고 있으며, 한 설문조사에 따르면 화면 읽기 프로그램 사용자 중 약 86%가 데스크톱이나 노트북보다 모바일 기기에 더 많이 의존하고 있습니다. 그럼에도 불구하고 웹사이트는 꼼꼼하게 접근성 감사를 받으면서, 정작 모바일 앱은 단 하나의 접근성 기준으로도 테스트된 적이 없는 조직이 여전히 많습니다. 이 격차는 빠르게 줄어들고 있습니다. 변화하는 규제, 증가하는 소송, 그리고 무엇보다도 W3C가 WCAG 2.2를 네이티브 iOS 및 Android 애플리케이션에 명시적으로 매핑한 자체 가이드가 그 동력이 되고 있습니다.

WCAG 2.2가 귀사의 모바일 앱에 적용되는 이유

WCAG는 웹에만 적용되는 표준이라는 지속적인 오해가 있습니다. 사실이 아닙니다. W3C는 모바일 접근성을 위한 별도의 가이드라인을 두고 있지 않습니다. 대신 모바일 접근성은 기존 WCAG 프레임워크 안에서 다루어지며, W3C의 Mobile Accessibility Task Force(MATF)는 Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile)이라는 전용 가이드를 발행해 모든 A 및 AA 레벨 성공 기준을 네이티브 모바일 앱, 모바일 웹 앱, 하이브리드 앱에 매핑했습니다.

실무적인 함의는 매우 큽니다. WCAG 성공 기준에서 "웹 페이지"라는 표현을 읽게 되면, WCAG2Mobile 문서는 그 표현을 "화면(screen)" 또는 "뷰(view)"로 대체합니다. 기준에서 "사용자 에이전트(user agent)"를 언급할 때는 모바일 운영체제를 의미합니다. 네 가지 POUR 원칙 — 인지 가능(Perceivable), 운용 가능(Operable), 이해 가능(Understandable), 견고(Robust) — 은 iOS의 SwiftUI 뷰나 Android의 Jetpack Compose 레이아웃에서 사용자가 상호작용하는 방식에 그대로 대응됩니다.

법적 관점에서 보면, 압박은 더 이상 이론적인 수준이 아닙니다. ADA 제2편(Title II) 하에서, 2024년 4월에 발표된 개정 DOJ 규정은 주 및 지방 정부가 자사의 모바일 애플리케이션을 WCAG 2.1 AA 수준에 맞게 접근 가능하게 만들 것을 명시적으로 요구합니다. Medicare 또는 Medicaid를 받는 의료 기관도 2024년 5월에 최종 확정된 HHS 규정에 따라 유사한 요구사항을 따르게 됩니다. 민간 부문 모바일 앱에 대한 소송은 아직 웹사이트에 비해 빈도가 낮지만, 최소 한 명의 다수 소송 제기 원고가 ADA에 따른 공정한 접근성 부족을 이유로 모바일 애플리케이션을 구체적으로 겨냥한 바 있으며, 제2편 준수 기한이 2026년에 도래함에 따라 이러한 추세는 가속화될 것으로 예상됩니다.

2025년 6월 28일 발효된 유럽 접근성법(EAA)은 기술 표준으로 EN 301 549를 전제로 하며, EU 시장에서 판매되거나 제공되는 모바일 앱을 포함한 디지털 제품 및 서비스에 대해 WCAG 2.2 준수를 요구합니다. 글로벌 사용자 기반을 가진 조직이라면, 모바일에서의 WCAG 2.2는 미래의 목표가 아니라 현재의 의무입니다.

모바일에 특히 중요한 WCAG 2.2의 변화 사항

2023년 10월 W3C 권고안으로 발표된 WCAG 2.2는 9개의 새로운 성공 기준을 추가하고, 이제는 구식이 된 4.1.1 Parsing을 제거했습니다. 2.2는 완전히 하위 호환되며, 2.2에 적합하다는 것은 2.1과 2.0에도 적합함을 의미합니다. 새 기준 중 상당수는 모바일 상호작용 패턴을 명시적으로 염두에 두고 작성되었으며, 키보드 사용을 중심으로 서술된 기준조차 iOS와 Android의 보조 기술에서 직접적인 유사점을 찾을 수 있습니다.

여기에는 나름의 계보가 있습니다. 2018년 이후 Mobile Accessibility Task Force는 모바일 고려사항이 WCAG 2.1과 2.2 모두를 형성하도록 했습니다. 1.3.4 Orientation (AA), 1.4.10 Reflow (AA), 2.5.1 Pointer Gestures (A), 2.5.4 Motion Actuation (A), 그리고 새로 추가된 2.5.7 Dragging Movements (AA), 2.5.8 Target Size Minimum (AA), 3.3.7 Redundant Entry (A) 같은 기준은 모두 스마트폰과 태블릿에서 장애가 있는 사용자와의 실제 테스트를 통해 확인된 특정 모바일 사용성 패턴을 반영합니다.

WCAG 2.2에서 새로 도입된 9개의 성공 기준은 실제 사용자가 겪는 구체적인 장벽을 겨냥합니다. 기억력에 문제가 있는 사람에게 불리한 로그인 흐름, 정교한 탭을 요구하는 인터페이스, 화면마다 다른 위치에 묻혀 있는 도움말 기능, 고정 내비게이션 바 뒤로 사라지는 포커스 표시 등입니다. 각 기준은 구체적인 구멍을 메우며 — 거의 모든 기준이 모바일에 직접 적용됩니다.

새로운 WCAG 2.2 기준과 iOS 및 Android에의 적용 방식

2.5.8 Target Size Minimum (Level AA)

이 기준은 모바일 팀에 가장 큰 영향을 미치는 새 기준이라고 해도 과언이 아닙니다. 버튼, 링크, 폼 필드, 체크박스, 토글 등 인터랙티브 타깃은 최소 24 × 24 CSS 픽셀 크기를 가져야 하며, 타깃 자체가 더 작다면 인접 타깃 사이에 24픽셀의 간격 오프셋이 있어야 합니다. 이유는 명확합니다. 손 떨림, 파킨슨병, 제한된 손동작을 가진 사용자는 16픽셀 아이콘 버튼을 안정적으로 누르는 것이 사실상 불가능하며, 장애가 없는 사용자조차 작은 타깃에서 오류를 훨씬 더 많이 발생시킵니다.

네이티브 모바일 개발에서 WCAG 2.2의 24 × 24 최소값은 상한이 아니라 하한입니다. Apple의 Human Interface Guidelines는 iOS 및 iPadOS에서 최소 터치 타깃을 44 × 44 포인트로 권장합니다. Google의 Material Design은 Android에서 48 × 48 밀도 독립 픽셀(dp)을 권장합니다. 앱이 Apple 또는 Google의 플랫폼 가이드를 충족한다면 이미 WCAG 2.2 최소값을 초과하고 있는 셈이지만, 실제로는 그렇지 않은 앱이 많습니다. 모달 시트의 아주 작은 닫기 버튼, 설정 화면의 가느다란 체크박스, 20 × 20 dp 크기의 아이콘 전용 툴바 액션 등은 모두 감사에서 드러나기만을 기다리는 준수 실패 사례입니다.

실무적인 참고 사항: WCAG의 요구사항은 아이콘의 시각적 크기가 아니라 인터랙티브 히트 영역에 관한 것입니다. 16포인트 아이콘에 각 방향으로 14포인트의 패딩을 감싸면 실질적인 탭 타깃은 44 × 44 포인트가 됩니다. 즉, 개발자는 요소를 시각적으로 키우지 않고도 이 기준을 충족할 수 있지만, 시스템이 자동으로 처리해 줄 것이라고 기대하지 말고 의도적으로 패딩을 설정해야 합니다.

2.5.7 Dragging Movements (Level AA)

이 기준은 슬라이더, 드래그 앤 드롭 재정렬, 당겨서 새로고침, 캐러셀 스크러빙 등 드래그 제스처로 구현된 모든 기능이 드래그를 요구하지 않는 단일 포인터 동작으로도 수행 가능해야 한다고 요구합니다. iOS와 Android에서 플랫폼 자체 보조 기술이 일부 제스처를 다르게 처리하기도 하지만, 앱이 구현한 모든 커스텀 드래그 동작에 대해 비드래그 대안을 제공하는 책임은 앱에 있습니다.

실제로는, 드래그로 재정렬하는 리스트는 "위/아래" 스테퍼 버튼 같은 대안을 제공해야 합니다. 드래그 제스처에만 반응하는 커스텀 범위 슬라이더는 특정 지점을 탭해도 반응하거나 증감 버튼을 제공해야 합니다. 기준은 기본 OS나 보조 기술이 자동으로 대안을 제공하는 경우에는 적용되지 않지만, 개발자는 항상 자동으로 처리될 것이라고 가정하지 말고 이를 명시적으로 테스트해야 합니다.

2.4.11 Focus Not Obscured — Minimum (Level AA) 및 2.4.12 (Enhanced, Level AAA)

이 기준은 웹과 네이티브 모바일 앱 모두에서 매우 흔한 패턴을 다룹니다. 포커스를 받은 요소가 고정 UI — 지속적인 하단 내비게이션 바, 플로팅 액션 버튼, 스크롤 영역을 덮는 상단 툴바 — 에 의해 부분적으로 또는 완전히 가려지는 경우입니다. 최소 기준(AA 레벨)은 구성 요소가 포커스를 받을 때 적어도 일부는 화면에 보이도록 요구합니다. 향상된 버전(AAA 레벨)은 포커스를 받은 구성 요소 전체가 보여야 합니다.

네이티브 모바일에서 "키보드 포커스"는 Switch Control 또는 Switch Access, iOS 15+의 Full Keyboard Access, Voice Control/Access에서 사용하는 포커스 링을 폭넓게 포함하는 개념으로 해석됩니다. Switch Control 스윕 중에 포커스된 요소가 하단 내비게이션 바 아래로 미끄러져 들어간다면 물리적 키보드가 전혀 없더라도 이 기준을 위반하는 것입니다. 앱 UI는 개발자가 만든 오버레이, 고정 바, 일시적인 표면으로 포커스된 컨트롤을 가리지 않도록 설계해야 합니다.

2.4.13 Focus Appearance (Level AA)

이 기준은 포커스 표시의 시각적 특성에 대한 최소 요구사항을 설정합니다. 포커스 표시 영역은 구성 요소 둘레 × 2 CSS 픽셀에 해당하는 최소 면적을 가져야 하며, 인접 색상과 최소 3:1의 명도 대비를 가져야 합니다. 네이티브 모바일 플랫폼에서 VoiceOver와 TalkBack의 포커스 링은 운영체제가 제어하며, 개발자가 그 모양을 변경할 수 없습니다. 따라서 일반적으로 이 기준에 대해서는 예외가 인정됩니다. 다만 앱 스타일링이 반투명 스크림을 포커스된 컨트롤 위에 덮는 등 포커스 가시성을 적극적으로 떨어뜨려서는 안 됩니다.

3.3.8 Accessible Authentication — Minimum (Level A)

이 기준은 인지적 접근성 측면에서 큰 진전입니다. 인증 과정이 인지 기능 테스트에만 의존해서는 안 된다는 요구사항입니다. 즉, 앱이 접근 가능한 대안을 제공하지 않는 한 사용자가 비밀번호를 암기하거나, 퍼즐을 풀거나, CAPTCHA를 옮겨 적도록 요구해서는 안 됩니다. iOS에서는 사용자가 자격 증명을 외우지 않고도 인증할 수 있도록 Apple의 Keychain과 Sign in with Apple을 지원해야 합니다. Android에서는 Google의 Autofill 프레임워크, 생체 인증을 지원하고, 서드파티 비밀번호 관리자의 사용을 차단해서는 안 됩니다.

좀 더 구체적으로 말하면, 앱이 비밀번호 필드에서 붙여넣기 동작을 차단한다면 3.3.8을 준수하지 않을 가능성이 큽니다. 2단계 인증 흐름에서 알림에 표시된 OTP 코드를 복사-붙여넣기 방식 없이 사용자가 직접 입력하도록 요구한다면 불필요한 인지적 부담을 초래합니다. Android의 Messages 앱이 이미 OTP 알림에 "코드 복사" 버튼을 제공하는 이유가 바로 이 기준의 취지와 맞닿아 있습니다.

핵심 인사이트: 생체 인증(Face ID, Touch ID, Android Biometric API) 지원은 단순한 UX 향상을 넘어, 비밀번호를 안정적으로 기억할 수 없는 인지 장애 사용자를 위한 WCAG 2.2 준수 메커니즘입니다.

3.3.7 Redundant Entry (Level A)

앱의 다중 화면 흐름 — 결제, 온보딩, 의료 문진 폼 등 — 에서 사용자가 동일한 정보를 두 번 이상 입력해야 하는 경우, 이전에 입력한 값을 자동으로 채워 넣거나 이전 입력값을 선택할 수 있는 방법을 제공해야 합니다. 이 기준은 네이티브 모바일 앱에 직접적으로 적용됩니다. 대표적인 실패 사례는 배송 주소 폼에서 나중에 청구 주소를 다시 묻지만 "배송지와 동일" 옵션이 없어, 운동 장애나 인지 장애가 있는 사용자가 동일한 텍스트를 여러 번 다시 입력해야 하는 경우입니다.

3.2.6 Consistent Help (Level A)

앱이 도움말 메커니즘 — 지원 채팅 버튼, 도움말 아이콘, "문의하기" 링크 — 을 제공한다면, 앱 내 모든 화면에서 일관된 위치에 나타나야 합니다. 인지 장애가 있는 사용자는 내비게이션과 지원 메커니즘의 예측 가능한 위치에 의존합니다. 일부 화면에서는 헤더에, 다른 화면에서는 탭 바에, 또 어떤 흐름에서는 설정 메뉴 안에 도움말 버튼을 숨겨두는 방식은 이 기준을 위반합니다.

여전히 모바일에 중요하게 남아 있는 WCAG 2.1 기준

새로운 WCAG 2.2 기준이 대부분의 주목을 받지만, 모바일을 염두에 두고 도입된 여러 WCAG 2.1 요구사항은 여전히 네이티브 앱에서 자주 실패하고 있으며, 감사 시 준수 담당자가 간과해서는 안 됩니다.

1.3.4 Orientation (AA)는 콘텐츠 기능에 필수적인 경우가 아니라면 앱을 세로 또는 가로 방향으로 고정하는 것을 금지합니다. 많은 앱이 온보딩 흐름이나 인앱 동영상 플레이어에서 정당한 이유 없이 세로 방향으로 고정합니다. 이는 회전이 어려운 휠체어 장착 기기를 사용하는 사용자에게 특히 큰 영향을 미칩니다. 1.4.10 Reflow (AA)는 콘텐츠가 320 CSS 픽셀 너비(400% 확대에 해당)로 표시될 때 가로 스크롤 없이도 표시될 수 있어야 한다고 요구합니다. 모바일 관점에서는 Dynamic Type과 시스템 텍스트 크기 확대를 지원하면서 레이아웃이 깨지거나 콘텐츠가 잘리지 않도록 해야 한다는 의미입니다.

2.5.1 Pointer Gestures (A)는 멀티포인트 또는 경로 기반 제스처 — 핀치 투 줌, 두 손가락 스와이프 등 — 를 사용하는 모든 기능에 단일 포인터 대안을 제공해야 한다고 요구합니다. 2.5.4 Motion Actuation (A)는 기기를 흔들거나 기울이는 동작으로 트리거되는 기능이 표준 UI 컨트롤로도 조작 가능해야 하며, 사용자가 우발적인 활성화를 피하기 위해 모션 기반 트리거를 비활성화할 수 있어야 한다고 요구합니다.

시각적 표현 측면에서 1.4.3 Contrast Minimum (AA)은 일반 텍스트에 최소 4.5:1, 큰 텍스트에 3:1의 명도 대비를 요구합니다. 입력 필드의 플레이스홀더 텍스트, 비활성 버튼 레이블, 사진 배경 위의 텍스트 등에서 이 최소 기준을 충족하지 못하는 앱이 여전히 많습니다. 개발자는 모든 카피, 컨트롤, 콘텐츠가 iOS와 Android에서 Dynamic Type, Bold Text, 다크 모드, 시스템 수준 대비 옵션과 함께 잘 동작하는지 확인해야 합니다.

플랫폼별 구현 가이드

iOS와 SwiftUI / UIKit

Apple은 UIAccessibility API와 SwiftUI의 접근성 모디파이어를 통해 광범위한 네이티브 접근성 지원을 제공합니다. VoiceOver 지원을 위해 모든 인터랙티브 요소는 의미 있는 접근성 레이블, 힌트, 값을 가져야 합니다. 표준 UIKit 구성 요소를 상속하지 않는 커스텀 컨트롤은 VoiceOver가 올바르게 안내할 수 있도록 .isButton, .isHeader, .isLink와 같은 적절한 접근성 특성을 명시적으로 채택해야 합니다. Xcode Accessibility Inspector는 개발 중 누락된 레이블과 특성 불일치를 찾아내는 데 도움이 됩니다.

Dynamic Type을 위해 UIKit의 UIFont.preferredFont(forTextStyle:)와 SwiftUI의 .font(.body) 시스템 폰트는 사용자의 선호 텍스트 크기에 따라 자동으로 확대/축소됩니다. scaledValue(for:)를 사용하지 않는 포인트 단위의 하드코딩된 폰트 크기는 1.4.4 Resize Text 기준을 충족하지 못합니다. 타깃 크기의 경우 UIKit에서는 contentEdgeInsets, SwiftUI에서는 .contentShape() 모디파이어를 사용해 요소의 시각적 크기를 변경하지 않고도 작은 아이콘의 탭 영역을 확장할 수 있습니다.

// SwiftUI: 시각적 크기를 바꾸지 않고 탭 영역 확장
Image(systemName: 'xmark')
    .frame(width: 20, height: 20)
    .contentShape(Rectangle().size(CGSize(width: 44, height: 44)))
    .accessibilityLabel('Close')
    .accessibilityAddTraits(.isButton)

Android와 Jetpack Compose / Views

Android의 접근성은 TalkBack과 Switch Access가 사용하는 AccessibilityNodeInfo API를 통해 노출됩니다. Jetpack Compose에서는 Modifier.semantics 블록을 사용해 콘텐츠 설명, 역할, 상태 설명을 설정하고 하위 의미를 병합할 수 있습니다. View 기반 UI에서는 ViewCompat.setAccessibilityDelegate()를 사용해 어떤 뷰든 접근성 속성을 프로그래밍 방식으로 조작할 수 있습니다.

터치 타깃 크기 측면에서 Material Design 가이드는 최소 48 × 48 dp를 권장합니다. 컴포저블이나 뷰가 시각적으로 더 작다면 Compose(Material3)에 도입된 Modifier.minimumInteractiveComponentSize()를 사용해 자동으로 48 dp 최소값을 적용하거나, 레거시 View 시스템에서는 작은 뷰를 TouchDelegate로 감싸 히트 영역을 확장할 수 있습니다. 텍스트 확대를 위해 모든 텍스트 크기는 dp가 아닌 sp(scale-independent pixels)로 지정해 Android 디스플레이 설정에서 사용자가 설정한 폰트 크기 선호를 존중해야 합니다.

// Jetpack Compose: 최소 크기를 갖춘 접근 가능한 아이콘 버튼
IconButton(
    onClick = { onClose() },
    modifier = Modifier
        .minimumInteractiveComponentSize() // 48dp 최소값 적용
        .semantics { contentDescription = 'Close dialog' }
) {
    Icon(
        imageVector = Icons.Default.Close,
        contentDescription = null // 상위에서 설명
    )
}

WCAG 2.2 기준으로 앱 테스트하기

모바일 접근성 테스트는 자동화 도구와 실제 보조 기술을 활용한 수동 테스트를 병행해야 합니다. Deque의 axe DevTools Mobile, Android용 Google Accessibility Scanner, Xcode의 Apple Accessibility Inspector 같은 자동화 도구는 누락된 레이블, 부족한 대비, 플랫폼 최소값에 미치지 못하는 터치 타깃 등을 찾아낼 수 있습니다. 하지만 자동화 도구는 실제 접근성 문제의 일부만 포착합니다. iOS의 VoiceOver와 Android의 TalkBack을 사용한 수동 테스트는 복잡한 흐름 전반에서 올바른 읽기 순서, 의미 있는 레이블, 논리적인 포커스 관리 여부를 검증하는 데 필수입니다.

WCAG 2.2 전용 기준에 대해서는 수동 테스트가 특히 중요합니다. 2.5.8(Target Size)을 테스트할 때는 iOS 시뮬레이터의 마우스 커서가 아니라 실제 손가락으로 작은 컨트롤을 조작해 보아야 합니다. 3.3.8(Accessible Authentication)을 테스트할 때는 로그인 흐름에서 비밀번호 필드에 붙여넣기가 가능하고, 비밀번호 관리자(1Password, Bitwarden, 시스템 키체인)를 지원하며, 생체 인증을 지원하는지 확인해야 합니다. 2.4.11(Focus Not Obscured)을 테스트할 때는 iOS에서는 Switch Control, Android에서는 Switch Access만으로 앱을 탐색하며, 포커스된 요소가 내비게이션 바, 모달 오버레이, 플로팅 버튼 뒤로 사라지지 않는지 확인해야 합니다.

포괄적인 접근성 테스트 계획에는 최소 두 대의 실제 기기 — iPhone 한 대와 Android 기기 한 대 — 에서, 기본 폰트 크기와 시스템 최대 폰트 크기 모두로, 각각 VoiceOver와 TalkBack을 활성화한 상태에서 테스트하는 것이 포함되어야 합니다. 시뮬레이터만으로 테스트하면 실제 렌더링 차이와 보조 기술 동작을 놓치게 됩니다.

CI/CD 파이프라인에 접근성 검사를 통합하는 것도 고려해 보십시오. Espresso(Android)와 XCUITest(iOS)는 콘텐츠 설명, 특성, 활성 상태 등 접근성 속성을 검증하는 자동 UI 테스트 작성을 지원하므로, 코드가 병합되기 전에 회귀를 잡아낼 수 있고, 프로덕션 감사에서 뒤늦게 발견하는 일을 줄일 수 있습니다.

지금 행동해야 하는 법적·비즈니스적 이유

포용이라는 도덕적 당위성을 넘어, 모바일 접근성의 비즈니스적 근거는 매우 구체적입니다. 장애 포용을 선도하는 기업은 동종 업계 대비 매출이 1.6배, 순이익이 2.6배 높습니다. 미국의 장애인은 거의 5천억 달러에 달하는 가처분 소득을 보유하고 있습니다. 그리고 장애가 있는 온라인 소비자의 69%가 사용하기 어렵다고 느끼는 앱과 웹사이트를 이탈한다는 점을 고려하면, 모든 접근성 장벽은 일어나지 않은 전환을 의미합니다.

법적 리스크도 커지고 있습니다. 디지털 접근성 실패를 겨냥한 소송은 해마다 증가하고 있습니다. ADA 준수를 위한 기술 표준으로 DOJ가 WCAG를 채택하고, 2026년 제2편 집행 기한, 2025년 6월 EAA 발효가 맞물리면서, 이제 네이티브 모바일 애플리케이션까지 명시적으로 포괄하는 다중 관할권 준수 요구사항이 형성되었습니다. 과거의 WCAG 2.1 감사는 WCAG 2.2 준수를 자동으로 입증하지 못합니다. 인증 흐름, 폼 필드, 인터랙티브 구성 요소, 포커스 관리는 새로 추가된 9개 성공 기준에 비추어 다시 평가해야 합니다.

무엇보다, 모바일에서의 접근성은 출시 후 저렴하게 덧붙일 수 있는 기능이 아닙니다. 출시된 앱에서 WCAG 실패를 해결하려면 에셋 업데이트, 컴포넌트 재구축, 레이아웃 수정, 흐름 재테스트, 경우에 따라 인증 시스템 리팩터링까지 필요합니다. 최소 터치 타깃 크기, 대비 토큰, 시맨틱 역할, 인증 패턴을 컴포넌트 수준에서 강제하는 디자인 시스템과 컴포넌트 라이브러리에 처음부터 WCAG 2.2 준수를 내장한 팀은, 출시 후 접근성 미준수 앱을 수정하는 데 드는 비용의 일부만으로도 문제를 해결할 수 있습니다.

핵심 요약

  • WCAG 2.2는 네이티브 iOS 및 Android 앱에 적용됩니다. W3C의 WCAG2Mobile 가이드는 모든 A 및 AA 레벨 성공 기준을 모바일 화면과 뷰에 매핑하며, 이는 네이티브 앱도 범위에 포함된다는 뜻입니다 — 모바일 웹사이트만이 아닙니다.
  • 터치 타깃 크기는 모바일 감사에서 가장 흔한 새로운 실패 항목입니다. WCAG 2.2의 24 × 24 최소값은 하한선일 뿐이며, Apple은 44 × 44 pt, Google은 48 × 48 dp를 권장합니다. 아이콘을 시각적으로 키우는 대신 패딩과 플랫폼 네이티브 API로 히트 영역을 확장하십시오.
  • 비밀번호 필드에서 붙여넣기를 차단하는 것은 3.3.8 Accessible Authentication 위반일 가능성이 큽니다. 두 플랫폼 모두에서 로그인 흐름의 인지적 접근성 요구사항을 충족하려면 시스템 키체인, 비밀번호 관리자, 생체 인증, OTP 자동 채우기를 지원해야 합니다.
  • VoiceOver와 TalkBack을 활용한 수동 테스트는 선택이 아니라 필수입니다. 자동화 도구는 접근성 문제의 일부만 포착합니다. 실제 기기에서 최대 폰트 크기와 보조 기술을 활성화한 상태로, 모든 핵심 사용자 여정을 테스트해야 합니다.
  • 접근성은 출시 후가 아니라 디자인 시스템 단계에서부터 내장해야 합니다. 출시 후 접근성 미준수 앱을 수정하는 비용은, 첫날부터 접근 가능한 컴포넌트 표준을 강제하는 것보다 훨씬 큽니다. DOJ, HHS, EAA의 집행 일정이 2025–2026년에 도래함에 따라, 저비용으로 준수 작업을 할 수 있는 시간은 점점 줄어들고 있습니다.