Chrome DevTools는 개발자가 전체 트리에 대한 개요를 더 쉽게 확인할 수 있도록 완전한 접근성 트리를 출시합니다. 이 게시물에서는 이 트리를 만드는 방법과 이 트리를 업무에 사용하는 방법을 알아봅니다.
접근성 트리란 무엇인가요?
스크린 리더와 같은 보조 기술은 Chromium의 Accessibility API를 사용하여 웹 콘텐츠와 상호작용합니다. 이 API의 기본 모델은 접근성 트리입니다. 보조 기술이 속성과 속성을 쿼리하고 작업을 실행할 수 있는 접근성 객체의 트리입니다. 웹 개발자는 주로 HTML용 ARIA 속성과 같은 DOM 속성을 통해 접근성 트리를 만들고 조작합니다.
Chrome DevTools에는 콘텐츠가 보조 기술에 노출되는 방식을 개발자가 이해할 수 있도록 접근성 창이 제공됩니다. 구체적으로 DOM 트리 뷰어에서 노드를 선택하면 상응하는 접근성 노드의 속성이 노드의 상위 항목 및 직계 하위 항목 뷰와 함께 창에 표시됩니다.
트리는 어떻게 만들어지나요?
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>
Chromium의 Blink라는 렌더기는 대략 다음과 같이 내부 접근성 트리를 파생합니다.
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 트리와 동기화된 새로운 전체 접근성 트리를 통해 개발자가 두 트리를 오가며 전환할 수 있습니다. Google은 새 트리가 더욱 탐색 가능하고 유용하고 사용하기 쉽게 되기를 바랍니다.
이제 접근성 트리의 작동 방식을 알게 되었으므로 DevTools를 사용하여 새 트리 뷰의 모양을 확인할 수 있습니다. 제목, 제목과 두 개의 버튼이 있는 다음 HTML 문서는 트리를 표시하는 데 사용됩니다.
<!DOCTYPE html>
<title>Test</title>
<h1>Heading for example page</h1>
<div>
<button>Back</button>
<button>Next</button>
</div>
이전 트리 보기에서는 단일 노드와 그 상위 항목만 탐색할 수 있었습니다.
이제 새 트리를 전환하면 DOM 트리 뷰가 대체되고 페이지의 전체 접근성 트리를 볼 수 있습니다.
지연 나무 건설
규모가 큰 사이트에서도 트리 성능이 향상되도록 하기 위해 트리는 탐색될 때 프런트엔드에 느리게 구성됩니다. 트리에서 노드가 확장되면 노드의 하위 요소를 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를 사용하여 페이지에서 '클릭', 스크롤 또는 값 변경과 같은 작업을 허용할 수 있습니다.