• 언제 접근성 테스트를 추가해야 하는가
  • 빈 상태
  • 사용자 상호작용 전 준수 확인
  • 페이지 구조 변경 후 준수 확인
  • 다양한 테스트 스위트를 위한 별도의 파일
  • 공유된 예시
• 접근성 테스트를 추가하는 방법
  • 알려진 접근성 위반 사항

자동 접근성 테스트

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

우리는 World Wide Web Consortium (W3C) 웹 콘텐츠 접근성 지침 2.1의 AA 수준을 준수하기를 목표로 합니다.

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

애플리케이션에 새로운 뷰를 추가할 때, 기능 테스트에 접근성 검사를 포함하는지 확인하세요. 우리는 모든 뷰에 대한 완벽한 커버리지를 목표로 합니다.

기능 테스트에서 테스트하는 장점 중 하나는 단일 구성 요소뿐만 아니라 여러 상태를 확인할 수 있다는 것입니다.

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

빈 상태

어떤 뷰는 빈 상태를 가지고 있어 기본 뷰와는 다른 페이지 구조를 만듭니다. 또한, 예를 들어 첫 번째 이슈를 생성하거나 기능을 활성화하는 작업을 제공할 수도 있습니다. 이 경우, 빈 상태와 기본 뷰에 대한 어서션을 추가하세요.

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

자주 우리는 사용자가 수행할 것으로 예상되는 몇 가지 단계에 대해 테스트합니다. 이 경우, 시뮬레이션되기 전에 조기에 확인하여 사용자가 기대하는 것에 대한 장벽이 없도록 합니다.

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

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

다양한 테스트 스위트를 위한 별도의 파일

일부 뷰에서 기능 테스트는 여러 파일에 걸쳐 있습니다. 병합 요청 기능 테스트를 참조하세요. 커버해야 하는 사용자 상호작용의 수가 한 테스트 파일에 맞지 않을 정도로 큽니다. 결과적으로 여러 기능 테스트가 하나의 뷰를 다루고, 사용자 권한 또는 데이터 집합이 다릅니다. 이러한 경우, 모든 기능 테스트에 접근성 검사를 포함한다면 동일한 뷰 상태를 여러 번 커버하게 되고 실행 시간이 크게 증가할 수 있습니다. 또한 많은 파일에 어서션을 흩뿌리면 접근성 커버리지를 결정하기 어려워집니다.

이 경우 접근성에 전념하는 별도의 테스트 파일을 만드는 것을 고려하세요. 예를 들어 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 rules만 실행
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 컴포넌트 문서의 접근성 섹션을 확인할 수 있습니다. 오류 중 일부가 전역적인 변경이 필요한 경우 발행 문제를 생성하고 다음 레이블을 할당하세요: accessibility, WG::product accessibility.

알려진 접근성 위반 사항

이 섹션은 디자인 시스템과 다른 권장 내용으로 문서화된 위반 사항을 기록합니다:

• link-in-text-block: 현재는 link-in-text-block 규칙을 건너뛰는 skipping 절을 사용하여 위반 사항을 해결하세요. 이 사항은 이슈 1444의 일환으로 수정된 후 GlLink 컴포넌트에 밑줄이 추가되면 해당 절을 삭제할 수 있습니다.