[HIG] Accessibility (접근성)

 

 

접근성

- 애플의 접근성 기능은 사람들이 애플 기기를 사용할 때 개인 상황에 맞추어 개인화하여 이용을 보다 더 편리하게 사용할 수 있게 지원해주는 역할을 함.
- 특히 접근성은 '장애'를 고려해서 개인화를 할 수 있는데, 애플이 접근성을 고려하려는 이유가 대략 7명 중 한명은 장애를 갖고 있으며, 사람들은 선천적 장애 외에도 일상에서 경도가 다른 일시적 장애나 불편을 겪을 수 있기 때문이다. 애플의 접근성 개인화는 개인의 장애가 기기 사용에 주는 영향을 최대한 줄여주고자 한다.
 

 모범 사례

애플은 다음과 같은 항목을 접근성 모범 사례로 명시했다.
 
1. 접근성을 고려한 디자인

• 접근성은 단순히 장애를 가진 사람들이 사용할 수 있게 하는 것이 아니다.
• 어떠한 장애나 상황과 상관없이 "모든" 사람들이 사용할 수 있게 하고자 하는 것이 애플이 지향하는 접근성이다. 
• 접근성을 고려한 디자인은 "간단함" 과 "인지 가능성"을 우선시한 디자인이며, 매 요소마다 장애나 개인 상황에 따라 기기를 일반적인 방법에서 벗어나서 기기와 상호작용해야하는 사람들을 소외시키지 않음을 검증한 디자인이다.

 
간단함
복잡한 tasks를 간단하고 직관적이게 수행하는, 익숙하고 일관된 상호작용을 지원해야한다.
 
인지 가능성
사람들이 시각, 청각, 촉각 등에 구애받지 않고 디자인 된 모든 요소를 인지할 수 있어야 한다.
 
개인화 지원
사람들은 이미 기기를 구매하고 사용할 때 기기 취향, 화면 사이즈, 해상도, 색상 영역등의 개인화를 경험하기 때문에 해당 경험을 기기나 상황에 영향 받지 않고 즐길 수 있도록 고려한 디자인을 해야한다.
 
앱 감사 및 테스트 진행
접근성 테스트를 통해 접근성을 고려한 사용자 경험을 보다 더 안정적이게 개선 시킬 수 있다.
 
 

 

---

 

 
 

상호작용 (인터랙션)

 
- VoiceOver, Assistive Touch, Pointer Control, Switch Control같은 보조 기술은 사람들이 기기와의 상호작용할 수 있는 방법을 확장시켜준다.
- 이런 보조기술은 시스템에서 제공해주는 상호작용 방식을 통합하여 사용되기 때문에, 개발자는 올바른 방식으로 이러한 시스템 상호작용을 지원해주는 것이 중요하다.
 

Gesture

제스처 덮어쓰기는 NO
- 시스템을 작동 시키는 제스처를 사용하려고 할 때 겹쳐진 플랫폼(사용중인 앱의) 제스처 때문에 사용에 방해가 되어서는 안 된다. 단적인 예로, 어떤 앱을 쓰던 간에 아래로 스와이핑을 하면 알림센터가 나와야한다.
 
최대한 간단하게
- 일반적은 상호작용을 할 땐 간단하고 최소화된 제스처를 권장. 여러 손가락으로 화면 터치하기, 오래 누르기 등 현란한 제스처를 요구할 시 많은 사람들이 이용에 어려움을 겪을 수 있기 때문에 지양해야한다.
 
제스처 대안방안 제공
- 제스처로 제공되는 기능이 있다면, 제스처를 사용하지 않고도 사용할 수 있는 방안을 제시해야한다. 예시로, 리스트 항목에서 왼쪽으로 스와이핑 해서 삭제할 수 있다면, 스와이핑 하지 않고도 삭제할 수 있는 방법(편집 모드나 삭제 버튼)을 제공해야한다.
 
앱의 주요기능 접근엔 한 가지 방식 이상의 물리적 상호작용 제공
- 카메라에서 사진을 찍을 때 화면을 탭하거나 볼륨 버튼으로 찍을 수 있는 것처럼, 한 가지 이상의 방식을 제공하여 주요 기능을 약한 악력 등으로 사용할 수 없는 사람들도 사용할 수 있도록 앱의 주요 기능을 다양한 방법으로 사용할 수 있게 지원해주어야 한다.

 
 
