자동 접근성 테스트

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

우리는 World Wide Web Consortium (W3C) 웹 콘텐츠 접근성 지침 2.1의 AA 레벨을 준수하고자 합니다.

언제 접근성 테스트를 추가해야 합니까?

애플리케이션에 새로운 뷰를 추가할 때, 기능 테스트에 접근성 검사를 포함해야 합니다. 우리는 모든 뷰에 대해 완벽한 커버리지를 가질 것을 목표로 하고 있습니다.

기능 테스트에서 테스트하는 장점 중 하나는 단일 컴포넌트뿐만 아니라 다양한 상태를 확인할 수 있다는 것입니다.

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

비어 있는 상태(Empty state)

일부 뷰에는 기본 뷰와 다른 페이지 구조로 이어지는 비어 있는 상태가 있을 수 있습니다. 또한 예를 들어 첫 번째 이슈를 만들거나 기능을 활성화하는 등의 동작을 제공할 수도 있습니다. 이 경우 비어 있는 상태와 기본 뷰에 대한 어서션을 추가하세요.

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

일반적으로 우리는 사용자가 수행할 것으로 예상되는 단계들에 대해 테스트합니다. 이 경우, 사용자가 시뮬레이트되기 전에 체크를 포함해야 합니다. 이렇게 함으로써 우리는 사용자가 우리가 기대하는 것에 대한 장벽이 없는지 확인할 수 있습니다.

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

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

방대한 테스트 스위트에 대한 별도의 파일

일부 뷰에 대해 기능 테스트는 여러 파일에 걸쳐 있습니다. Merge Request을 위한 기능 테스트를 살펴보세요. 테스트해야 하는 사용자 상호 작용의 수가 한 테스트 파일에 들어 맞지 않을 정도로 큰 경우가 있습니다. 결과적으로 여러 기능 테스트가 하나의 뷰를 다루며, 사용자 권한이나 데이터 집합에 따라 다릅니다. 우리가 모두 그들에게 접근성 검사를 포함한다면, 같은 뷰의 상태를 여러 번 커버하고 실행 시간을 크게 늘릴 가능성이 있습니다. 또한, 여러 파일에 어서션을 흩뿌릴 경우에 접근성에 대한 커버리지를 결정하는 것이 더 어려워질 수 있습니다.

이 경우, 접근성에 대한 별도의 테스트 파일을 생성하는 것을 고려하세요. 예를 들어 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는 다음과 같이 사용할 수 있는 사용자 정의 매처 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는 비활성 메뉴나 모달 창과 같은 숨겨진 영역을 테스트하지 않습니다. 접근성을 위해 숨겨진 영역을 테스트하려면 해당 영역을 활성화하거나 표시하는 테스트를 작성하고 매처를 다시 실행하세요.

접근성 테스트를 로컬에서 실행하는 방법은 기능 테스트를 실행하는 방법과 동일합니다.

접근성 테스트를 추가한 후에는 가능한 모든 오류를 수정해야 합니다. 어떻게 수정해야 하는지 도움이 필요한 경우, 이 안내서를 참조하세요. 또한 파자마 컴포넌트 문서의 접근성 섹션을 확인할 수 있습니다. 오류 중 일부가 글로벌한 변경을 필요로 하는 경우, 후속 이슈를 생성하고 다음 라벨을 할당하세요: accessibility, WG::product accessibility.

알려진 접근성 위반

이 섹션은 디자인 시스템과 다른 권고 사항이 있는 위반 사례를 문서화합니다:

link-in-text-block: for now, use the skipping clause to skip :'link-in-text-block' rule to fix the violation. After this is fixed as part of issue 1444 and underline is added to the GlLink component, this clause can be removed.