Chrome 148 접근성 트리 기본화: 웹 UX QA가 DOM 밖에서 확인할 것

Chrome은 2026년 5월 5일 공개한 DevTools 148 변경 사항에서 전체 페이지 접근성 트리를 실험 단계에서 벗어나 Elements 패널의 기본 보기로 유지한다고 밝혔습니다. 기존의 축약된 breadcrumb 방식은 제거됐습니다. 확인된 사실은 검사 도구의 기본 경로가 더 포괄적인 접근성 표현으로 바뀌었다는 것입니다. POEMORA의 해석은 디자인 QA의 단위를 ‘보이는 화면’에서 ‘보조기술이 인식하는 인터페이스’까지 확장해야 한다는 신호라는 것입니다.

Chrome 148에서 실제로 달라진 점

접근성 트리는 브라우저가 DOM, CSS, ARIA 정보를 바탕으로 보조기술에 노출하는 구조입니다. Chrome 148에서는 전체 트리가 기본이 되었고, DOM 보기와 접근성 트리 보기는 Accessibility 사이드바의 전용 토글로 전환합니다. 이전의 부동 전환 버튼과 레거시 축약 트리는 제거됐습니다.

이 변화가 웹사이트의 접근성을 자동으로 개선하는 것은 아닙니다. 다만 개발자와 디자이너가 한 요소의 시각적 모양뿐 아니라 계산된 이름, 역할, 상태와 트리의 포함 여부를 더 쉽게 확인하게 합니다. Chrome 공식 접근성 기능 문서도 Lighthouse 감사를 통해 스크린 리더용 마크업과 텍스트 대비를 점검하고, 세부 도구로 요소를 검사하는 흐름을 안내합니다.

확인된 범위: Chrome 발표는 DevTools UI와 검사 흐름의 변경입니다. 특정 서비스가 WCAG를 준수한다거나 자동 감사만으로 모든 장벽을 찾는다는 의미는 아닙니다.

DOM과 접근성 트리는 왜 다르게 보이나

DOM은 문서의 노드 구조이고 접근성 트리는 사용자가 조작하고 이해하는 데 필요한 의미를 추려 보조기술에 전달하는 구조입니다. 장식 요소는 제외될 수 있고, 시각적으로 단순한 버튼도 접근 가능한 이름과 상태를 가져야 합니다. 반대로 화면에 글자가 보여도 CSS 배경 이미지나 잘못 숨긴 요소라면 기대한 의미가 전달되지 않을 수 있습니다.

이 차이를 이해하면 ‘HTML 태그를 썼으니 접근 가능하다’는 단순한 결론을 피할 수 있습니다. 네이티브 요소를 우선 사용하되, 실제 계산 결과와 상호작용을 함께 봐야 합니다.

디자인 QA에 접근성 트리를 넣는 절차

첫째, 대표 사용자 여정을 정합니다. 로그인, 검색, 상품 선택, 상담 신청처럼 시작과 완료가 분명한 흐름을 선택하고 오류·빈 상태·로딩 상태를 포함합니다. 둘째, 마우스를 치우고 키보드로 여정을 완료합니다. 셋째, 각 핵심 화면의 전체 접근성 트리에서 랜드마크, 제목, 컨트롤의 이름·역할·상태·순서를 확인합니다.

1. 기준 화면을 엽니다. 반응형 너비와 확대 조건을 함께 기록합니다.
2. 전체 트리로 전환합니다. 의미 없는 중복, 누락된 컨트롤, 예상과 다른 이름을 찾습니다.
3. 상태를 변화시킵니다. 메뉴 펼침, 검증 오류, 로딩 완료 전후를 비교합니다.
4. 키보드와 스크린 리더로 확인합니다. 트리 구조가 좋아 보여도 실제 읽기와 조작이 자연스러운지 검증합니다.
5. 결함을 사용자 영향으로 기록합니다. ‘ARIA 오류’ 대신 ‘오류 이유를 알 수 없어 신청을 완료하지 못함’처럼 씁니다.

자동화는 회귀 방지에 유용하지만 대표 여정 검토를 대체하지 않습니다. Lighthouse는 넓은 첫 점검으로 사용하고, 트리 검사와 실제 보조기술 테스트를 이어 붙이는 것이 현실적입니다.

