placeholder와 aria-label을 사용해도 레이블 문제가 남는 이유

input에 placeholder만 있어도 스크린리더는 이름을 읽습니다. 그런데도 placeholder-only가 문제로 지적되는 이유는 무엇일까요? 이 글은 여섯 가지 마크업에서 Chromium이 실제로 계산한 접근 가능한 이름을 읽고, 이 사이트 폼 레이블 엔진의 결과와 비교한 기록입니다. 이름이 '있느냐'와 이름이 '어디서 왔느냐'를 나눠 봅니다.

placeholder가 영구적인 레이블을 대체할 수 없는 4대 이유

W3C WCAG 가이드라인과 닐슨 노먼 그룹(NN/g)의 사용성 연구 보고서는 placeholder를 단독 레이블로 사용하는 것을 엄격히 경고합니다. 그 이유는 명백한 네 가지 치명적 결함 때문입니다.

첫째는 '입력 시작 시 안내 문구의 소멸과 단기 기억 의존(Short-term Memory Loss)'입니다. 사용자가 입력 필드를 클릭하고 글자를 타이핑하기 시작하는 순간 placeholder 문구는 화면에서 완전히 사라집니다. 사용자가 입력을 마치고 검토할 때, 혹은 다른 작업을 하다가 돌아왔을 때 해당 필드가 '집 전화번호'였는지 '휴대전화 번호'였는지 확인하려면 입력한 내용을 전부 지우고 다시 확인해야 하는 불필요한 인지 부하를 강요합니다.

