자동 접근성 테스트

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

우리는 World Wide Web Consortium (W3C) Web Content Accessibility Guidelines 2.1의 AA 레벨을 준수하도록 노력하고 있습니다.

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

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

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

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

빈 상태

일부 뷰에는 기본 뷰와 구조가 다른 빈 상태가 있습니다. 또한 첫 번째 이슈를 만들거나 기능을 활성화하는 기능을 제공할 수도 있습니다. 이 경우 빈 상태와 기본 뷰에 대한 어서션을 추가하십시오.

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

대부분의 경우, 우리는 사용자가 수행할 것으로 예상되는 여러 단계에 대해 테스트합니다. 이 경우 먼저 어떤 사용자 상호 작용도 시뮬레이트되기 전에 확인하십시오. 이렇게 함으로써 사용자가 우리가 기대하는 것에 대한 장벽이 없음을 보장할 수 있습니다.

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

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

포괄적인 테스트 스위트를 위한 별도 파일

일부 뷰에 대한 기능 테스트는 여러 파일에 걸쳐 있습니다. 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 # 페이지가 완전히 로드되었는지 보장
  
  expect(page).to be_axe_clean
end

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

또한 Axe는 특정 을 제공합니다.

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

# WCAG 2.1 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는 비활성 메뉴나 모달 윈도우와 같은 숨겨진 영역을 테스트하지 않습니다. 접근성용으로 숨겨진 영역을 테스트하려면 해당 영역을 활성화하거나 표시하도록 하는 테스트를 작성하고 매처를 다시 실행하십시오.

지역에서 접근성 테스트를 로컬에서 실행하려면 모든 기능 테스트를 실행하는 것과 동일한 방식으로 실행하십시오.

접근성 테스트를 추가한 후 모든 가능한 오류를 수정했는지 확인하십시오. 이를 돕기 위해 이 가이드를 참조하십시오. 또한 Pajamas 컴포넌트 문서의 접근성 섹션을 확인할 수 있습니다. 오류 중 일부가 전역적인 변경이 필요하다면, 관련된 레이블을 지정하여 후속 이슈를 만들고 실시하십시오: accessability, WG::product accessibility.

알려진 접근성 위반

이 섹션은 디자인 시스템에서 권장사항이 다른 위반사항을 문서화합니다.

  • link-in-text-block: 일시적으로 skipping 절을 사용하여 'link-in-text-block' 규칙을 건너뛰는 지침을 사용합니다. 이 문제가 이슈 1444의 일환으로 수정되고 GlLink 컴포넌트에 밑줄이 추가되면이 절을 제거할 수 있습니다.