Chrome DevTools의 전체 접근성 트리

Johan Bay
Johan Bay

Chrome DevTools는 개발자가 전체 트리의 개요를 더 쉽게 얻을 수 있도록 완전한 접근성 트리를 출시할 예정입니다. 이 게시물에서는 이 트리가 어떻게 만들어지고 작업에서 사용하는 방법을 알아봅니다.

접근성 트리란 무엇인가요?

스크린 리더와 같은 보조 기술은 Chromium의 Accessibility API를 사용하여 웹 콘텐츠와 상호작용합니다. 이 API의 기본 모델은 접근성 트리입니다. 접근성 트리는 보조 기술이 속성과 속성을 쿼리하고 작업을 실행할 수 있는 접근성 객체의 트리입니다. 웹 개발자는 주로 HTML용 ARIA 속성과 같은 DOM 속성을 통해 접근성 트리를 만들고 조작합니다.

Chrome DevTools에서는 개발자가 자신의 콘텐츠가 보조 기술에 어떻게 노출되는지 이해할 수 있도록 접근성 창을 제공합니다. 구체적으로 DOM 트리 뷰어에서 노드를 선택하면 해당하는 접근성 노드의 속성이 창의 상위 항목 및 바로 아래 하위 항목의 뷰와 함께 창에 표시됩니다.

Chrome DevTools 접근성 창

트리는 어떻게 만들어지나요?

DevTools에서 이 새로운 전체 트리 뷰가 어떤 모습인지 살펴보기 전에 접근성 트리가 무엇인지 더 구체적인 용어로 간략하게 살펴보겠습니다. 접근성 트리는 DOM 트리의 파생 트리입니다. 구조는 거의 동일하지만 스타일 지정에만 사용되는 <div> 요소와 같이 시맨틱 콘텐츠가 없는 노드를 삭제하도록 단순화되었습니다. 트리의 각 노드에는 Button 또는 Heading와 같은 역할이 있으며, 이름은 대개 ARIA 속성에서 비롯되거나 노드의 콘텐츠에서 파생됩니다. HTML 문서를 살펴보면 다음과 같습니다.

<html>
<head>
  <title>How old are you?</title>
</head>
<body>
  <label for="age">Age</label>
  <input id="age" type="number" name="age" value="42">
  <div>
    <button>Back</button>
    <button>Next</button>
  </div>
</body>
</html>

Blink라는 Chromium의 렌더기는 대략 다음과 같이 내부 접근성 트리를 파생합니다.

role='rootWebArea' focusable name='How old are you?'
  role='genericContainer' ignored
    role='genericContainer' ignored
      role='labelText'
        role='staticText' name='Age'
      role='spinButton' editable focusable name='Age' value='42'
        role='genericContainer' editable
          role='staticText' editable name='42'
      role='genericContainer'
        role='button' focusable name='Back'
          role='staticText' name='Back'
        role='button' focusable name='Next'
          role='staticText' name='Next'

이 표현에는 genericContainer 역할이 있는 불필요한 노드가 여러 개 포함되어 있습니다. 이는 접근성 트리가 DOM 트리의 단순화된 파생물이라는 위의 진술과 상반되는 것으로 보입니다. 하지만 이러한 노드는 대부분 내부 트리에서만 발생하며 보조 기술에 노출되지 않습니다. DevTools는 렌더러 프로세스에서 직접 접근성 정보를 수집하므로 DevTools는 이 트리 표현을 처리합니다.

DevTools의 전체 접근성 트리

새로운 전체 접근성 트리는 DOM 트리와 동기화되므로 개발자가 두 트리 간에 전환할 수 있습니다. 새 트리가 더욱 탐색 가능하고 유용하며 사용하기 쉽기를 바랍니다.

이제 접근성 트리의 작동 방식을 이해했으므로 DevTools를 사용하여 새로운 트리 뷰가 어떻게 표시되는지 확인할 수 있습니다. 제목, 제목 및 두 개의 버튼이 있는 다음 HTML 문서는 트리를 표시하는 데 사용됩니다.

<!DOCTYPE html>
<title>Test</title>
<h1>Heading for example page</h1>
<div>
  <button>Back</button>
  <button>Next</button>
</div>

이전 트리 보기에서는 단일 노드와 상위 노드만 탐색할 수 있었습니다.

DevTools의 이전 트리 뷰

이제 새 트리를 전환하면 DOM 트리 뷰가 대체되고 페이지의 전체 접근성 트리를 볼 수 있습니다.

DevTools의 새로운 트리 뷰

지연 트리 생성

규모가 큰 사이트에서도 트리가 잘 작동하도록 하기 위해 트리는 탐색 과정에서 프런트엔드에서 느리게 구성됩니다. 트리에서 노드가 확장되면 Chrome DevTools 프로토콜 (CDP)을 통해 노드의 하위 요소를 가져오고 트리가 다시 빌드됩니다.

큰 페이지의 결과를 보여주는 새 접근성 트리

라이브

새 트리 보기는 활성 상태이며 렌더기에서 접근성 트리가 변경되면 동적으로 업데이트됩니다. 트리 변경 사항을 보조 기술에 알리는 동일한 메커니즘에 연결하고 이를 사용하여 업데이트된 노드가 있는 DevTools 프런트엔드에 이벤트를 내보냅니다. 실제로 CDP 백엔드는 트리 업데이트를 수신 대기하고, 이전에 요청된 노드를 추적하고, 이러한 노드가 변경되면 DevTools 프런트엔드로 이벤트를 전송합니다.

