웹접근성 패턴 라이브러리를 이용한 해결방안 테스트
안녕하세요, 엔비전스입니다.
안드로이드에서 사용 가능한 접근성 관련 유틸 클래스 소개 아티클에서는 커스텀 위젯에서 여러 역할, 상태 정보의 접근성을 쉽게 구현할 수 있는 메서드들을 소개하였습니다. 같은 맥락에서 웹에서의 탭, 커스텀 라디오, 확장 축소, 커스텀 체크박스, 스크린 리더용 토스트 메시지 출력 등에 대한 접근성을 조금 더 쉽게 구현할 수 있도록 improveAccessibility.js를 제작하고 있으며 널리 포럼의 팁 코너를 통하여 각 메서드의 사용 방법에 대해 소개하고 있습니다.
각 메서드에 대한 사용방법은 널리 포럼을 통해 이미 팁 형태로 소개를 하고 있기 때문에 본 문서는 관점을 조금 달리하여 개발 관점이 아닌, 접근성 테스트를 하시는 진단자의 기준에서 해당 js를 활용할 수 있는 방법에 대해 다루어 보고자 합니다.
접근성을 테스트하면서 각 이슈에 대한 해결 방안을 제시할 때 일반적으로 두 가지를 고민하게 됩니다.
- 해당 해결 방안은 접근성 지침에 부합하는 표준 마크업인가?
- 제시하는 해결 방안을 적용할 경우 스크린 리더의 호환성은 문제가 없는가?
이 중 첫 번째 고민을 해결하기 위해서 접근성 마크업과 관련된 여러 문서들도 찾아보고 WAI-ARIA 관련 기술이 포함되는 경우에는 관련 공식 문서를 살펴보기도 합니다.
두 번째 고민을 해결하기 위해서 샘플 페이지를 찾아 테스트하거나 혹은 개발자 도구에서 일부 마크업을 변경하여 스크린 리더로 직접 테스트를 합니다.
그런데 탭, 커스텀 라디오, 모달 대화상자, 커스텀 콤보 상자와 같이 다양한 ARIA 커스텀 요소가 추가되는 경우에는 단순히 개발자 도구의 요소 탭에서 마크업 속성을 변경하여 테스트하기에는 한계가 있습니다. 다양한 이벤트가 복합적으로 추가되는 과정에서 여러 변수가 있을 수 있기 때문입니다. 그래서 스크립트에 능숙한 경우에는 비슷한 UI를 직접 구현해 보기도 하지만 개발 팀에 해결 방안을 리포트 하기 전에 보조 기술의 호환성 등에 문제가 없는지 일일이 이슈를 테스트하기에는 시간이 상당히 많이 소요됩니다. 게다가 진단자 입장에서 스크립트에 다 능숙하지 않을 수 있습니다.
이때 브라우저 개발자 도구에 있는 콘솔 기능을 이용하여 팁으로 꾸준히 공유되는 improveAccessibility.js를 첨부하면 마크업만으로 테스트하기 어려운 부분들을 단순 마크업과 콘솔창에 메서드를 입력하는 것만으로 마치 접근성 이슈가 해결된 것처럼 직접 테스트해 볼 수 있습니다. 또한 접근성 리포트에 해결 방안이 구현되었을 때의 영상을 함께 첨부한다면 제시한 해결 방안이 충족되었을 때 스크린 리더가 어떻게 동작하는지를 미리 영상으로 시연하여 기획자, 개발팀의 이해를 도울 수도 있습니다.
따라서 접근성 진단 브라우저로 앞으로 대부분 활용될 Google Chrome을 기준으로 하여 improveAccessibility.js 를 활용한 접근성 진단 방법에 대해 살펴보도록 하겠습니다.
참고: 사실 개발자 도구의 콘솔 기능은 개발자라면 너무나 잘 아는 기능입니다. 그러나 이러한 기능에 익숙지 않은 분들을 위해 본 아티클이 작성되었음을 밝혀 둡니다.
콘솔 실행 및 js 불러오기
브라우저 개발자 도구의 콘솔 기능은 자바스크립트 코드를 실행해 볼 수 있는 기능입니다. 이는 개발 과정에서 로그를 확인해야 하거나, 간단한 자바스크립트 코드를 직접 입력하여 특정 요소 혹은 이벤트가 어떻게 작용을 하는지 테스트할 때 주로 사용합니다. 예를 들어 페이지와 상관없이 콘솔에 다음과 같이 입력하면 브라우저에서 지원하는 대화상자 창이 뜨게 됩니다.
예: alert(“접근성 테스트입니다.”);
콘솔을 열고 접근성을 테스트하기 위한 js를 첨부하려면 다음과 같이 실행합니다.
- 개발자 도구를 열기 위해 F12 혹은 Control-Shift-I를 누릅니다. 기본적으로는 요소, 콘솔 등의 탭 중 요소 탭이 선택되어 있고 초점은 HTML 요소 트리뷰로 이동합니다.
- 상단의 탭 목록에서 콘솔 탭을 누릅니다. 그러면 명령어를 입력할 수 있는 편집창으로 초점이 이동합니다.
콘솔에 js를 첨부하는 방법은 두 가지가 있습니다. 하나는 js 전체의 소스코드를 복사하여 명령어 편집창에 붙여 넣는 방법이며 또 한 가지는 간단한 스크립트로 js 파일을 <head> 태그에 추가되도록 하는 방법입니다. 첫 번째 방법은 브라우저 상에서 과부하가 일어나거나 일시적으로 다운이 될 수 있어 본 문서에서는 두 번째 방법을 기준으로 설명합니다. 따라서 아래의 간단한 코드를 복사하여 콘솔 명령어 편집창에 붙여 넣기 합니다.
(()=>{
const improveAccessibility = document.createElement("script");
improveAccessibility.type = "text/javascript";
improveAccessibility.charset = "utf-8";
improveAccessibility.src = "https://a11y-nvisions.github.io/js/improveAccessibility.js";
document.querySelector("head").appendChild(improveAccessibility);
})();
그러면 첨부된 스크립트가 콘솔 편집창 위에 추가된 것을 확인할 수 있으며 편집창에서 shift tab을 누르면 추가된 DOM 트리뷰로 이동합니다.
콘솔에서 Js 사용법
improveAccessibility.js는 여러 접근성 적용 가능한 함수가 포함되어 있으며 특정 함수로 접근성을 테스트해 보기 위해서는 함수에 충족하는 마크업을 하고 콘솔 편집창에 함수를 실행해 주기만 하면 됩니다. 예를 들어 관심 상품 추가 버튼이 있고 CSS 스타일을 통하여 추가 혹은 해제 상태를 포함하고 있다고 가정해 보겠습니다. 이때 접근성 적용이 되어 있지 않으면 관심 추가 해제 모두 관심 버튼이라고만 읽을 것입니다. 해당 접근성 문제를 해결하기 위해서 aria-pressed 속성을 사용해야 합니다. 해당 설명을 보면 다음과 같이 기술하고 있습니다.
“사용 방법은 ariaPressed() 함수를 적용하는 시점에 마크업 된 모든 aria-pressed 속성을 가지고 오게 되며 각 버튼을 클릭했을 때 스타일의 변화가 있으면 값이 변경됩니다.”
즉 버튼을 누를 때 해당 버튼의 스타일이 변경되는 경우에만 해당 js가 동작된다는 의미입니다.
- 개발자 도구에서 관심 버튼에 현 상태의 aria-pressed 속성을 추가합니다. 다만 aria-pressed 버튼은 토글 버튼으로 일반 버튼 자체의 속성이 변경되는 것이기 때문에 버튼에 aria-pressed true 혹은 false 속성을 삽입하더라도 스크린 리더에서 토글 버튼으로 곧바로 읽어주지 못할 수 있습니다. 따라서 버튼의 역할을 갱신할 수 있도록 하기 위해서 role=”button” 속성을 함께 추가해 주어야 합니다. 물론 이것은 테스트에 한하며 개발에서는 버튼이 처음 불러와질 때부터 aria-pressed 속성이 함께 사용될 것이기 때문에 위 조건에 해당되지 않습니다.
- 콘솔 탭 패널 편집창에서 다음과 같이 입력하고 Enter를 누릅니다.
ariaPressed() - 그리고 스크린 리더로 버튼을 눌러서 관심 버튼의 속성을 변경하며 테스트를 해 봅니다.
참고: 테스트했는데도 마크업 상에서 속성은 변경되지만 스크린 리더가 변경된 속성을 캐치하지 못한다면 스크린 리더의 호환성 문제가 있는 것이며 마크업 속성에 변화가 없다면 스타일이 변경되지 않거나 js 자체에 오류가 있는 경우입니다. ariaPressed 메서드는 버튼을 눌렀을 때 CSS 속성에 변경이 있을 때에만 aria-pressed 속성이 변경되도록 개발되어 있기 때문입니다.
지금까지 스크립트에 익숙지 않더라도 접근성 패턴 라이브러리와 브라우저의 콘솔 기능을 이용하여 진단자가 생각하는 해결 방안을 직접 콘솔에 적용하여 테스트하는 방법을 소개하였습니다. 본 아티클이 접근성 진단 시 시행착오를 줄이는 데 도움이 되기를 바라봅니다.