접근성 트리

게시일: 2025년 11월 22일 | 원문 작성일: 2020년 6월 29일 | 저자: Hidde de Vries | 원문 보기

접근성 트리란 뭘까요?

프론트엔드 개발자라면 DOM 트리에 대해서는 들어봤을 거예요. 하지만 접근성 트리(Accessibility Tree)는 어떨까요? Hidde de Vries가 Accessible Bristol 행사에서 들은 Léonie Watson의 발표를 정리한 이 글은, 많은 개발자가 직관적으로만 알고 있던 접근성 트리가 실제로 존재한다는 걸 보여줘요.

DOM vs 접근성 트리

DOM 트리는 우리가 잘 아는 구조예요. 브라우저가 HTML을 파싱해서 만드는 트리죠. 그런데 브라우저는 동시에 또 다른 트리를 만들어요. 바로 접근성 트리예요.

접근성 트리에는 ‘접근성 객체’가 들어가요. 이 객체들은 DOM 엘리먼트를 기반으로 하지만, 모든 DOM 엘리먼트가 접근성 트리에 들어가는 건 아니에요. 뭔가를 “노출”하는 엘리먼트만 들어가요.

뭘 “노출”한다는 걸까요?

DOM 엘리먼트는 다음을 노출할 수 있어요:

• 프로퍼티 (Property): 예를 들어, “Label”이 라벨이라는 속성
• 관계 (Relationship): 어떤 라벨이 어떤 체크박스를 위한 것인지
• 기능 (Feature): 체크 가능하다는 기능
• 상태 (State): 체크됨/안됨 상태

일부 엘리먼트는 기본적으로 뭔가를 노출해요. __CODE_UNDER_0__이 좋은 예예요. 버튼이라는 역할, 클릭 가능하다는 기능, 활성/비활성 상태 등을 자동으로 노출하죠.

하지만 __CODE_UNDER_1__이나 __CODE_UNDER_2__ 같은 엘리먼트는 의미가 중립적이에요. 기본적으로는 아무것도 노출하지 않아요.

새로운 접근 방식: 접근성 우선 사고

이게 바로 Léonie Watson이 제안한 새로운 접근 방식이에요. 웹 페이지를 만들 때, 단순히 “이게 어떻게 보이지?”가 아니라 “이게 접근성 트리에 뭘 노출하지?”라고 물어야 해요.

노출의 예시

구체적인 예를 볼까요:

__FENCED_UNDER_0__

이 간단한 HTML은 많은 걸 노출해요:

• “Label”이 라벨이라는 프로퍼티
• 이 라벨이 __CODE_UNDER_3__ 체크박스와 연결됐다는 관계
• 체크 가능하다는 기능
• 체크됨/안됨 상태

이 모든 정보가 접근성 트리에 추가돼요. 그리고 개발자는 아무것도 추가하지 않았어요! 의미 있는 HTML 엘리먼트를 사용했을 뿐이에요. 대부분의 브라우저에 이미 내장되어 있어요.

문제: 노출하지 않는 엘리먼트

하지만 모든 엘리먼트가 이렇게 친절하지는 않아요. __CODE_UNDER_4__과 __CODE_UNDER_5__는 의미가 중립적이에요. CSS와 JavaScript로 스타일링하고 동작을 추가할 수 있지만, 접근성 트리에는 아무것도 노출하지 않아요.

__FENCED_UNDER_1__

CSS와 JavaScript로 버튼처럼 보이고 동작하게 만들 수 있어요. 많은 프론트엔드 프레임워크가 이렇게 해요. 하지만 이 “버튼”의 모양과 동작은 일부 사용자만 접근할 수 있어요. 여전히 __CODE_UNDER_6__ 엘리먼트이기 때문에, 브라우저는 의미가 중립적이라고 가정하고 접근성 트리에 아무것도 노출하지 않아요.

해결책: ARIA로 수동으로 노출하기

Léonie는 이 문제를 __CODE_UNDER_7__과 ARIA 속성, 그리고 __CODE_UNDER_8__로 해결할 수 있다고 설명해요:

__FENCED_UNDER_2__

이제 이 엘리먼트는 버튼 역할을 접근성 트리에 노출해요. 완벽하진 않아요 (진짜 __CODE_UNDER_9__이 여전히 더 좋아요), 하지만 아무것도 안 하는 것보다는 훨씬 나아요.

SVG에서의 노출

SVG가 점점 더 인기를 끌면서, SVG에서도 접근성이 중요해졌어요. SVG 1.1은 ARIA를 공식적으로 지원하지 않지만, SVG 2.0에는 내장될 예정이에요.

SVG 엘리먼트는 비시각적으로 의미를 노출할 수단이 별로 없어요 (__CODE_UNDER_10__과 __CODE_UNDER_11__ 정도). ARIA 라벨로 이걸 개선할 수 있어요.

Web Components에서의 노출

Web Components는 JavaScript로 만드는 커스텀 HTML 엘리먼트예요. 예를 들어, __CODE_UNDER_12__이 맞지 않으면 __CODE_UNDER_13__을 만들 수 있어요.

현재는 두 가지 방법이 있어요:

• 기존 엘리먼트 기반: __CODE_UNDER_14__이 __CODE_UNDER_15__처럼 동작. 가능하면 기존 엘리먼트의 프로퍼티와 역할을 상속받아요
• 완전히 새로운 엘리먼트: 프로퍼티와 역할을 상속받지 않아요. 개발자가 직접 추가해야 해요

첫 번째 방법이 최근에 스펙에서 제거될 뻔했어요. Bruce Lawson은 이게 HTML의 우선순위 원칙을 위반한다고 주장했어요.

”진심으로 코딩하세요”

Léonie는 긍정적인 메시지로 발표를 끝냈어요: 접근 가능한 웹사이트를 만들기 위해 기능이나 디자인을 희생할 필요가 없어요. “진심으로 코딩”하기만 하면 돼요.

많은 엘리먼트 (예: __CODE_UNDER_16__)는 접근성 트리에 자동으로 노출돼요. 무료 접근성 기능이 내장되어 있어요. 그리고 내장 접근성 기능이 없는 엘리먼트를 사용해야 한다면, ARIA를 사용해서 접근성 트리에 유용한 정보를 노출할 수 있어요.

최선의 전략

개인적으로, 저는 항상 엘리먼트를 본래 용도대로 사용하는 게 최선의 전략이라고 생각해요. 예를 들어:

• 버튼에는 __CODE_UNDER_17__을 사용하세요 (ARIA로 보완된 __CODE_UNDER_18__이 아니라)
• 가능한 곳에서는 의미 있는 HTML을 작성하세요
• 이미 의미가 없는 것들 (SVG, Web Components, 프론트엔드 프레임워크가 출력하는 __CODE_UNDER_19__)을 개선할 때만 ARIA를 사용하세요

핵심 교훈

접근성 트리는 웹을 보편적으로 만드는 보이지 않는 인프라예요. 좋은 아키텍처는 기본적으로 접근 가능하게 만들어요. 서로 다른 사용 사례 (시각 렌더링과 프로그래밍 방식 액세스)를 위한 병렬 데이터 구조는 보편적 디자인을 가능하게 해요.

수백만 명이 매일 접근성 트리에 의존하지만, 대부분의 개발자는 그 존재조차 몰라요. 이제 우리는 알아요. 그리고 이 지식으로, 더 나은 웹을 만들 수 있어요.