접근성 테스트

학습 목표

이 유닛을 완료하면 다음을 수행할 수 있습니다.

• 자동화된 테스트 외에도 수동 접근성 테스트를 반드시 실행해야 하는 이유를 설명할 수 있습니다.
  
• MacOS에서 키보드 및 초점 관리 테스트를 수행하는 과정을 요약할 수 있습니다.
  
• VoiceOver를 사용하여 화면 판독기 테스트를 수행할 때 완료해야 할 검사를 나열할 수 있습니다.
  
• 접근성 테스트 계획에 반영해야 할 요소들을 파악합니다.
  
• 효과적인 수동 접근성 테스트를 위한 전략을 설명할 수 있습니다.
  

수동 테스트의 중요성 이해하기

자동화된 접근성 테스트는 다양한 문제를 찾아낼 수 있지만 맥락을 고려하거나 미묘한 접근성 문제를 식별하지는 못합니다. 때로는 아주 중요한 문제를 놓치기도 합니다. 그래서 수동 테스트를 함께 실시해서 자동 테스트로는 찾아내지 못하는 장벽들을 찾아내는 것이 중요합니다. 또한 수동 테스트를 실시하면 자동화된 테스트로 찾아낸 문제를 다시 한번 확인할 수 있고 잘못 식별한 사례를 찾아낼 수 있습니다.

자동화된 접근성 테스트와는 달리 수동 테스트는 사용자의 여정을 종합적으로 평가하여 장애가 있거나 지원 기술을 사용하는 사용자의 경험을 시뮬레이션할 수 있습니다. 예를 들어 수동 키보드 테스트로는 키보드만을 사용해 소프트웨어를 탐색하는 사용자의 행동을 시뮬레이션할 수 있으며, 화면 리더기 테스트로는 시각 장애인 사용자의 소프트웨어 사용 방식을 시뮬레이션할 수 있습니다.

그러면 수동 접근성 테스트 중 키보드 및 초점 관리부터 자세히 살펴보겠습니다.

키보드 및 초점 관리 테스트 실시하기

키보드 및 초점 관리 테스트는 사용자가 간단하고 예상 가능한 방식으로 UI를 탐색하고 상호작용할 수 있는지 확인하는 훌륭한 방법입니다.

키보드 테스트를 할 때는 다음과 같은 점을 확인해야 합니다.

• 다양한 입력을 사용해 컨텐츠에 접근할 수 있는가? 사용자가 음성 명령, 터치 스크린, 스위치 컨트롤과 같은 다양한 입력 기기를 사용해 컨텐츠를 탐색할 수 있어야 합니다. 마우스 커서를 사용해서만 볼 수 있는 컨텐츠는 터치화면, 음성 명령 및 키보드 사용자가 접근하지 못할 수 있습니다.
  
• 초점 순서가 논리적인가? 초점 순서는 사용자가 상호작용 요소들(링크, 버튼, 양식 필드 등)에 집중하게 되는 순서를 말합니다. 이 순서가 논리적 흐름을 따르지 않으면 컨텐츠를 탐색하기 어려워집니다.
  
• 사용자가 컨텐츠를 효율적으로 일관성 있게 탐색할 수 있는가? 키보드 입력이나 명령 등의 탐색 방식에 일관성이 없을 경우 특히 지원 기술을 사용하는 최종 사용자는 어려움을 겪을 수 있습니다.
  
• 모든 사용자가 컨텐츠를 이용할 수 있는가? 운동 장애, 손 및 시력 장애가 있는 사용자를 고려합니다.
  

Mac에서 테스트할 경우에는 키보드 시스템 환경설정에서 모든 키보드 액세스를 활성화해야 합니다. 방법은 다음과 같습니다.

MacOS에서 키보드 탐색 활성화

1. System Preferences(시스템 환경설정)에서 Keyboard(키보드) 설정을 엽니다.
   
2. Shortcuts(바로 가기) 탭을 선택합니다.
   
3. Full Keyboard Access(전체 키보드 액세스)에서 All controls(모든 컨트롤)를 선택합니다.
   

Safari에서 키보드 액세스 활성화

1. Safari의 Preferences(환경설정)를 엽니다.
   
2. Advanced(고급) 탭을 선택합니다.
   
3. Accessibility(접근성)에서 Press Tab to highlight each item on a webpage(Tab을 눌러 웹 페이지의 각 항목을 강조 표시)를 선택합니다.
   

웹 페이지 탐색에 사용되는 키는 다음과 같습니다.

모든 대화형 요소에 도달하여 동작을 트리거할 수 있나요?

