2026 Global 빅테크 접근성 동향: Apple과 Google
안녕하세요. 엔비전스입니다.
매년 5월과 6월은 Google과 Apple이 전 세계 개발자를 대상으로 개발자 행사를 여는 시기입니다. 모두가 아시듯 Google IO와 Apple WWDC가 그것인데요. 이 두 기업은 Google IO와 Apple WWDC 시즌에 맞추어 새로운 접근성 기능을 발표하고, 개발자를 위한 접근성 API를 업데이트합니다. 물론 매년 5월 셋째 주 목요일마다 돌아오는 세계 접근성 인식의 날(GAAD, Global Accessibility Awareness Day)도 중요한 접근성 발표 이벤트입니다.
2026년 Google IO와 Apple WWDC가 모두 끝난 지금, 저희는 Google과 Apple이 각각 어떤 접근성 기능을 발표했는지, 그리고 개발 측면에서 새롭게 바뀐 접근성 API가 무엇인지 여러분께 안내하려 합니다.
Part 1. Apple: Apple Intelligence를 접근성의 중심에 두다
VoiceOver와 Magnifier, 이제 화면을 더 상세히 설명합니다
올해 Apple 접근성 발표의 주인공은 단연 Apple Intelligence입니다. 그 효과가 가장 먼저 드러나는 곳이 스크린 리더인 VoiceOver입니다.
강화된 VoiceOver는 이미지와 화면 정보를 훨씬 자세히 설명합니다. 사진 한 장, 스캔한 청구서, 개인적인 기록물의 맥락까지 풀어서 읽어 주는데요. 여기에 Live Recognition 기능이 더해집니다. iPhone의 Action 버튼을 누르면 카메라가 비추는 장면에 대해 질문하고, 답을 들은 뒤 다시 이어서 물어볼 수 있습니다. 참고로 Live Recognition은 이전부터 있었습니다. 이 기능을 통해 사용자는 인쇄된 글자를 읽고, 주변 사물을 인식하며 출입문 따위를 손쉽게 찾을 수 있었습니다. 이번 iOS, MacOS 등의 27 운영체제 업데이트를 통해 더 많은 정보를 사용자에게 제공합니다.
돋보기 기능인 Magnifier도 비슷하게 발전합니다. 기존에는 화면을 크게 확대하고 OCR만 있는 것이 전부였습니다. 이제는 고대비 화면 안에서 주변 환경과 시각 콘텐츠에 대해 묻고 답을 받을 수 있습니다. "확대해 줘", "손전등을 켜 줘" 같은 음성 명령으로 앱을 직접 조작하는 것도 가능합니다.
정리하면 저시력과 시각장애 사용자는 이제 단순히 크게 보는 것을 넘어, 눈앞의 내용이 무엇인지 대화하듯 확인할 수 있습니다. 다만 Apple은 여기에 분명한 주의를 붙였습니다. 내비게이션, 의료 진단이나 치료처럼 위험이 큰 상황에서는 이 기능에 의존하지 말라는 것입니다. AI 설명은 어디까지나 보조 수단이라는 점을 기억할 필요가 있습니다.
Voice Control: 정확한 라벨을 몰라도 됩니다
운동 장애가 있는 사용자에게 반가운 변화도 있습니다. 음성으로 기기를 조작하는 Voice Control이 자연어를 이해하도록 개선됩니다.
기존 방식은 화면 속 버튼의 정확한 이름이나 번호를 알아야 조작할 수 있었습니다. 개선된 Voice Control은 눈에 보이는 항목을 자연스럽게 설명하는 것만으로 조작할 수 있습니다. 예를 들어 정확한 버튼 이름 대신 그 위치나 생김새를 말로 풀어내면 됩니다.
이 변화는 접근성 라벨이 부실한 앱에서도 일부 장벽을 낮춰 줍니다. 다만 초기 제공 범위는 넓지 않습니다. 영어로, 미국·캐나다·영국·호주 지역에서 먼저 시작합니다.
Accessibility Reader: 복잡한 논문도 읽기 편하게
시스템 전체에서 쓰이는 읽기 모드인 Accessibility Reader도 한 단계 나아갑니다. 여러 단으로 나뉘고 이미지와 표가 뒤섞인 과학 논문 같은 복잡한 자료를 더 읽기 좋은 형태로 정리해 주는데요. 여기에 요약과 내장 번역 기능이 더해집니다.
덕분에 난독 장애가 있거나 저시력 사용자는 문서의 구조를 잃지 않으면서 핵심을 파악할 수 있습니다. 긴 자료를 처음부터 끝까지 훑지 않아도 된다는 점이 특히 도움이 됩니다.
자막과 청각 접근성: 소리를 놓치지 않도록
청각장애와 난청 사용자를 위한 발표도 풍성합니다. 그중 눈에 띄는 것이 Generated Subtitles입니다. 자막이 아예 없는 영상에 기기 자체 음성 인식으로 자동 자막을 만들어 주는 기능인데요. iPhone으로 직접 찍은 영상, 친구나 가족이 보내 준 영상, 온라인 스트리밍까지 폭넓게 아우릅니다.
Generated Subtitles는 iPhone, iPad, Mac, Apple TV, Apple Vision Pro에서 제공됩니다. 다만 처음에는 영어로, 미국과 캐나다에서 먼저 쓸 수 있습니다.
이름을 부르면 알려 주는 Name Recognition도 기능이 확대됩니다. 누군가 사용자의 이름을 불렀을 때 알림을 주는 이 기능이 전 세계 50개 이상 언어에서 동작합니다. 회의실이나 사무실처럼 소리를 놓치기 쉬운 환경에서 자기 호출을 알아채는 데 도움이 됩니다.
FaceTime에는 수어 통역을 위한 새 API가 열립니다. 수어 통역 앱을 만드는 개발자가 FaceTime 통화 도중 사람 통역사를 통화에 추가할 수 있도록 돕는 것인데요. 수어 사용자와 비수어 사용자 사이의 실시간 영상 통화 접근성을 끌어올립니다. 다만 공개된 API 이름과 상세 문서는 아직 Newsroom 발표만으로는 확인되지 않아, 앞으로 나올 개발자 자료를 지켜봐야 합니다.
이동과 입력: Vision Pro가 휠체어를 제어합니다
올해 Apple 발표에서 가장 인상적인 장면은 Apple Vision Pro와 전동 휠체어의 연결입니다. Vision Pro의 시선 추적(eye tracking)을 호환 대체 구동 시스템의 입력으로 사용해 전동 휠체어를 제어하는 것인데요. 조이스틱을 다루기 어려운 사용자가 눈만으로 이동성을 확보할 수 있습니다.
이 기능은 Tolt, LUCI 같은 대체 구동 시스템과 함께 미국에서 먼저 시작합니다. Bluetooth와 유선 연결을 지원하며, 통제된 환경에서 쓰도록 설계되었습니다. 유선으로 연결하려면 Apple Vision Pro Developer Strap이 필요합니다.
visionOS에는 다른 입력 편의도 더해집니다. 움직이는 차 안에서 겪는 멀미를 줄여 주는 Vehicle Motion Cues가 visionOS에 추가됩니다. 또 Vision Pro가 얼굴 제스처(face gestures)를 인식하고, 시선을 일정 시간 머무르게 해서 항목을 고르는 Dwell Control의 새로운 눈 선택 방식을 지원합니다. 손을 쓰기 어려운 사용자의 입력 방식이 넓어지는 셈입니다.
iOS와 iPadOS에서는 터치 입력 보조 설정인 Touch Accommodations를 개인화하는 새로운 방법이 생깁니다. 게임 접근성도 넓어집니다. Sony의 Access controller를 iOS, iPadOS, macOS 게임 컨트롤러로 연결하고, 버튼과 스위치, 컨트롤러 조합을 자유롭게 구성할 수 있습니다.
하드웨어 액세서리도 있습니다. 접근성을 염두에 두고 설계한 Hikawa Grip & Stand for iPhone인데요. MagSafe에 붙는 이 적응형 그립 겸 스탠드는 손 힘이나 쥐는 힘, 이동성에 어려움이 있는 사용자가 iPhone을 더 안정적으로 잡거나 세우도록 돕습니다. 2026년 5월 19일부터 여러 국가에서 Apple Store 온라인으로 판매하며, 판매 국가에 한국도 포함됩니다.
시각, TV, 보청기의 작지만 반가운 변화
큰 발표에 가려지기 쉬운 실용적인 개선도 있습니다. tvOS에 Larger Text 지원이 들어와 Apple TV 화면의 글자 크기를 키울 수 있습니다. 거실에서 멀찍이 떨어져 화면을 보는 저시력 사용자에게 유용합니다.
보청기 경험도 매끄러워집니다. iOS, iPadOS, macOS, visionOS에서 Made for iPhone(MFi) 보청기의 페어링과, 여러 Apple 기기 사이를 오가는 handoff가 더 안정적으로 동작하도록 개선됩니다. 기기를 바꿀 때마다 소리와 설정이 어긋나던 불편이 줄어듭니다.
접근성 인접 기능: Live Translation
여기서 잠깐 구분이 필요한 기능이 하나 있습니다. 실시간 번역인 Live Translation입니다. Apple은 이것을 2026년 접근성 Newsroom 발표의 핵심 접근성 기능으로 분류하지는 않았습니다. 다만 언어 장벽을 낮추고 청각·의사소통 접근성 흐름과 맞닿는 지점이 있어, "접근성 인접 기능"으로 소개합니다.
Apple Support 문서에 따르면 Live Translation은 iOS 26, iPadOS 26, macOS Tahoe 26 이후에서 Messages, Phone, FaceTime에 Apple Intelligence 기능으로 제공됩니다. AirPods와 함께 쓰는 실시간 번역도 있습니다. AirPods 4(ANC 모델) 또는 AirPods Pro 2 이상과 Apple Intelligence 지원 iPhone을 함께 쓰면 대화를 실시간으로 번역할 수 있습니다. 지원 언어에 한국어도 포함됩니다.
Part 2. Apple: 개발자가 챙겨야 할 API와 정책
지금까지가 사용자 관점이었다면, 이제 개발자 관점으로 넘어가겠습니다. 접근성 기능이 아무리 똑똑해져도, 앱이 화면의 정보를 제대로 노출하지 않으면 보조 기술은 제 역할을 하지 못합니다. 올해 Apple이 개발자에게 전한 메시지도 이 점을 짚습니다.
커스텀 컨트롤의 접근성을 다듬기
WWDC26 세션 "Refine accessibility for custom controls"는 표준 컨트롤이 아닌 요소를 다루는 방법을 설명합니다. 직접 만든 슬라이더, 2D 패드, 제스처 기반 표면 같은 것인데요. 이런 커스텀 컨트롤은 그 목적(purpose), 값(value), 사용 가능한 동작(actions), 피드백(feedback)을 VoiceOver, Switch Control, Voice Control이 이해하도록 반드시 노출해야 합니다.
세션은 구체적인 도구를 함께 소개합니다. accessibilityLabel, accessibilityValue, .accessibilityAddTraits(.adjustable), .accessibilityAdjustableAction, accessibilityActivationPoint, AccessibilityNotification.Announcement, 그리고 커스텀 액션과 direct touch입니다. 핵심 원칙은 간단합니다. 시각적으로 직관적인 커스텀 컨트롤이 있다면, 그에 상응하는 대체 조작과 상태 피드백을 보조 기술에도 똑같이 제공해야 한다는 것입니다.
생성 자막과 자막 스타일 구현
앞서 소개한 Generated Subtitles는 개발자 입장에서도 챙길 지점이 있습니다. WWDC26 세션 "Discover generated subtitles and subtitle styles"는 이 기능의 구현 세부를 다룹니다. 온디바이스 모델로 자막을 실시간 생성하고, 재생 중에 자막 스타일을 미리 보며 조정하는 흐름인데요. 세션은 AVKit, AVPlayerLayer, AVCaptionRenderer, 그리고 Media Accessibility 프레임워크를 언급합니다.
여기서 오해를 하나 풀어야 합니다. 앱이 생성 자막 자체를 직접 구현한다기보다, 시스템 플레이어와 자막 선택 UI, 스타일 미리보기가 앱에서 제대로 노출되는지 확인하는 것이 요점입니다. 시스템 미디어 플레이어를 쓰지 않고 자체 플레이어를 만든 앱이라면, 자막 메뉴와 스타일 설정 경험을 따로 점검해야 합니다.
VoiceOver를 자동 테스트에 넣다
흥미로운 개발자 도구도 눈에 띕니다. Xcode 27 beta 3 릴리스 노트에 XCUIVoiceOverService가 포함된 것으로 확인됩니다. XCTest에서 VoiceOver의 동작을 검증하기 위한 UI 테스트 API입니다.
이 API가 있으면 VoiceOver의 포커스 이동, 발화 내용, 탐색 흐름을 자동화 테스트 범위에 포함할 수 있습니다. 그동안 접근성 회귀 테스트는 사람이 직접 손으로 확인하는 경우가 많았습니다. 이 변화는 그 부담을 줄이는 기반이 됩니다. 다만 개별 심볼 문서의 색인이 아직 제한적이라, 현재로서는 릴리스 노트 수준의 확인으로 봐 두는 것이 안전합니다.
접근성에 인접한 App Intents와 Foundation Models
WWDC26의 Apple Intelligence 가이드에는 접근성에 간접적으로 관련있는 항목이 여럿 있습니다. 다만 Apple이 이것들을 접근성 API로 명시하지는 않았으므로, 이 아티클에서는 접근성 인접 항목으로 분류해 소개해 드리겠습니다.
먼저 Foundation Models 프레임워크입니다. 앱이 온디바이스 모델과 Apple Foundation Models를 쓸 수 있고, Claude나 Gemini처럼 Language Model 프로토콜을 따르는 다른 제공자도 연결할 수 있습니다. 여기에는 멀티모달 프롬프트, OCR과 바코드용 Vision 도구 등이 포함됩니다. 이미지 이해나 텍스트 요약, 음성 중심 작업 흐름을 앱에 넣을 때 검증과 안전 제한을 함께 설계해야 합니다.
App Intents도 마찬가지입니다. App Intents 스키마와 Spotlight 의미 색인, View Annotations는 앱의 콘텐츠와 기능을 Siri, Shortcuts, Spotlight가 자연어로 이해하도록 연결합니다. 특히 View Annotations는 화면의 뷰를 특정 엔티티와 매핑하는데요. 손을 쓰지 않는 흐름이나 음성만으로 진행하는 흐름에 좋은 영향을 줄 수 있습니다. 다만 Apple이 이를 접근성 요구사항으로 프레이밍하지는 않았으므로, 접근성 QA 범위에 넣어 함께 점검하는 정도가 적절합니다.
플랫폼 정책: 접근성 리소스 배포에 영향을 주는 변화
접근성 전용 정책은 아니지만, 접근성 앱 운영에 영향을 줄 수 있는 변화도 있습니다. 대표적으로 On-Demand Resources(ODR)의 지원 중단입니다. iOS 27, iPadOS 27, tvOS 27, visionOS 27부터 ODR이 deprecated 상태가 되고, Apple이 호스팅하는 Background Assets가 대안으로 제시됩니다.
이 변화가 왜 접근성과 관련이 있을까요. 접근성 리소스, 언어팩, 음성이나 비디오 asset을 ODR로 나눠 배포하던 앱이라면 마이그레이션 계획이 필요하기 때문입니다. 반대로 Background Assets 쪽에는 반가운 소식도 있습니다. 언어 데이터를 별도 asset pack으로 나눠 초기 로딩 시간을 줄이고, VoiceOver 음성이나 비디오 파일 같은 필수 asset을 앱 첫 실행 전에 받아 둘 수 있습니다.
이 밖에 age rating과 소셜 미디어 기능 표시, 자녀의 앱 사용 시간을 카테고리별로 관리하는 Time Allowances 같은 정책도 새로 들어옵니다. 접근성 전용은 아니지만, 아동·가족 보호와 인지적 부담이라는 관점에서 함께 살펴볼 가치가 있습니다.
Part 3. Google/Android: 플랫폼의 의미 정보를 넓히다
이제 Google로 넘어가겠습니다. 앞서 말씀드렸듯 Google은 올해 접근성만을 위한 대형 발표를 크게 내세우지는 않았습니다. 그래서 오히려 플랫폼과 API를 중심으로 살펴보는 것이 이해에 도움이 됩니다.
Android 16: 2025년 릴리스지만 지금도 살펴볼 필요가 있는 이유
Android 16은 2025년에 안정 버전이 나왔습니다. 그런데도 2026년 현재 Android 접근성 구현에서 가장 중요한 공식 변경은 여전히 Android 16에 담겨 있습니다. 관련 개발자 문서가 2026년에도 계속 갱신되고 있기 때문입니다.
사용자가 체감하는 변화부터 보겠습니다. 첫째, LE Audio 보청기 사용자는 통화 중에 보청기 내장 마이크와 휴대전화 마이크를 전환할 수 있습니다. 소음이 심한 곳에서 상대방에게 더 또렷한 목소리를 전달할 수 있는데요. 여기에 보청기 마이크가 잡는 주변음의 볼륨을 조정하는 기능도 더해집니다.
둘째, Outline text입니다. 기존의 High contrast text(고대비 텍스트)를 대체하는 모드인데요. 대비를 최대한 끌어올리기 위해 글자 주변에 넓은 대비 영역을 그려 줍니다. 배경과 글자를 구분하기 어려웠던 저시력 사용자에게 도움이 됩니다.
2025년에 발표했지만 여전히 유효한 Google의 AI 접근성
여기서 앞서 당부드린 연도 구분이 중요해집니다. 지금 소개하는 기능들은 모두 2025년 5월 15일 GAAD 발표입니다. 2026년 현재도 유효하게 쓰이지만, 올해 신규 발표가 아니라는 점을 기억해 주세요.
TalkBack에 Gemini가 결합된 것이 대표적입니다. Android의 화면 낭독기인 TalkBack 사용자는 이미지 설명을 듣고 후속 질문을 던질 수 있습니다. 특정 이미지뿐 아니라 화면 전체에 대해서도 설명을 듣고 물어볼 수 있는데요. 대체 텍스트가 없는 이미지나 쇼핑 화면, 낯선 앱 화면의 맥락을 파악하는 데 유용합니다. 삼성 기기 등 일부 모델에는 이 기능이 아직도 확대 적용 중이기에 2026년에도 소개할 만한 가치가 있다 판단하여 언급합니다.
청각 접근성 쪽에는 Expressive Captions가 있습니다. 이 자막 기능은 말을 길게 끄는 뉘앙스를 표시하고, 휘파람이나 목을 가다듬는 소리 같은 추가 소리 라벨을 제공합니다. 덕분에 발화의 감정과 주변 소리의 맥락까지 함께 읽어 낼 수 있습니다.
Chrome에도 두 가지 개선이 있었습니다. 데스크톱 Chrome은 스캔한 PDF를 OCR로 처리해, 텍스트 선택과 복사, 검색, 스크린 리더 읽기를 지원합니다. 이미지로만 되어 있어 보조 기술로 접근할 수 없던 PDF가 열리는 셈입니다. 또 Android용 Chrome의 Page Zoom은 페이지 레이아웃을 크게 망가뜨리지 않으면서 글자 크기를 키우도록 돕습니다. 사이트별로 적용하거나 전체 페이지에 적용할 수 있어 모바일 웹 가독성이 좋아집니다.
Android 17: 한중일·베트남어(CJKV) 입력의 접근성을 개선하다
그렇다면 2026년 새 OS인 Android 17에는 접근성 변화가 없을까요. 그렇지 않습니다. Android 17의 기능 문서에서는 접근성으로 분류된 큰 소비자 항목이 두드러지지 않습니다. 하지만 개발자용 동작 변경 문서에는 접근성 섹션이 별도로 있습니다.
핵심은 복잡한 IME(입력기)와 물리 키보드 입력의 접근성 지원입니다. Android 17은 한국어, 중국어, 일본어, 베트남어(CJKV) 같은 언어를 입력하는 도중 스크린 리더가 읽어 주는 피드백을 개선하기 위해 새로운 AccessibilityEvent와 TextAttribute API를 도입합니다.
조금 더 구체적으로 보겠습니다. IME는 TextAttribute.Builder.setTextSuggestionSelected()로 변환 후보가 선택되었는지를 알릴 수 있습니다. 커스텀 InputConnection을 직접 유지하는 앱은 TextAttribute.isTextSuggestionSelected()와 AccessibilityEvent.setTextChangeTypes()로 텍스트 변경의 성격을 전달할 수 있습니다. 표준 TextView를 쓰는 앱이라면 Android 17을 타깃할 때 이 처리가 기본으로 적용됩니다. 한글처럼 조합과 변환 과정이 있는 언어에서, 지금 무엇이 입력되고 있는지 스크린 리더가 더 정확히 안내한다는 뜻입니다.
이 밖에 접근성에 인접한 항목도 있습니다. Assistant 음량을 미디어 음량과 분리해 독립적으로 조절하는 전용 스트림, 그리고 알림 진행 표시에 초록·주황·빨강·파랑 같은 보편적 의미 색상을 부여하는 API입니다. 다만 Google이 이들을 접근성 기능으로 분류하지는 않았습니다. 특히 색상 API는 유용하지만, 색상만으로 의미를 전달해서는 안 된다는 접근성 원칙을 함께 기억해야 합니다.
Part 4. Google/Android: 접근성 API와 정책의 실제 변화
Android 개발자에게 2026년의 진짜 숙제는 Android 16이 새로 열어 준 접근성 API를 반영하고, 함께 사라진 옛 API를 정리하는 일입니다. 하나씩 보겠습니다.
화면을 더 정확히 설명하는 AccessibilityNodeInfo
Android 16은 화면 요소의 정보를 담는 AccessibilityNodeInfo에 여러 의미 정보를 새로 추가했습니다. 이 정보들은 TalkBack 같은 접근성 서비스가 화면을 더 정확히 읽도록 돕습니다.
- 다중 라벨(Multi-label): 하나의 요소가 여러 라벨과 관계를 맺을 수 있습니다. 복잡한 폼이나 웹 형태의 UI에서 접근성 트리 품질이 좋아집니다.
- 삼상태 체크박스(Tri-state checkbox): 체크됨, 체크 안 됨에 더해 부분 선택 상태까지 표현할 수 있습니다. "전체 선택"이 일부만 켜진 상태를 정확히 알릴 수 있습니다.
- 필수 입력 필드:
setFieldRequired로 어떤 입력란이 필수인지 접근성 서비스에 명시합니다. 폼을 탐색하고 오류를 예방하는 데 도움이 됩니다. - 보조 설명(Supplemental description):
setSupplementalDescription으로 그룹 설명이 자식 요소의 정보를 덮어쓰지 않게 합니다. 드롭다운이나 복합 위젯에서 그룹 이름과 현재 선택값을 함께 보존할 수 있습니다. - 확장 상태(Expanded state):
setExpandedState와CONTENT_CHANGE_TYPE_EXPANDED로 펼침과 접힘 상태를 스크린 리더에 전달합니다. 메뉴, 아코디언, 확장 목록의 상태 변화를 자연스럽게 안내합니다. - 불확정 진행 상태:
RANGE_TYPE_INDETERMINATE로 진행 정도가 정해지지 않은 로딩 표시도 일관되게 노출할 수 있습니다. - 시간 읽기 개선:
TtsSpan.TYPE_DURATION으로 시, 분, 초를 나눠 음성 합성에 전달해 시간 길이를 더 자연스럽게 읽습니다.
반드시 정리해야 할 deprecation
새 기능만큼 중요한 것이 사라지는 API입니다. Android 16은 접근성과 관련해 몇 가지 중요한 deprecation을 예고했습니다.
가장 눈여겨볼 것은 무차별 알림의 정리입니다. announceForAccessibility와 TYPE_ANNOUNCEMENT 이벤트에 기대던 방식이 deprecated 처리됩니다. 그동안 개발자들은 화면 변화를 알리려고 이 방식을 자주 썼습니다. 하지만 맥락 없이 쏟아지는 알림은 오히려 TalkBack 사용자의 흐름을 방해할 수 있다고 판단했습니다.
그래서 Android는 목적별로 다른 수단을 쓰라고 권합니다. 화면 영역이 바뀌면 paneTitle을, 실시간으로 갱신되는 영역이면 live region을, 오류 상황이면 error event나 setError를 쓰는 식입니다. 어떤 변화인지에 따라 알림 채널을 나누라는 것입니다.
이 밖에도 라벨과 체크 상태 관련 API가 바뀝니다. setLabeledBy와 getLabeledBy는 다중 라벨을 지원하는 addLabeledBy, removeLabeledBy, getLabeledByList로 옮겨 갑니다. 불리언 값만 다루던 isChecked와 setChecked(boolean)은 삼상태를 지원하는 getChecked, setChecked(int)로 대체됩니다. 앞서 본 Outline text가 High contrast text를 대체한 것도 같은 맥락입니다. 커스텀 텍스트 렌더링을 하는 앱이라면 Outline text 활성 여부를 감지해 대응해야 합니다.
Jetpack과 Compose의 접근성 수정
2026년에는 AndroidX와 Jetpack Compose 쪽에서도 접근성 관련 갱신이 이어졌습니다. 최신 버전으로 올리는 것만으로 얻을 수 있는 개선이 많습니다.
AndroidX Core는 2026년 3월 11일 1.18.0 버전에서 AccessibilityNodeInfoCompat.SelectionCompat을 추가했습니다. Android 16 계열의 접근성 상태를 하위 호환 계층에서 다루기 쉽게 해 주는데요. 체크 상태 상수와 확장 상태 관련 정의도 함께 정리되었습니다. 다만 Android 16의 모든 다중 라벨·필수 필드 API가 Core 라이브러리에 그대로 옮겨진 것은 아니므로, 필요한 API가 지원되는지는 각자 확인하는 편이 안전합니다.
Compose 쪽 수정도 실무에 중요합니다. Compose UI는 토글 상태가 바뀔 때 CONTENT_CHANGE_TYPE_CHECKED를 전송하도록 바뀌어, TalkBack이 토글 변경을 더 정확히 감지합니다. 스크롤 컨테이너 안 요소의 show-on-screen 동작도 개선되었습니다. Material3에서는 TimePicker에서 시와 분을 오갈 때 키보드 포커스가 사라지던 문제가 고쳐졌고, Slider, ProgressIndicator, Snackbar, FloatingToolbar 등의 접근성도 손봤습니다. Compose 기반 앱이라면 이런 수정 내용을 반영해 TalkBack과 키보드 포커스 회귀 테스트를 돌려 볼 필요가 있습니다.
Google Play 정책: AI 에이전트 시대의 뜨거운 감자
마지막으로 정책입니다. 2026년 Android 생태계에서 가장 민감한 접근성 정책은 AccessibilityService API의 자동화 제한입니다.
원칙은 이렇습니다. 장애가 있는 사용자를 돕는 것이 주된 목적인 서비스만 isAccessibilityTool=true를 선언할 수 있습니다. 그 외의 앱이 AccessibilityService API를 쓰려면 눈에 띄는 사전 고지와 사용자 동의, 그리고 Play 선언이 필요합니다.
특히 중요한 것은 자동화 제한입니다. 사용자를 대신해 자율적으로 동작을 계획하고 실행하는 용도로 Accessibility API를 쓰는 것은 금지됩니다. 정해진 규칙에 따라 결정론적으로 동작하는 자동화는 예외이고, 검증된 접근성 도구도 장애 지원이라는 본래 목적 안에서는 예외가 될 수 있습니다. 이 규정은 화면을 대신 조작하는 AI 에이전트 앱이 늘어나는 2026년에 특히 민감해질 수 있습니다. AccessibilityService를 범용 화면 제어 수단으로 쓰는 앱은 정책 위반 위험이 큽니다.
권한 정책도 강화됩니다. 연락처 권한의 경우, 2026년 10월 28일부터 Android 17(API 37) 이상을 타깃하면서 READ_CONTACTS를 요청하는 앱은 넓은 연락처 접근이 핵심 기능에 꼭 필요하고 Contact Picker로는 충분하지 않다는 점을 선언해야 합니다. 위치 권한도 2026년 10월 말에 최소 범위를 유도하는 방향으로 정비될 예정입니다. 통화나 메시지를 돕는 커뮤니케이션 접근성 앱이라면, 권한을 기본값으로 넓게 요구하기보다 최소 범위 대안을 먼저 검토하는 편이 좋습니다.
글을 마치며
지금까지 저희는 Apple과 Google이 2026년에 발표한 접근성 기능과 API 그리고 정책에 대해 알아보았습니다. 글의 분량 때문에 새로운 API와 정책을 상세히 소개할 수 없었는데요. 추후 다른 글에서 중요한 내용을 하나씩 살펴보도록 하겠습니다.
긴 글 읽어주셔서 감사합니다.