Accessibility Nutrition Labels 어떻게 작성하나요? 2026 App Store 검수 목록

이 글을 읽어야 하는 개발자

처음 Accessibility Nutrition Labels를 작성하지만 Apple의 판단 기준과 제출 범위를 정확히 구분하기 어려운 독립 개발자에게 적합합니다.

iPhone, iPad 또는 Mac을 함께 지원하는 소규모 팀, 그리고 상시 테스트 기기를 보관하기 어려워 원격 macOS 환경에서 반복 검증을 만들려는 개발자도 대상입니다.

2026년 9월 7일 기준으로 Apple은 초기 접근성 라벨 제공을 자율 사항으로 안내하면서, 앞으로 새 앱과 업데이트 제출에 필요한 정보가 될 수 있다고 설명합니다. 다만 공개된 공식 자료에서 통일된 의무 시작일은 확인되지 않습니다. 따라서 발표되지 않은 날짜를 전제로 일괄 제출하거나 미제출하는 방식은 피해야 합니다. 공식 개요 안내를 기준으로 현재 App Store Connect 화면을 함께 확인해야 합니다.

공통 작업 중심의 검증 범위

접근성 지원 여부는 특정 화면 하나가 열리는지가 아니라 사용자가 앱을 내려받은 뒤 주요 목적을 달성할 수 있는지로 판단해야 합니다. 다음 작업을 먼저 앱의 테스트 기준으로 고정합니다.

• 첫 실행과 권한 안내
• 계정 로그인과 로그아웃
• 핵심 콘텐츠 탐색과 검색
• 결제, 구독 또는 구매 복구
• 앱 설정 변경
• 오류 메시지 확인과 재시도
• 종료 후 재실행했을 때의 상태 복구

이 목록에서 앱의 성격과 관계없는 항목은 제외 사유를 기록합니다. 반대로 결제가 없는 앱이라도 로그인이나 핵심 콘텐츠 탐색이 실제 사용에 필요하다면 해당 흐름은 빠지면 안 됩니다.

프로젝트에 accessibilityLabel, accessibilityValue 또는 SwiftUI 접근성 수정자가 있다는 사실은 코드 수준의 준비 상태만 보여 줍니다. 화면 하나가 작동하거나 샘플 경로가 통과해도 전체 앱의 공통 작업을 지원한다고 볼 수 없습니다.

음성 상호작용과 초점 이동

VoiceOver 결과

VoiceOver에서는 각 공통 작업을 처음부터 끝까지 실행합니다. 다음 항목을 한 번에 기록해야 합니다.

• 초점 순서가 시각적이고 논리적인 순서와 맞는지
• 버튼, 이미지, 입력창의 이름이 목적을 설명하는지
• 선택 상태, 값, 진행 상태가 전달되는지
• 사용자 정의 컨트롤이 올바른 동작으로 조작되는지
• 모달, 알림, 키보드와 오류 복구가 접근 가능한지

Apple의 VoiceOver 평가 기준은 단순히 요소가 읽히는지보다 사용자가 기능을 이해하고 조작할 수 있는지를 평가하도록 안내합니다. 따라서 “초점이 잡힘”과 “작업 완료”를 같은 결과로 기록하면 안 됩니다.

Voice Control 결과

Voice Control은 VoiceOver의 대체 이름이 아닙니다. 화면에 표시된 이름으로 버튼을 호출할 수 있는지, 사용자 정의 제어 요소가 음성 명령에 반응하는지, 음성으로 화면을 이동하고 오류에서 회복할 수 있는지를 별도로 검사해야 합니다. Voice Control 평가 기준에 따라 VoiceOver 통과 결과를 Voice Control 항목에 복사하지 않습니다.

다음처럼 내부 기록 파일을 만들면 선언 근거가 명확해집니다.

작업: 로그인
VoiceOver: 통과 - 이메일 입력, 비밀번호 입력, 로그인 결과 확인
Voice Control: 실패 - 사용자 정의 로그인 버튼을 음성 명령으로 실행할 수 없음
증거: 로그인-voiceover.mov, 로그인-voice-control.mov
결정: VoiceOver는 검토 대상, Voice Control은 미신고

시각 환경과 동작 변화

큰 텍스트, 어두운 화면, 색상 대비와 동작 줄이기는 한 묶음으로 처리하지 않습니다. 각각 실제 공통 작업에서 확인하고 별도 결과를 남겨야 합니다.

큰 텍스트를 켠 뒤에는 글자가 커졌다는 사실보다 다음 문제가 생기는지를 봅니다.

• 구매 버튼이 화면 밖으로 밀리는지
• 가격이나 오류 문장이 잘리는지
• 스크롤이 막혀 다음 단계로 이동할 수 없는지
• 텍스트가 다른 컨트롤을 덮는지

