접근성 기능 테스트

요약

axe-core-gem을 사용한 기능 테스트는 HAML, Vue 및 JavaScript 등 모든 UI 기술에 걸쳐 완전한 사용자 여정을 다루는 가장 포괄적인 접근성 테스트 접근 방식을 제공합니다. 다음에 대한 접근성 테스트를 우선시합니다:

접근성 테스트를 추가해야 하는 경우#

axe-core-gem을 사용한 기능 테스트는 HAML, Vue 및 JavaScript 등 모든 UI 기술에 걸쳐 완전한 사용자 여정을 다루는 가장 포괄적인 접근성 테스트 접근 방식을 제공합니다.

다음에 대한 접근성 테스트를 우선시합니다:

미션 크리티컬 사용자 여정: 사용자가 의존하는 핵심 워크플로우.
트래픽이 많은 페이지: 사용자 상호작용이 많은 영역.
새 기능: 처음부터 접근성 보장.
복잡한 UI 상호작용: 다단계 프로세스, 모달, 동적 콘텐츠.

전략적 접근 방식#

가능한 모든 페이지 조합을 테스트하는 것보다 주요 사용자 시나리오에 대한 심층 커버리지에 집중하세요. 이 접근 방식은 모든 뷰에 걸쳐 광범위하지만 얕은 커버리지보다 더 나은 가치를 제공합니다.

기능 테스트에서 테스트하는 것의 장점 중 하나는 개별 컴포넌트만이 아닌 다양한 상태와 완전한 사용자 흐름을 확인할 수 있다는 것입니다.

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

빈 상태#

일부 뷰에는 기본 뷰와 다른 페이지 구조를 만드는 빈 상태가 있습니다. 이러한 뷰는 예를 들어 첫 번째 이슈를 만들거나 기능을 활성화하는 등의 일부 작업을 제공할 수도 있습니다. 이 경우 빈 상태와 기본 뷰 모두에 대한 어설션을 추가합니다.

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

종종 우리는 사용자가 수행할 것으로 예상하는 여러 단계에 대해 테스트합니다. 이 경우 시뮬레이션이 시작되기 전에 일찍 검사를 포함해야 합니다. 이렇게 하면 사용자에게 기대하는 것에 대한 장벽이 없음을 보장합니다.

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

사용자 상호작용은 페이지 구조에 상당한 변화를 초래할 수 있습니다. 예를 들어 대화 상자가 표시되거나 새 섹션이 렌더링됩니다. 그 경우 이러한 변경 후에 어설션을 추가합니다. 사용자가 사용 가능한 모든 컴포넌트와 상호작용할 수 있음을 확인하고 싶습니다.

접근성 테스트를 추가하는 방법#

새 스펙 파일 생성#

자동화된 접근성 테스트를 위해 다양한 사용자 여정에 이미 정의된 단계를 따르고자 합니다. 이를 달성하기 위해 E2E 테스트용으로 정의된 테스트 케이스를 재사용합니다.

황금 사용자 여정#

이미 정의된 황금 사용자 여정에 접근성 테스트 커버리지가 있는지 확인하고 싶습니다. 이를 위해 Figma 파일을 접근성 스펙을 생성하는 데 사용할 수 있는 YAML 형식으로 변환했습니다.

이러한 스펙을 구현하는 방법은 Accessibility journeys README를 참조하세요.

특정 사용자 흐름#

기능에 대한 새 접근성 스펙을 추가하려면, 다음 중 하나로 그룹의 테스트 케이스 목록을 탐색합니다:

그룹 레이블로 필터링할 수 있는 테스트 케이스 페이지를 탐색합니다.
E2E browser_ui 디렉토리 및 ee/browser_ui 디렉토리로 이동한 다음 스테이지 디렉토리와 다루고자 하는 기능을 선택합니다.

다루고자 하는 사용자 여정을 알면:

spec/features/accessibility로 이동합니다.
스테이지와 다루고 있는 기능의 폴더 아래에 새 Ruby 스펙을 만듭니다. 예: create/repository/.
따르는 E2E 테스트 케이스 이름으로 파일 이름을 지정합니다. 예: add_new_branch_rule_spec.rb.

이 예시에서 결과는 spec/features/accessibility/create/repository/add_new_branch_rule_spec.rb 아래에 전용 기능 스펙이 됩니다.

다음 단계는 Capybara 기능 테스트 구문과 설정으로 테스트 케이스를 재현하는 것입니다.

axe 메서드 사용#

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

# spec/features/accessibility/create/repository/add_new_branch_rule_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"]'

# run only WCAG 2.1 Level AA rules
expect(page).to be_axe_clean.according_to :wcag21aa

# specifies which rule to skip
expect(page).to be_axe_clean.skipping :'link-in-text-block'

# clauses can be chained
expect(page).to be_axe_clean.within('[data-testid="element"]')
                            .according_to(:wcag21aa)

Axe는 비활성 메뉴나 대화 상자와 같은 숨겨진 영역을 테스트하지 않습니다. 숨겨진 영역의 접근성을 테스트하려면 영역을 활성화하거나 보이도록 렌더링하고 매처를 다시 실행하는 테스트를 작성합니다.

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

접근성 테스트를 추가한 후 가능한 모든 오류를 수정해야 합니다. 방법에 대한 도움은 이 가이드를 참조하세요. Pajamas 컴포넌트 문서의 접근성 섹션도 확인할 수 있습니다. 오류 중 전역 변경이 필요한 경우 후속 이슈를 생성하고 accessibility, WG::product accessibility 레이블을 할당합니다.

모범 사례#

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

페이지에서 접근성 테스트를 추가할 부분#

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

탐색 경로나 메인 네비게이션과 같이 모든 애플리케이션 뷰에 나타나는 요소가 있습니다. 이를 모든 기능 스펙에 포함하면 상당한 리소스를 사용하고 한 번만 할 수 있는 것을 여러 번 반복합니다. 이 요소들은 자체 기능 스펙이 있으며 그곳에서 테스트하고 싶습니다.
기능 스펙이 전체 뷰를 다루는 경우 <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 컴포넌트를 자주 사용하기 때문에 요소가 식별에 도움이 될 주석이 없는 <div>일 수 있습니다. 그러나 axe_core 규칙이 Ruby 테스트와 Deque 브라우저 확장 - axe devTools 모두에 사용된다는 사실을 활용할 수 있습니다. 둘 다 동일한 출력을 제공합니다.

원하는 브라우저에 axe DevTools 확장이 설치되어 있는지 확인합니다. 자세한 내용은 axe DevTools 공식 웹사이트를 참조하세요.
기능 테스트로 테스트하는 뷰로 이동합니다.
axe DevTools 확장을 열고 페이지 스캔을 실행합니다.
발견된 이슈를 펼치고 강조 표시 옵션을 사용하여 각 위반에 대한 페이지의 요소를 확인합니다.

알려진 접근성 위반#

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

link-in-text-block: 현재 위반을 수정하기 위해 skipping 절을 사용하여 :'link-in-text-block' 규칙을 건너뜁니다. 이것이 이슈 1444의 일부로 수정되고 GlLink 컴포넌트에 밑줄이 추가되면 이 절을 제거할 수 있습니다.