여러 대화형 요소를 포함하는 일부 복잡한 구성 요소는 콤보 상자, 메뉴, 데이터 그리드, 비모달 및 모달 대화 상자 및 탭 집합을 포함하여 기본 기능 이상의 고유 키보드 상호 작용을 제공합니다. 이러한 키보드 상호 작용은 W3C(World Wide Web Consortium)의 ARIA 작성 관행 지침에 의해 정의된 특정 기대치를 따릅니다.

Salesforce는 이러한 기대치를 기준으로 키보드 지침을 구축하며, 이 지침은 Lightning 및 Lightning Design System의 React 구성 요소 라이브러리에 사용됩니다. 이러한 구성 요소를 구축하고 테스트하는 데 도움이 되는 몇 가지 유용한 리소스를 Lightning Design System 2 사이트에서 모아두었습니다.

• 키보드 상호작용 접근성 지침: 수동 키보드 테스트 체크리스트
  
• 글로벌 초점 접근성 지침: 초점 관리를 위한 예상되는 행동에 대한 팁
  
• 접근성: 일반적인 위젯/패턴에 대한 HTML 및 상호작용 사양
  

키보드 탐색

키보드 탐색을 테스트할 경우 다음을 확인하세요.

• 탭 순서가 논리적인지 여부. 키보드를 사용하여 앱을 탭합니다. 기본 탐색 순서는 논리적이고 자연스럽게 보여야 합니다.
  
• 키보드 포커스가 보이는지 여부. 키보드를 사용하여 페이지를 탐색하고 시각적 표시기에 키보드 포커스가 있는 요소가 표시되는지 확인합니다.
  

• 실행 가능한 항목이 포커스를 받는지 여부. 키보드를 사용하여 페이지를 탐색합니다. 모든 버튼, 링크, 양식 필드, 탭 및 기타 대화형 항목에서 키보드 초점을 허용하는지 테스트합니다. 사용자가 항목을 클릭해서 작업을 수행하거나 마우스 커서를 올려 정보를 표시하려면 키보드 포커스를 허용해야 합니다.
  

• 대화형 요소의 탐색 가능 여부. 메뉴, 모달, 드래그 앤 드롭 요소, 탭 집합, 패널 및 자동 완성 드롭다운과 같은 모든 대화형 요소를 탐색할 수 있는지 확인합니다. 키보드를 사용하여 항목을 선택하고 활성화할 수 있는지 확인합니다.
  

• 모달 대화상자를 탐색할 수 있는지 여부. 키보드를 사용하여 모달 대화 상자를 열고 탐색하고 모든 컨트롤을 작동시킬 수 있습니다. 백그라운드 페이지가 아닌 현재 모달 창과만 상호 작용할 수 있는지 확인합니다. 모달이 열려 있는 경우 포커스는 해당 모달 내에 있어야 합니다. 모달이 닫히면 포커스가 페이지의 올바른 위치로 돌아가는지 확인합니다.
  

키보드 테스트와 화면 리더기 테스트는 동일하지 않다는 점을 기억하세요. 화면 리더기 테스트 이전에 키보드 테스트를 수행하여 화면 리더기로는 포착할 수 없는 각종 문제를 식별하세요.

화면 리더기 테스트 실시하기

MacOS와 Windows 모두에서 화면 리더기를 테스트하는 것이 좋습니다. MacOS에는 선택한 요소를 음성으로 말하며 그 라벨이나 대체 텍스트를 읽는 화면 리더기인 VoiceOver가 내장되어 있습니다. 화면 리더기를 테스트할 때는 대체 텍스트가 정확한지 확인한 뒤 필요에 따라 수정합니다.

MacOS의 VoiceOver로 수행할 수 있는 간단한 검사는 다음과 같습니다.

• Cmd+F5를 눌러 VoiceOver를 켜거나 끕니다.
  
• Cmd+u를 눌러 Web Rotor를 엽니다.
  
• Web Rotor를 사용하여 다음을 확인합니다.
  
  • 링크와 버튼에는 간결하고 의미 있는 라벨이 있습니다.
    
  • 제목의 순서가 올바릅니다.
    
  • 페이지에 적절한 랜드마크가 있습니다.
    
• UI를 차례로 탭하여 다음 내용을 확인합니다.
  
  • 편집 가능한 필드의 라벨, 입력 유형, 단어 편집이 음성으로 출력됩니다.
    
  • 탭 집합은 선택한 탭을 나타내며 화살표 키를 사용하여 탐색할 수 있습니다.
    
  • 확인란은 스페이스바를 사용하여 전환할 경우 상태를 음성으로 표시합니다.
    

