기본 widget 을 사용하면 기본접근성을 제공한다.
하지만 커스텀위젯을 사용하는경우 접근성을 작업해줘야한다.
접근성 ?
우리가 의도한 Present 를 사용자가 action 하도록 하는게 접근성이다.
ex) 음성안내 지원 - 시작정보 + 시각장애인에겐 음성으로 제공
이런식으로 안드로이드 프레임웤을 이용해, 사용자에게 맞는 접근성을 제공해야 한다.
장애인에 대한 접근성 제공은 옵션이 아닌 의무라고 표현하는듯 하다.
인터페이스에
AccessibilityNodeInfo : 화면에 표시 되는것
텍스트, 이미지 등 뷰를 의미한다. (정보의 캡쳐)
AccessibilityEvent : 사용자가 반응하여 UI내의 명령(질의)를 날리는 행위
AccessibilityAction : 스크롤, 클릭, 길게누르기같은것
ViewPager2(RecyclerView)
페이지를 전환해주는 뷰, VP2 에 접근성을 녹여내는 과정에 대한 설명이다.
AccessibilityEvent 를 통해, 아래와 같은 접근성을 만들게된다.
페이지 변경경이 있을때마다 이전, 다음에 대한 기록을 해준다.
그러면
AccessibilityNodeInfo 에 2가지의 이벤트가 추가되고, 이전/다음 으로 넘길수 있는지 없는지를 제공하게된다. (우리는 시각장애인인것을 늘 염두해두고 이 설명을 봐야합니다.)
사실은 뷰에서 이전 접근성노드에 이전 스크롤 이벤트에 대한 대한 정보를 지워줘야한다.
VP 는 가로/세로가 있긴하지만, 방향이란건 없어서, 이부분에 대한 고민이 시작된다.
(ex : Top to Bottom,Right to Left )
사용자가 페이지 전환을 위해 어떻게 해야할지에 대해서 설명이 필요하다는것이다.
논리방향, 절대방향
페이지 카운트 (기존에는 없었는데, 이제는 들어옴)
onInitializeAccessibilityNOdeInfo( info ) {
// collection Info 에 대해서 알아야한다.( 접근성노드 정보상의 객체)
AccessiblityNodeInfoCompat.wrap(info)
}
하위뷰를 갖는 공통무도뷰가 알게되는 info 인데,
AccessiblityNodeInfo 는 플랫폼에 있는 API이고,
AccessiblityNodeInfoCompat 는 androidX 에있는 API 라 API19 지원이 가능.
그동안 뷰페이저에서는 페이지수가 업데이트 되지 않고있따는걸 알게됐다.
뷰페이저는 모르지만, RV는 스스로 처리한다. (접근성은 VP에 제공되는것인데, RV의 변화는 대상이 아니었었다.)
하여, VP에 접근성 쿼리를 날려도 RV변화가 감지되지않아, 접근성업데이트가 안됐던것
접근성에 대해서 아직 혼란스러운건 알겠따. SCROLL_FOWARD vs PAGE_RIGHT 같은;;
이런 것들은 레거시라;;API복잡해,
커스텀을 사용할수록, 사용자에게 의도된 접근성을 제공해줘야하는 이유는 커지는데
뷰페이저처럼 쉽게할수도있지만, 커스텀뷰보단 일반뷰를 써라-
테스팅
자주 되는게아니어서 로직짜다보면 간과하기 좋다.
접근성서비스의 차이 : 음정안내, 스위치제어
https://www.youtube.com/watch?v=AdTzK7xHPSc
기본 widget 을 사용하면 기본접근성을 제공한다. 하지만 커스텀위젯을 사용하는경우 접근성을 작업해줘야한다.
접근성 ?
우리가 의도한 Present 를 사용자가 action 하도록 하는게 접근성이다. ex) 음성안내 지원 - 시작정보 + 시각장애인에겐 음성으로 제공
이런식으로 안드로이드 프레임웤을 이용해, 사용자에게 맞는 접근성을 제공해야 한다.
인터페이스에
ViewPager2(RecyclerView)
사실은 뷰에서 이전 접근성노드에 이전 스크롤 이벤트에 대한 대한 정보를 지워줘야한다.
VP 는 가로/세로가 있긴하지만, 방향이란건 없어서, 이부분에 대한 고민이 시작된다. (ex : Top to Bottom,Right to Left ) 사용자가 페이지 전환을 위해 어떻게 해야할지에 대해서 설명이 필요하다는것이다.
논리방향, 절대방향
페이지 카운트 (기존에는 없었는데, 이제는 들어옴)
onInitializeAccessibilityNOdeInfo( info ) { // collection Info 에 대해서 알아야한다.( 접근성노드 정보상의 객체) AccessiblityNodeInfoCompat.wrap(info) } 하위뷰를 갖는 공통무도뷰가 알게되는 info 인데, AccessiblityNodeInfo 는 플랫폼에 있는 API이고, AccessiblityNodeInfoCompat 는 androidX 에있는 API 라 API19 지원이 가능.
그동안 뷰페이저에서는 페이지수가 업데이트 되지 않고있따는걸 알게됐다. 뷰페이저는 모르지만, RV는 스스로 처리한다. (접근성은 VP에 제공되는것인데, RV의 변화는 대상이 아니었었다.) 하여, VP에 접근성 쿼리를 날려도 RV변화가 감지되지않아, 접근성업데이트가 안됐던것
접근성에 대해서 아직 혼란스러운건 알겠따. SCROLL_FOWARD vs PAGE_RIGHT 같은;; 이런 것들은 레거시라;;API복잡해,
커스텀을 사용할수록, 사용자에게 의도된 접근성을 제공해줘야하는 이유는 커지는데 뷰페이저처럼 쉽게할수도있지만, 커스텀뷰보단 일반뷰를 써라-
테스팅
자주 되는게아니어서 로직짜다보면 간과하기 좋다. 접근성서비스의 차이 : 음정안내, 스위치제어
뷰에서 액션을 실행하고 뷰의 상태를 체크해보는 방식
뷰의 접근성노드를 만들어, 노드정보가 뷰를 잘 반영하는지 확인하는 방식
기억해야할 2가지