WCAG 성공 기준 · Level A
WCAG 2.4.2: 페이지 제목 제공
WCAG 2.4.2는 모든 웹 페이지가 그 주제나 목적을 식별할 수 있는 설명적이고 의미 있는 제목을 갖도록 요구합니다. 이는 특히 스크린 리더에 의존하거나 여러 개의 탭을 관리하는 사용자들이 빠르게 방향을 파악하고 효율적으로 탐색할 수 있도록 보장합니다.
- Level A
- Wcag
- Wcag 2 2 a
- 작동 가능한
- 접근성
이 규칙의 의미
WCAG 2.4.2 Page Titled는 Operable 원칙 아래의 레벨 A 성공 기준이다. 이 기준은 다음과 같이 규정한다: "웹 페이지는 주제나 목적을 설명하는 제목을 가진다." 실질적으로 이는 사용자에게 제공되는 모든 HTML 문서가 <head> 섹션 안에 <title> 요소를 포함해야 하며, 그 요소 안에는 페이지의 콘텐츠, 기능 또는 사이트 내 맥락을 의미 있게 식별하는 텍스트가 들어 있어야 한다는 뜻이다.
이 기준은 모든 개별 웹 페이지에 적용된다. 정적 HTML 파일이든, 동적으로 렌더링되는 싱글 페이지 애플리케이션(SPA)의 뷰이든, 모달 페이지이든, 다단계 마법사(wizard)의 한 단계이든 상관없다. 사용자가 직접 탐색할 수 있거나 현재 보기를 대체하는 각 개별적인 "화면"은 고유하고 설명적인 제목을 가져야 한다.
페이지는 <title> 요소가 존재하고 비어 있지 않으며, 페이지의 주제나 목적을 적절히 설명하는 텍스트를 포함할 때 이 기준을 충족한다. 제목이 전 세계 인터넷 전체에서 유일할 필요는 없지만, 제목만 듣거나 읽었을 때 추가적인 맥락 없이도 페이지가 무엇에 관한 것인지 사용자가 이해할 수 있을 정도로 구체적이어야 한다.
다음 조건 중 하나라도 참이면 페이지는 이 기준을 충족하지 못한다. <head>에 <title> 요소가 전혀 없는 경우, <title> 요소는 있지만 비어 있는 경우(텍스트가 전혀 없는 경우), 제목이 "Untitled Document", "New Page"와 같은 일반적인 플레이스홀더 텍스트만 포함하거나 설명적인 내용 없이 순수 도메인 이름만 포함하는 경우, 또는 싱글 페이지 애플리케이션이 새로운 논리적 뷰로 이동하면서 문서 제목을 동적으로 업데이트하지 않는 경우이다.
WCAG는 이 기준에 대해 레벨 A에서 명시적인 예외를 정의하지 않는다. 크기, 대상, 목적과 관계없이 모든 웹 페이지는 설명적인 제목을 가져야 한다. 다만 Understanding 문서는 제목이 유일한 식별 수단일 필요는 없다고 명시한다. 제목은 단지 존재해야 하며, 기본적인 방향 감각을 제공할 만큼 충분히 설명적이면 된다.
왜 중요한가
페이지 제목은 사용자가 웹 페이지에 도착하거나 페이지 간을 이동할 때 접하는 가장 첫 번째 정보 중 하나이다. 제목이 없거나 부적절하면 여러 유형의 사용자에게 장벽을 만든다.
스크린 리더 사용자 — 대부분은 시각장애가 있거나 심각한 저시력을 가진 사람들 — 는 페이지가 로드되거나 포커스가 새 문서로 이동할 때 페이지 제목이 즉시 낭독되는 것을 듣는다. 세계보건기구(WHO)에 따르면 전 세계 약 22억 명이 어떤 형태로든 시각 장애를 가지고 있으며, 이들에게 이 알림은 올바른 페이지가 로드되었는지 확인하고, 더 탐색하기 전에 페이지에 무엇이 있는지 이해하는 주요 수단이다. 의미 있는 제목이 없으면, 탭 사이를 이동하거나 잠시 후 페이지로 돌아오는 시각장애 사용자는 다시 방향을 잡기 위해 전체 페이지 내용을 읽어야 한다. 복잡한 레이아웃에서는 이 작업에 몇 분이 걸릴 수 있다.
인지 및 학습 장애가 있는 사용자는 명확하고 일관된 페이지 제목으로부터 큰 도움을 받는다. 기억에 어려움이 있는 사용자가 조사 과정에서 여러 탭을 열어 두는 경우, 탭 제목은 각 탭을 구분하는 유일한 시각적 레이블인 경우가 많다. "Account Settings — Accsible Dashboard"와 같은 제목은 올바른 탭을 즉시 식별할 수 있게 해 주지만, "Page"와 같은 제목이나 비어 있는 제목은 각 탭을 클릭해 내용을 확인해야 하므로 인지적 부담과 혼란을 초래한다.
운동 장애가 있는 사용자 중 Dragon NaturallySpeaking과 같은 음성 제어 소프트웨어에 의존하는 사람들은 페이지 제목을 사용해 탐색 명령을 내린 후 의도한 목적지에 도달했는지 확인할 수 있다. 명확한 제목은 반복적인 수정과 재탐색의 필요성을 줄여 시간과 신체적 노력을 절약해 준다.
구체적인 사례를 생각해 보자. 터키의 한 병원 환자가 보조 스크린 리더를 사용해 여러 단계에 걸친 온라인 진료 예약 양식을 작성하고 있다. 각 단계가 현재 단계를 반영하도록 페이지 제목을 업데이트하지 않는다면 — 예를 들어 "Step 2 of 4: Personal Information — Appointment Booking — Hospital Name"와 같이 — 환자는 페이지가 다시 로드되거나 다른 브라우저 창을 확인하기 위해 탭을 전환한 후 자신의 진행 상황을 빠르게 확인할 방법이 없다. 어디에 있는지 이해하기 위해 매번 전체 양식을 다시 읽어야 하며, 이는 이미 아프거나 스트레스를 받고 있을 수 있는 사람에게 특히 부담이 된다.
접근성을 넘어, 페이지 제목은 상당한 SEO 가치를 가진다. 검색 엔진은 검색 결과 목록의 기본 레이블로 <title> 요소를 사용한다. 설명적이고 키워드가 잘 포함된 제목은 클릭률과 검색 노출을 향상시킨다. WCAG 2.4.2를 올바르게 구현하는 웹사이트는 장애가 있는 사용자뿐 아니라 전체 유기적 검색 성과에도 이점을 제공하므로, 접근성은 동시에 비즈니스와 기술 측면에서의 이득이 된다.
관련 Axe-core 규칙
- document-title: 이것은 WCAG 2.4.2와 연관된 기본 axe-core 규칙이다. 현재 HTML 문서가
<head>안에<title>요소를 포함하는지, 그리고 그 요소가 공백이 아닌 텍스트 콘텐츠를 최소한 일부라도 포함하는지 확인한다.<title>요소가 완전히 없거나, 존재하지만 비어 있거나, 공백 문자만 포함하는 경우 이 규칙은 위반으로 표시한다. Axe-core는 이를 WCAG 2.4.2 레벨 A에 매핑된 심각한(critical) 위반으로 보고한다. 이 규칙은 페이지 로드 시 자동으로 실행되며 구조적 누락을 안정적으로 잡아낸다. - 수동 테스트도 필요한 이유: axe-core와 같은 자동화 도구는
<title>요소가 존재하고 비어 있지 않다는 사실은 확인할 수 있지만, 제목이 의미 있는지 또는 설명적인지는 평가할 수 없다.<title>aaa</title>나<title>Untitled Document</title>와 같은 페이지는 요소가 존재하고 비어 있지 않기 때문에 자동 규칙을 통과하지만, WCAG 2.4.2의 취지에는 명백히 어긋난다. 제목이 페이지의 주제와 목적을 정확히 반영하는지 평가하려면 사람의 검토가 필요하다. 마찬가지로 싱글 페이지 애플리케이션에서는 자동 스캔이 일반적으로 초기 페이지 로드 시의 제목만 포착하고, 클라이언트 측 라우트 변경 시 제목이 업데이트되지 않는 경우를 놓칠 수 있다. 이러한 전환은 수동 탐색 테스트가 필요하다.
테스트 방법
- axe DevTools 또는 Lighthouse를 사용한 자동 스캔: Chrome 또는 Firefox에서 대상 웹 페이지를 연다. DevTools(F12)를 열고 axe DevTools 패널(설치된 경우) 또는 Lighthouse 탭으로 이동한다. 접근성 감사를 실행한다. axe 결과에서 "Critical" 또는 "Serious" 범주 아래의
document-title규칙 위반 여부를 특히 확인한다. Lighthouse 역시 접근성 감사에서 누락되었거나 비어 있는 제목을 표시한다. 보고서를 위해 정확한 페이지 URL과 제목 텍스트(또는 그 부재)를 기록한다. 오류 페이지(404, 500)와 확인 페이지를 포함해 애플리케이션의 모든 고유한 라우트나 뷰에 대해 이 테스트를 반복한다. - 수동 브라우저 검사: 어떤 브라우저에서든 브라우저 탭 레이블을 확인한다. 페이지를 식별하는 의미 있고 설명적인 제목이 표시되어야 한다. 페이지를 마우스 오른쪽 버튼으로 클릭해 "페이지 소스 보기"를 선택하거나 DevTools를 열고 Elements 패널로 이동한다.
<head>섹션을 찾아<title>요소가 존재하며 일반적인 텍스트가 아닌 적절한 텍스트 콘텐츠를 가지고 있는지 확인한다. 제목이 현재 보이는 페이지 콘텐츠와 관련이 있는지, 그리고 다중 페이지 사이트의 경우 페이지의 고유한 목적을 반영하는 방식으로 다른 페이지의 제목과 구분되는지 확인한다. - NVDA + Firefox를 사용한 스크린 리더 테스트: Firefox에서 페이지를 열고 NVDA를 활성화한다. 페이지가 로드되면 NVDA는 페이지 제목을 즉시 읽어야 한다. Alt+왼쪽 화살표, Alt+오른쪽 화살표를 사용해 페이지를 떠났다가 다시 돌아와 올바른 제목이 다시 읽히는지 확인한다. 싱글 페이지 애플리케이션에서는 클라이언트 측 라우트 변경을 트리거하고 업데이트된 제목이 낭독되는지 듣는다. NVDA가 아무것도 읽지 않거나 페이지 로드 시 일반적이거나 도움이 되지 않는 문자열을 읽는다면 이는 실패이다.
- VoiceOver + Safari(macOS/iOS)를 사용한 스크린 리더 테스트: VoiceOver를 활성화한다(Mac에서는 Command+F5). 페이지를 로드한다. VoiceOver는 로드 시 페이지 제목을 읽는다. Rotor(Control+Option+U)를 사용해 Web Spots 또는 Headings 목록으로 이동한다. 페이지 상단에 표시되는 창 제목이
<title>요소의 내용과 일치해야 한다. iOS에서는 Safari 탭 전환기에서 제목이 표시되므로, 이 제목이 설명적인지 확인한다. - JAWS + Chrome을 사용한 스크린 리더 테스트: JAWS를 실행한 상태에서 Chrome에서 페이지를 연다. JAWS는 로드 시 페이지 제목을 읽는다. Insert+F1을 눌러 JAWS 도움말 창을 열고 보고된 페이지 제목을 확인한다. 세션 중 언제든 Insert+T를 눌러 제목을 읽어 SPA 탐색 이벤트 이후 제목이 올바르게 업데이트되었는지 확인한다.
- 싱글 페이지 애플리케이션(SPA) 라우트 변경 테스트: SPA의 서로 다른 뷰(예: 홈 페이지에서 상품 페이지, 결제 페이지로)를 탐색한다. 각 탐색 후 브라우저 탭 레이블을 확인하고 스크린 리더를 사용해 제목이 업데이트되었는지 검증한다. 현재 뷰와 관계없이 세션 내내 탭 레이블이 동일하게 유지된다면, 고유한 제목이 없는 모든 뷰에 대해 이는 2.4.2 실패이다.
수정 방법
제목 요소 누락 — 잘못된 예
<!DOCTYPE html>
<html lang='tr'>
<head>
<meta charset='UTF-8'>
<meta name='viewport' content='width=device-width, initial-scale=1.0'>
<!-- No <title> element present -->
</head>
<body>
<h1>Ürünlerimiz</h1>
</body>
</html>
제목 요소 누락 — 올바른 예
<!DOCTYPE html>
<html lang='tr'>
<head>
<meta charset='UTF-8'>
<meta name='viewport' content='width=device-width, initial-scale=1.0'>
<!-- Title added: describes the page topic and includes the site name for context -->
<title>Ürünlerimiz — Accsible Mağaza</title>
</head>
<body>
<h1>Ürünlerimiz</h1>
</body>
</html>
일반적인 플레이스홀더 제목 — 잘못된 예
<!DOCTYPE html>
<html lang='en'>
<head>
<meta charset='UTF-8'>
<!-- Generic title provides no useful context to the user -->
<title>Untitled Document</title>
</head>
<body>
<h1>Contact Us</h1>
</body>
</html>
일반적인 플레이스홀더 제목 — 올바른 예
<!DOCTYPE html>
<html lang='en'>
<head>
<meta charset='UTF-8'>
<!-- Descriptive title: page function first, then site name -->
<title>Contact Us — Accsible Support</title>
</head>
<body>
<h1>Contact Us</h1>
</body>
</html>
라우트 변경 시 제목을 업데이트하지 않는 싱글 페이지 애플리케이션 — 잘못된 예
<!-- React Router example: title is set only once at app root and never updated -->
<!DOCTYPE html>
<html lang='en'>
<head>
<title>My App</title>
</head>
<body>
<div id='root'></div>
<!-- JavaScript bundle loads React SPA; title never changes during navigation -->
</body>
</html>
라우트 변경 시 제목을 업데이트하지 않는 싱글 페이지 애플리케이션 — 올바른 예
<!-- Use document.title in each route component or a head-management library -->
<!-- Example using React with react-helmet-async -->
<!-- In your ProductPage component: -->
<!-- import { Helmet } from 'react-helmet-async'; -->
<!-- <Helmet><title>{product.name} — Accsible Store</title></Helmet> -->
<!-- Or using plain JavaScript on each route render: -->
<script>
// Called whenever the SPA navigates to a new view
function updatePageTitle(pageTitle, siteName) {
document.title = pageTitle + ' — ' + siteName;
}
// Example: updatePageTitle('Shopping Cart', 'Accsible Store');
// Results in: <title>Shopping Cart — Accsible Store</title>
</script>
각 단계의 제목이 동일한 다단계 폼 — 잘못된 예
<!-- Step 1 -->
<title>Checkout — Accsible Store</title>
<!-- Step 2 (same title — user cannot distinguish steps) -->
<title>Checkout — Accsible Store</title>
<!-- Step 3 (same title again) -->
<title>Checkout — Accsible Store</title>
각 단계의 제목이 동일한 다단계 폼 — 올바른 예
<!-- Step 1: title reflects the current step's purpose -->
<title>Step 1 of 3: Shipping Address — Checkout — Accsible Store</title>
<!-- Step 2: clearly distinct and descriptive -->
<title>Step 2 of 3: Payment Details — Checkout — Accsible Store</title>
<!-- Step 3: confirmation step identified clearly -->
<title>Step 3 of 3: Order Review — Checkout — Accsible Store</title>
자주 발생하는 실수
- CMS나 프레임워크의 기본 제목을 운영 환경에 그대로 두는 경우: 많은 콘텐츠 관리 시스템(WordPress, Drupal, 커스텀 프레임워크)은 "Just another WordPress site"나 사이트 URL과 같은 플레이스홀더 제목을 기본으로 제공한다. 개발자가 출시 전에 제목 템플릿을 설정하는 것을 잊어 모든 페이지가 도움이 되지 않거나 동일한 제목을 갖게 되는 경우가 있다. 항상 CMS 설정에서 제목 구성을 확인하고, 출시 전에 실제 URL을 테스트하라.
- 모든 페이지에 사이트 이름만 제목으로 사용하는 경우: 사이트의 모든 페이지에
<title>Accsible</title>을 설정하면document-title자동 검사(요소가 비어 있지 않음)는 통과하지만, WCAG 2.4.2의 설명적이어야 한다는 요구사항은 충족하지 못한다. 각 페이지는 같은 사이트의 다른 페이지와 구분되는 제목을 가져야 한다. - 페이지별 콘텐츠보다 사이트 이름을 먼저 두는 경우:
<title>Accsible — Contact</title>패턴은 스크린 리더 사용자가 페이지가 무엇에 관한 것인지 알기 전에 브랜드 이름을 먼저 들어야 하게 만든다. 권장 패턴은<title>Contact — Accsible</title>처럼 페이지 주제를 먼저, 사이트 이름을 나중에 두는 것이다. 이렇게 하면 사용자가 가장 관련 있는 정보를 즉시 얻을 수 있다. - 클라이언트 측 탐색 후 싱글 페이지 애플리케이션에서
document.title을 업데이트하지 않는 경우: React, Vue, Angular와 같은 프레임워크는 라우트가 변경될 때 문서 제목을 자동으로 업데이트하지 않는다. 개발자는 각 라우트 컴포넌트에서document.title을 명시적으로 설정하거나(head-management 라이브러리(react-helmet-async, Vue Meta 등)를 사용해야 한다. 이를 하지 않으면 초기 로드 이후의 모든 SPA 뷰가 동일한 제목을 공유하게 된다. - 비어 있거나 공백만 있는 제목 요소를 사용하는 경우: 공백이나 줄바꿈만 포함하는
<title> </title>요소는 보조 기술 사용자에게는 제목이 없는 것과 사실상 동일하지만, 브라우저 탭이 오류를 표시하지 않고 단순히 비어 보이기 때문에 시각적 QA에서 간과될 수 있다. Axe-core는 이를 감지하지만, 수동 검토에서는 놓칠 수 있다. - 오류 페이지(404, 500, 검증 오류)에서 제목을 업데이트하지 않는 경우: 오류 페이지는 이전 페이지의 제목을 그대로 상속하거나 일반적인 사이트 제목으로 되돌아가는 경우가 많다. 404 오류를 발생시킨 스크린 리더 사용자는 자신이 이전에 있던 페이지의 제목이 아니라 "Page Not Found — Accsible"과 같은 제목을 들어야 탐색이 실패했다는 사실을 이해할 수 있다.
- 서로 다른 콘텐츠를 가진 페이지들 간에 제목이 중복되는 경우: 상품 목록 페이지와 상품 상세 페이지가 모두 "Products — Accsible Store"라는 제목을 가진다면, 인지 장애가 있는 사용자나 여러 탭을 관리하는 사용자는 두 페이지를 구분할 수 없다. 논리적으로 구분되는 모든 페이지는 자신의 구체적인 콘텐츠를 반영하는 고유한 제목을 가져야 한다.
- 템플릿 변수 이름이 그대로 포함된 동적 생성 제목: 서버 측 렌더링 버그로 인해 템플릿 변수가 렌더링되지 않고
<title>{{page.title}} — MySite</title>와 같은 제목이 생성될 수 있다. 이런 제목은 비어 있지 않기 때문에 검사를 통과하지만, 의미 있는 정보를 제공하지 않는다. 배포 전에 템플릿 렌더링 실패를 잡기 위해 CI/CD 파이프라인에 자동화된 제목 콘텐츠 검사를 구현하라. - 너무 길거나 키워드가 과도하게 삽입된 제목: WCAG는 글자 수 제한을 두지 않지만, 60–70자를 넘는 지나치게 긴 제목은 브라우저 탭과 검색 결과에서 잘리고, 스크린 리더는 가장 관련 있는 부분을 읽기 전에 전체 문자열을 읽어야 한다. 제목은 간결하고 구체적이며, 가장 중요한 정보를 앞부분에 배치하라.
- iframe 문서에 제목을 생략하는 경우: 전체 HTML 문서를 로드하는 인라인 프레임(
<iframe>) 역시 의미 있는<title>요소를 가져야 한다.iframe요소 자체는 프레임의 목적을 설명하는title속성을 가져야 하지만, 프레임 안에 로드되는 문서도 자신의<head>안에<title>을 포함하면 프레임 콘텐츠로 탐색하는 보조 기술에 도움이 된다.
터키 접근성 규정과의 관계
2025년 6월 21일 관보 제32933호에 게재된 터키 대통령령 2025/10은 광범위한 공공 및 민간 부문 디지털 서비스에 대해 구속력 있는 접근성 요구사항을 수립한다. WCAG 2.4.2 Page Titled는 레벨 A 성공 기준이며, 레벨 A 준수는 이 대통령령에서 요구하는 의무적인 최소 수준이다. 해당 기관은 공공 기관인 경우 1년 이내에, 민간 부문 조직인 경우 2년 이내에 레벨 A 준수를 달성해야 한다.
이 대통령령은 폭넓은 유형의 기관을 포괄하므로, WCAG 2.4.2는 터키 디지털 경제의 상당 부분과 관련이 있다. 대상 기관에는 모든 공공 기관과 정부 부처, 전자상거래 플랫폼, 은행 및 금융 기관, 병원 및 의료 서비스 제공자, 가입자 200,000명 이상을 보유한 통신 회사, 허가받은 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 사립 학교가 포함된다.
이러한 조직에게 의미 있는 페이지 제목을 제공하지 않는 것은 단순한 모범 사례 미준수가 아니라 규제상 비준수 위험이다. 예를 들어, 상품 카테고리 페이지가 모두 동일한 일반적인 제목을 공유하는 터키의 전자상거래 플랫폼이나, 예약 흐름의 모든 단계가 구분되지 않는 동일한 제목을 사용하는 공공 병원의 진료 예약 시스템은 모두 이 대통령령의 접근성 요구사항을 직접적으로 위반하는 것이다. 규제 기관이나 민원 제기자는 이러한 실패를 의무적인 레벨 A 기준 위반으로 지적할 수 있다.
WCAG 2.4.2를 올바르게 구현하는 것은 일반적으로 각 페이지에 잘 구성된 설명적 <title> 요소가 있도록 템플릿 수준에서 변경만 하면 되므로, 가장 적은 노력으로 가장 큰 효과를 얻을 수 있는 접근성 개선 중 하나이다. 2025/10 대통령령의 적용을 받는 조직이라면, 페이지 제목 문제를 어떤 접근성 개선 로드맵에서도 가장 먼저 해결해야 할 항목 중 하나로 삼아야 한다. 구현이 간단하고, 검증이 쉽고, axe-core의 document-title 규칙으로 직접 테스트할 수 있어 감사나 규제 기관에 준수 여부를 입증하기도 용이하기 때문이다.
터키어 사용자를 대상으로 서비스를 제공하는 조직은 페이지 제목이 페이지 콘텐츠와 일치하는 올바른 언어로 제공되도록 해야 하며, 이는 lang 속성 요구사항(WCAG 3.1.1)을 보완한다. 이렇게 해야 터키어 환경의 스크린 리더가 페이지 로드 시 발표되는 제목을 올바르게 해석하고 발음할 수 있다.
