자동화된 접근성 테스트

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

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

접근성 테스트 추가 시기

응용 프로그램에 새로운 뷰를 추가할 때는 기능 테스트에 접근성 검사도 포함되도록 하세요.

우리는 모든 뷰에 대한 완전한 커버리지를 목표로 합니다.

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

접근성 검사를 수행하는 방법에 대한 몇 가지 예는 아래에서 확인할 수 있습니다.

비어 있는 상태

일부 뷰는 기본 뷰와 다른 페이지 구조의 빈 상태를 가집니다.

그들은 첫 번째 이슈를 만들거나 기능을 활성화하는 등의 작업을 제공할 수 있습니다.

이 경우 빈 상태와 기본 뷰 모두에 대한 단언을 추가하세요.

사용자 상호작용 전에 준수 보장

종종 우리는 사용자가 수행할 것으로 예상되는 여러 단계를 테스트합니다.

이 경우 사용자가 시뮬레이션되기 전에 조기 검사를 포함하는 것이 중요합니다.

이렇게 하면 사용자가 기대하는 것에 대한 장벽이 없다는 것을 보장할 수 있습니다.

변경된 페이지 구조 후 준수 보장

사용자 상호작용은 페이지 구조에 중대한 변화를 초래할 수 있습니다.

예를 들어, 모달이 표시되거나 새로운 섹션이 렌더링됩니다.

이 경우, 그러한 변경 후에 단언을 추가하세요.

우리는 사용자가 모든 available 구성 요소와 상호작용할 수 있도록 보장하고자 합니다.

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

일부 뷰의 기능 테스트는 여러 파일에 걸쳐 있을 수 있습니다.

Merge Request에 대한 기능 테스트를 살펴보세요.

커버해야 하는 사용자 상호작용의 수가 너무 커서 하나의 테스트 파일에 담을 수 없습니다.

결과적으로, 여러 기능 테스트가 하나의 뷰를 다루며, 서로 다른 사용자 권한이나 데이터 세트를 사용합니다.

모두에 접근성 검사를 포함하면 동일한 뷰의 상태를 여러 번 커버할 가능성이 있으며 실행 시간을 상당히 늘릴 수 있습니다.

또한, 단언이 여러 파일에 분산되어 있으면 접근성 커버리지를 결정하기가 더 어려워질 것입니다.

이 경우 접근성에 전념하는 하나의 테스트 파일을 만드는 것을 고려하세요.

동일한 디렉터리에 위치시키고 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는 다음과 같이 사용할 수 있는 사용자 지정 매처 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 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는 비활성 메뉴나 모달 창과 같은 숨겨진 영역은 테스트하지 않습니다.

숨겨진 영역에 대한 접근성을 테스트하기 위해서는 해당 영역을 활성화하거나 렌더링하여 다시 매처를 실행하는 테스트를 작성하세요.

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

접근성 테스트를 추가한 후에는 가능한 모든 오류를 수정해야 합니다.

수정 방법에 대한 도움은 이 가이드를 참고하세요.

또한 Pajamas 구성 요소 문서에서 접근성 섹션을 확인할 수 있습니다.

오류 중 일부가 글로벌 변경을 요구하는 경우, 후속 이슈를 생성하고 다음 레이블을 할당하세요: accessability, WG::product accessibility.

모범 사례

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

테스트에서 페이지 찾기

페이지 URL이 없는 경우 미리 보기 모드에서 기능 사양을 실행하여 시작할 수 있습니다. 이렇게 하려면 테스트를 실행하는 명령어의 시작 부분에 WEBDRIVER_HEADLESS=0을 추가합니다. live_debug와 함께 사용하여 :js 태그가 있는 테스트 케이스 내에서 브라우저를 중지할 수도 있습니다(가시적인 브라우저에서 JS 사양 실행에 대한 문서를 참조하세요: 테스트 모범 사례).

접근성 테스트를 추가할 페이지의 부분

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

모든 애플리케이션 보기에서 나타나는 요소가 있으며, 예를 들어 빵 부스러기(navigation) 또는 주요 내비게이션이 있습니다. 이러한 요소를 모든 기능 사양에 포함시키면 상당한 자원을 소모하고 한 번만 수행할 수 있는 것을 다중화하게 됩니다. 이러한 요소에는 자체 기능 사양이 있으며, 우리가 이들을 테스트하고자 하는 곳입니다.
기능 사양이 전체 보기를 포함하는 경우, 모범 사례는 <main id="content-body"> 요소로 범위를 제한하는 것입니다. 다음은 그러한 테스트 케이스의 예입니다:
```
 it "passes axe automated accessibility testing" do
   expect(page).to be_axe_clean.within('#content-body')
 end
```
기능 테스트가 부분적인 페이지의 일부만 포함하는 경우, 예를 들어 일부 구성 요소를 포함하는 섹션의 경우 해당 섹션으로 제한하십시오. 가능하다면 기능 사양이 테스트 케이스에 사용하는 동일한 선택기를 사용하세요. 다음은 그러한 테스트 케이스의 예입니다:
```
 it 'passes axe automated accessibility testing for todo' do
   expect(page).to be_axe_clean.within(todo_selector)
 end
```

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

axe 테스트 케이스가 실패하면 발견된 위반 사항과 관련된 요소가 출력됩니다. 우리는 종종 Pajamas Components를 사용하기 때문에, 요소가 식별하는 데 도움이 될 수 있는 주석 없이 <div>가 될 수 있습니다. 그러나 우리는 Ruby 테스트와 Deque 브라우저 확장인 axe devTools 모두에서 axe_core 규칙이 사용된다는 사실을 활용할 수 있습니다. 두 가지 모두 동일한 출력을 제공합니다.

선호하는 브라우저에 axe DevTools 확장이 설치되어 있는지 확인하세요. 추가 정보는 axe DevTools 공식 웹사이트를 참고하세요.
기능 테스트로 테스트 중인 보기를 탐색하세요.
axe DevTools 확장을 열고 페이지 스캔을 실행하세요.
발견된 문제를 확장하고 하이라이트 옵션을 사용하여 각 위반의 페이지에서 요소를 확인하세요.

알려진 접근성 위반 사항

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

link-in-text-block: 현재로서는 :'link-in-text-block' 규칙을 건너뛰기 조항을 사용하여 위반을 수정합니다. 이것이 문제 1444의 일환으로 수정되고 GlLink 구성 요소에 밑줄이 추가되면 이 조항은 제거될 수 있습니다.