판정 기준은 Larger Text 평가 기준을 따릅니다. Dynamic Type을 프로젝트에 연결했다는 이유만으로 통과 처리하지 않습니다.

어두운 화면에서는 색상만 바뀌는지 확인하지 말고 로그인부터 구매까지의 전체 흐름을 다시 실행합니다. 색상만으로 성공과 실패를 구분하는 요소가 있는지, 중요한 정보의 대비가 떨어지는지 확인합니다. Apple의 접근성 디자인 지침을 기준으로 시각 정보와 조작 피드백을 함께 검토해야 합니다.

동작 줄이기는 애니메이션 하나를 끄는 테스트가 아닙니다. 화면 전환, 로딩 상태, 자동 재생, 구매 완료 안내가 동작을 줄인 상태에서도 이해되고 조작되는지 확인합니다. 세부 판단은 Reduced Motion 평가 기준을 사용합니다.

증거 기록과 선택 결정

다음 표는 코드 상태와 실제 선언 결정을 분리하기 위한 기준입니다.

개발자가 실패 항목을 숨기기 위해 정상 화면의 캡처만 모으면 증거의 추적성이 떨어집니다. 통과한 경로와 실패한 경로, 수정 커밋 또는 빌드 식별자를 함께 보관해야 합니다.

미디어 기능의 적용 범위

자막과 오디오 설명은 모든 앱에 자동으로 적용되는 항목이 아닙니다. 앱의 핵심 작업에 동영상, 음성 안내 또는 다른 미디어가 필요한지 먼저 판단합니다.

일반 텍스트 설명은 자막과 같지 않습니다. 자막은 영상의 음성이나 중요한 소리를 사용자가 이해할 수 있게 제공해야 하며, 오디오 설명은 화면에만 나타나는 핵심 정보를 음성으로 전달해야 합니다. 안내문이나 대본이 있다는 이유로 두 기능을 모두 지원한다고 선택해서는 안 됩니다.

다음 조건을 나누어 기록합니다.

• 지원 언어별 자막이 실제 재생 경로에서 선택되는지
• 일시 정지와 다시 재생할 때 자막이 유지되는지
• 화면 변화와 중요한 시각 정보가 오디오 설명에 포함되는지
• 로그인이나 구매처럼 미디어가 아닌 핵심 작업에는 미디어 지원이 필요하지 않은지

자막은 Captions 평가 기준, 오디오 설명은 Audio Descriptions 평가 기준으로 확인합니다. 주요 미디어 경로를 덮지 못하면 해당 항목은 신고하지 않는 편이 정확합니다.

기기 가족별 테스트 매트릭스

iPhone에서 통과한 결과를 iPad나 Mac에 복사하지 않습니다. 화면 크기와 방향, 키보드나 포인터 입력, 플랫폼별 시트와 메뉴가 공통 작업의 완료 가능성을 바꿀 수 있기 때문입니다.

App Store Connect에서 실제로 제공하는 기기 가족과 항목을 기준으로 선택합니다. 해당 기기에서 기능이 제공되지 않는 경우에는 지원한다고 추정하지 말고, 적용되지 않음과 테스트하지 않음을 구분해 내부 기록에 남깁니다.

Accessibility Inspector와 반복 실행

Accessibility Inspector는 문제를 찾는 데 유용하지만, 공통 작업의 완료를 대신 증명하지는 않습니다. 검사 결과가 깨끗해도 구매 흐름의 사용자 정의 컨트롤이 실제로 작동하지 않을 수 있습니다.

반복 테스트에서는 다음 순서를 고정합니다.

• 테스트할 빌드와 기기 가족을 기록합니다.
• 접근성 설정을 초기 상태로 맞춥니다.
• 공통 작업별 시작 조건을 통일합니다.
• Accessibility Inspector로 요소 이름, 역할, 값과 경고를 확인합니다.
• VoiceOver와 Voice Control을 각각 실행합니다.
• 큰 텍스트, 어두운 화면, 동작 줄이기 조건으로 다시 실행합니다.
• 실패 화면과 재현 절차를 저장합니다.
• 수정 빌드에서 같은 작업을 다시 실행합니다.

원격 Mac을 사용할 때는 세션이 바뀌면 화면 배율, 입력 포커스, 시뮬레이터 상태가 달라질 수 있습니다. 그러므로 원격 세션 자체를 통과 증거로 삼지 말고, 빌드 식별자와 설정 화면, 작업 결과를 함께 저장해야 합니다. 장시간 테스트 환경이 필요한 팀은 원격 Mac 사용 환경을 검토할 수 있습니다. 여러 지역의 접속 조건을 비교해야 한다면 서울 원격 Mac 주문 환경도 함께 확인할 수 있지만, 실제 기기 연결이 필요한 검증은 별도 장비 조건을 확인해야 합니다.

재현 가능한 명령 기록은 다음처럼 남길 수 있습니다.

