2020-03-07 토요일
웹접근성과 슬라이더(carousel)
tab키를 이용해 엘리먼트에 포커스가 가면, 브라우저는 포커스가 된 엘리먼트를 바로 보여주게 된다.
슬라이더의 경우 이는 문제가 되는데, 보통 슬라이더는 나열되어 있는 자식 엘리먼트들을 담고 있는 부모 컨테이너가 overflow 속성을 갖고 있어서 특정 부분만 보여주는 형식으로 구현되어 있다.
그런데 tab을 누르면, 포커스된 엘리먼트가 바로 화면에 보여지게 된다. 슬라이더는 내부적으로 현재 보여지는 자식 엘리먼트의 인덱스값 및 보여지는 위치값 등을 관리하고 있을텐데, tab키를 누르면 포커싱된 요소가 보여지지지만 코드상에서 관리되고 있는 값에는 변화가 없어서 그 다음 슬라이드 애니메이션이 작동하게 되면, 현재 보여지는 부분과 달라져서 스크립트가 꼬이게 된다.
대표적으로 슬라이더에 오류가 자주 나오는 동작이 있는데
tab키를 누른다.- 포커스 된 엘리먼트가 화면에 바로 보인다.
- 이 상태에서 네비게이션 버튼을 누른다.
위의 동작을 어떻게 하다보면 내부적으로 관리되는 인덱스와 보여지는 화면의 위치값 등이 꼬여서 사진이 아무것도 없는 배경화면으로 슬라이드 되는 것을 볼 수 있다. (하물며 청와대 역시 그렇다...)
정부24 조직도에서 공공기관 사이트들 중 슬라이더가 구현된 곳에서 한번 실험해보면 금방 그 결과를 알 수 있다.
하물며 네이버의 로그인 후 아래와 같은 탭
여기서도 포커스를 하다가 다음 탭으로 넘어가게 되면, 포커스에 의해 다음 탭에 있는 메뉴가 순간적으로 선택되어 순간이동 되었다가 다시 이전 탭으로 순간이동 되고, 또 다시 슬라이드 된다. 즉, 어떻게 보면 버그라고 볼 수 있다.
결론은 탭에 의한 슬라이더의 버그는 브라우저 구현체의 문제와 밀접하므로 기술적으로 해결하기 까다롭다.
개인적인 생각으로는 어차피 접근성이라는 것은 비장애인들에게는 큰 의미가 없으므로 접근성 동작(tab키) + 비접근성 동작(그냥 클릭하기) 으로 인해 보여지는 부분이 이상하게 바뀌는 것을 굳이 잡을 필요도 없고, 실제 시각장애인분들은 애초에 위와 같은 일을 발생시킬 수가 없으며(tab키 누르다가 네비게이션 탐색을 할 수가 없음) 발생된다 하더라도 어차피 흰색 배경화면을 볼 수가 없다.
굳이 비용을 들여 해결할 필요는 없다고 생각한다. 접근성에 위배되지 않는 범위 내에서 해결해야 되는 동작은
tab을 눌렀을 때, 다음 슬라이드 부분으로 포커스가 이동되게 하기(굳이 슬라이드가 동작하면서 보여질 필요는 없음)- 이 때, 슬라이더를 구현하면서 생기는 일종의 클론(혹은 더미)엘리먼트에는 포커스가 되지 않게 하기(기술적으로만 의미 있는 엘리먼트이므로 스크린 리더 사용자들이 알 필요가 없는 내용)
- 숨겨진 슬라이드들까지 전부 포커스를 지나면 네비게이션 버튼으로 포커스 되게 하기
이 정도까지만 해결하면 된다고 본다.
