피해야 할 접근성 사례
액세스할 수 있는 Windows 앱을 만들려는 경우 다음을 방지하는 방법 목록을 참조하세요.
사용자 지정 UI 요소를 빌드하면 안 되는 경우는 기본 Windows 컨트롤을 사용할 수 있는 경우 또는 Microsoft UI 자동화 지원을 이미 구현한 컨트롤을 사용할 수 있는 경우입니다. 표준 Windows 컨트롤은 기본적으로 액세스할 수 있으며 일반적으로 앱별 접근성 속성 몇 가지만 추가해야 합니다. 반면, 진정한 사용자 지정에 대한 AutomationPeer 지원을 구현하는 것은 좀 더 복잡합니다( 사용자 지정 자동화 피어를 참조하세요).
정적 텍스트 또는 비대화형 요소를 탭 순서에 넣지 마세요 (예: 대화형이 아닌 요소를 위한 TabIndex 속성 설정하기). 비대화형 요소가 탭 순서에 있는 경우, 사용자의 키보드 탐색 효율성이 떨어지므로 키보드 접근성 지침에 위배됩니다. 많은 보조 기술이 보조 기술 사용자에게 앱의 인터페이스를 제공하는 방법에 대한 논리의 일부로 탭 순서 및 요소에 초점을 맞추는 기능을 사용합니다. 탭 순서의 텍스트 전용 요소는 (버튼, 체크박스, 텍스트 입력 필드, 콤보 상자, 목록 등) 탭 순서에서 대화형 요소만 예상하는 사용자에게 혼란을 줄 수 있습니다.
프레젠테이션 순서가 자식 요소 선언 순서(사실상 논리적 순서)와 다른 경우가 많으므로 (예를 들어 Canvas 요소 내) UI 요소의 절대 위치 지정을 사용하지 마세요. 가능하면 UI 요소를 문서 또는 논리적 순서로 정렬하여 화면 읽기 프로그램이 해당 요소를 올바른 순서로 읽을 수 있도록 합니다. UI 요소의 표시 순서가 문서나 논리 순서와 다를 수 있는 경우, 명시적 탭 인덱스 값을 사용하여( TabIndex설정) 올바른 읽기 순서를 정의합니다.
정보를 전달하는 방법으로 색상만을 사용하지 마세요. 색맹인 사용자는 색 상태 표시기처럼 색을 통해서만 전달되는 정보를 받을 수 없습니다. 정보에 액세스할 수 있도록 다른 시각적 신호, 가급적 텍스트를 포함합니다.
전체 앱 캔버스를 자동으로 새로 고침 하지 마시되 앱 기능에 실제로 필요한 경우에는 예외로 합니다. 페이지 콘텐츠를 자동으로 새로 고침해야 하는 경우 페이지의 특정 영역만 업데이트합니다. 보조 기술은 통상 유효한 변경 내용이 최소인 경우에도 새로 고친 앱 캔버스가 완전히 새로운 구조라고 가정해야 합니다. 보조 기술 사용자에게 드는 비용은 새로 고친 앱에 대한 문서 보기 또는 설명이 다시 만들어 사용자에게 다시 제공돼야 한다는 것입니다.
사용자가 의도적으로 페이지 탐색을 시작하는 것은 앱 구조를 새로 고치는 데 적합한 경우일 때입니다. 그러나 탐색을 시작하는 UI 항목이 올바르게 식별되거나 이름이 지정되어있어 호출 시 컨텍스트 변경 및 페이지 다시 로드가 발생한다는 표시가 뜨는지 확인합니다.
참고 항목
리전 내에서 콘텐츠를 새로 고치는 경우 AccessibilityProperties.LiveSetting 접근성 속성을기본값이 아닌 Polite 또는 Assertive로 설정하는 것이 좋습니다. 일부 보조 기술은 이 설정을 라이브 리전의 ARIA(Access Rich Internet Applications) 개념에 매핑할 수 있으므로 콘텐츠 리전이 변경되었음을 사용자에게 알릴 수 있습니다.
초당 3회 이상 깜박이는 UI 요소를 사용하지 마세요. 깜박이는 요소로 인해 발작을 겪는 사람이 생길 수도 있습니다. 깜박이는 UI 요소를 사용하지 않는 것이 가장 좋습니다.
사용자 컨텍스트를 변경하거나 기능을 자동으로 활성화하지 마세요. 컨텍스트 또는 활성화 변경은 사용자가 포커스가 있는 UI 요소에 대해 직접 작업을 수행할 때만 발생합니다. 사용자 컨텍스트에서의 변경 내용에는 포커스 변경, 새 콘텐츠 표시 및 다른 페이지로의 이동 등이 있습니다. 사용자를 포함하지 않고 컨텍스트를 변경하면 장애가 있는 사용자에게 혼란을 줄 수 있습니다. 이 요구 사항의 예외로는 하위 메뉴 표시, 양식 유효성 검사, 다른 컨트롤에 도움말 텍스트 표시, 비동기 이벤트에 대한 응답으로 컨텍스트 변경 등이 있습니다.
관련 항목
Windows developer