화면 리더기를 사용하여 UI를 탭하여 모든 컨텐츠에 연결할 수 없더라도 걱정하지 마세요. 화면 리더기 사용자는 페이지를 요소(비상호작용형 요소 포함)별로 탐색하기 위한 특정 키보드 단축키를 가지고 있으므로, 탭 키가 모든 요소에 도달할 필요는 없으며 그래서도 안 됩니다. VoiceOver를 사용하면 Ctrl+Option+왼쪽 화살표 또는 Ctrl+Option+오른쪽 화살표를 사용하여 페이지 내용을 선형적으로 앞뒤로 읽을 수 있습니다.

Windows에서는 NVDA를 사용하는 것이 좋습니다.

여러 화면 리더기를 사용해 접근성 테스트를 실시하세요. VoiceOver로만 테스트하면 다른 화면 리더기(JAWS 또는 NVDA)는 포착할 수 있는 특정 문제를 놓칠 수 있습니다.

화면 리더를 자주 사용하지 않을 경우 화면 리더기로 테스트할 때 사용자 오류가 발생하기 쉽습니다. 리소스 섹션의 A11ycasts 동영상을 참조하여 화면 리더기 사용과 관련된 상세 내용을 확인하세요.

접근성 테스트 계획 작성

구성 요소 사양, 수용 기준, 사용자 스토리에 접근성을 포함시켜 테스트 계획에 접근성을 반영합니다.

예: 앱 시작 관리자

아이콘을 선택해 앱 시작 관리자를 엽니다. 앱 시작 관리자에서 사용자는 앱을 검색하고, 앱을 열고, 앱 설명을 읽고, 앱을 재정렬할 수 있습니다.

앱을 재배열하려면 어떤 테스트 사례를 만들 수 있을까요?

앱 시작 관리자와 관련된 다양한 사용 사례에 대한 샘플 테스트 계획입니다.

참고로 기능이란 제품이나 시스템이 수행할 수 있는 바와 동작을 의미합니다. 행동 유도성이란 개체의 모습이나 동작을 통해 해당 개체의 사용 방식을 암시하는 디자인 요소입니다.

추가할 수 있는 다른 테스트 사례는 무엇인가요? 어떻게 테스트할 수 있을까요? 화면 리더기 속성 및 키보드 동작에 대한 자동 테스트를 작성할 수 있더라도 수동 테스트 또한 실시해서 환경의 접근성을 확실히 확인하는 것이 좋습니다.

수동 테스트 전략 사용하기

이제 내용을 종합해 봅시다. 수동 접근성 테스트를 효과적으로 수행하기 위한 전략은 다음과 같습니다.

테스트 계획 작성

다음 사항을 반영할 수 있습니다.

• 주요 시각적 상태에 대해 $A.test.assertAccessible을 호출합니다(구성 요소 테스트용).
  
• 키보드 플로를 수동으로 확인합니다.
  
• 사용 사례 고유의 요소들을 고려합니다.
  

조기 테스트 및 주기

사용자 인터페이스 구축 시:

• 수동으로 테스트합니다.
  
• 테스트 자동화를 활용합니다.
  
• 사용자 정의 테스트를 통해 접근성을 높일 수 있는 기회를 찾아봅니다.
  

로그 및 버그 수정

Salesforce는 아무리 소수에게 미치는 문제라 하더라도 접근성 버그를 우선적으로 처리합니다. 버그로 불편을 겪는 사용자에게 해당 문제는 작업 수행을 가로막는 근본적인 장벽입니다. 여러분의 소속 조직이 이러한 버그에 설령 소홀하더라도 해결되지 않은 접근성 문제를 최소화하기 위해 목소리를 내세요.

자동화된 접근성 테스트와 수동 접근성 테스트를 모두 실시해 접근성 장벽을 제거하면 모두가 참여하고 즐길 수 있는 진정한 포용적 디지털 경험을 제공할 수 있습니다!

리소스

• 웹 페이지: ARIA 작성 실무
• Salesforce 사이트: Lightning Design System 2: 키보드 상호작용 접근성 지침
• Salesforce 사이트: Lightning Design System 2: 글로벌 초점 접근성 지침
• Salesforce 사이트: Lightning Design System 2: 접근성
• 웹 사이트: NV 액세스
• 웹 사이트: Freedom Scientific: JAWS
• 동영상: A11ycasts: 접근성 확인 방법—A11ycasts #11
• 동영상: A11ycasts: 화면 리더기의 기초: VoiceOver—A11ycasts #07
• 동영상: A11ycasts: 화면 리더기의 기초: NVDA—A11ycasts #09