접근성 있는 앱에서 피해야 할 사례(HTML)

Applies to Windows and Windows Phone

이 항목의 C#/VB/C++/XAML 버전을 찾고 계세요?접근성 있는 앱에서 피해야 할 사례(XAML)를 참조하세요.

JavaScript로 작성한 Windows 런타임 앱에 접근성을 구현할 때 다음과 같은 상황은 피해야 합니다.

  • Windows 런타임 프레임워크를 사용하는 Windows 스토어 앱에 포함된 컨트롤 또는 표준 HTML 태그를 사용할 수 있으려면 사용자 지정 UI 요소를 빌드하지 않도록 합니다. 일반적으로 div 태그를 사용하여 사용자 UI 요소를 빌드하면 접근성을 구현하기 위해 더 많은 작업이 필요합니다. 표준 HTML 태그 및 Windows 런타임 컨트롤은 기본적으로 접근성이 있으므로 완전하게 접근성을 구현하려면 접근성 있는 컨트롤 이름을 설정하기만 하면 됩니다.
  • 정적 텍스트나 다른 비대화형 요소를 탭 순서에 배치하지 마세요(예: 대화형이 아닌 요소에 대해 0보다 큰 tabIndex 특성 설정). 비대화형 요소를 탭 순서에 넣는 것은 키보드 탐색의 효율성을 떨어뜨리므로 키보드 접근성 지침에 위배됩니다. 탭 순서에서 텍스트 전용 요소는 탭 순서에서 대화형 요소(단추, 확인란, 텍스트 입력 필드, 콤보 상자, 목록 등)만 예상하는 사용자에게 혼동을 줄 수 있습니다.
  • role 특성을 임의 값으로 설정하면 Windows 런타임 플랫폼에 기본 제공되는 접근성 지원을 활용할 수 없게 되므로 그렇게 하면 안 됩니다. 요소의 role 특성을 유효한(추상이 아닌) WAI-ARIA(Web Accessibility Initiative - Accessible Rich Internet Applications) 역할 값으로 설정하는 것은 플랫폼이 화면 읽기 프로그램 및 기타 보조 기술 도구에 요소를 올바르게 나타낼 수 있도록 하는 가장 좋은 방법입니다.
  • UI 요소의 사용자 지정 CSS 스타일시트 절대 위치를 사용하지 마세요. 가능할 때마다 화면 낭독 프로그램이 올바른 순서로 UI 요소를 읽을 수 있도록 문서 또는 논리 순서의 UI 요소를 배치하는 것이 좋습니다. UI 요소의 표시 순서를 문서 또는 논리 순서와 다르게 하려면 aria-flowtox-ms-aria-flowfrom 특성을 사용하여 올바른 읽기 순서를 정의합니다.
  • 정보를 전달하는 유일한 수단으로 색을 사용하지 마세요. 색맹인 사용자는 색 상태 표시기같이 색을 통해 전달되는 정보를 받을 수 없습니다. 다른 시각 신호(예: 텍스트)를 포함시켜 정보에 대한 접근성을 유지합니다.
  • 전체 페이지를 자동으로 새로 고치지 마세요. 페이지 콘텐츠를 자동으로 새로 고쳐야 하면 페이지의 특정 영역만 업데이트하고 해당 영역을 라이브 영역으로 표시합니다.
  • 초당 4번 이상 깜박이는 UI 요소를 사용하지 마세요. 깜박이는 요소로 인해 일부 사용자가 발작을 일으킬 수 있습니다. 깜박이는 UI 요소를 아예 사용하지 않는 것이 가장 좋은 방법입니다.
  • 자동으로 사용자 컨텍스트를 변경하거나 기능을 활성화하지 마세요. 컨텍스트 또는 활성화 변경은 사용자가 포커스가 있는 UI 요소에 직접 작업을 수행할 때만 발생해야 합니다. 사용자 컨텍스트 변경에는 포커스 변경, 새 콘텐츠 표시, 다른 페이지로의 이동이 포함됩니다. 사용자 개입 없이 컨텍스트를 변경할 경우 장애를 가진 사용자는 혼란을 겪을 수 있습니다. 단, 하위 메뉴 표시, 양식 유효성 검사, 다른 컨트롤에 도움말 텍스트 표시, 비동기 이벤트에 대한 응답 컨텍스트 변경 등은 이 요구 사항의 예외입니다.

관련 항목

JavaScript를 사용한 Windows 런타임 앱의 접근성 빌드

 

 

표시:
© 2014 Microsoft