Content Description: 개념, 원칙 및 접근성을 위한 설정 방법

접근성에서 Content Description이란

Content Description은 시각적 콘텐츠의 텍스트 표현을 보조 기술에 제공하는 UI 요소의 문자열 속성입니다. 스크린 리더(iOS의 VoiceOver, Android의 TalkBack)는 요소를 시각적으로 인식하려고 시도하는 대신 설명을 소리 내어 읽습니다. 설명은 텍스트 레이어가 없는 이미지, 아이콘, 차트, 사용자 정의 컨트롤 및 모든 비텍스트 요소에 적용됩니다.

Google Material Design, 2024에 따르면, contentDescription이 없는 요소는 WCAG 1.1.1(Non-text Content)을 위반합니다. Accessibility Scanner 검사에 따르면 쇼핑 앱의 최대 40% 아이콘에 설명이 없습니다. VoiceOver 사용자는 구체적인 내용 없이 “이미지” 또는 “버튼”만 듣게 되며, 이러한 인터페이스는 탐색에 사용할 수 없게 됩니다.

Content Description은 요소의 표시 텍스트를 대체하지 않습니다. 버튼에 “보내기” 텍스트 레이블이 포함된 경우 추가 설명을 설정할 필요가 없습니다. 스크린 리더가 텍스트를 읽어줍니다. 이미지, 아이콘 및 입력 필드의 경우 설명이 필수입니다.

Accessibility Scanner(Android) 및 Xcode Accessibility Inspector(iOS) 도구는 자동으로 설명의 존재를 확인합니다. 릴리스 전에 모든 화면에서 이러한 검사를 실행하는 것이 좋습니다.

Content Description이 중요한 이유: 사용자 시나리오

시각 장애가 있는 사용자는 인터페이스를 이해하기 위해 VoiceOver에 의존합니다. 쇼핑 카트 아이콘에 설명이 없으면 “버튼”만 듣게 됩니다. 버튼의 기능을 알기 위해 눈감고 탭해야 하며, 돌이킬 수 없는 작업의 위험이 있습니다. “카트에서 항목 제거”와 같은 설명은 1초 만에 이 문제를 해결합니다.

일시적 제약이 있는 사용자(야외의 강한 햇빛, 깨진 화면)도 VoiceOver를 사용합니다. Apple Accessibility Report, 2023에 따르면 VoiceOver 사용자의 약 20%는 영구적인 시각 장애가 없으며 상황에 따라 기능을 켭니다.

WCAG 1.1.1: 비텍스트 콘텐츠

WCAG 1.1.1(레벨 A)은 모든 비텍스트 콘텐츠에 텍스트 대체 수단이 있어야 한다고 요구합니다. 예외: 장식용이거나 시각적 표현에만 사용되거나 정보를 전달하지 않는 콘텐츠. 장식성 테스트: 요소를 제거하면 페이지의 의미가 바뀌나요? 그렇지 않다면 스크린 리더에서 숨길 수 있습니다.

Content Description과 Label의 차이점

Accessibility Label(iOS의 accessibilityLabel)은 포커스 시 스크린 리더가 발음하는 요소 이름입니다. Content Description(iOS의 accessibilityHint)은 이름 뒤에 읽히는 추가 설명으로, 작업 결과를 알려줍니다.

차이점은 “카트” 버튼 예시에서 명확합니다. Label: “카트”. Description: “결제 화면을 엽니다”. VoiceOver: “카트. 결제 화면을 엽니다”. Label만 설정된 경우 사용자는 탭 후에 무슨 일이 일어날지 알 수 없습니다.

표: Label 대 Description

규칙: Label은 “이게 뭐죠?”에 답하고, Description은 “무슨 일이 일어날까요?”에 답합니다. Android에서 contentDescription은 두 역할을 모두 수행할 수 있지만, 실제로는 “[이름], [설명]” 연결 형태로 분리하는 것이 좋습니다.

Description이 Label보다 더 중요한 경우

복잡한 제스처(스와이프하여 삭제, 길게 눌러 컨텍스트 메뉴)의 경우 accessibilityHint가 필수입니다. VoiceOver 사용자는 설명되지 않은 숨겨진 제스처를 알 수 없습니다. 요소의 hint에 “삭제하려면 왼쪽으로 스와이프”를 지정합니다.

iOS: accessibilityHint 속성

iOS 플랫폼에서 accessibilityHint는 UIView 또는 NSObject의 동일한 이름의 속성을 통해 설정됩니다. 값은 최대 80자의 문자열입니다. VoiceOver는 자세한 설명 모드가 활성화된 경우(VoiceOver 설정의 “Verbosity”) 레이블 뒤에 hint를 읽습니다.

사용자 정의 버튼에 hint 설정 예시:

import UIKit

class CustomButton: UIButton {
    override func awakeFromNib() {
        super.awakeFromNib()
        self.accessibilityLabel = "즐겨찾기에 추가"
        self.accessibilityHint = "항목을 즐겨찾기 목록에 저장합니다"
    }
}

텍스트 콘텐츠가 없는 UIImageView의 경우 isAccessibilityElement = true와 accessibilityHint를 설정해야 합니다:

let imageView = UIImageView(image: UIImage(named: "chart-sales"))
imageView.isAccessibilityElement = true
imageView.accessibilityHint = "지난 분기의 판매 차트"

VoiceOver 읽기: “지난 분기의 판매 차트”. hint가 비어 있으면 “이미지”만 읽습니다. Apple HIG, 2024는 hint에 “탭”이나 “누르기” 같은 동사를 사용하지 말 것을 권장합니다. VoiceOver가 자동으로 제스처 지침을 추가합니다.

SwiftUI: accessibilityHint 수정자

