액세스 가능한 앱 디자인을 위한 지침

Applies to Windows and Windows Phone

앱을 디자인할 때는 항상 사용자가 갖는 능력, 장애, 선호도를 고려해야 합니다. 액세스 가능한 디자인 원칙을 따르면 최대한 많은 사용자가 앱에 액세스할 수 있으며 Windows 스토어에서 더 많은 고객을 앱으로 이끄는 데 도움이 됩니다.

접근성을 계획하는 이유?

접근성을 고려해서 앱을 디자인하면 다음과 같은 시나리오에서도 적합한 앱을 만들 수 있습니다.

  • 화면 판독: 시각에 장애가 있는 사용자는 앱 UI의 멘탈 모델을 만들고 유지 관리하기 위해 화면 읽기 프로그램을 활용합니다. UI 요소의 이름을 비롯한 UI에 대한 청각 정보는 사용자가 UI 콘텐츠를 이해하고 앱을 조작하는 데 도움을 줍니다.

    화면 판독을 지원하려면 앱은 이름, 역할, 설명, 상태, 값 등을 비롯하여 해당 UI 요소에 대한 충분하고 정확한 정보를 제공해야 합니다. HTML 또는 XAML용 UI 요소에 대한 기본 정보를 표시하는 방법을 알아보세요.

    HTML과 함께 JavaScript로 작성한 Windows 런타임 앱의 라이브 영역처럼 동적 콘텐츠를 포함하는 UI 요소에 대해서는 추가 접근성 정보를 제공해야 합니다. 추가 접근성 정보가 제공되면 화면 읽기 프로그램에서 콘텐츠에 발생한 변경 내용을 읽어줍니다. 라이브 영역에 대한 접근성 정보를 HTML로 제공하려면 동적 콘텐츠를 포함하는 요소에 대해 aria-live 특성을 설정합니다. 자세한 내용은 라이브 영역에 접근성 구현을 참조하세요. XAML의 라이브 콘텐츠에 ARIA 메타포를 사용하는 라이브 영역에 대한 접근성 정보를 제공하려면 연결된 속성 AutomationProperties.LiveSetting을 사용합니다.

  • 키보드 접근성: 키보드는 화면 읽기 프로그램과 함께 사용되며 앱을 조작하기 위한 좀 더 효율적인 방법으로 키보드를 선호하는 사용자에게 매우 중요합니다. 액세스 가능한 앱을 통해 사용자는 키보드만으로 모든 대화형 UI에 액세스할 수 있으며 다음을 수행할 수 있습니다.

    • 탭 및 화살표 키를 사용하여 앱 탐색
    • 스페이스바 및 Enter 키를 사용하여 UI 요소 활성화
    • 바로 가기 키를 사용하여 명령 및 컨트롤에 액세스

    실제 키보드가 없는 시스템에서나 움직일 수 없어서 일반적인 입력 장치를 사용할 수 없는 사용자는 화상 키보드를 사용할 수 있습니다.

    HTML 또는 XAML용 키보드 접근성을 구현하는 방법을 알아보세요.

  • 액세스 가능한 시각적 효과: 시각에 장애가 있는 사용자를 위해서는 텍스트가 고대비 비율로 표시되어야 합니다. 또한 고대비 모드에서 잘 보이고 접근성 제어판에서 설정을 변경한 후에도 적절히 크기가 조정되는 UI가 필요합니다. 색을 구분해서 정보를 전달할 경우 색맹 사용자에게는 텍스트, 모양, 아이콘과 같이 색 차이를 대신하는 장치가 필요합니다. HTML 또는 XAML용 고대비 테마를 지원하는 방법을 알아보세요. 또는 HTML 또는 XAML용 접근성 텍스트에 대한 요구 사항을 충족하는 방법을 알아보세요.

