• 언제 접근성 테스트를 추가해야 하는가
  • 비어 있는 상태
  • 사용자 상호작용 전 준수 확인
  • 변화된 페이지 구조 후 준수 확인
  • 방대한 테스트 스위트를 위한 별개의 파일
  • 공유된 예시들
• 접근성 테스트 추가 방법
  • 좋은 관행
    • 테스트에서 페이지 찾기
    • 페이지의 어떤 부분에 대해 접근성 테스트를 추가할 것인지
    • 테스트 출력이 충분히 구체적이지 않음
  • 알려진 접근성 위반 사례

자동 접근성 테스트

우리는 axe-core gems를 사용하여 기능 테스트에서 자동 접근성 테스트를 수행합니다.

우리는 World Wide Web Consortium (W3C) Web Content Accessibility Guidelines 2.1의 AA 수준을 준수하려고 합니다..

언제 접근성 테스트를 추가해야 하는가

앱에 새로운 뷰를 추가할 때는 기능 테스트에서 접근성 검사를 포함해야 합니다. 우리는 모든 뷰에 대한 완전한 커버리지를 목표로 합니다.

기능 테스트에서 테스트하는 장점 중 하나는 단일 구성 요소가 아닌 다양한 상태를 확인할 수 있다는 것입니다.

접근성 검사에 대한 접근 방법에 대한 몇 가지 예제를 찾을 수 있습니다.

비어 있는 상태

일부 뷰는 기본 뷰와는 다른 페이지 구조로 이어지는 비어 있는 상태를 가지고 있습니다. 그들은 첫 번째 이슈를 만들거나 특정 기능을 활성화하는 것과 같은 몇 가지 작업을 제공할 수도 있습니다. 이 경우, 빈 상태와 기본 뷰에 대한 어서션을 추가하세요.

사용자 상호작용 전 준수 확인

일반적으로 사용자가 수행할 것으로 예상되는 여러 단계에 대해 테스트합니다. 이 경우, 시뮬레이션된 단계가 사전에 진행되기 전에 확인하세요. 이렇게 함으로써 사용자가 기대하는 바에 장애물이 없는지 확인합니다.

변화된 페이지 구조 후 준수 확인

사용자 상호작용은 페이지 구조에 중요한 변화를 일으킬 수 있습니다. 예를 들어 모달이 표시되거나 새로운 섹션이 렌더링될 수 있습니다. 이 경우, 해당 변경 이후의 어서션을 추가하세요. 우리는 사용자가 모든 사용 가능한 구성 요소와 상호 작용할 수 있는지 확인하고 싶습니다.

방대한 테스트 스위트를 위한 별개의 파일

일부 뷰에 대해 기능 테스트는 여러 파일에 걸쳐 있습니다. 병합 요청에 대한 기능 테스트를 살펴보세요. Cover해야 할 사용자 상호작용의 수가 하나의 테스트 파일에 맞지 않을 정도로 큽니다. 따라서 여러 기능 테스트는 하나의 뷰를 커버하며, 서로 다른 사용자 권한 또는 데이터 세트를 갖습니다. 모든 테스트에 접근성 검사를 포함하면 동일한 뷰 상태를 여러 번 커버하고 실행 시간을 크게 증가시킬 수 있습니다. 또한 여러 파일에 어서션을 분산시키면 접근성의 커버리지를 파악하기 어려워집니다.

이 경우에는 접근성에 전용하는 한 테스트 파일을 만든 것을 고려하세요. 이 파일을 동일한 디렉터리에 넣고 accessibility_spec.rb라는 이름으로 지정하세요. 예를 들면 spec/features/merge_request/accessibility_spec.rb입니다. 기능 테스트에 접근성 커버리지가 있는지를 명시하고 추가적인 어서션이 필요하지 않음을 명시하세요. 최상위 블록의 열림 아래에 다음 주석을 포함하세요.

# spec/features/merge_request/user_approves_spec.rb

# frozen_string_literal: true

require 'spec_helper'

RSpec.describe 'Merge request > User approves', :js, feature_category: :code_review_workflow do
# covered by ./accessibility_spec.rb

공유된 예시들

일반적으로 기능 테스트에는 여러 시나리오에 대한 공유된 예시들이 포함됩니다. 제공된 데이터에 의해 다르지만 동일한 사용자 상호작용에 기반한 경우에는 공유된 예시들 외부에서 접근성 준수를 확인할 수 있습니다. 이렇게 하면 한 번만 테스트를 실행하고 리소스를 절약할 수 있습니다.

접근성 테스트 추가 방법

Axe는 다음과 같이 사용할 수 있는 커스텀 matcher be_axe_clean을 제공합니다.

# spec/features/settings_spec.rb
it 'passes axe automated accessibility testing', :js do
  visit_settings_page

  wait_for_requests # ensures page is fully loaded

  expect(page).to be_axe_clean
end

필요한 경우 within를 사용하여 페이지의 특정 영역으로 테스트 범위를 지정할 수 있습니다.

