널리

안녕하세요, 엔비전스입니다.

‘안드로이드 접근성을 고려한 XML 마크업 4부, 헤딩’에서는 네이티브 앱의 한 화면이 여러 영역으로 나누어져 있거나 그리드 뷰나 리스트 뷰와 같은 영역이 제공되는 경우에 스크린리더 사용자를 위한 제목을 제공하는 방법에 대해 살펴보았습니다.

이번 챕터부터는 안드로이드에서 제공하는 버튼, 체크박스, 라디오 버튼, 슬라이더 등의 여러 컨트롤의 접근성 이슈에 대해 살펴보도록 하겠습니다. 본 아티클은 그 첫 번째 세션으로 ‘버튼’에 대해 살펴보고자 합니다.

안드로이드 앱에서의 요소 유형(role)

스크린리더 사용자는 각 요소의 유형 및 상태 정보를 통하여 요소의 의미를 파악하므로 웹과 마찬가지로 모바일 네이티브 앱에서도 각 요소의 유형 정보를 적절하게 제공해 주는 것은 무엇보다 중요합니다. 그렇게 하지 않으면 임의 터치하거나 한 손가락 오른쪽 혹은 왼쪽 쓸기 등을 통해서 탐색되는 각 요소가 텍스트인지 이중 탭하여 활성화할 수 있는 요소인지, 또는 이중 탭할 경우 다른 화면으로 이동하는지 혹은 해당 요소가 체크되는지 등을 파악하기 어렵기 때문입니다.

물론 안드로이드에서는 접근성 API에서 각 view를 분석하여 클릭할 수 있거나 롱 클릭할 수 있다는 정보가 있으면 자동으로 활성화하려면 이중 탭하세요 등과 같은 힌트 메시지를 출력하여 이중 탭할 수 있다는 것을 사용자에게 알려줍니다. 그러나 이러한 힌트 메시지를 접근성 진단 시 꼼꼼하게 분석/수정해 주지 않으면 실제 클릭할 수 있는 요소가 아님에도 클릭 가능한 요소로 판단하여 힌트 메시지가 제공되는 경우도 있어 오히려 해당 힌트 메시지가 더 혼란스러울 수도 있습니다. 이러한 힌트 메시지의 커스터마이징에 대해서는 뒤의 챕터에서 자세히 다루겠습니다.

안드로이드에서의 버튼

웹페이지에서는 버튼과 링크를 명확하게 구분하여 마크업 하도록 권장하고 있습니다. 즉 링크는 A에서 B로 이동할 때 사용하며 버튼은 기능을 확장/축소하거나 무언가를 제출하거나 로그인 등을 하는 기능의 의미를 표시할 때 사용합니다. 그런데 모바일 앱에서는 웹과 달리 접근성 API에서 스크린리더 사용자를 위한 요소 유형 정보가 웹이나 윈도 애플리케이션만큼 다양하지 않습니다. 안드로이드에서는 접근성 API가 각 view에 마크업 된 클래스 정보를 요소 유형으로 처리하게 되는데 목록 항목, 메뉴 항목, 앱 뷰에서의 링크와 같은 다양한 요소 유형을 처리할 수 있는 클래스가 없기 때문에 실행할 수 있는 모든 view에 역할을 부여하는 것이 현재로서는 불가능합니다.

따라서 본 아티클에서 다루고 있는 ‘버튼’의 경우에도 웹 에서처럼 view를 확장/축소하거나 무언가를 제출하는 등의 액션에만 버튼을 적용해야 한다고 규정할 경우 접근성을 고려한 마크업에 많은 어려움이 발생하게 됩니다. 모바일 앱에서도 접근성 API에서 표현할 수 있는 역할(role)들이 웹이나 윈도 애플리케이션처럼 다양해지기 전까지는 모바일 앱에서의 버튼의 개념을 좀 더 확장할 필요가 있습니다. 즉 A에서 B로 이동하는 요소를 버튼이라고 읽어준다고 해서 요소 유형이 잘못 적용되었다고 보기는 어렵다는 것입니다.

버튼의 키보드 접근성

PC뿐 아니라 모바일에서도 필요에 따라 블루투스 키보드 등을 이용하여 앱을 조작하는 경우가 있습니다. 따라서 안드로이드에서 버튼을 구현할 경우에는 블루투스 키보드 등에서 탭 키를 누를 시 해당 버튼에 포커스가 되어야 하고 엔터나 스페이스로 실행할 수 있어야 합니다. 만약 커스텀 컨트롤을 버튼과 같이 구현했을 경우에는 웹페이지에서 커스텀 컨트롤을 버튼으로 구현 시 tabindex, keycode 이벤트를 추가해야 하듯이 안드로이드에서도 android:focusable=”true”를 적용하여 탭 키를 눌러 해당 버튼에 포커스 될 수 있도록 하고 onKey 메서드를 사용하여 엔터나 스페이스로 버튼이 실행될 수 있도록 해 주어야 합니다. 키보드 접근성을 추가로 구현해야 하는 대표적인 예는 onTouch 메서드입니다. 메서드 이름에서 알 수 있듯이 onTouch는 스마트폰을 터치했을 때만 실행되게 하는 메서드이기 때문에 해당 메서드를 사용할 경우에는 키보드로 버튼을 실행할 수 없습니다.

스크린리더 사용자를 위한 버튼 마크업

HTML을 마크업 할 때는 커스텀 컨트롤을 ‘버튼’으로 읽어주도록 해야 할 경우 WAI-ARIA의 role=”button”을 사용합니다. 그런데 안드로이드 네이티브 앱에서는 커스텀 컨트롤을 ‘버튼’으로 읽어주도록 하는 접근성 적용 방식이 잘 알려지지 않아 대체 텍스트로 ‘버튼’이라고 삽입하는 경우가 종종 있습니다. 이런 경우 톡백으로 한 손가락 쓸기 혹은 임의 터치를 통해 커스텀 뷰에 포커스 해서 요소의 유형 정보를 들었을 때는 아무런 문제가 없는 것처럼 보이지만 실제로는 몇 가지 문제가 있습니다.

1.      톡백에서 제공하는 컨트롤 단위 탐색을 사용할 수 없습니다. 톡백에서는 한 손가락 오른쪽 혹은 왼쪽 쓸기를 할 경우 기본적으로는 각 view를 순차 탐색하면서 각각의 view 내용 및 요소 유형, 상태 정보 등을 읽어주는데 한 손가락 위 또는 아래 쓸기 하면 컨트롤 요소가 부여된 view 단위로만 이동할 수도 있습니다. 이는 한 화면에 여러 view가 있을 경우 조금 더 빠르게 특정 요소로 이동할 수 있도록 만든 편의 기능입니다. 그런데 버튼 요소가 유형 정보로 잘 마크업 되어 있다면 톡백에서 컨트롤 단위로 이동 시에 각 버튼에 초점이 이동되지만 contentDescription 메서드를 활용한 글자로 버튼 등으로 요소 유형 정보를 제공하는 경우에는 접근성 API에서 요소 유형 정보를 파악할 수 없어 해당 버튼으로 이동해 주지 못합니다.

2.      톡백의 음성 안내 지원 설정에는 요소 유형 정보를 읽게 할 것인지 읽지 않게 할 것인지에 대한 설정이 있습니다. 만약 요소 유형 정보를 읽지 않도록 설정하면 버튼, 슬라이더, 체크박스와 같은 컨트롤 유형 정보는 읽지 않고 요소 텍스트 및 상태정보가 있는 경우 이 두 개만 읽게 됩니다.