디자인 시스템 컴포넌트의 계약을 바꿔라

디자인 시스템 문서가 색상·간격·변형만 설명한다면 구현팀마다 접근성 의미가 달라집니다. 이제 각 컴포넌트의 ‘접근성 계약’을 함께 적어야 합니다.

• 버튼은 보이는 레이블과 접근 가능한 이름의 관계를 정의합니다.
• 입력은 레이블, 도움말, 필수 여부, 오류 메시지 연결을 명시합니다.
• 팝오버와 모달은 열기·닫기·Escape·초기 포커스·복귀 포커스를 정의합니다.
• 탭과 메뉴는 키보드 패턴과 선택·확장 상태를 정의합니다.
• 비동기 알림은 언제 어떤 우선순위로 전달할지 정합니다.

Figma 컴포넌트 설명에는 이 계약을 짧게 넣고, Storybook이나 코드 문서에는 예상 접근성 트리와 키보드 동작을 예제로 남길 수 있습니다. QA 티켓에는 화면 캡처만 첨부하지 말고 문제 상태의 접근성 속성과 재현 순서를 함께 적는 편이 좋습니다.

한국어 서비스에서 특히 확인할 항목

한국어 버튼은 ‘확인’, ‘보기’, ‘더보기’처럼 문맥 의존적인 짧은 표현이 많습니다. 카드가 여러 개 반복될 때 접근성 트리에는 모두 같은 이름으로 나타날 수 있습니다. 시각적 문맥을 볼 수 없는 사용자를 위해 ‘요금제 상세 보기’, ‘주문 내역 더보기’처럼 목적을 구분하되, 보이는 문구와 접근 가능한 이름이 지나치게 어긋나지 않게 설계해야 합니다.

주소 검색, 본인 인증, 결제처럼 외부 모듈이 끼는 흐름도 중요합니다. 팀 코드의 컴포넌트만 검사하면 전체 여정의 포커스 손실이나 iframe 제목 누락을 놓칠 수 있습니다. 완전한 업무 흐름 단위로 공급자 화면과 복귀 지점까지 확인해야 합니다.

• [ ] 반복 아이콘 버튼의 이름이 항목별로 구분된다.
• [ ] 입력 오류의 원인과 수정 방법이 텍스트로 연결된다.
• [ ] 모달과 외부 인증 전후에 포커스가 유지된다.
• [ ] 한국어·영문 혼합 콘텐츠의 문서 언어와 부분 언어가 적절하다.
• [ ] 동적 결과 건수와 완료 알림이 필요한 때 전달된다.

릴리스 게이트로 운영하는 방법

POEMORA는 접근성 트리 점검을 디자인 리뷰, 컴포넌트 개발, 기능 QA 세 단계에 배치할 것을 권합니다. 디자인 리뷰에서는 이름과 상태를 주석으로 정의하고, 개발 단계에서는 단위 테스트와 키보드 테스트를 만들며, 기능 QA에서는 대표 여정을 실제 브라우저와 스크린 리더로 완료합니다.

웹사이트 개편 과정에서 이 기준을 컴포넌트와 테스트에 함께 반영하려면 POEMORA 웹 서비스를 참고할 수 있습니다. 목표는 검사 도구의 점수를 높이는 데 있지 않습니다. 사용자가 정보를 이해하고 조작을 완료하며 오류에서 회복할 수 있다는 증거를 남기는 데 있습니다.

도구 변화가 남기는 실무 결론

Chrome 148의 기본값 변경은 접근성 트리를 전문 도구의 숨은 기능이 아니라 일상적인 프런트엔드 디버깅 화면으로 끌어옵니다. 팀은 이를 계기로 ‘픽셀 일치’만 통과하는 QA에서 벗어날 수 있습니다.

다만 트리는 모델이고 사용자는 사람이므로, 트리가 예상대로 보인다는 사실만으로 사용성이 입증되지는 않습니다. 전체 트리 검사, 키보드 이동, 스크린 리더 청취, 실제 사용자 피드백을 층으로 쌓아야 합니다. 가장 좋은 변화는 새 도구를 켜는 것이 아니라 각 컴포넌트와 사용자 여정에 접근성 책임자를 지정하는 것입니다.