SwiftUI에서 hint는 체인 수정자를 통해 설정됩니다:

Image(systemName: "trash")
    .accessibilityLabel("삭제")
    .accessibilityHint("선택한 항목을 영구적으로 삭제합니다")

SwiftUI는 자동으로 복합 뷰의 수정자를 결합합니다. Image가 Button 내부에 있는 경우 SwiftUI는 버튼 레이블을 기본 accessibilityLabel로 사용합니다.

Android: contentDescription 속성

Android에서 contentDescription은 XML 마크업에서 또는 프로그래밍 방식으로 setContentDescription()을 통해 설정됩니다. TalkBack은 요소에 포커스가 갈 때 설명을 읽어줍니다.

XML 예시:

<ImageView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:src="@drawable/ic_search"
    android:contentDescription="제품 검색" />

동적 요소를 위한 프로그래밍 방식 설정:

binding.iconSearch.contentDescription =
    "검색. 필터가 있는 검색 화면을 엽니다"

장식 이미지(구분선, 배경, 장식 아이콘)의 경우 contentDescription = "@null" 또는 setContentDescription(null)을 설정합니다. TalkBack이 이러한 요소를 건너뜁니다. XML에서: android:contentDescription="@null". 빈 문자열 ""은 작동하지 않습니다. TalkBack이 여전히 “이미지”를 읽습니다.

Android: ImageButton 및 CheckBox에 대한 중요한 세부 사항

ImageButton의 경우 항상 contentDescription을 설정하세요. TalkBack은 이미지의 텍스트를 볼 수 없습니다. CheckBox의 경우 설명이 동적으로 변경되어야 합니다. 정적 설명 대신 “선택됨” / “선택되지 않음”을 사용합니다. 상태 리스너에서 setContentDescription을 사용합니다.

설명 작성 규칙

정보성 — 설명은 외형이 아닌 의미를 전달해야 합니다. “체크 표시가 있는 파란색 아이콘”이 아니라 “항목이 카트에 추가되었습니다”. 스크린 리더는 색상에 관심이 없으며 결과에 관심이 있습니다.

간결성 — 최적의 길이는 2~4단어(최대 80자)입니다. 긴 설명은 탐색 속도를 늦춥니다. VoiceOver는 순차적으로 읽으며, 각 단어는 사용자 시간의 1초입니다. Apple WWDC 2023, “Accessibility by Design”에 따르면 읽는 데 5초 이상 걸리는 구문은 인지 흐름을 방해합니다.

고유성 — 같은 화면에 동일한 설명을 가진 두 요소가 있어서는 안 됩니다. 사용자는 첫 번째 요소와 두 번째 요소에 포커스했을 때의 결과를 구분할 수 없습니다. 여러 “구매” 버튼이 있는 경우 식별자를 추가합니다: “iPhone 15 구매”, “iPhone 15 Pro 구매”.

지역화 — Content Description은 앱이 지원하는 모든 언어로 번역되어야 합니다. 설명의 지역화 오류는 App Store에서 Accessibility Review가 실패하는 일반적인 원인 중 하나입니다.

설명 길이: 연구

Nielsen Norman Group, 2024의 연구에 따르면 스크린 리더에 최적의 설명 길이는 3~5단어(최대 50자)입니다. 더 긴 설명은 사용자가 다음 단계 전에 읽기가 끝날 때까지 기다려야 하므로 탐색 속도가 30% 감소합니다.

사용 시 일반적인 실수

중복 — 설명이 표시 텍스트를 복제합니다. 버튼에 “보내기” 텍스트가 포함된 경우 accessibilityHint = “보내기 버튼”을 설정하지 마세요. VoiceOver가 자동으로 텍스트를 읽고 hint는 불필요한 노이즈를 추가합니다.

Label과의 혼동 — 텍스트 버튼에 레이블 대신 contentDescription을 사용하는 경우. iOS에서 accessibilityLabel은 버튼 텍스트와 일치해야 하며(텍스트가 이미 표시된 경우 비어 있을 수 있음), hint는 작업만 설명해야 합니다. Google Testing Blog, 2024에 따르면 Play Store에서 검토된 앱의 23%에 중복 설명이 있습니다.

동적 변경 무시 — 상태가 변경되어도 설명이 업데이트되지 않습니다. 예를 들어 “Wi-Fi” 토글의 설명이 켠 후에도 “Wi-Fi 활성화”로 남아 있습니다. 올바른 방법: 상태를 관찰하여 설명을 동적으로 “Wi-Fi 비활성화”로 변경합니다.

렌더링 사이클 및 회귀

디자인 업데이트(아이콘 변경, 요소 재배열) 후 Content Description이 자주 손실됩니다. 이유: 디자이너가 이미지를 교체하고 개발자가 새 에셋의 접근성 속성을 확인하지 않기 때문입니다. 해결책: 코드 리뷰에서 접근성 검사를 필수 단계로 만듭니다. 체크리스트 항목에 “Content Description이 업데이트되었나요?”를 추가합니다.

Content Description 확인 방법

• iOS: Xcode → Accessibility Inspector — 요소 선택, Label 및 Hint 필드 확인
• Android: Play Store에서 Accessibility Scanner 설치 — 화면에서 실행
• 두 플랫폼 모두: VoiceOver/TalkBack 활성화하고 제스처로 전체 화면 탐색
• 모든 ImageView의 contentDescription을 확인하는 UI 테스트 작성

iOS용 UI 테스트 예시

func testContentDescriptionExists() {
    let app = XCUIApplication()
    app.launch()
    let image = app.images["chart-sales"]
    XCTAssertNotNil(image.label)
    XCTAssertGreaterThan(image.label.count, 0)
}