권장 사항 및 금지 사항

  • 이름, 역할, 설명, 상태, 값 등을 비롯하여 앱의 UI 요소에 대한 정보를 제공하여 화면 판독을 지원합니다.
  • 탭 및 화살표 키를 사용하여 앱을 탐색할 수 있습니다.
  • 스페이스바 및 Enter 키를 사용하여 UI 요소 활성화
  • 바로 가기 키를 사용하여 명령 및 컨트롤에 액세스
  • 고대비 테마를 지원하도록 텍스트 및 UI를 디자인합니다.
  • 접근성 설정이 변경되면 텍스트와 UI의 크기가 적절하게 조정되는지 확인합니다.
  • 정보를 전달하는 유일한 수단으로 색을 사용하지 마세요. 색맹인 사용자는 색 상태 표시기같이 색을 통해서만 전달되는 정보를 받을 수 없습니다. 다른 시각 신호(예: 텍스트)를 포함시켜 정보에 대한 접근성을 유지합니다.
  • 초당 4번 이상 깜박이는 UI 요소를 사용하지 마세요. 깜박이는 요소로 인해 일부 사용자가 발작을 일으킬 수 있습니다. 깜박이는 UI 요소를 아예 사용하지 않는 것이 가장 좋은 방법입니다.
  • 자동으로 사용자 컨텍스트를 변경하거나 기능을 활성화하지 마세요. 컨텍스트 또는 활성화 변경은 사용자가 포커스가 있는 UI 요소에 직접 작업을 수행할 때만 발생해야 합니다. 사용자 컨텍스트 변경에는 포커스 변경, 새 콘텐츠 표시, 다른 페이지로의 이동이 포함됩니다. 사용자 개입 없이 컨텍스트를 변경할 경우 장애를 가진 사용자는 혼란을 겪을 수 있습니다. 단, 하위 메뉴 표시, 양식 유효성 검사, 다른 컨트롤에 도움말 텍스트 표시, 비동기 이벤트에 대한 응답 컨텍스트 변경 등은 이 요구 사항의 예외입니다.
  • Windows 런타임에 포함된 기본 컨트롤이나 Microsoft UI 자동화 지원을 이미 구현한 컨트롤을 사용할 수 있는 경우 사용자 지정 UI 요소를 빌드하지 않도록 합니다. 표준 Windows 런타임 컨트롤은 기본적으로 접근성이 있으므로 일반적으로 앱과 관련된 몇 가지 접근성 특성만 추가하면 됩니다. 반대로 실제 사용자 지정 컨트롤에 대한 AutomationPeer 지원 구현은 약간 더 많은 작업이 필요합니다(사용자 지정 자동화 피어 참조).
  • 정적 텍스트나 다른 비대화형 요소를 탭 순서에 배치하지 마세요(예: 대화형이 아닌 요소에 대해 TabIndex 속성 설정). 비대화형 요소가 탭 순서에 있으면 사용자의 키보드 탐색 효율성이 감소되므로 키보드 접근성 지침에 위배됩니다. 많은 보조 기술은 앱 인터페이스를 보조 기술 사용자에게 제공하는 방법에 대한 논리의 일부로 요소에 집중하는 기능과 탭 순서를 사용합니다. 탭 순서에서 텍스트 전용 요소는 탭 순서에서 대화형 요소(단추, 확인란, 텍스트 입력 필드, 콤보 상자, 목록 등)만 예상하는 사용자에게 혼동을 줄 수 있습니다.
  • 프레젠테이션 순서가 자식 요소 선언 순서(실제로는 논리 순서임)와 다른 경우가 자주 있으므로 UI 요소(예: Canvas 요소)의 절대 위치 지정은 사용하지 마세요. 가능하면 화면 읽기 프로그램이 올바른 순서로 해당 요소를 읽을 수 있도록 문서 또는 논리 순서로 UI 요소를 정렬하는 것이 좋습니다. UI 요소의 표시 순서를 문서 또는 논리 순서와 다르게 하려면 명시적인 탭 인덱스 값(TabIndex 참조)을 사용하여 올바른 읽기 순서를 정의합니다.
  • 실제로 앱 기능에 필요하지 않는 한 전체 앱 canvas를 자동으로 새로 고치지 마세요. 페이지 콘텐츠를 자동으로 새로 고쳐야 하면 페이지의 특정 영역만 업데이트합니다. 일반적으로 보조 기술에서는 적용된 변경 내용이 최소인 경우에도 새로 고친 앱 canvas가 완전히 새로운 구조라고 가정합니다. 따라서 보조 기술 사용자는 새로 고친 앱의 문서 보기 또는 설명을 다시 만들어 사용자에게 다시 제공해야 할 수 있습니다.

    참고  영역 내의 콘텐츠를 새로 고치는 경우 해당 요소의 AccessibilityProperties.LiveSetting 접근성 속성을 기본 설정이 아닌 Polite 또는 Assertive 중 하나로 설정하는 것이 좋습니다. 일부 보조 기술은 라이브 영역의 ARIA(Accessible Rich Internet Applications) 개념에 이 설정을 매핑하여 해당 콘텐츠 영역이 변경되었음을 사용자에게 알릴 수 있습니다.

    참고  사용자가 의도적으로 페이지 탐색을 시작한 경우 앱의 구조를 새로 고치는 데 적합합니다. 그러나 탐색을 시작한 UI 항목을 올바르게 식별하거나 해당 항목을 호출하여 컨텍스트가 변경되고 페이지가 다시 로드되었음을 나타내도록 이름을 지정해야 합니다.

추가 사용법 지침

HTML 사용자 지정 컨트롤을 액세스 가능하게 만들기

HTML 사용자 지정 컨트롤을 사용하는 경우 해당 컨트롤에 대해 액세스 가능 이름, 역할, 상태, 값 등을 비롯한 기본적인 모든 접근성 정보를 제공해야 합니다. 또한 이 컨트롤을 키보드를 통해 완전히 액세스할 수 있고 UI가 시각적 접근성 요구를 충족하도록 해야 합니다.