또한 Axe는 다음과 같은 특정 조항들을 제공합니다.

expect(page).to be_axe_clean.within '[data-testid="element"]'

# WCAG 2.1 Level AA 규칙만 실행
expect(page).to be_axe_clean.according_to :wcag21aa

# 건너뛸 규칙을 지정
expect(page).to be_axe_clean.skipping :'link-in-text-block'

# 조항은 연결될 수 있습니다
expect(page).to be_axe_clean.within('[data-testid="element"]')
                            .according_to(:wcag21aa)

Axe는 비활성 메뉴 또는 모달 윈도우와 같은 숨겨진 영역을 테스트하지 않습니다. 접근성을 위해 숨겨진 영역을 테스트하려면 해당 영역을 활성화하거나 렌더링하는 테스트를 작성한 후 matcher를 다시 실행하세요.

접근성 테스트는 로컬에서 기능 테스트를 실행하는 것과 동일한 방식으로 실행할 수 있습니다.

접근성 테스트를 추가한 후 가능한 모든 오류를 수정하세요. 도움이 필요한 경우, 이 가이드를 참조하세요. Pajamas 구성 요소의 문서에서 접근성 섹션을 확인할 수도 있습니다. 오류 중 일부가 전체적인 변경이 필요한 경우, 후속 작업 문제를 만들고 accessability, WG::product accessibility 라벨을 지정하세요.

좋은 관행

기능 테스트에 접근성 검사를 추가하는 것은 관련 제품 영역의 도메인 지식이 있는 경우 더 쉽습니다. 그러나 접근성 테스트에 기여하는 데 도움이 되는 몇 가지 요소가 있습니다.

테스트에서 페이지 찾기

페이지 URL이 없는 경우, 미리보기 모드로 기능 spec을 실행하여 시작할 수 있습니다. 테스트를 실행하는 명령의 시작 부분에 WEBDRIVER_HEADLESS=0을 추가하세요. 또한, :js 태그가 있는 테스트 케이스 내에서 브라우저를 멈추려면 live_debug로 짝을 지으면 됩니다 (테스트 최상의 관행의 문서 참조).

페이지의 어떤 부분에 대해 접근성 테스트를 추가할 것인지

대부분의 경우 전체 페이지에 대한 접근성을 테스트하고 싶지 않습니다. 그 이유는 몇 가지 있습니다:

1. 모든 애플리케이션 뷰에 나타나는 요소, 예를 들어 breadcrumb나 주요 탐색과 같은 요소가 있습니다. 이러한 요소는 각 기능 spec에 포함되면 자원을 상당히 차지하며 한 번만 수행할 수 있는 작업을 복제합니다. 이러한 요소는 각자의 기능 spec을 가지며 거기서 테스트하고 싶습니다.

2. 기능 spec이 전체 뷰를 커버하는 경우, 가장 좋은 관행은 <main id="content-body"> 요소로 범위를 지정하는 것입니다. 이에 대한 예시는 다음과 같습니다:

    it "passes axe automated accessibility testing" do
      expect(page).to be_axe_clean.within('#content-body')
    end
   

3. 기능 테스트가 페이지의 일부만을 커버하는 경우, 일부 구성 요소를 포함하는 섹션과 같은 페이지의 일부분에 대한 테스트를 유지하세요. 가능하다면, 기능 spec이 사용하는 동일한 선택기를 사용하세요. 다음은 그러한 테스트 사례의 예시입니다:

    it 'passes axe automated accessibility testing for todo' do
      expect(page).to be_axe_clean.within(todo_selector)
    end
   

테스트 출력이 충분히 구체적이지 않음

Axe 테스트 케이스가 실패하면 발견된 위반 사항과 해당하는 엘리먼트를 표시합니다. Pajamas Components를 자주 사용하기 때문에, 엘리먼트가 식별에 도움이 되는 어노테이션이 없는 <div>일 수 있습니다. 그러나 axe_core 규칙은 루비 테스트와 Deque 브라우저 확장 프로그램 - axe DevTools 모두 동일한 출력을 제공합니다.

1. 선택한 브라우저에 axe DevTools 확장 프로그램이 설치되어 있는지 확인하세요. 자세한 정보는 axe DevTools 공식 웹사이트를 참조하세요.

2. 테스트할 뷰로 이동하세요.

3. axe DevTools 확장 프로그램을 열고 페이지를 스캔하세요.

4. 발견된 문제를 확장하고 각 위반에 대한 페이지의 엘리먼트를 확인하는 데 하이라이트 옵션을 사용하세요.

알려진 접근성 위반 사례

이 섹션은 디자인 시스템과 달리하는 권장 사항의 위반을 문서화합니다:

• link-in-text-block: 현재는 :'link-in-text-block' 규칙을 건너뛰는 절을 사용하여 위반을 해결하세요. issue 1444의 일환으로 문제가 해결되고 GlLink 컴포넌트에 밑줄이 추가되면 이 절을 제거할 수 있습니다.