Velog
<h1> 요소의 기본 스타일이 변경됩니다
브라우저는 더 이상 <section> > <h1> 을 자동으로 <h2> 처럼 보이게 만들지 않는다. 모든 `<h1>` 은 동일한 큰 글씨로 통일되며, Lighthouse 도 명시적 font-size 가 없으면 경고한다.
핵심 요약
변경 핵심:
/* 이전 UA 기본값 (제거됨) */
section h1 { font-size: 1.5em; }
section section h1 { font-size: 1.17em; }
/* 등등 깊이별 자동 축소 */
이제 모든 <h1> 은 같은 크기(2em)로 통일된다. 결과:
| 적용 시점 | Chrome | Safari | Firefox |
|---|---|---|---|
| 제거 시작 | 신규 버전 | 신규 버전 | 진행 중 |
대응 액션 두 가지:
- 명시적 스타일 추가 —
<h1>에 직접font-size/margin을 정의 - 마크업 점검 —
<section> > <h1>패턴을 진짜 H1 으로 의도했는지 확인. 실제로는<h2>/<h3>가 맞는 경우가 대부분
h1 { font-size: 2rem; margin-block: 0.67em; }
section h1, article h1, aside h1, nav h1 {
/* 의도적으로 H1 시각 크기를 줄이려면 명시 */
}
HTML 의 "의미" 와 CSS 의 "보임" 을 분리하라 는 원칙이 한 발 더 나아간 것. 과거 UA 스타일은 섹셔닝 요소 깊이 에 따라 <h1> 시각 크기를 자동 변경했지만 접근성 트리에는 반영되지 않아 스크린 리더와 시각이 불일치했다. 이제 그 "마법" 이 사라지고, 시각 크기는 개발자가 명시 해야 한다.
이 변화는 단순한 스타일 패치가 아니라 "올바른 헤딩 구조" 가 강제되는 신호다. 영향 범위는 다음과 같다.
- 시각 회귀:
<section> > <h1>이 모두 거대한 H1 크기로 보이는 페이지가 무너짐 - Lighthouse 경고:
H1UserAgentFontSizeInSection— 명시적font-size없으면 점수 하락 - SEO/접근성: 한 페이지에 여러 H1 이 있는 구조가 더 일찍 드러남
면접에서 "왜 페이지에 H1 은 보통 1개여야 하나요" 같은 질문에 "SEO 때문" 만 답하면 부족하고, 접근성 트리와 UA 스타일의 분리 까지 짚어야 한다.
학습 포인트
면접 답변으로 연결할 학습 포인트입니다.
Outline algorithm 의 사망 → UA 마법의 종료
한때 HTML 표준은 outline algorithm 으로 <h1> 의 "논리적 레벨" 을 섹셔닝 깊이에서 추론하려 했다. UA 스타일이 이를 따랐지만 접근성 트리는 이를 무시 — "보이는 레벨" 과 "읽히는 레벨" 이 달랐다. 알고리즘은 2022년에 HTML 사양에서 제거됐고, 이제 UA 스타일도 따라간다. 정리:
- 시각 자동 축소 → 사라짐
- 접근성 트리 → 처음부터 그대로(작가가 명시한 H1~H6 그대로 읽음)
<section> > <h1> 가 "자동으로 H2" 라고 알고 있는 것. 시각만 그랬을 뿐 스크린 리더에는 항상 H1 이었다.
Lighthouse 경고와 회귀의 정체
Lighthouse 는 <section>/<article>/<nav>/<aside> 안에 든 <h1> 에 명시 font-size 가 없으면 경고한다(H1UserAgentFontSizeInSection). 이건 "폰트 크기를 정해라" 라는 단순 규칙이 아니라, 마크업이 의도와 일치하는가 를 묻는 신호다.
<!-- 의도가 "이건 진짜 H1" 이라면 명시 -->
<section><h1 style="font-size:2rem">Title</h1></section>
<!-- 의도가 "섹션 헤딩" 이라면 H2 로 고침 -->
<section><h2>Section heading</h2></section>
경고를 끄려고 font-size 만 박는 것. 마크업 의도 가 잘못된 케이스가 더 많다.
리셋 CSS / 디자인 시스템 측 영향
Tailwind preflight, modern-css-reset, Bootstrap reboot 등은 이미 h1{ font-size: 2.25rem } 식으로 명시해서 영향이 없다. 영향받는 곳은:
- 자체 작성한 "가벼운 reset"
- 디자인 시스템에서
h1만 정의하고 섹션 안 H1 은 별도로 처리하지 않은 경우 - 빌드된 사이트에 브라우저 기본값 을 의존했던 마크다운 렌더러
점검 우선순위: 디자인 시스템 토큰 → 마크다운 콘텐츠 → 레거시 페이지.
"우린 Tailwind 쓰니 무관" 으로 점검 생략. 실제로는 블로그/문서 페이지의 마크다운 출력 이 자주 깨진다.
읽는 순서
- 1이론
outline algorithm 이 무엇이고 왜 제거됐는지, 접근성 트리와 UA 스타일이 어떤 책임 분리를 갖는지 정리한다.
- 2구현
로컬 페이지에
<body><h1> ... <section><h1></section></body>마크업을 두고, 브라우저 별 기본 크기 차이를 확인한다. 그 후 디자인 토큰으로h1명시 스타일을 추가해 일관화한다. - 3실무
프로젝트의 마크다운 렌더러/디자인 시스템에서
<section>안에 들어가는<h1>을 grep 으로 찾아본다. 의미상 H2~H6 이 맞다면 마크업을 수정. - 4설명
동료에게 "한 페이지 H1 여러 개의 트레이드오프" 를 5분 안에 설명. SEO 만이 아니라 접근성 트리/스크린 리더 관점까지 다룬다.
면접 연결 질문
[감점 답변] "브라우저가 그냥 통일했다". [좋은 답변] outline algorithm 이라는 "섹셔닝 깊이로 헤딩 레벨을 자동 추론" 하던 사양이 있었지만, 접근성 트리에 반영되지 않아 시각/낭독 불일치 가 발생했다. 알고리즘은 2022년 HTML 표준에서 제거되었고 이제 UA 스타일도 일치시킨다. 결과적으로 시맨틱은 작가가 명시 한 헤딩 레벨이 그대로 사용된다.
[감점 답변] "font-size 만 박으면 됨". [좋은 답변] 먼저 마크업 의도부터 확인한다. 그 헤딩이 페이지의 진짜 H1 이면 font-size 명시가 맞고, 단순 섹션 제목 이라면 <h2>/<h3> 가 의미상 정답이다. "경고를 끄는 법" 이 아니라 마크업 의도 점검 트리거 로 보는 게 핵심.
[감점 답변] "SEO 때문에 1개여야 함". [좋은 답변] HTML5 자체는 여러 개 허용하지만, 접근성 트리에 모두 H1 으로 노출 되어 사용자가 페이지 구조를 파악하기 어렵다. 또한 검색 엔진은 보통 첫 H1 위주로 가중치를 둔다. 권장 패턴은 페이지당 H1 1개 + 섹션은 H2~H6. 단, 문서 영역마다 독립 H1 을 두는 디자인이 필요하다면 ARIA aria-level 로 보정할 수 있다.
자기 점검
이전에는 <section> > <h1> 이 접근성 트리에서도 H2 로 노출됐다는 오해. 사실 트리는 항상 H1 이었다.
"리셋 CSS 쓰니까 자동으로 안전" 이라는 가정. 자체 reset 이나 마크다운 출력 페이지는 그대로 영향을 받는다.