H1 하나면 충분할까? 제목 구조를 DOM으로 점검하는 방법

웹페이지를 제작할 때 디자이너와 퍼블리셔 사이에 가장 많은 논쟁이 오가는 영역 중 하나가 바로 제목 태그(<h1>~<h6>)의 계층 구조입니다. 과거 2000년대 초반의 낡은 SEO 지침인 'H1 태그는 한 페이지에 반드시 단 하나만 존재해야 하며, H1이 2개 이상이면 검색 엔진에서 불이익을 받는다'는 잘못된 미신이 여전히 많은 현업 실무자들을 얽매고 있습니다. 그러나 최신 구글 검색 알고리즘과 W3C WCAG 2.2 웹 접근성 표준의 핵심은 H1의 물리적 개수가 아니라, 전체 문서가 논리적이고 예측 가능한 계층 트리(Hierarchical Outline Tree)를 형성하고 있는가에 있습니다. 특히 시각장애인이 웹페이지를 처음 열었을 때 가장 먼저 취하는 행동이 스크린리더의 '제목 탐색 단축키(H 키)'를 눌러 문서 전체의 목차를 파악하는 것임을 감안하면, 제목 구조의 설계는 웹 접근성의 주춧돌과 같습니다. 이 글에서는 DOM 접근성 트리 관점에서 올바른 제목 구조를 검증하고 설계하는 기준을 심층적으로 다룹니다.

스크린리더 사용자의 실제 웹페이지 탐색 행동 패턴

시력이 정상인 사용자는 웹사이트에 접속했을 때 화면 전체를 눈으로 훑으며(Scanning) 큰 글씨와 굵은 텍스트를 통해 어디에 어떤 정보가 있는지 수초 만에 인지합니다. 반면 화면 전체를 한눈에 볼 수 없는 시각장애인은 웹페이지를 선형적(Linear)으로 탐색해야 합니다.

이때 웹페이지 상단부터 본문 끝까지 모든 문장을 처음부터 끝까지 듣는 것은 엄청난 시간 낭비입니다. 따라서 대다수의 스크린리더(NVDA, VoiceOver 등) 사용자는 책의 목차를 훑어보듯이 '헤딩 이동 단축키(H 키)'나 숫자 키(1~6)를 연속으로 눌러 제목만 빠르게 건너뛰며 듣는 탐색 전략을 취합니다. 제목을 듣다가 자신이 원하는 섹션(예: '배송지 정보 입력')에 도달했을 때 비로소 아래 방향키를 눌러 본문 세부 내용을 읽기 시작합니다. 따라서 제목 태그의 누락이나 왜곡은 시각장애인에게서 '책의 목차 페이지를 통째로 찢어버린 것'과 같은 막대한 피해를 줍니다.

헤딩 레벨 건너뜀(Heading Level Skipping)이 초래하는 혼란

실무 마크업에서 가장 빈번하게 발생하는 오류는 '헤딩 레벨 건너뜀(Skipping Levels)'입니다. 메인 타이틀로 <h1>을 선언한 뒤, 그 하위 섹션으로 <h2>를 거치지 않고 곧바로 <h3>이나 <h4>를 사용하는 현상입니다.

퍼블리셔가 브라우저의 기본 CSS 폰트 크기(User Agent Stylesheet)에 의존하여, 'H2는 글씨가 너무 크니까 적당한 크기인 H3 태그를 쓰자'라고 시각적 스타일링을 목적으로 태그를 선택할 때 발생합니다.

스크린리더가 <h1>을 읽은 직후 곧바로 '3레벨 제목'을 낭독하면, 시각장애인 사용자는 '내가 탐색 과정에서 2레벨 상위 대분류 섹션을 실수로 놓쳤는가?' 혹은 '웹페이지의 중요한 정보 영역이 누락되었는가?'라는 심각한 방향 감각 상실(Disorientation)에 빠지게 됩니다. 제목 레벨은 반드시 h1 ➔ h2 ➔ h3 순으로 한 단계씩 순차적으로 내려가야 하며, 필요에 의해 상위 레벨로 복귀할 때만 여러 단계를 건너뛸 수 있습니다.

시각적 스타일(CSS font-size)과 문서 의미(HTML Semantic)의 완전한 분리

접근성 높은 마크업을 작성하기 위한 황금률은 '시각적 외형은 CSS에 전적으로 위임하고, HTML 태그는 오직 문서 구조의 계층적 의미만을 담당한다'는 원칙을 실천하는 것입니다.

예를 들어 메인 프로모션 배너의 제목이 디자인상 48px의 거대한 폰트 크기를 가지고 있더라도, 문서 구조상 전체 서비스 페이지의 부제목이라면 <h2>가 되어야 합니다. 반대로 사이드바 위젯의 제목이 14px의 작은 글씨이더라도 독립된 메인 콘텐츠 블록의 시작점이라면 <h2>가 될 수 있습니다.

