접근 가능한 구성 요소 작성하기

학습 목표

이 유닛을 완료하면 다음을 수행할 수 있습니다.

Lightning 구성 요소 프레임워크에 포함된 구성 요소 집합을 식별합니다.
접근 가능한 구성 요소를 만드는 단계를 나열합니다.
사용자 정의 웹 구성 요소를 빌드하는 단계를 나열합니다.

개요

Lightning 구성 요소 프레임워크는 완벽하게 동작하는 구성 요소 집합을 제공합니다. 이러한 모든 구성 요소는 관련 접근성 지침을 따르는 최신 SLDS 구성 요소 청사진을 기반으로 합니다. 가능한 경우 이러한 기존 구성 요소를 사용하세요. 접근성에 대한 검증을 받았기 때문에 많은 추가 작업을 수행할 필요가 없습니다. 이러한 구성 요소는 구성 요소 참조에서 자세히 알아볼 수 있습니다.

구성 요소 사용

구성 요소 참조에는 Aura 구성 요소와 Lightning 웹 구성 요소라는 두 가지 구성 요소 집합에 대한 정보가 포함되어 있습니다. 나열된 Aura 구성 요소는 다양한 네임스페이스에 속합니다. ui 및 force 네임스페이스의 구성 요소는 예전 ARIA 사양을 충족하도록 개발되었기 때문에 이제는 가장 접근성이 뛰어난 구성 요소가 아닙니다.

Lightning 웹 구성 요소(LWC)는 Salesforce로 UI를 구축하는 데 선호되는 방법입니다. Aura에서 Lightning 웹 구성 요소로 마이그레이션 모듈에서 LWC를 사용하고 현재 웹 표준을 준수하는 방법을 알아보세요. 또는 Aura에 대해 자세히 알아보려면 Lightning Aura 구성 요소 개발자 가이드나 Aura 구성 요소 문서를 방문하세요.

lightning 접두사가 있는 Lightning 웹 구성 요소는 모두 최신 ARIA 표준에 따라 작성되었으며, 최신 SLDS 구성 요소 청사진을 따릅니다. 가능한 경우 예전 구성 요소 대신 이러한 구성 요소를 사용하세요.

Lightning 구성 요소를 사용하는 경우에도 접근성을 염두에 두어야 합니다. 예를 들어 <lightning-icon>을 사용하여 정보 아이콘을 배치하는 경우 사용자가 아이콘의 목적을 알 수 있도록 적절한 alternative-text 값을 지정해야 합니다. <lightning-input>을 사용하는 경우에도 결과 <input>을 해당 <label>과 프로그래밍 방식으로 연결하려면 label을 지정해야 합니다. required="true"를 설정하면 접근 가능한 방식의 입력을 필요로 합니다.

‘This field is required(이 필드는 필수입니다).’ 오류 메시지가 표시된 입력 레이블 및 자리 표시자 텍스트입니다.

많은 Lightning 구성 요소에는 ARIA 속성을 설정하기 위한 특성도 있습니다. 접근성을 위해 필요하지 않을 수도 있지만, 이러한 값을 설정해야 하는 경우를 대비하여 포함하겠습니다.

구성 요소 만들기

구성 요소 참조에서 원하는 구성 요소를 찾을 수 없는 경우 고유한 Lightning 구성 요소를 빌드해야 할 수 있습니다. 그러한 경우 다음 단계에 따라 접근성을 확인하세요.

항상 SLDS 구성 요소 청사진에서 시작합니다. 마크업과 ARIA 역할, 상태 및 속성을 주의 깊게 살펴보세요. 모든 필수 특성 그리고 사용자가 구성 요소와 상호 작용할 때 변경되는 특성을 기록해두세요.
키보드 상호 작용을 구현합니다. ARIA 역할은 사용자에 대한 약속임을 기억하세요. 이러한 약속에는 여러분이 지정한 역할에 대해 사용자가 기대하는 키보드 기능을 제공하는 것이 포함됩니다. Salesforce의 구성 요소 청사진에는 키보드 탐색 지침이 포함되어 있습니다.

팁: Tab 키 누르기 이벤트를 수신하지 말고, 대신에 포커스를 수신하세요. 화면 판독기 사용자가 Tab 키를 사용하여 페이지를 탐색하는 경우는 거의 없습니다.

사용자 포커스를 관리합니다. 전역 포커스 지침에 따라 대화형 요소에 포커스를 둘 수 있는지 확인하세요.
자동화를 작성하고 구성 요소를 수동으로 테스트합니다.
1. 통합 테스트를 작성하여 키보드 상호 작용을 테스트합니다. 키보드 상호 작용을 테스트하는 신뢰할 수 있는 유일한 방법은 실제 브라우저를 사용하는 것입니다. 회귀를 포착하기 위해 수동 DOM 검사를 사용하지 마세요. 다음을 포함하여 마크업 정확도를 보장하는 테스트를 작성하세요.
  - 올바른 노드에 올바른 시맨틱이 있습니다.
  - 올바른 노드에 올바른 특성이 설정되어 있습니다.
  - 구성 요소 수명 주기 동안 올바른 특성 값이 업데이트됩니다.
2. SLDS 사양에 따라 키보드만 사용하여 엔드투엔드 기능 테스트를 수동으로 완료합니다. 모든 작업을 키보드만 사용하여 완료할 수 있어야 합니다.

웹 구성 요소

웹 구성 요소는 웹을 위한 표준 구성 요소 모델을 제공하는 브라우저 기능으로, Shadow DOM, 사용자 정의 요소, HTML 템플릿, CSS 변경 사항(소스)과 같은 다양한 위치에서 유지 관리되는 여러 부분으로 구성됩니다. 실질적으로 웹 구성 요소에는 사용자 정의가 루트로 있습니다. 이러한 사용자 정의 요소는 시맨틱 가치는 없지만, 보조 과학 기술에 대한 직접적 종속 문제를 일으킬 수 있습니다.