xcrun simctl list devices
xcodebuild -version
date

출력 예시는 테스트 당시의 환경을 설명하기 위한 것이며, 특정 Xcode 버전이나 성능을 보장하는 자료가 아닙니다. 화면 녹화에는 개인 계정과 테스트 데이터를 포함하지 않아야 합니다.

제출 전 증거 묶음

최종 증거 묶음은 다음 순서로 구성하면 검토자가 선언의 근거를 따라가기 쉽습니다.

• 앱이 지원하는 기기 가족과 빌드 식별자
• 공통 작업 목록과 각 작업의 시작 조건
• VoiceOver 결과
• Voice Control 결과
• 큰 텍스트, 어두운 화면, 색상 구분과 동작 줄이기 결과
• 적용 가능한 미디어 항목의 언어별 결과
• 실패 경로와 수정 기록
• 최종 라벨 결정과 보류 항목
• 실제 공개 버전과 App Store Connect 입력 내용의 대조 결과

App Store Connect에 입력하는 값은 개발 브랜치의 예정 기능이 아니라 현재 제출하는 버전의 동작과 일치해야 합니다. 접근성 라벨 관리 안내를 확인한 뒤 저장하고, 공개 후에는 실제 표시 결과를 다시 확인합니다.

자동화가 필요한 팀은 선언 값을 API로 관리할 수도 있지만, 접근성 선언 API 문서는 입력을 자동화하는 방법을 설명할 뿐 실제 접근성 테스트를 대신하지 않습니다.

제출 전 복사 점검표

[ ] 로그인, 구매, 설정, 핵심 기능 작업을 정의했습니다.
[ ] 기기 가족별로 테스트 행을 나누었습니다.
[ ] VoiceOver와 Voice Control을 별도로 실행했습니다.
[ ] 사용자 정의 컨트롤과 오류 회복을 확인했습니다.
[ ] 큰 텍스트에서 잘림과 겹침을 확인했습니다.
[ ] 어두운 화면과 색상 외 구분을 확인했습니다.
[ ] 동작 줄이기 상태에서 핵심 피드백을 확인했습니다.
[ ] 자막과 오디오 설명을 적용 대상일 때만 검토했습니다.
[ ] 실패 경로와 수정 결과를 저장했습니다.
[ ] 공개 버전과 App Store Connect 선언을 대조했습니다.
[ ] 계정, 앱 이름, 번들 식별자와 테스트 사용자를 가렸습니다.

자주 묻는 내용

Accessibility Nutrition Labels의 적용 상태

현재 공식 안내만으로는 통일된 의무 시작일을 정할 수 없습니다. 자동으로 모두 작성하거나 반대로 무시하기보다, 현재 App Store Connect에 표시되는 항목과 앱의 실제 지원 범위를 확인해야 합니다.

기기별 선언 범위

기기 가족별로 화면과 입력 방식이 달라질 수 있으므로 결과를 복사하지 않습니다. iPhone, iPad, Mac 중 실제 지원 범위에 포함되는 대상만 별도로 검증합니다.

VoiceOver 통과의 의미

초점이 읽히는 것만으로는 부족합니다. 로그인, 핵심 기능, 구매와 설정처럼 앱에서 중요한 작업을 끝까지 완료할 수 있어야 하며, 실패와 복구 경로도 결과에 포함해야 합니다.

공개 표시가 늦는 경우

저장된 선언이 어느 버전에 연결되었는지, 게시 처리가 완료되었는지, 지원 기기 조건이 맞는지부터 확인합니다. 개발 버전의 결과가 공개 제품 페이지에 즉시 표시된다고 가정하지 않습니다.

로컬 Mac 한 대만 사용하는 방식은 테스트 상태가 다른 작업에 의해 바뀌고, 여러 기기 가족의 시뮬레이터와 캡처 자료를 동시에 유지하기 어렵다는 단점이 있습니다. 새 장비를 추가하면 구매 비용과 관리 부담이 생기고, 상시 켜 둔 테스트 환경은 저장 공간과 계정 보안 관리도 요구합니다. 짧은 기간의 반복 검증이나 팀별 격리 환경이 목적이라면 NodeMini에서 주기 단위로 원격 Mac을 마련해 독립된 회귀 환경으로 사용하는 편이 현실적입니다. 다만 장기간 무거운 작업을 계속 실행하거나 물리 기기 연결이 필수인 팀에는 직접 장비를 보유하는 방식이 더 적합할 수 있습니다.

이번 주에는 라벨을 먼저 선택하지 말고, 공통 작업 목록과 기기 가족별 테스트 표를 만든 뒤 VoiceOver와 Voice Control의 실패 경로부터 채우는 것이 좋습니다. 검증이 끝난 항목만 App Store Connect에 반영하면, 코드에 접근성 수정자가 있다는 이유로 과도하게 신고하는 실수를 줄일 수 있습니다.