앱 MVP 폼 오류 안내: 레이블·오류 설명·포커스를 나누는 5가지 기준
회원가입, 상담 신청, 결제처럼 입력을 완료해야 다음으로 갈 수 있는 화면에서는 ‘빨간 테두리’만으로 오류를 처리하기 쉽습니다. 그러나 화면을 보지 않거나 화면을 순서대로 탐색하지 않는 사용자에게는 무엇이 틀렸고 무엇을 고치면 되는지가 별도의 정보입니다.
이 글은 특정 앱이 접근성 기준을 충족한다고 판정하는 자료가 아닙니다. 앱 MVP에서 폼 오류를 기획·개발·검수할 때 레이블, 값, 오류 설명, 포커스, 재시도 경로를 하나의 체크리스트로 분리하는 방법을 다룹니다. Android Compose와 Apple VoiceOver의 공식 안내를 확인한 뒤, 실제 제품의 구현과 기기별 읽기 결과는 별도 QA로 남겨야 합니다.
먼저 정할 것: 이 필드는 무엇을 받는가
입력값이 비어 있거나 형식이 맞지 않을 때부터 설명을 쓰면 문구가 모호해지기 쉽습니다. 먼저 필드의 역할을 한 문장으로 적습니다. 예를 들어 ‘연락받을 이메일’, ‘사업자등록번호’, ‘비밀번호 확인’은 모두 서로 다른 입력 목적입니다.
Apple은 버튼·아이콘·폼 컨트롤을 포함한 UI 요소에 간결한 레이블을 두고, 텍스트 입력 필드는 값과 별도로 ‘전화번호’ 같은 레이블을 제공하라고 안내합니다. 즉, 입력칸에 이미 입력된 글자와 그 입력칸의 목적을 같은 정보로 취급하지 않는 편이 안전합니다. 기본 컴포넌트인지, 직접 만든 컴포넌트인지도 함께 기록하세요. 직접 만든 UI는 자동으로 같은 접근성 정보를 제공한다고 가정할 수 없습니다.
1. 오류의 종류와 고칠 행동을 분리합니다
‘입력이 올바르지 않습니다’는 오류 사실은 알리지만 다음 행동을 알려 주지 못합니다. MVP 요구사항에는 최소한 오류가 난 필드, 오류의 이유, 사용자가 바꿀 수 있는 행동을 나눠 적는 편이 좋습니다.
예를 들어 이메일 형식 오류라면 ‘이메일 형식으로 입력해 주세요’처럼 형식과 행동을 함께 말할 수 있습니다. 반면 서버에서 이미 사용 중인 이메일을 반환했다면 형식 오류와 섞지 말고 로그인·비밀번호 재설정·다른 주소 사용 중 무엇을 제공할지 제품 정책으로 결정해야 합니다. 오류 문구만으로 계정 존재 여부나 보안 정책을 단정해서는 안 됩니다.
2. 색상은 보조 신호로 두고, 오류 설명을 따로 제공합니다
테두리 색, 아이콘, 흔들림 효과는 시각적 보조 신호일 수 있지만 오류의 전부가 아닙니다. Android Compose 문서는 오류 상태에서 error semantics로 접근성 서비스에 확장된 오류 메시지를 제공할 수 있다고 설명합니다. 따라서 개발 요구사항에는 ‘화면의 오류 문구’와 ‘보조기술에 전달할 오류 설명’이 실제로 같은 의미인지 확인하는 항목을 둡니다.
여기서 중요한 것은 모든 오류에 똑같은 긴 설명을 붙이는 일이 아닙니다. 필드 목적과 오류 원인, 다음 행동이 다른데도 같은 문장이 반복되면 오히려 수정하기 어렵습니다. 화면 문구, 접근성 설명, 서버 오류 코드의 대응표를 작게라도 유지하면 변경 때 무엇을 함께 고쳐야 하는지 추적하기 쉬워집니다.
3. 제출을 눌렀을 때 어디로 돌아갈지 정합니다
여러 필드가 한 번에 검증될 때는 화면 상단 요약만 보여 줄지, 첫 오류 필드로 이동할지, 각 필드에서 순서대로 수정하게 할지 정해야 합니다. 정답 하나가 있는 선택은 아닙니다. 다만 사용자가 오류를 인지한 뒤 수정할 위치를 다시 찾지 않아도 되는가를 기준으로 판단할 수 있습니다.
Apple은 VoiceOver 사용자가 UI의 각 부분에 포커스하고, 무엇인지 듣고, 활성화할 수 있어야 하며 일반 작업을 보조 없이 완료할 수 있어야 한다고 안내합니다. 이를 MVP 검수 항목으로 옮기면, 제출 실패 뒤 현재 포커스가 어디에 있는지, 오류 필드까지 탐색 순서가 자연스러운지, 취소·뒤로가기 후 입력값이 어떤 상태인지 확인하는 일로 바뀝니다. 실제 포커스 이동 구현은 사용하는 프레임워크와 화면 구조에 맞춰 개발자가 정해야 합니다.
4. 레이블·값·오류를 한 덩어리로 들을지 확인합니다
시각적으로는 필드 제목, 입력값, 도움말, 오류가 가까이 있어도 스크린리더 탐색에서는 떨어져 읽힐 수 있습니다. Apple의 VoiceOver 안내는 맥락이 같은 레이블과 값을 그룹으로 묶어 의도한 순서로 탐색되게 할 수 있다고 설명합니다. 폼에서는 ‘무슨 필드인지 → 현재 값 또는 비어 있음 → 오류 또는 도움말 → 다음 행동’의 흐름이 사용자가 이해할 수 있는지 확인하는 것이 핵심입니다.
그래서 디자인 검토 때는 예쁜 배치만 보지 말고 다음 질문을 남깁니다. 레이블이 화면 밖으로 잘렸을 때도 목적을 알 수 있는가? 아이콘만 있는 제거·보기 전환·도움말 버튼은 무엇을 하는지 들리는가? 오류 아이콘은 독립된 정보인가, 이미 읽히는 오류 문구를 반복하는 장식인가? 이 답은 화면마다 달라질 수 있으므로 공통 컴포넌트 규칙과 화면별 예외를 구분합니다.
5. ‘개발 완료’ 대신 실제 탐색 시나리오를 기록합니다
Android 문서는 Compose semantics가 접근성뿐 아니라 자동완성과 테스트에도 맥락을 제공한다고 설명합니다. 이 점을 활용해 화면 단위의 체크를 만듭니다. 예시는 다음과 같습니다.
빈 필드로 제출했을 때 필드 목적과 수정 행동을 이해할 수 있는지
형식 오류와 서버 응답 오류가 같은 문구로 뭉개지지 않는지
오류가 여러 개일 때 수정 순서와 현재 위치를 알 수 있는지
직접 만든 입력·아이콘·선택 컨트롤이 레이블과 상태를 제공하는지
수정 후 오류 상태가 사라지거나 바뀔 때 화면과 보조기술 안내가 어긋나지 않는지
이 목록을 통과했다고 모든 기기·OS·보조기술 조합에서 같은 경험이 보장되는 것은 아닙니다. 사용 중인 Android/iOS 버전, 기기, 입력 방식, 화면 흐름을 적고 실제 TalkBack·VoiceOver 탐색 결과와 자동화 테스트 결과를 분리해 보관하세요. 더 넓은 출시 전 점검은 앱 MVP 출시 전 접근성 테스트: 핵심 흐름 QA에 넣을 5가지에서 이어서 확인할 수 있습니다.
자주 묻는 질문
오류 문구를 화면에 보여 주면 스크린리더 안내도 끝난 건가요?
아닙니다. 화면에 보이는 문구와 보조기술이 실제로 전달하는 정보가 일치하는지는 별도 확인이 필요합니다. Android Compose는 오류 상태에 확장 오류 메시지를 제공하는 semantics를 안내하며, 실제 적용 여부와 읽기 결과는 구현·기기에서 검수해야 합니다.
모든 제출 실패 때 첫 오류 필드로 강제로 이동해야 하나요?
그렇게 단정할 수 없습니다. 여러 오류의 요약, 수정 순서, 화면 구조에 따라 다른 흐름이 가능할 수 있습니다. 다만 제출 실패 후 사용자가 현재 위치와 다음 수정 대상을 이해할 수 있는지 실제 보조기술 탐색으로 점검하세요.
기존 입력 컴포넌트를 쓰면 레이블과 상태 검수가 필요 없나요?
아닙니다. 기본 컴포넌트는 역할 정보를 제공할 수 있지만, 화면의 레이블·도움말·오류·상태가 실제 사용자 흐름에서 이해되는지는 별도 문제입니다. 직접 만든 요소나 조합한 UI는 특히 확인 대상입니다.
이 체크리스트로 접근성 적합성이나 스토어 심사를 보장할 수 있나요?
아닙니다. 이 글은 MVP 요구사항과 QA 기록을 정리하는 방법입니다. 적용 법령, 스토어 정책, 플랫폼 버전, 실제 앱 동작은 해당 시점의 공식 자료와 전문 검토, 기기 테스트를 기준으로 별도 확인해야 합니다.
확인한 공식 출처
Android Developers · Semantics — 2026-09-20 확인
Apple Developer · VoiceOver evaluation criteria — 2026-09-20 확인
Apple Developer · Supporting VoiceOver in your app — 2026-09-20 확인