수많은 나무 이야기

접근성 트리가 무엇인지 설명하면서 Blink가 렌더링하는 DOM의 접근성 트리를 구성하고 DevTools가 CDP를 통해 이 트리를 가져오는 방법을 알아봤습니다. 이 내용이 사실이지만 이 설명에서 몇 가지 복잡한 내용을 생략했습니다. 실제로는 다양한 방법으로 Chromium의 접근성 트리를 체험할 수 있습니다. 우리는 DevTools를 위한 새로운 트리 뷰를 설계할 때 Chromium의 접근성 내부 기능 중 어떤 부분을 표시하고 싶은지 몇 가지 선택했습니다.

플랫폼

모든 플랫폼에는 다른 접근성 API가 있으며 트리의 모양은 모든 플랫폼에서 동일하지만 트리와 상호작용하기 위한 API도 다르며 속성의 이름은 다를 수 있습니다. DevTools에 역할 및 속성이 ARIA 사양에 정의된 역할과 속성과 일치하는 경향이 있는 Chromium의 내부 트리가 표시됩니다.

다중 프레임 및 사이트 격리

Chromium은 모든 탭의 콘텐츠를 서로 다른 렌더기 프로세스에 배치할 뿐만 아니라 여러 렌더기 프로세스에서 크로스 사이트 문서를 격리하기 때문에 CDP를 통해 프로세스 외부 하위 문서에 개별적으로 연결하고 접근성 트리를 가져와야 합니다. 그런 다음 이러한 하위 트리를 프런트엔드에서 병합하여 Chromium의 다른 렌더러 프로세스에 상주하지만 하나의 일관된 트리처럼 보입니다.

무시되고 관심이 없는 노드

무시된 노드와 이름이 없는 '일반' 역할을 가진 노드 등 기본값별로 일부 노드를 숨깁니다. 이러한 노드는 의미론적 의미를 갖지 않으며, 노드를 무시하는 경우 보조 기술에 노출되지 않습니다. 트리 보기가 복잡해지지 않도록 이러한 노드를 숨깁니다. 그렇게 하지 않으면 대부분의 웹페이지의 접근성 트리는 다음과 같이 표시됩니다.

모든 노드가 표시된 새로운 트리 보기

여기서 주의할 점은 이는 기본적으로 백엔드에서 사용할 수 있는 트리가 아닌 다른 트리를 구성해야 한다는 것을 의미합니다. 예를 들어 A, B, C, X가 있고 A에 하위 X와 B가 있고 X에 하위 C가 있다고 가정해 보겠습니다. X가 무시된 노드인 경우 트리에서 X를 프루닝한 후 대신 C가 A의 하위 요소인 트리를 만듭니다.

나무 가지치기 방법을 보여주는 다이어그램

프런트엔드에서는 무시된 노드를 포함한 전체 트리를 구성하고 노드를 렌더링하기 직전에만 프루닝합니다. 이렇게 하는 이유는 두 가지입니다.

  • 두 엔드포인트에서 동일한 트리 구조가 있으므로 백엔드의 노드 업데이트를 훨씬 간단하게 처리할 수 있습니다. 예를 들어 예에서 노드 B가 제거되면 하위 노드가 변경되었으므로 노드 X에 대한 업데이트를 받지만 이 노드를 프루닝한 경우 무엇을 업데이트할지 파악하는 데 어려움을 겪을 수 있습니다.
  • 모든 DOM 노드에 상응하는 접근성 노드가 있도록 합니다. 트리가 전환되면 DOM 트리에서 현재 선택된 노드에 해당하는 노드가 선택됩니다. 따라서 이전 예에서 X에 해당하는 DOM 노드가 선택되어 있는 동안 사용자가 트리를 전환하면 노드 A와 B 사이에 X를 삽입하고 트리에서 X를 선택합니다. 이를 통해 사용자가 모든 DOM 노드의 접근성 노드를 검사하고 노드가 무시되는 이유를 판단할 수 있습니다.

향후 아이디어

새로운 접근성 트리를 실행하는 것은 시작에 불과합니다. 새로운 뷰를 바탕으로 향후 프로젝트를 위한 몇 가지 아이디어를 준비하고 있으니 의견을 보내주시기 바랍니다.

대체 필터링

위에서 설명한 것처럼 현재 흥미롭지 않은 것으로 간주되는 노드를 필터링합니다. 이 동작을 사용 중지하고 모든 노드를 표시하는 방법을 제공하거나 랜드마크 노드 표시 또는 제목 표시와 같은 대체 필터링을 제공할 수도 있습니다.

접근성 문제 강조표시

'접근성 권장사항' 분석을 트리에 통합하고 문제가 되는 노드에서 바로 접근성 문제를 강조 표시할 수 있습니다.

DevTools에 접근성 작업 표시

현재 표시되는 트리는 일방통행입니다. 따라서 특정 웹페이지를 탐색할 때 보조 기술에 어떤 정보가 제공될지 파악할 수 있습니다. 접근성 작업은 다른 방향의 통신을 나타냅니다. 이를 통해 보조 기술이 표시된 UI에서 작동할 수 있습니다. DevTools에 이러한 작업을 표시하여 보조 기술에 사용할 수 있는 API를 사용하여 페이지에서 '클릭', 스크롤 또는 페이지 값 변경과 같은 작업을 허용할 수 있습니다.