국내 접근성과 국제 접근성은 어떻게 다를까?
WCAG와 KWCAG의 가장 큰 차이
국제 접근성 기준인 WCAG는 Web Content Accessibility Guidelines의 약자이고, 국내 접근성 기준인 KWCAG는 Korea Web Content Accessibility Guidelines의 약자이다.
KWCAG는 WCAG에서 앞에 Korea만 붙은 것으로 유추할 수 있듯이 WCAG를 국내 웹 환경을 고려하여 제작한 우리나라만의 접근성 준수 지침이다.
접근성 준수를 위한 리뉴얼 시작
대한항공은 첫 접근성 이슈가 터졌던 2012년 말 당시의 웹사이트는 table 마크업으로 제작된 오래된 사이트였다. table 태그로 제작된 사이트이다 보니 접근성은 물론이고 웹표준도 준수되지 않아서 IE 하위버전만 호환되었던 구닥다리 환경이었다.
전면 개편이 필요했던 시점에 장애인 단체로부터 소송도 걸렸기에 글로벌 항공사에 걸맞게 해외 유명한 에이전시를 통해 리뉴얼을 진행했고 2014년 9월 전면 개편하여 새롭게 사이트를 오픈했다. 하지만 미국 에이전시이니 접근성은 기본으로 잘해 주겠지라는 막연한 믿음을 가졌던 나를 절망에 빠지게 하였다.
첫 웹 접근성 인증마크 획득!! 하지만..
국내의 유명한 웹접근성 인증 심사 업체와 함께 부랴부랴 접근성 TFT를 꾸려 현재의 웹사이트의 접근성을 개선하여 그로부터 6개월후에는 인증마크를 드디어 획득하였고, 접근성 소송을 걸었던 장애인 단체와도 잘 끝난 상태였다.
바로 그때 미국 교통부 (US DOT)에서 미국에 취항하는 모든 항공사는 WCAG2.0을 준수하라는 통보가 떨어졌고 우리는 statement를 받아보고자 미국의 접근성 전문 업체에게 심사를 보냈다. 국내 접근성 인증마크까지 획득했으니 얼마나 의기양양 했겠는가..
하지만 심사 결과는 참담했다.
50페이지 심사 결과 782건 위배...
미국 접근성 전문업체에 항공사 예약과 같은 핵심 기능을 포함한 약 50페이지를 심사를 받은 결과 수정해야 하는 건수가 무려 782건이었다. 모든 케이스를 포함한 것도 아니었는데 정말 많은 부분을 크리티컬한 위배항목으로 지적을 받았다. 국내 접근성 인증마크까지 획득한 사이트가..... 782건이라니.. 한 페이지당 15건의 수정이 필요한 것이었다.
가장 지적이 많았던 항목은 WCAG2.1의 4.1.2 Name, Role, Value 항목으로 보기좋은 디자인을 위해 리뉴얼을 하면서 기본 브라우저 컴포넌트였던 버튼, 입력폼, 체크박스를 비롯한 탭, 다이얼로그, 캐러셀, 메뉴 등 사용자들이 가장 많이 사용하는 커스터마이징한 UI가 모두 위배였다.
커스터마이징했던 UI를 스크린리더 사용자는 역할도 알 수 없고 상태도 알기 어려우며 사용조차 불가능했다는 것이다. 즉, 출도착 도시를 선택하기 위한 자동완성 입력박스는 물론이고 tabs로 제작된 공항 목록, 탑승날짜를 선택하기 위한 datepicker와 항공편을 선택하기 위한 라디오버튼조차 모두 위배였다.
WCAG과 KWCAG 차이
결국 국내 접근성과 국제 접근성의 가장 큰 차이는 WAI-ARIA 사용이었다.
미국에서 가장 많이 사용하는 스크린리더는 JAWS와 NVDA였는데 WAI-ARIA를 잘 지원하였기에 커스터마이징된 UI여도 WAI-ARIA를 적절히 잘 사용하면 스크린리더 사용자들은 기본 브라우저 UI를 사용하는 것처럼 사용할 수 있다.
tabs UI를 제작하더라도 WAI-ARIA의 요소들을 사용하여 tabs UI임을 스크린리더 사용자에게 안내해야 하고 스크린리더 사용자들이 공통적으로 사용하는 키보드 인터랙션을 구현하여 운용까지 할 수 있게 하는 것이다. 우리가 웹 콘텐츠를 제작할 때 외국의 오픈소스를 많이 사용하는데 WAI-ARIA소스가 기본 설정되어 있는 것을 볼 수 있는데 그것들이 모두 WCAG를 준수할 수 있도록 삽입해 놓은 것이다.
하지만 우리나라에서 사용하는 스크린리더는 대부분이 센스리더이다. 지금은 많이 좋아지긴 했지만 2015년 당시 센스리더는 WAI-ARIA를 지원하지 않았기에 접근성 인증마크 심사에서도 커스터마이징된 UI를 심사할 수 있는 환경이 뒷받침 되지 않은 것이다.
WAI-ARIA를 사용하면 스크린리더로 반드시 테스트하자.
WAI-ARIA를 사용하고 있다면 스크린리더로 반드시 테스트 해봐야 한다. 웹 기술이 발전하듯이 브라우저도 계속 업데이트가 되고 있고 스크린리더도 업데이트가 된다.
WCAG도 나날이 발전되고 있고 WCAG2.1에서 곧 WCAG2.2로 업데이트가 되고 있으며 WAI-ARIA 기술도 마찬가지이다. 2017년 WAI-ARIA 1.1이 권고안으로 발표되고 1.2 업데이트를 앞두고 있다. 새로운 ARIA 속성이 발표되고 있으며 그 새로운 속성을 스크린리더 제작사들이 따라가고 있지만 표준 스펙을 바로바로 지원하는 것은 불가능하다.
WAI-ARIA를 사용하는 이유가 스크린리더 사용자들을 위한 것이기에 개발자들도 WAI-ARIA를 사용했으면 스크린리더에서 제대로 읽고 안내하는지 테스트를 해야 하는데, 그 이유가 브라우저와 스크린리더의 조합별로 다르게 읽는 경우도 많고 버그가 있거나 지원을 하지 않는 경우가 상당히 많기에 그런 경우가 있다면 다른 대안을 생각해보아야 하기 때문이다. 스크린리더에서 아직 지원하지 못하는 기술을 가져다 써도 결국 사용해야 하는 사용자들이 제대로 사용하지 못한다면 최신 기술이 무슨 의미가 있을까...
실제로 W3C의 ARIA 적용 사례 코드들도 무수히 이슈가 많으며 수시로 변경되고 있으므로 100% 신뢰하지 않아야 하고 직접 테스트를 해보는 것이 필요하다.
W3C의 WAI-ARIA 적용사례를 볼 수 있는 곳 https://www.w3.org/WAI/ARIA/apg/
WAI-ARIA를 사용하지 않고 접근성을 제대로 준수하는 것이 가장 좋은 방법이지만 불가피하다면 WAI-ARIA를 가장 보편적인 방법으로 사용하여 가장 많은 사용자들이 잘 사용할 수 있게 하는 것이 중요하다.
여기 블로그에서는 국내가 아닌 미국에서 가장 많이 사용하는 JAWS, NVDA 스크린리더가 가장 보편적으로 지원하는 WAI-ARIA 적용 사례를 직접 테스트하여 구현한 사례이다.
Last updated