티스토리 뷰

반응형

WWDC 2020 - Accessibility design for Mac Catalyst 를 본 기록 ✏️

 

Mac Catalyst 앱을 만들 때, ios에서 accessible하게 만들었다면,

그 앱을 mac으로 가져왔을 때도 accessible 해야합니다. 

 

 

iOS에서의 손가락이 

맥에서는 키보드이므로 (?) 

우리의 목표는 키보드로 다양한 기능을 제공해서 앱을 accessible하게 만드는 것입니다. 

 

[1] Keyboard focus 

 

첫번째로 고려해야하는 것은 keyboard focus 입니다. 

 

iOS에서 손가락으로 포커스를 이동했다면

맥에서는 키보드의 Tab 키로 포커스를 이동합니다. 

 

우선 설정 > 키보드 > Shorcuts로 가서 Use keyboard~~ 를 체크해줍니다.

그러면 keboard로 다른 control들간의 포커스를 이동시킬 수 있습니다. 

 

 

앞으로 가는 것은 Tab 키 / 뒤로 가는 것은 Shift + Tab 키라고 합니다. 

 

 

 

예제 앱으로 돌아와봅시다.

키보드에서 Tab 을 누르면 + 버튼에 focus ring이 생깁니다. 

이 ring은 add button이 keyboard focus를 가지고 있다는 것을 의미합니다. 

 

 

Space bar를 눌러봅시다. 버튼이 활성화가 되었습니다.  (+버튼을 눌렀다는 뜻인듯)

 

 

 

그리고 Tab 을 누르면 사이드바의 첫번째 아이템이 하이라이트 됩니다.

 

 

키보드의 up and down arrow key를 눌러서 

tableview의 selection을 바꿀 수 있습니다. 

 

 

마찬가지로 공유버튼 등 다른 컨트롤 등도 Tab 키로 이동할 수 있습니다. 

 

 

위에서처럼 up and down arrow key 로 tableview 또는 collectionview 의 selection을 바꿀 수 있게 하려면

selectionFollowsFocus를 true로 설정해줘야합니다. 

 

 

참고로 여기 예제는 tableView가 UISplitView의 sidebar이기 때문에 

selectionFollowFocus가 기본으로 true여서 위의 작업을 해줄 필요는 없습니다-!! 

 

 

[2] Keyboard Shortcuts 

 

단축키를 제공할 때 

사람들이 이미 익숙한 단축키를 제공하도록 합니다. 

 

 

우리 예제 앱에서는 share를 단축키로 제공하고 싶은데, 위의 가이드라인에 없습니다. 

그럴 때는 이미 나온 앱에 유사한 단축키가 있는지 봅니다.

사파리에서는 Command + I 가 share을 위한 단축키 조합이군요..! 

이거와 똑같이 해주겠습니다. 

 

 

이 단축키를 제공하기 위해서는 AppDelegate의 buildMenu function을 오버라이딩 해야합니다.

우선 UIKeyCommand로 단축키를 만들고 

EditMenu에도 나올 수 있게 해줍니다. 

 

 

그리고 iOS13.4부터 이런 API가 제공되는데

게임같은 것을 만들 때 유용할 것입니다. 

 

 

[3] Navigation Efficiency

 

사용자는 압도당하지 않고(?) navigation을 효율적으로 이동할 방법이 필요합니다. 

우리 예제 앱에서는 accessibility element가 26개 입니다. 

 

 

Voice Over 관점에서 accessibility tree가 이렇게 그려져있는 것이죠

 

 

iOS에서는 one by one이동을 touchscreen이라서 빨리 할 수 있지만

macOS는 빨리 이동하기 어렵습니다. 

 

이것을 어떻게 개선할 수 있을까요? 

메뉴판을 생각해봅시다.

연관된 section으로 카테고라이징되어있습니다. 

이것은 VoiceOver 사용자가 그룹간 네비게이션을 가능하게 해줍니다. (그룹안에 있는 개별적인 element로 네비게이션 하기 전에)

 

 

이 아이디어를 accessibility tree에도 그대로 적용시켜서 더 나은 navigation 경험을 제공해봅시다! 

accessibility element에 accessibility container type을 적용해서 그룹핑해줍니다. 

 

 

이렇게 하면 iOS에서랑 macOS랑 navigation이 다른데요

iOS에서는 next container의 first accessibility element 로 이동합니다. 

(하늘색 칠한 것을 보세요)

 

현재 위치

 

다음 이동
또 다음 이동 

 

 

반면 macOS는 accessibility container가 accessiblity element 처럼 동작합니다.

즉 다음으로 이동할 때 container의 첫번째 요소가 아니라 그냥 container로 이동한다는 뜻 입니다. 

 

현재 위치

 

다음 이동
또 다음 이동

 

그래서 사용자는 container를 이동할 지, 또는 container안에서 element를 이동할 지 선택할 수 있습니다.

 

 

이렇게 동작가능한 이유는 MacCatalyst에서의 accessibilty tree는

accessibility container를 사실상 서브 트리로 가지기 때문 입니다. 

 

 

여기서 핵심포인트는 Mac Catalyst의 accessibilty container는 accessibily element로 취급되는 것입니다. 

그래서 container에 accessibility label 같은 standard accessibilty properties를 설정해줘야합니다.

 

 

다시 예제 앱으로 돌아와봅시다.

container를 해주기 전의 모습이고 

 

 

container를 해준 후 모습입니다!  (26 -> 8로 visible elements가 줄었어요) 

 

 

 

[4] Accessibility Container 적용하기 

 

우선 위에서 나온 accessibility container를 더 살펴보겠습니다.

특정 경우에는 dataTable, list 등의 타입을 설정해주지만  

일반적으로 사용하는 것은 semanticGroup 입니다. 

 

우리는 semanticGroup을 쓸 것 입니다. 

 

 

그리고 위에서 말했듯이 Mac Catalyst의 accessibilty container는 accessibily element로 취급되므로 

container에 accessibility label를 설정해주는 것도 할 것입니다. 

 

우선 tableView에 accessibilty label을 세팅해줍니다. 

 

 

그리고 tableview에서 어떤 커피가 select 되었는 지 알려주는 label 도 설정해줍니다. 

(이거는 WWDC 19 - Writing Great Accessibility Labels 를 참고하라고 하네요) 

 

 

그리고 이런 stackview가 있다면 

 

 

이렇게 container 설정해주면 됩니다. 

 

 

[5] MacOS에서 Accessiblity 테스트하기 

 

iOS처럼 Accessibility Inspector를 사용해주면 됩니다.

 

 

아까 설정한 Container의 type이랑 Label도 볼 수 있습니다. 

 

 

 

반응형

'🍏 > Accessibility' 카테고리의 다른 글

[iOS] Visual Accessibility  (3) 2021.05.27
[iOS] Switch Control Accessibility  (0) 2021.05.26
[iOS] Great Accessibility Label  (1) 2021.05.25
[iOS] Dynamic Type  (0) 2021.05.21
[Accessibility] 접근성 테스트할때 알면 좋은 것들  (0) 2020.08.07
댓글