예를 들어 사용자 지정 대화형 요소를 나타내는 div 요소(onclick 이벤트 처리)를 포함할 경우 다음과 같이 해야 합니다.

  • div 요소에 대해 접근 가능한 이름을 설정합니다.
  • 해당되는 대화형 ARIA 역할(예: "button")에 대해 role 특성을 설정합니다.
  • 탭 순서에 이 요소를 포함하려면 tabindex 특성을 설정합니다.
  • 키보드 활성화를 지원하려면 키보드 이벤트 처리기를 추가합니다(즉, onclick 이벤트 처리기에 해당하는 키보드 동작).

접근성을 위한 사용자 지정 HTML UI 요소 표시에 대한 자세한 내용은 ARIA(Accessible Rich Internet Applications)를 참조하세요.

참고  

HTML5 canvas 요소는 접근성을 지원하지 않습니다. 콘텐츠에 대해 접근성 정보를 노출할 수 있는 방법을 제공하지 않으므로 반드시 필요한 경우가 아니면 canvas는 사용하지 않도록 합니다. canvas를 사용하는 경우 사용자 지정 UI 요소로 간주하세요.

XTML 사용자 지정 컨트롤을 액세스 가능하게 만들기

XAML 사용자 지정 컨트롤을 사용하는 경우 해당 컨트롤에 대해 액세스 가능 이름, 역할, 상태, 값 등을 비롯한 기본적인 일부 접근성 정보를 조정해야 할 수 있습니다. 또한 이 컨트롤을 키보드를 통해 완전히 액세스할 수 있고 UI가 시각적 접근성 요구를 충족하도록 해야 합니다. XAML용 사용자 지정 컨트롤을 만들 때는 사용자 지정 컨트롤의 기본 클래스로 사용한 컨트롤에 사용할 수 있는 UI 자동화 지원을 상속합니다. 이것으로 충분할 수 있지만 컨트롤을 사용자 지정하는 수준에 따라 기본 UI 자동화 지원을 수정하거나 확대하는 사용자 지정 UI 자동화 피어 클래스를 만들 수도 있습니다. 이 작업은 Windows.UI.Xaml.AutomationWindows.UI.Xaml.Automation.Peers 네임스페이스의 API에서 지원합니다. 자세한 내용은 사용자 지정 자동화 피어를 참조하세요.

개발 플랫폼의 접근성 지원

Windows 런타임 개발 플랫폼은 개발 주기의 모든 단계에서 접근성을 지원합니다.

  • 만들기: Microsoft Visual Studio 앱 템플릿에서 생성된 코드에는 접근성 정보가 포함되어 있습니다.
  • 코딩: 개발 플랫폼은 코딩 단계 중에 다음의 접근성 지원을 제공합니다.
    • Visual Studio의 Microsoft IntelliSense에 접근성 정보가 포함되어 있습니다.
    • Windows 8 플랫폼에 포함된 컨트롤은 접근성을 기본적으로 지원합니다. 표준 HTML 및 플랫폼 컨트롤을 사용하여 대부분의 접근성 지원을 기본 플랫폼 동작으로 설정할 수 있습니다. 예를 들어 등급 컨트롤은 추가 작업 없이도 완전히 액세스 가능하지만 ListView 컨트롤에는 기본 목록 요소에 대한 액세스 가능한 이름만 있으면 됩니다. —다른 모든 접근성은 기본적으로 제공됩니다. 플랫폼 컨트롤 목록은 컨트롤 목록(HTML) 또는 컨트롤 목록(XAML)을 참조하세요.
    • Windows 개발자 센터 설명서에는 접근성 지침 및 샘플 앱이 포함되어 있습니다.
  • 테스트: Windows SDK(소프트웨어 개발 키트)에는 접근성 테스트 도구가 포함되어 있습니다. HTML 또는 XAML용 접근성 앱을 테스트하는 방법을 알아보세요.
  • 판매: 사용자가 스토어를 탐색하는 동안 접근성 필터를 사용하여 앱을 검색할 수 있도록 Windows 스토어에 앱을 게시할 때 앱에 접근성 기능이 포함되었음을 표시할 수 있습니다. Windows 스토어에 액세스할 수 있는 HTML 또는 XAML용 앱으로 선언하는 방법에 대해 자세히 알아보세요.

관련 항목

개발자용(HTML)
JavaScript로 작성된 Windows 런타임 앱의 접근성
앱의 접근성 테스트
ARIA(Accessible Rich Internet Applications)
ARIA 샘플
개발자용(XAML)
C++, C# 또는 Visual Basic으로 작성한 Windows 런타임 앱의 접근성
앱의 접근성 테스트
Windows.UI.Xaml.Automation
XAML 접근성 샘플

 

 

표시:
© 2014 Microsoft