Apple: 손쉬운 사용
야곰닷넷: Accessibility & UITest
WWDC: Accessibility Inspector
WWDC: Writing Great Accessibility Labels
"웹의 힘은 그 광범위함에 있다. 장애에 관계 없이 모든 사람이 접근할 수 있다는 것이 절대적인 장점이다."
-팀 버너스 리-*
접근성이란, 사용자의 신체적 특성이나 지역,나이,지식수준,기술,체험과 같은 제한 때문에 제품,서비스를 이용함에 있어 불편하거나 사용할 수 없는 상황이 발생하는 정도를 뜻합니다
우리는 가능한 한 많은 사용자가 App을 불편함없이 이용할 수 있도록하는 것을 목표합니다
접근성을 지원한다는 것은, 장애인뿐만 아니라 성별,지역,나이 등을 모두 고려함을 의미합니다
Apple 제품들은 누구나 편리하게 이용할 수 있도록 '손쉬운 사용'이라는 이름으로 접근성을 적극적으로 지원합니다
크게 4가지 카테고리로 분류합니다
VoiceOverVoiceOver+점자콘텐츠 말하기동작 줄이기텍스트 크기디스플레이Siri다크 모드텍스트 표시확대/축소확대기받아쓰기오디오 설명대화 부스트소리 인식오디오 조정FaceTime아이폰용 보청기아이폰용 보청기: 실시간 듣기모노 오디오감각 알림청각 장애인용 자막소음 App음성 명령스위치 제어플랫폼 전환AssistiveTouch대체 입력뒷면 탭배경 사운드Safari 읽기 도구사용법 유도얼굴 인식나의 찾기iCloud 키체인





Swift에는 접근성 지원을 위한 API들이 존재합니다
UIAccessiblity는 App의 유저 인터페이스 요소에 대한 accessibility information 정보를 제공하는 informal protocol입니다
표준 UIKit control/view들에는 UIAccessibility 메서드들이 구현되어 있어 Assistive App들에 기본적으로 접근이 가능합니다
(Custom으로 UI를 만드는 경우, informal protocol인 UIAccessiblity는 직접 채택이 불가하므로 UIAccessibilityElement라는 class를 상속함으로써 접근성을 지원합니다)
UIAccessiblity의 핵심적인 프로토콜에 대해 알아봅시다
isAccessibilityElement : 접근성을 지원하는 요소인가?accessibilityLabel : 요소가 무엇인지 설명accessibilityValue : 요소의 값을 설명accessibilityTraits : 요소의 특징에 대한 값accessibilityHint : 요소의 실행 결과를 설명VoiceOver에 사용되는 정보를 정제하여 접근성을 개선시킬 수 있습니다
이 정보는 스토리보드로도, 코드로도 제공할 수 있습니다

UILabel 혹은 Label을 포함하는 UI 요소들은 accessibilityLabel를 별도로 설정하지 않아도 Label을 그대로 읽어주는 정도는 해줍니다

Label -> Value -> Trait -> Hint
단, Trait를 읽을 때 Static Text는 읽지 않으며 여러 trait을 설정했을 경우 차례대로 전부 읽습니다
텍스트들이 발음이 되는 단어거나 숫자라면 이해하여 읽습니다
(ex. 123 -> 백이십삼)
Label이 매우 길어서 끊어서 읽게 하고 싶다던지하는 특수한 경우는
WWDC Creating an Accessible Reading Experience 참고
🔘 '간단명료'해야 합니다
🔘 Context를 담아야 합니다
예로, 더하기 모양의 버튼에 대한 설명은 메모 App에선 '메모 추가하기', 스토어 App에선 '장바구니에 추가하기'가 될 수 있습니다
🔘 Element type은 넣지 않습니다
버튼, 이미지같은 Element type은 VoiceOver가 자동으로 읽으므로 Label에 포함시키지 말아야 합니다
🔘 UI가 바뀌면 Label도 바꿔야 합니다
UI에 변화가 생기면 Label도 그에 맞추어 변경해야 함을 기억해야 합니다
예로, 추가하기 버튼이 삭제하기 버튼으로 변경되었다면 그에 맞춰 Label도 변경해야 합니다
🔘 불필요한 표현과 중복을 피합니다
🔘 중요한 애니메이션에도 Label을 추가합니다
예로, 로딩 중임을 나타내는 spinner가 있습니다
🔘 웬만하면, 길지 않게 만들어야 합니다
길면 듣기 힘들다..
Dynamic Type을 지원하기 위해선 2가지 작업이 필요합니다

Label이 Dynamic Type을 지원하려면 2가지 방법이 있습니다
(1) Text Style Font를 사용하는 것이고
(2) System Font를 사용하되 UIFontMetrics로 추가 처리
2번 방법이 모든 경우에 합리적인 디자인이라 할 수는 없지만 preferredSize를 매우 크거나/작게 설정하고 싶을 때 유용합니다

마찬가지로 2가지 방법 중 하나를 선택하면 되고
버튼 titleLabel의 경우, 스토리보드에서 선택이 불가하므로 2번 방법으로 적용할 수 있습니다
자동으로 줄바꿈이 일어나도록 변경합니다
Lines 속성을 0으로 설정하면 텍스트 길이에 따라 line이 계속 늘어납니다

Xcode 13 부터는 UIButton의 size에도 기본적으로 Dynamic Type이 적용되어 있어 별도의 설정을 해줄 필요가 없습니다
단, 자동으로 적용되지 않는 예외적인 경우에 유의합시다
이 경우, 내부 titleLabel을 반드시 Text Style로 적용해주어야만 Button size에 Dynamic Type이 적용됩니다
일반적으로 스토리보드에 UI 요소를 '그냥' 배치해도 어느정도 동작하게 되는데, 그 이유는 Constraint가 없더라도 auto-resizing이 동작하기 때문입니다
이렇게 Constraint 기반이 아닌 auto-resizing을 기반으로 크기/위치가 설정된 Button은 Dynamic Type이 적용되지 않습니다
Button에 Constraint를 설정함으로써 해결할 수 있으며, 확인 방법은 아래 사진처럼 'Size Inspector'에서 View의 Layout을 Constraint로부터 추론하도록 설정되어 있으면 된 것입니다

우선 현재 인터페이스에 적용된 Dynamic Type 값은
traitCollection.preferredContentSizeCategory로 읽으면 됩니다
참고로, traitCollection는 UIView라면 모두 가지고 있는 프로퍼티입니다
(UIView가 UITraitEnvironment 프로토콜을 채택하며 가지는 프로퍼티이기 때문)
Dynamic Type는 App 전체적으로 적용되는 개념이므로 아무 View나 잡아 읽으면 됩니다
Accessibility Inspector로 audit을 하다보면 Contrast failed라는 경고를 볼 수 있습니다
대상이 Text라면 text color를 조정하여 Contrast를 키워줄 수 있으나
대상이 Image라면 별도의 image를 준비해야 합니다
또한, Text의 경우 작을수록 높은 Contrast를 주어야 가독성이 보장되므로 H.I.G에서 size 별 권장 Contrast 값을 제공하고 있습니다


Image Contrast 해결방법Contrast가 높은 별도의 Image를 준비하여 추가해야 합니다
유저는 '손쉬운 사용'에서 '대비 증가' 옵션을 on/off함에 따라 App에서 보일 Image를 선택할 수 있습니다
아래와 같이 Asset에 Contrast별 Image를 별도로 추가해줍니다

Accessibility Inspector에서도 'Increase Contrast' 옵션을 체크하여 테스트해볼 수 있습니다