둘째는 '색상 대비율(Contrast Ratio)의 만성적 미달'입니다. 대부분의 브라우저 기본 CSS 스타일에서 placeholder 텍스트는 연한 회색(#757575 또는 #A0A0A0)으로 렌더링되며, 이는 흰색 배경 기준 4.5:1 명암비를 충족하지 못합니다. 반대로 가독성을 위해 placeholder 색상을 진하게 만들면, 사용자는 이미 폼에 값이 채워져 있는 것으로 오인하여 입력을 건너뛰는 역효과가 발생합니다.

셋째는 '브라우저 자동 완성 기능과의 시각적 충돌'입니다. 크롬이나 사파리가 아이디, 비밀번호, 주소를 자동으로 채워 넣는 순간 placeholder는 덮어씌워져 사라지므로 사용자가 어떤 정보가 채워졌는지 검증하기 어렵습니다.

넷째는 '자동 번역 툴의 번역 누락'입니다. Google 번역이나 Chrome 내장 번역기는 일반 DOM 텍스트 노드는 완벽하게 번역하지만, input 태그의 placeholder 속성값은 번역 대상에서 누락하거나 오역하는 경우가 빈번합니다.

측정 기록: 여섯 가지 마크업의 접근 가능한 이름

Chromium 153.0.8010.12, Windows, 2026-10-17 환경에서 같은 전화번호 input을 여섯 가지 방식으로 마크업하고, Playwright의 ariaSnapshot(Chromium 접근성 트리)으로 계산된 이름을 읽은 뒤 폼 레이블 엔진(form-label)의 결과와 비교했습니다. 여섯 경우 모두 Chromium의 이름과 엔진의 접근 가능한 이름이 일치했습니다.

• placeholder만 있는 input: Chromium 이름 "010-0000-0000", 엔진 이름 출처 placeholder, 엔진 이슈 potential_issue:placeholder_only
• label for/id 연결: Chromium 이름 "휴대폰 번호", 엔진 이름 출처 label, 엔진 이슈 없음
• label + placeholder 예시: Chromium 이름 "휴대폰 번호", 엔진 이름 출처 label, 엔진 이슈 없음
• aria-label만 있고 보이는 label 없음: Chromium 이름 "휴대폰 번호", 엔진 이름 출처 aria-label, 엔진 이슈 manual_review:missing_visible_label
• 존재하지 않는 id를 가리키는 aria-labelledby: Chromium 이름 "010-0000-0000", 엔진 이름 출처 placeholder, 엔진 이슈 potential_issue:broken_labelledby_reference, potential_issue:placeholder_only
• title 속성만 있음: Chromium 이름 "휴대폰 번호", 엔진 이름 출처 title, 엔진 이슈 manual_review:missing_visible_label

측정에서 알게 된 점

첫째, placeholder만 있는 input도 Chromium은 이름을 계산했고, 그 이름은 "010-0000-0000"였습니다. 이름이 없는 것이 아니라 placeholder가 곧 이름이 됩니다. 문제는 값을 입력하면 placeholder가 사라져 화면에 남는 레이블이 없어진다는 점입니다(측정 캡처 참고). 엔진은 이 경우를 오류가 아니라 potential_issue:placeholder_only로 표시합니다.

둘째, label과 placeholder를 함께 쓰면 이름은 label("휴대폰 번호")에서 오고, placeholder는 접근성 트리에서 별도 속성으로 분리되어 나옵니다. 입력 예시는 placeholder에 두어도 이름을 해치지 않습니다.

셋째, 존재하지 않는 id를 가리키는 aria-labelledby를 넣어도 Chromium은 오류 없이 placeholder("010-0000-0000")로 이름을 대신했습니다. 이름이 비어 있지 않아 눈에 띄지 않지만 엔진은 potential_issue:broken_labelledby_reference, potential_issue:placeholder_only 두 가지를 모두 보고했습니다.

넷째, aria-label만 있는 경우와 title만 있는 경우는 이름은 있지만 보이는 레이블이 없습니다. 엔진은 manual_review:missing_visible_label로 사람이 확인하도록 표시합니다.

이 측정은 Chromium 접근성 트리 기준입니다. NVDA, VoiceOver 같은 스크린리더가 실제로 어떻게 읽는지, Firefox·Safari의 이름 계산 차이는 측정하지 않았습니다.

HTML Accessible Name Computation 알고리즘의 우선순위 해부

W3C의 공식 사양인 '접근 가능한 이름 및 설명 계산(Accessible Name and Description Computation 1.2)' 알고리즘에 따르면, 브라우저가 <input> 요소의 스크린리더 낭독 이름을 결정할 때 다음과 같은 엄격한 위계 서열(Priority Hierarchy)을 적용합니다.

• 1순위: aria-labelledby 속성 (지정된 ID를 가진 다른 요소의 텍스트를 참조)
• 2순위: aria-label 속성 (요소에 직접 선언된 문자열)
• 3순위: 네이티브 <label for='...'> 요소 (명시적 결합 또는 암시적 감싸기)
• 4순위: placeholder 속성 (가장 낮은 대체 수단)
• 5순위: title 속성 (최후의 보루)

placeholder가 스크린리더에서 야기하는 혼선

위 알고리즘에서 볼 수 있듯이 placeholder는 가장 마지막 우선순위인 4순위에 불과합니다. 만약 개발자가 <label> 없이 placeholder='이메일을 입력하세요'만 지정해 둔 경우, 일부 구형 보조공학 기기나 브라우저 조합에서는 이를 폼의 공식 '이름(Name)'이 아닌 단순 '값(Value)'이나 '설명(Description)'으로 취급합니다.

그 결과 시각장애인이 Tab 키로 해당 입력창에 진입했을 때 '빈 텍스트 편집창'이라고만 낭독되고, 무엇을 입력해야 하는지 전혀 알려주지 않는 심각한 침묵 사태가 벌어집니다. 설령 placeholder를 읽어준다 하더라도, 실제 사용자가 텍스트를 한 글자 입력하는 순간 placeholder 값이 제거되면서 폼 컨트롤의 식별 정보가 증발하는 치명적인 사용성 왜곡이 발생합니다.

실무 디자인과 접근성을 모두 만족하는 최적의 구현 전략

시각적인 미니멀리즘 디자인을 포기하지 않으면서도 완벽한 접근성을 확보하는 실무적인 해법은 두 가지가 있습니다.

첫 번째는 '플로팅 레이블(Floating Label)' 패턴입니다. 평상시에는 placeholder처럼 입력창 내부 중앙에 위치하다가, 사용자가 포커스를 맞추거나 값을 입력하면 크기가 작아지며 입력창 상단 테두리 위로 부드럽게 이동하는 방식입니다. 이 방식은 네이티브 <label for> 요소를 정식으로 사용하므로 시각적으로도 아름답고 스크린리더 접근성도 100% 충족합니다.

두 번째는 '접근성 전용 숨김(.sr-only / .visually-hidden)' 클래스 활용입니다. 화면 공간이 극도로 부족한 검색창이나 단일 입력 폼의 경우, <label for='search-input' class='sr-only'>통합 도서 검색</label>처럼 레이블을 시각적으로만 화면 밖으로 숨기고 DOM 트리에는 온전히 남겨둡니다. display: none을 쓰면 스크린리더도 읽지 못하므로, 반드시 clip: rect(0 0 0 0) 기법의 sr-only 스타일을 적용해야만 완전한 접근성을 보장받을 수 있습니다.