--- 여기에 두 개 더 있는데, 위 내용과 같은 맥락의 내용이라 굳이 정리하지 않았다. 대신 생략한 부분인  VoiceOver, Dwell Control, and Switch Control 이나 drag-drop 기능에 대해 더 알아볼 필요가 있을 시 문서 다시 확인하기.
 
 

버튼과 컨트롤

hit target 영역은 충분한 크기로
- 터치 스크린에서 필요한 hit target 최소 크기는 44 x 44pt다. 

 
커스텀한 요소의 접근성을 특징화
- 시스템 api를 사용하여 해당 component이 어떻게 동작하는지 보조기술이 사용자에게 알려줄 수 있다.
 
버튼의 중요성 및 중요도를 일관된 스타일로 표현
- 가장 중요한 액션을 수행하는 버튼이면 시각적으로 채워진 스타일을 사용하여 강조거나 덜 중요한 액션을 수행하는 버튼엔 회색이나 일반적인 버튼 스타일을 적용하는 것과 같은 걸 의미한다. 즉, 버튼을 보는 것만으로도 해당 버튼의 액션과 중요성을 사용자가 쉽게 알 수 있어야한다.
 
시스템에서 제공한 스위치 구성 사용 권장(선호)
- SwiftUI와 같이 애플 시스템에선 이미 스위치(토글)의 상태를 knobs와 색 채우기 등으로 표시하고 있지만, 스위치 상태를 텍스트로 추가하여 일부 사용자의 상태 인식을 더 명확하고 쉽게 할 수 있다.
- 위와 같은 예시처럼, 시스템에서 제공하는 스위치를 사용하면 자동으로 'on/off' 상태가 표시 되어 접근성을 더 높일 수 있다.
 
링크에 색상 외 시각적 요소 추가하기
- 색상만으로 링크를 구별하려고 하면 색맹과 같이 인지에 어려움이 있는 사람들이 구분하기 힘들기 때문에 시각적 요소에 밑줄 등을 추가해주는 것이 좋다.
 
 

사용자 입력

음성입력 지원
- 텍스트 필드에 음성입력 버튼을 추가해서 사람들이 음성입력을 사용자 선호 입력 방식으로 쓸 수 있게 하자. 만약 커스텀한 키보드를 제공하고 있다면, 음성입력 기능을 추가했는지 확인할 것.
 
시리나 단축키 지원
- 음성으로 사용자 입력 시 시리나 단축키 지원을 고려해야한다.
 
일반텍스트 선택을 막지 말 것
- 가능하다면 사용자가 번역이나 정의를 확인하기 위해 일반 텍스트 선택을 막지 말아야한다.
 

햅틱

- 화면을 볼 수 없는 많은 사람들이 햅틱 기능을 사용하고 있기 때문에 시스템에서 정의한 햅틱 기능을 제공할 수 있다면 기능을 지원해주어야 한다.
 
 
 
 

---

 
 
 
 

보이스오버(VoiceOver)

- 보이스오버란 화면을 볼 수 없는 사람들에게 그들 역시 시각적 컨텐츠를 즐길 수 있도록 소리로 시각적 컨텐츠의 정보나 네비게이션을 제공해주는 기능이다.
 
--- visible contents에 어떻게 해야 더 많은 사람들이 평등하게 정보를 얻을 수 있는지는 문서가 너무 세세하게 정리해놓아서 내가 요약하는 것보단 필요 시 다시 문서를 보는 게 나을 것 같아 해당 디테일 부분은 생략했다.
 
 
 

 

---

 
 
 

텍스트 (Text Display)

- 텍스트는 폰트 사이즈 조절이 가능한 다이나믹 타입을 사용해야한다.
- 폰트 사이즈에 따라 텍스트 잘림 현상을 최소화해야한다. 긴 텍스트를 잘림현상 없이 보여줘야 한다면 numberOfLines 을 사용해서 효율적으로 나타낼 수 있다.
 

출처: 애플 문서

 
- 큰 폰트 사이즈를 사용할 때 텍스트 레이아웃을 스택 등을 활용해서 조정해야한다.