직접적 종속 문제

웹 구성 요소 목록 항목 <lightning-example-list-item>을 사용하여 순서가 지정되지 않은 목록 <ul>을 작성하는 경우 마크업은 다음과 같습니다.

<ul>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <li>content</li>
  </lightning-example-list-item>
</ul>

하지만 <ul>의 모든 하위 항목은 <li> 요소여야 하므로 접근이 불가능합니다. 화면 판독기는 이것이 세 가지 항목으로 구성된 목록임을 인식할 수 없습니다. 여기서는 시맨틱 요소가 아니라 ARIA 역할을 사용하는 것이 더 좋습니다.

<ul> 대신에 role="list"가 포함된 다른 웹 구성 요소를 사용할 수 있습니다. 그러면 목록 항목 웹 구성 요소에 role="listitem"이 필요하며, <li> 요소는 사용하지 않습니다. 아래 표시된 코드를 통해 화면 판독기는 세 가지 항목으로 구성된 목록임을 올바르게 식별할 수 있습니다.

<lightning-example-list>
<div role="list">
  <lightning-example-list-item>
    <div role="listitem">content</div>
  </lightning-example-list-item>
  <lightning-example-list-item”>
    <div role="listitem">content</div>
  </lightning-example-list-item>
  <lightning-example-list-item>
    <div role="listitem">content</div>
  </lightning-example-list-item>
</div>
</lightning-example-list>

전역 HTML 특성

전역 HTML 특성을 사용하여 내부 요소에 대한 특성을 설정하지 마세요. Lighting 웹 구성 요소를 사용하여 호스트에 대한 전역 HTML 특성을 설정하면, 프레임워크는 사용자가 전달하더라도 해당 특성이 호스트에 있기를 원한다고 가정합니다. 예를 들어 입력 웹 구성 요소의 aria-describedby 특성을 API로 사용하여 하위 항목에 대한 특성을 설정하는 경우 의도치 않게 두 번 설정하게 됩니다.

<lightning-example-input aria-describedby="foo">

다음과 같이 렌더링됩니다.

<lightning-example-input aria-describedby="foo">
  <input aria-describedby="foo" />
</lightning-example-input>

대신에, 다음 예제와 같이 웹 구성 요소의 API 이름을 CamelCase로 표기하세요.

<lightning-example-input ariaDescribedby="foo">

이제 올바르게 렌더링됩니다.

<lightning-example-input>
  <input aria-describedby="foo" />
</lightning-example-input>

CamelCase 사용을 포함하여 속성 및 특성 이름에 대한 자세한 내용은 리소스 섹션을 참조하세요.

Shadow DOM

Shadow DOM이 활성화된 웹 구성 요소는 접근성에 대한 추가 문제를 유발합니다. 웹 접근성의 많은 측면은 페이지의 서로 다른 요소를 연결하는 구성 요소 ID 참조에 의존합니다. 간단한 예로는 양식 입력에 레이블을 지정하는 것을 들 수 있습니다.

<label for="foo">First Name</label>
<input type="text" id="foo" />

위 코드 예제에서 id “foo" 는 ‘First Name(이름)' 레이블을 텍스트 입력과 연결합니다. 레이블과 입력이 Shadow DOM으로 인해 별도의 웹 구성 요소에 배치된 경우 이 관계는 브라우저의 접근성 트리에 더 이상 존재하지 않습니다.

<lightning-example-label>
     <label for="foo">First Name</label>
</lightning-example-label>
<lightning-example-input>
     <input type="text" id="foo" />
</lightning-example-input>

이 시나리오에서는 레이블과 입력이 더 이상 연결되지 않고, 양식에 더 이상 접근할 수 없습니다. 이때 해결책은 ID 참조 관계가 필요할 때 요소를 다른 사용자 정의 요소로 분리하지 않는 것입니다.

<lightning-example-input>
     <label for="foo">First Name</label>
     <input type="text" id="foo">
</lightning-example-input>

사용자 정의 웹 구성 요소를 빌드하면서 SLDS 청사진 및 ARIA 설계 사양을 자세히 살펴보세요. ID 참조에 의존하는 HTML 및 ARIA 속성을 식별하고, 그러한 요소를 별도의 섀도우 루트로 분리하지 마세요.

W3C의 한 그룹은 접근성 개체 모델을 개발합니다. 이 접근 방식은 HTML 특성 및 ID 참조에 의존하지 않고 역할 및 속성을 할당하고, 상태를 업데이트하고, 관계를 생성할 수 있는 수단을 제공합니다. 이 모델은 아직 초안 상태이지만, 브라우저, 보조 과학 기술, 개발 커뮤니티에서 채택되면 웹 구성 요소의 접근성에 대해 향상된 제어 기능을 제공할 것입니다.

정리

지금까지 접근 가능한 사용자 인터페이스를 구축하기 위한 기본 사항에 대해 알아보았습니다. 접근성을 위한 설계 및 테스트를 시작할 준비가 되면 Trailhead에서 더 많은 리소스를 살펴보시기 바랍니다. 또한 Salesforce Trailblazer Community에서 방대한 관리자 및 개발자 커뮤니티에 가입하여 아이디어를 공유하고, 그룹에 가입하고, 성공 사례를 확인할 수 있습니다.

리소스

문서: W3C 표준 및 초안
Salesforce 개발자 참조: Lightning 웹 구성 요소
Salesforce 개발자 참조: 속성 및 특성 이름
문서: 접근성 개체 모델
Salesforce 도움말: 구성 요소 청사진
문서: W3C 웹 구성 요소 사양