DEV_Larva
Foundations - Accessibility(접근성) 본문
Apple의 손쉬운 사용 기능을 사용하여 자신에게 맞는 방식으로 기기와 상호 작용하는 방식을 개인화한다.
유튜브를 보다 보면 장애인 분들은 어떻게 스마트폰을 이용하는지 어렵지 않게 찾을 수 있는데 가장 메인이 되는 기능은 개인적으로 기존에도 알고 있던 VoiceOver라고 생각한다. 특히 해당 기능은 시각 장애인 분들에게는 꼭 필요한 기능이라고 생각한다. 이것 말고도 더 자세히 알아보고 공부해보는 시간을 가져 보자.
1. Best practices
- 접근성을 염두에 두고 디자인.
앞서 말했듯이 접근성은 장애인에게 꼭 필요한 정보 제공 방법이지만 일반인 또한 정보를 사용할 수 있도록 하는 것이다. 그래서 항상 앱을 디자인할 때는 단순함, 인지 가능성을 우선시에 두고 설계를 하는 것이 중요하다고 한다. 그렇게 함으로써 디바이스와 상호 작용을 하는 방식이 다른 사람들을 소외시키지 않는다는 것을 의미한다.
- 개인화를 지원
사용자들이 다양한 상황과 장치에서 즐길 수 있기를 원하고 있기 때문에 디바이스의 방향, 화면 크기, 해상도, 색 영역과 같은 변화에 적응하도록 디자인을 하자. 이를 위해 사용자가 디바이스와 상호 작용하는 방식을 개인화하는 데 사용하는 접근성 기능을 지원하도록 앱을 디자인하여야 한다.
- 접근성을 위해 앱을 심사하고 테스트
심사는 사용자가 앱을 사용하며 얻는 경험의 모든 요소를 검사하게 되며 해결해야 하는 문제 목록을 제공한다. 그래서 테스트를 통해 모든 사람이 디바이스와 상호 작용하는 방식에 구애받지 않고 중요한 목표 작업까지 완료할 수 있는지를 확인할 수 있다.
심사와 테스트를 통해 앱의 중요한 사용자 흐름에 대해 VoiceOver, 텍스트 크기 키우기와 같은 접근성 기능을 켜서 모든 작업을 완료할 수 있는지 확인할 수 있다.
2. Interactions (상호 작용)
2.1. 제스처
- 플랫폼 제스처를 무시하지 마세요.
- 사람들은 아래로 밀어 알림 센터를 확인하거나 시스템 설정에서 사용할 수 있는 시스템 제스처가 사용 중인 앱과 상관없이 작동할 것이라고 기대한다.
- 일반적인 상호 작용에는 단순화된 제스처를 선호.
- 여러 손가락 제스처, 길게 누르기, 반복적으로 버튼 누르기와 같이 복잡한 제스처는 많은 사람들에게 어려울 수 있다. 최대한 간단한 제스처를 사용하여 앱과 사용자 간의 경험 난이도를 낮추자.
- 제스처 기반 작업을 수행하는 다른 방법을 제공.
- 특정 동작을 수행할 수 없는 사람들을 위한 옵션을 포함합시다. 예를 들어 스와이프 해서 행을 삭제하는 경우 편집 모드의 삭제 버튼을 제공하여 항목을 삭제하는 방법을 제공할 수도 있다.
- 최소 두 가지 이상의 물리적 상호 작용 유형을 이용해 앱의 핵심 기능에 접근 가능한 기회 제공
- 예를 들면 카메라 화면의 버튼을 터치하거나 디바이스의 볼륨 조절 기능을 통해 사진을 찍을 수 있는 거처럼 2가지 이상의 물리적 상호 작용이 가능하도록 제작해야 한다.
- iOS 앱에서 끌어서 놓기에 액세스 가능.
- 접근성 API를 이용하여 앱에서 드래그 소스 및 드롭 대상을 식별할 때 보조 기술을 사용하면 사용자들이 화면 항목을 드래그 앤 드롭하는데 도움이 될 수 있다.
2.2. 버튼 및 컨트롤
- 모든 터치스크린 컨트롤과 대화형 요소에 최소 44 x 44pt를 측정하는 적중 대상을 지정.
- 이동성이 제한된 사용자는 앱과 상호 작용할 수 있도록 더 큰 적중 대상이 필요합니다. 사람들이 포인터를 사용하는 경우에도 모든 플랫폼에서 너무 작은 컨트롤과 상호 작용하는 것은 실망스러울 수 있습니다.
- 맞춤 요소의 접근성을 특성화.
- 시스템 API를 사용해 구성 요소의 작동 방식을 보조 기술에 알릴 수 있다. 예를 들어 VoiceOver가 뷰의 설명을 말한 다음 버튼이라는 단어를 말하며 뷰가 버튼처럼 작동함을 사람들에게 알리는 것을 말한다.
- 일관된 스타일 계층 구조를 사용하여 버튼의 상대적 중요성을 전달.
- 버튼 스타일의 일관된 계층 구조를 사용하면 사람들은 모양을 기반으로 버튼의 중요성을 파악할 수 있습니다. 예를 들어 iOS, iPadOS 및 tvOS에서는 뷰에서 가장 가능성이 높은 작업을 수행하는 버튼에 시각적으로 눈에 띄는 채워진 스타일을 사용하고 덜 중요한 작업을 활성화하는 버튼에는 회색 또는 일반 스타일과 같이 덜 눈에 띄는 스타일을 사용할 수 있습니다. (이거는 primary, secondary와 같은 것을 말하는 것 같다.)
- 시스템 제공 스위치 구성 요소를 선호.
- SwiftUI는 노브의 위치와 채우기 색상으로 상태를 나타내는 스위치를 제공합니다. 그러나 일부 사람들에게는 레이블을 추가하면 스위치가 켜져 있는지 꺼져 있는지 더 쉽게 인식할 수 있습니다.
2.3. 사용자 입력
- 사람들이 입력하는 대신 말로 정보를 입력 가능.
- 텍스트 입력 필드에 받아쓰기 버튼을 추가하면 사람들이 선호하는 입력 방법으로 음성을 선택할 수 있습니다. 사용자 정의 키보드를 생성하는 경우 받아쓰기용 마이크 키를 포함해야 합니다.
- 음성만으로 중요한 작업을 수행할 수 있도록 Siri 또는 바로 가기를 지원.
- 가능하면 사람들이 일반 텍스트를 선택하는 것을 막지 마십시오.
- 많은 사람들이 선택한 텍스트를 번역 및 정의 입력으로 사용합니다.
2.4. 햅틱
- 시스템 정의 햅틱을 지원.
- 많은 사람들이 화면을 볼 수 없을 때 앱과 상호 작용할 수 있도록 햅틱에 의존합니다. 예를 들어 시스템 앱은 작업이 성공 또는 실패하거나 이벤트가 발생하려고 할 때 사람들에게 알리기 위해 햅틱을 재생합니다. 사람들을 혼란스럽게 하지 않도록 앱에서 시스템 정의 햅틱을 일관되게 사용해야 한다.
3. VoiceOver
3.1. 콘텐츠 설명
- 의미를 전달하는 모든 이미지에 대해 대체 설명을 제공.
- 콘텐츠에 의미 있는 이미지를 설명하지 않으면 VoiceOver 사용자가 앱을 충분히 경험하지 못하게 됩니다. 유용한 설명을 만들려면 먼저 이미지를 볼 수 있는 사람에게 설명이 필요 없는 내용을 보고하세요. VoiceOver는 이미지 주변의 텍스트와 캡션을 읽기 때문에 이미지 자체가 전달하는 정보에 설명을 집중하십시오.
- 인포그래픽에 완전히 액세스.
- 전달하는 내용을 설명하는 인포그래픽에 대한 간결한 설명을 제공합니다. 사람들이 인포그래픽과 상호 작용하여 더 많거나 다른 정보를 얻을 수 있는 경우 이러한 상호 작용을 VoiceOver 사용자도 사용할 수 있도록 해야 합니다. 접근성 API는 사용자 지정 대화형 요소를 표현하는 방법을 제공하므로 보조 기술을 통해 사람들이 이를 사용할 수 있습니다.
- 이미지가 순전히 장식용이고 어떤 것도 전달하기 위한 것이 아닌 경우 보조 기술에서 숨김.
- VoiceOver가 순전히 장식적인 이미지를 설명하도록 만들면 사람들의 시간을 낭비하고 아무런 이점도 제공하지 못한 채 인지 부하를 가중시킬 수 있습니다.
- 각 화면에 고유한 제목을 지정하고 정보 계층에서 섹션을 식별하는 제목을 제공.
- 사람들이 화면에 도착하면 제목은 보조 기술에서 받는 첫 번째 정보입니다. 사람들이 앱의 구조를 이해하는 데 도움이 되도록 콘텐츠나 목적을 간결하게 설명하는 각 화면의 고유한 제목을 만드세요. 마찬가지로 사람들은 각 화면의 정보 계층 구조에 대한 정신적 지도를 구축하는 데 도움이 되는 정확한 섹션 제목이 필요합니다.
- 모두가 비디오 및 오디오 콘텐츠를 즐길 수 있도록 도움.
- 폐쇄 캡션, 오디오 설명 및 대본을 제공하면 사람들이 오디오 및 비디오 콘텐츠를 자신에게 맞는 방식으로 활용할 수 있도록 도울 수 있습니다.
3.2. 내비게이션
- VoiceOver 사용자가 모든 요소를 탐색할 수 있는지 확인.
- VoiceOver는 화면 요소의 접근성 정보를 사용하여 사람들이 각 요소의 위치와 수행할 수 있는 작업을 이해하도록 돕습니다. 시스템 제공 UI 구성요소에는 기본적으로 이 접근성 정보가 포함되어 있지만 정보를 제공하지 않는 한 VoiceOver는 사람들이 사용자 정의 요소를 찾고 사용하는 데 도움을 줄 수 없습니다.
- 요소를 그룹화, 정렬 또는 연결하는 방법을 지정하여 VoiceOver 환경을 개선.
- 근접성, 정렬 및 기타 상황별 신호는 정안인이 화면 요소 간의 관계를 인식하는 데 도움이 될 수 있지만 이러한 신호는 VoiceOver 사용자에게는 적합하지 않습니다. 요소 간의 관계가 시각적인 경우에만 앱을 검사하고 이러한 관계를 VoiceOver에 설명합니다.
- 화면 콘텐츠나 레이아웃이 변경되면 VoiceOver에게 알림.
- 콘텐츠 또는 레이아웃의 예기치 않은 변경은 화면의 정신적 지도가 더 이상 정확하지 않음을 의미하기 때문에 VoiceOver 사용자에게 매우 혼란스러울 수 있습니다. VoiceOver 및 기타 보조 기술이 사람들이 화면에 대한 이해를 업데이트하는 데 도움이 되도록 화면 변경 사항을 보고하는 것이 중요합니다.
- 필요한 경우 VoiceOver 로터를 지원하십시오.
- VoiceOver 사용자는 로터라고 하는 화면 컨트롤을 사용하여 제목, 링크 또는 기타 섹션 유형별로 문서 또는 웹 페이지를 탐색할 수 있습니다.
- 모든 중요한 인터페이스 요소에 대한 대체 텍스트 레이블을 제공.
- 대체 텍스트 레이블은 화면에 표시되지 않지만 VoiceOver가 화면 요소를 소리로 설명하도록 하여 시각 장애가 있는 사용자가 더 쉽게 탐색할 수 있도록 합니다. 시스템 제공 컨트롤에는 기본적으로 유용한 레이블이 있지만 사용자 지정 요소에 대한 레이블을 만들어야 합니다.
4. Text display (텍스트 표시 )
- 글꼴 크기가 커지면 텍스트 잘림을 최소화.
- 일반적으로 가장 큰 표준 글꼴 크기만큼 유용한 텍스트를 가장 큰 접근성 글꼴 크기로 표시하는 것을 목표로 합니다. 사람들이 콘텐츠의 나머지 부분을 읽기 위해 별도의 보기를 열 수 있는 경우가 아니면 스크롤 가능 영역에서 텍스트를 자르지 마십시오. 유용한 양의 텍스트를 표시하는 데 필요한 만큼의 줄을 사용하도록 레이블을 구성하여 레이블의 텍스트 잘림을 방지할 수 있습니다.
- 큰 글꼴 크기에서 레이아웃 조정을 고려.
- 글꼴 크기가 커지면 인라인 항목과 컨테이너 경계로 인해 텍스트가 꽉 차서 가독성이 떨어집니다. 예를 들어 글리프 또는 타임스탬프와 같은 보조 항목과 함께 텍스트를 인라인으로 표시하면 텍스트의 가로 공간이 줄어듭니다. 큰 글꼴 크기에서 인라인 레이아웃으로 인해 텍스트가 잘리거나 텍스트와 보조 항목이 겹칠 수 있습니다. 이 경우 텍스트가 보조 항목 위에 표시되는 스택 레이아웃을 사용하는 것이 좋습니다.
- 글꼴 크기가 커질수록 의미 있는 인터페이스 아이콘의 크기가 커짐.
- 인터페이스 아이콘을 사용하여 중요한 정보를 전달하는 경우 더 큰 글꼴 크기에서도 쉽게 볼 수 있는지 확인하십시오. SF 기호를 사용하면 동적 유형 크기 변경에 따라 자동으로 크기가 조정되는 아이콘을 얻을 수 있습니다.
- 현재 글꼴 크기에 관계없이 일관된 정보 계층 구조를 유지.
- 예를 들어 글꼴 크기가 매우 큰 경우에도 주요 요소를 화면 상단에 배치하여 사람들이 이러한 요소를 놓치지 않도록 합니다.
- 앱에서 일반 또는 무거운 글꼴 두께를 선호.
- 일반, 중간, 세미 볼드 또는 볼드 글꼴 두께를 사용하면 더 쉽게 볼 수 있습니다. 보기 어려울 수 있는 Ultralight, Thin 및 Light 글꼴 두께는 피하십시오.
5. Color and effects (색상 및 효과)
- 물체를 구별하거나 중요한 정보를 전달하기 위해 색상에만 의존하지 않음.
- 색상을 사용하여 정보를 전달하는 경우 모든 사람이 정보를 인식할 수 있도록 텍스트 레이블이나 글리프 모양을 제공해야 합니다.
- 텍스트에 대해 시스템 색상을 선호.
- 텍스트에서 시스템 색상을 사용하면 색상 반전 및 대비 증가와 같은 접근성 설정에 올바르게 반응합니다.
- 대비가 강한 색상을 사용하여 가독성을 높임.
- 글꼴 크기와 무게, 색상 밝기, 화면 해상도, 조명 조건 등 많은 요소가 색상 인식에 영향을 미칩니다. 텍스트, 글리프 및 컨트롤과 같은 시각적 요소의 색상 대비를 높이면 더 많은 사람들이 더 많은 상황에서 앱을 사용하도록 도울 수 있습니다.
- 경험에 필수적인 경우가 아니면 애니메이션을 요구하지 않음.
- 일반적으로 사람들이 애니메이션에 의존하지 않고 앱을 사용하도록 합니다.
- 사람들이 투명도 감소를 켤 때 흐림 및 투명도를 변경.
- 예를 들어 흐릿한 콘텐츠 영역과 반투 명도를 대부분 불투명하게 만듭니다. 최상의 결과를 얻으려면 영역이 흐리거나 반투명할 때 사용한 원래 색상 값과 다른 불투명 영역의 색상 값을 사용하십시오.
오늘은 HIG의 가장 기본 요소 중 하나인 접근성에 대해 알아보았다. 정말 이렇게 하나하나 읽으며 공부하다 보니 생각보다 더 깊고, 폭넓게 작용하는 것을 알게 된 것 같다. 그리고 각 요소 하나하나에 의미를 부여하고 사용자 경험을 중시하는 것을 보았을 때 애플이 왜 HIG를 강조하는지도 알 것 같다. 그리고 중간중간 내가 만들고 있던 앱들에서도 고쳐야 할 부분들이 보였기도 했는데 예를 들면 행을 삭제하려고 스와이프 하는 것 말고도 다른 방법을 제공하는 것과 같이 앞으로도 계속 공부를 해보면서 경험치를 쌓아가야겠다. 오늘의 HIG는 여기까지~!👏
Accessibility - Foundations - Human Interface Guidelines - Design - Apple Developer
Accessibility People use Apple’s accessibility features to personalize how they interact with their devices in ways that work for them. An accessible app or game supports accessibility personalizations by design and gives everyone a great user experience
developer.apple.com
'iOS > HIG' 카테고리의 다른 글
| Foundation - Color (2) | 2023.01.29 |
|---|---|
| Foundation - Branding (0) | 2023.01.16 |
| Foundations - App icons (0) | 2022.12.22 |