출처: 애플 문서

 
- 폰트 사이즈가 커지면 의미 전달을 하는 인터페이스 아이콘의 크기도 그만큼 커져야하는 걸 고려해야한다.
- 현재 글꼴 크기와 관계없이 일관된 정보전달 구조를 유지해야한다. 사람들이 전달되야하는 주요 정보를 한눈에 알아볼 수 있게 해야하기 때문!
- 앱에서 볼드체를 적용했을 시 올바르게 사용하여 사용자가 읽기 편한 지를 확인해야한다.
- 커스텀 폰트는 읽기 가능해야한다. 간혹 읽기 힘든 커스텀 폰트가 존재하기 때문에 이런 점을 고려해야 한다.
- 전체 정렬로 텍스트의 정렬 설정을 하면 텍스트에 집중해서 읽는 것이 힘들기 때문에 언어에 따라 왼쪽 및 오른쪽 정렬을 해야한다.
- 긴 텍스트 구절은 강조가 필요한 부분 외에 전체 텍스트에 이탈릭체나 대문자 사용을 지양해야한다.
- 가독성을 위해 애플이 가이드한 텍스트 두께를 활용할 것
* 추천 두께 : Regular, Medium, Semibold, bold
* 피해야하는 두께: UltraLight, Thin, Light
 
 
 
 

---

 
 
 
 
 

색상과 효과 (Color and effects)

- 객체 구분 및 주요정보를 전달할 때 색상 외 레이블이나 모양을 추가해서 모든 사람들이 해당 의미를 전달 받을 수 있게 해야한다.
- 색상 반전을 하거나대비를 변경 했을 때 올바르게 적용 되기 때문에 텍스트를 사용할 때 시스템 색상 사용을 선호하면 좋다.
- smart Invert를 했을 때 해당 색상 적용이 되어야 하는 대상에 맞게 올바르게 되는지 확인해야 한다. (사진, 영상, 어플 아이콘 등은 색상 반전이 되어서는 안된다)

출처: https://support.apple.com/en-mide/111773

 
- 읽는 것이 쉬울 수 있도록 색상 대비가 강한 컬러를 사용해야 한다. 특히, 가독성 보장을 위해 작거나 얇은 텍스트에 더 강한 대비가 필요하다.
 
- Reduce Transparency 기능에 대한 내용은 번역을 생략했다. 딱히 사용할 일이 없을 것 같아서.
 
 
 
 
 

---

 
 
 
 

모션 (Motion)

 
- 애니메이션이 꼭 필요하지 않다면 사용을 자제해야한다. 앱 사용 시 애니메이션에 좌지우지 되는 앱 개발을 지양할 것.
- 애니메이션을 원하지 않는 사용자가 Reduce Motion 기능을 설정하면 그에 맞게 애니메이션 효과가 대응 되어야 한다.
- 사용자가 영상 및 기타 모션 효과를 제어할 수 있게 해주어야 한다. 자동재생 되는 영상은 자제하고, 제어 버튼이나 원치 않는 모션을 제어할 수 있는 다른 대안 방안을 마련해야한다. 
- 움직이거나 깜빡이는 요소는 사람들에게 여러 장애를 일으키거나 어려움을 호소하게 만들 수 있기 때문에, 정보 전달의 유일한 방법으로 쓰여서는 안되고 그런 요소는 조심해서 적용해야한다.
 
 
 
 
 
 
 
 
Reference
 
https://developer.apple.com/design/human-interface-guidelines/accessibility

Accessibility | Apple Developer Documentation

 
https://support.apple.com/en-mide/111773

Use display and text size preferences on your iPhone, iPad, and iPod touch - Apple Support

 
 

---

 
 
요즘 실용적인 앱을 만들려면 어떤 걸 공부하고 고려해야하는 지에 고민을 해보다가, 언젠가 봐야지- 했던 애플의 HIG 문서를 뜯어보고 정리하며 공부해보기로 했다. 단순히 문서를 보고 내가 이해한 대로 번역하는 방식이긴 하지만, 그래도 공식에서 제시한 가이드를 전체적으로 보는 거라 꽤 의미 있는 작업이 될 것 같다.
 
최근 회사의 새 프로젝트에 참여하면서 기획이나 디자인 단계에서 iOS로 구현이 가능한지 해당 팀과 의견을 나눠야할 때가 오는데, 직접 구현해보기 전까진 나도 잘 모를 때가 있어서 앞으로 그런 상황에서 큰 도움이 되지 않을까.
 
그리고 이번에 정리하면서 텍스트 파트가 굉장히 공부가 되었다. 개인앱 업데이트 때 내가 놓쳤던 부분들을 조금 고려해봐야겠다.