부트스트랩(Bootstrap)이나 테일윈드(Tailwind CSS) 같은 모던 CSS 프레임워크가 .h1, .h2, .text-xl, .text-sm 같은 시각 전용 유틸리티 클래스를 제공하는 이유가 바로 여기에 있습니다. <h2 class='text-sm font-bold'>처럼 마크업의 시맨틱 계층과 시각적 스타일을 완벽히 분리하여 코딩해야만 디자이너의 의도와 웹 표준을 동시에 만족할 수 있습니다.

Chrome 개발자 도구를 활용한 3단계 헤딩 구조 검증 루틴

실무 배포 전 제목 구조의 무결성을 검증하기 위해 다음 3단계 점검 절차를 거치는 것을 권장합니다.

1단계는 '빈 제목 요소 제거'입니다. <h2></h2>처럼 텍스트 내용 없이 비어 있거나 배경 이미지만 들어간 헤딩 태그가 있는지 점검합니다. 스크린리더가 '2레벨 제목, 빈 줄'이라고 낭독하는 것은 전형적인 접근성 결함입니다.

2단계는 'Chrome DevTools Accessibility 트리의 Heading Outline 확인'입니다. 개발자 도구의 Elements 패널 우측 Accessibility 탭을 열면 브라우저가 해석한 전체 제목 개요 트리가 표시됩니다. 여기서 레벨 건너뜀(Skipped Level) 경고가 발생하는지 확인합니다.

3단계는 'role="heading"과 aria-level의 올바른 활용'입니다. 부득이하게 컴포넌트 프레임워크 제약으로 네이티브 <h> 태그를 쓸 수 없는 커스텀 UI의 경우, <div role='heading' aria-level='3'>을 선언하여 보조공학에 명확한 계층 정보를 주입해야 합니다.

HTML5 아웃라인 알고리즘 폐기와 브라우저 접근성 트리의 레벨 계산

과거 HTML5 명세 초안에는 section이나 article 태그로 본문을 감싸면 h1 태그만 반복해서 사용해도 브라우저가 문서 중첩도에 따라 자동으로 아웃라인을 계산해 줄 것이라는 HTML5 Document Outline Algorithm이 포함되어 있었습니다.

그러나 Chromium, WebKit, Gecko를 비롯한 주요 브라우저 엔진은 성능과 호환성 문제로 인해 이 알고리즘을 단 한 번도 상용 엔진에 공식 구현하지 않았습니다. 결과적으로 W3C 및 WHATWG는 HTML 표준에서 문서 아웃라인 알고리즘을 공식 폐기했습니다.

현재 모든 주요 브라우저의 접근성 트리는 개발자가 DOM에 직접 선언한 <h1>부터 <h6>까지의 정적 태그 이름이나 명시적인 aria-level 속성만을 기반으로 헤딩 레벨을 직렬화합니다. 따라서 section 안에 h1만 반복하면 스크린리더 사용자는 문서 전체에 1단계 헤딩이 수십 개 나열된 것으로 인지하게 됩니다.

• W3C 표준 폐기: HTML5 Document Outline Algorithm 공식 폐기, 브라우저 자동 레벨 계산 미지원
• 접근성 트리 직렬화: h1~h6 태그 이름 또는 role="heading"과 aria-level="N" 명시적 선언만을 신뢰
• 단일 H1 원칙: 페이지 전체의 주제를 대표하는 H1은 단 하나만 배치하고, 하위 섹션은 H2, H3로 순차적 위계 형성

컴포넌트 기반 아키텍처(React)에서의 동적 Heading Level 주입 패턴

현대 웹 개발에서는 모듈화된 UI 컴포넌트가 사이드바, 메인 본문, 모달 팝업 등 서로 다른 컨텍스트에서 재사용됩니다. 이때 컴포넌트 내부에 <h3> 태그를 하드코딩하면 상위 래퍼의 계층에 따라 레벨 건너뜀(Heading Skip) 결함이 발생합니다.

이를 해결하기 위해 React의 Context API를 활용한 계층적 헤딩 시스템을 도입할 수 있습니다. 상위 섹션이 중첩될 때마다 자식 Heading 컴포넌트가 자동으로 h2, h3, h4로 순차 승격되므로 DOM 구조의 무결성과 접근성 규격을 완벽히 유지할 수 있습니다.

• HeadingLevelContext: React Context를 통해 부모 섹션 깊이에 따라 자동으로 level을 +1씩 동적 주입
• 최대 레벨 가드: Math.min(level, 6) 처리를 통해 HTML 표준 유효 범위(h1~h6) 초과 방지
• 린트 및 자동 검사: ESLint jsx-a11y/heading-has-content 및 axe-core heading-order 규칙 통합