참고. ARIA Authoring Practices Guide
사용자 정의 컴포넌트를 구현할 때는 W3C의 ARIA Authoring Practices Guide를 참고하면, 다양한 컴포넌트에 대한 접근성 패턴, ARIA 속성 사용 방법, 그리고 키보드 인터페이스 설계 원칙을 상세히 제공하여 표준에 기반한 개발에 도움을 받을 수 있다.
4.2.1. 웹 애플리케이션 접근성 준수
콘텐츠에 포함된 웹 애플리케이션은 접근성이 있어야 한다.
웹 콘텐츠에 포함된 플러그인이나 애플리케이션이 보조 기술을 사용하는 사용자도 문제없이 접근하고 사용할 수 있도록 보장하기 위함이다.
배경 및 필요성
섹션 제목: “배경 및 필요성”웹 애플리케이션과 플러그인은 단순한 정보 제공을 넘어 사용자와의 상호작용, 데이터 처리, 동적 콘텐츠 제공 등 다양한 기능을 수행한다.
이러한 기능이 보조 기술과 호환되지 않거나 키보드 조작을 지원하지 않으면, 키보드 사용자와 보조 기술 사용자는 콘텐츠를 인식하거나 조작할 수 없는 문제가 발생할 수 있다. 또한, 시각적 정보만으로 콘텐츠를 이해하기 어려운 색각 이상 사용자나, 특정 환경에서 플러그인이나 기술이 특정 운영 체제 또는 보조 기술과 호환되지 않는 경우 접근성이 크게 저하될 수 있다. 이로 인해 일부 사용자는 정보에 접근할 수 없거나, 중요한 기능을 사용할 수 없는 문제가 발생한다.
따라서 웹 콘텐츠에 포함된 플러그인과 웹 애플리케이션은 보조 기술 호환성을 고려하고, 키보드 내비게이션을 지원하며, 시각적 정보 외에도 다양한 대체 수단을 제공하는 등 앞서 다룬 모든 검사항목에 대한 접근성이 보장되어야 한다.
기본 규칙
섹션 제목: “기본 규칙”- 플러그인과 웹 애플리케이션은 화면낭독프로그램, 화면 확대 프로그램 등 주요 보조 기술과 호환되어야 한다.
- 마우스 사용이 어려운 사용자도 키보드만으로 모든 기능에 접근하고 조작할 수 있도록 인터페이스가 설계되어야 한다.
- 다양한 브라우저, 운영 체제, 보조 기술 환경에서 웹 애플리케이션과 플러그인의 접근성을 테스트하고 개선해야 한다.
- 플러그인이나 웹 애플리케이션을 선택할 때는 접근성 지원 여부를 검토하고, 접근성이 확보된 솔루션을 채택해야 한다.
- 플러그인
- 웹 브라우저에서 기본적으로 지원하지 않는 특정 기능이나 콘텐츠를 제공하기 위해 추가 설치하는 소프트웨어이다. 플러그인은 웹 페이지와 통합되어 사용자가 특정 콘텐츠를 원활하게 이용할 수 있도록 돕는 역할을 한다.
- 웹 애플리케이션
- 웹 서버와 클라이언트(웹 브라우저) 간의 상호작용을 통해 동적 콘텐츠 제공, 데이터 처리, 사용자 상호작용 등의 기능을 수행하는 소프트웨어 프로그램을 의미한다.
적용 사례
섹션 제목: “적용 사례”1) 접근성을 준수하는 부가 웹 애플리케이션 제공
섹션 제목: “1) 접근성을 준수하는 부가 웹 애플리케이션 제공”부가 웹 애플리케이션을 사용하는 경우, 사전에 접근성 지침 준수 여부(대체 텍스트 제공, 키보드 접근성, 화면낭독프로그램 호환성 등)를 충분히 검토하는 것이 필수적이다. 부가 웹 애플리케이션은 직접 개발하거나 수정할 수 없는 경우가 많으므로, 접근성 지원 사항을 미리 확인하는 것이 중요하다.
숙소 예약 사이트에서 지도 서비스를 부가 웹 애플리케이션으로 사용할 때, 해당 서비스가 키보드 탐색이 가능한지, 화면낭독프로그램을 통해 상호작용 요소의 이름과 기능이 명확히 전달되는지 등을 점검해야 한다.
사용한 부가 애플리케이션이 접근성을 완전히 충족하지 못한다면, 추가 설명이나 대체 수단을 제공하여 모든 사용자가 동등하게 콘텐츠를 이용할 수 있도록 개선해야 한다.
2) 리치 웹 애플리케이션(RIA)의 접근성 보장
섹션 제목: “2) 리치 웹 애플리케이션(RIA)의 접근성 보장”사용자 정의 컴포넌트와 같은 리치 웹 애플리케이션 요소는 기본 HTML 요소가 제공하는 접근성 정보를 상속받지 못하는 경우가 많다. 또한, 탭(Tab) UI와 같이 HTML 요소만으로는 역할 및 상태 정보를 충분히 전달하기 어려운 동적 콘텐츠의 경우가 있으므로, ARIA 속성을 적절히 활용하여 보조 기술에서 해당 컴포넌트의 역할과 상태를 해석할 수 있도록 제공할 수 있다.
예를 들어, 사용자 정의 콤보박스를 구현할 때, 다음과 같이 적용할 수 있다.
- 메뉴 전체에
role="listbox"와 각 옵션에role="option"을 사용하고, - 메뉴의 열림/닫힘 상태는
aria-expanded="true/false"로, - 선택된 항목은
aria-selected="true"설정한다.
또한, 콤보박스는 기본 HTML 콤보박스와 동일한 키보드 조작(예: 옵션 목록 펼침은 Enter/Space, 닫힘 및 선택 취소는 ESC, 옵션 탐색은 상하 화살표)이 가능하도록 제공해야 한다.
이와 같이 ARIA 속성을 활용하면, 시각장애인이나 키보드 전용 사용자가 사용자 정의 컴포넌트를 보다 쉽게 인식하고 조작할 수 있다. 다만, ARIA 속성은 기본 HTML 요소의 기능이나 조작을 대체하지 않으므로 자바스크립트 등 구현이 추가로 필요하여, 가능한 경우 HTML 기본 기능을 우선으로 활용하는 것이 바람직하다.
개선 필요 사례
섹션 제목: “개선 필요 사례”1) 접근성이 미흡한 웹 애플리케이션 제공
섹션 제목: “1) 접근성이 미흡한 웹 애플리케이션 제공”다음은 도서관 사이트에서 뷰어 시스템이 적용되었으나 키보드로 페이지를 제어할 수 없는 사례이다.
웹 뷰어를 마우스로 사용 시에는 정상적으로 목록, 페이지 보기, 설정, 검색, 이전/다음 버튼 등 다양한 기능을 사용할 수 있지만, 키보드 탐색 시에는 해당 기능 버튼이 화면에 노출되지 않아 사용할 수 없다. 이는 키보드 사용자를 고려하지 않은 설계로 인해 웹 애플리케이션의 접근성이 저하된 사례이다.
또한, 화면낭독프로그램 사용자가 라디오 버튼 옵션을 키보드 방향키로 제어할 때, 옵션 변경과 동시에 책 페이지가 변경되어 의도치 않은 페이지 이동이 발생하는 문제가 있다. 이러한 문제는 키보드 상호작용 설계가 적절하지 않아 사용자가 원하는 정보를 인식하거나 조작할 수 없게 만든다.
개선 방법
섹션 제목: “개선 방법”외부 프로그램을 도입하기 전에 해당 프로그램이 키보드 내비게이션, 보조 기술 호환성, 그리고 시각적·청각적 정보의 대체 수단 제공 등 접근성 요구사항을 충족하는지 확인해야 한다.
만약 접근성 요구사항을 충족하지 못하는 프로그램이라면, 동일한 기능을 제공하면서 접근성을 보장할 수 있는 다른 대안을 검토해야 한다. 이러한 기준을 충족하는 프로그램을 선택함으로써, 다양한 사용자 그룹이 콘텐츠를 동등하게 이용할 수 있는 환경을 마련할 수 있다.
2) 접근성 일부만 준수한 웹 애플리케이션
섹션 제목: “2) 접근성 일부만 준수한 웹 애플리케이션”접근성이 일부만 준수되어 키보드 및 보조 기술 사용자에게 불편을 주는 공동인증서 로그인 웹 애플리케이션 사례이다.
배너에 대체 텍스트가 제공되지 않아, 화면낭독프로그램 사용자는 해당 정보를 그래픽 링크로만 인식하게 되어 배너의 목적과 내용을 파악하기 어렵다. 탭 키를 사용하여 탐색할 때 인증서 암호 입력은 가능하지만, 인증서 개수가 많을 경우 원하는 인증서를 선택하기 어렵다.
또한, 순차 탐색 시 화면에 표시되는 콘텐츠 순서와 실제 탐색 순서가 일치하지 않아, 사용자가 논리적인 흐름대로 탐색할 수 없다. 인증서 목록은 표 형태로 제공되지만, 각 항목이 개별 요소로 분리되어 있어 정보의 연관성을 파악하기 어렵다.
이에 따라 보조 기술을 사용하는 사용자는 인증 과정에서 불편함을 겪게 된다.
개선 방법
섹션 제목: “개선 방법”웹 애플리케이션 또한 앞에서 다룬 검사 항목을 모두 준수하는지 점검해야 한다.
이미지 배너에 대체 텍스트를 제공하고, 키보드 사용을 보장하고, 초점은 논리적으로 이동하고, 표는 보조 기술 사용자가 행과 열의 관계를 쉽게 이해할 수 있도록 설계하고, 탐색이 쉽도록 개선한다.
이러한 개선을 통해, 키보드 및 보조 기술 사용자도 인증 절차를 원활하게 수행할 수 있도록 해야 한다.
3) 접근성이 준수되지 않은 사용자 정의 콤보박스
섹션 제목: “3) 접근성이 준수되지 않은 사용자 정의 콤보박스”다음은 상품 상세 페이지의 옵션 선택 영역이 콤보박스로 인식되지 않는 사례이다.
옵션 목록이 ul 요소로 구현되어 있어 보조 기술 사용자는 이를 선택 가능한 콤보박스가 아닌 단순한 목록으로 인식할 수 있다. a 요소로 제공된 각 옵션은 페이지 이동 링크로 인식되어, 사용자가 옵션 목록을 제대로 탐색하거나 상호작용을 하기 어렵다.
또한, 옵션 목록의 열림/닫힘 상태 및 선택 상태가 명확하게 제공되지 않아, 사용자가 자신이 선택한 옵션을 확인하거나 변경하는 데 어려움을 겪는다.
<div class="prd_option_box" id="buy_option_box"> <a href="javascript:;" class="sel_option" id="buyOpt"> 상품을 선택해주세요 </a> </div> <ul class="sel_option_list" id="option_list"> <li class="type1"> <a style="cursor:pointer" onclick="javascript:..."> <span class="color"> <img src="..." alt=""> </span> <div class="set"> <span class="option_value"> [1+1 한정] 핸드크림 <span class="option_price"> 7,900원 </span> </span> </div> </a> </li> ...</ul>개선 방법
섹션 제목: “개선 방법”콤보박스는 select 요소를 사용하여 구현하는 것이 가장 적합하다. 이는 기본적으로 키보드 탐색과 역할 안내, 선택 상태를 제공하므로 추가 작업이 필요 없다.
만약 사용자 정의 컴포넌트를 사용해야 한다면, role="listbox"와 role="option"을 사용해 보조 기술이 이를 선택 가능한 옵션으로 인식하도록 하고, 열림/닫힘 상태 정보를 aria-expanded 등의 ARIA 속성을 통해 제공해야 한다. 또한, 키보드로 탐색할 수 있도록 방향키, Enter 키, Space 키 등의 적절한 키보드 탐색을 구현해야 한다.
참고. WAI-ARIA를 사용하기 전에 알아야 할 것들
WAI-ARIA는 웹 접근성을 높이기 위한 강력한 도구이지만, 올바르게 사용하지 않으면 오히려 접근성을 저하시킬 수 있다. 따라서 다음 사항을 반드시 확인하고 활용해야 한다.
- 나쁜 ARIA 보다 ARIA가 없는 것이 낫다.
기본 HTML만으로 접근성을 충분히 제공할 수 있다면 WAI-ARIA를 사용하지 않는다. 예를 들어, 버튼은<div role="button">이 아닌, 키보드 접근성과 클릭 이벤트를 제공하는button요소를 사용한다. - WAI-ARIA는 보조기기를 위한 정보 제공 도구임을 이해한다.
aria-*와 role 속성은 시각적 스타일이나 동작을 변경하지 않으며, 보조 기술과의 소통을 돕는 역할만 한다.<div role="button">은 보조 기술에서 버튼으로 인식되지만, 키보드 접근성은 제공하지 않는다. 이 때, 초점을 받을 수 있도록 하려면tabindex="0"을 추가해야 한다. - aria-hidden은 신중하게 사용해야 한다.
aria-hidden=“true”는 보조 기술이 해당 요소를 무시하도록 한다. 따라서 링크, 버튼, 입력란과 같이 상호작용이 필요한 요소에는 사용하지 않는다. 숨겨진 요소가 다시 표시될 경우aria-hidden=”false”로 변경해야 한다. 만약, 숨겨진 콘텐츠가 초점을 받지 않도록 해야 한다면tabindex="-1"을 함께 적용해야 한다. - 실제 환경에서 반드시 테스트한다.
WAI-ARIA를 적용한 콘텐츠는 실제 보조 기술 환경에서 반드시 테스트해야 한다. 특정 브라우저나 보조 기기에서 예상과 다르게 동작할 수 있으며, 지원하지 않는 기능이나 버그가 존재할 수 있다.
자세한 내용은 앞서 소개한 W3C의 ARIA Authoring Practices Guide를 참조한다.
참고자료
섹션 제목: “참고자료”한국지능정보사회진흥원 © National Information Society Agency. All Rights Reserved.