브라우저 안에서만 계산
폼 label·접근 가능한 이름 정적 검사기
네이티브 폼 컨트롤의 이름 원천, 지속적으로 보이는 label, 깨진 ID 참조와 이름·레이블 불일치를 지원된 알고리즘 범위에서 검사합니다.
무엇을 결정할 수 있나요?
input, select, textarea, button의 명시적 label과 ARIA 이름 참조를 정적으로 확인합니다.
전체 Accessible Name Computation을 구현했다고 주장하지 않으며 CSS, Shadow DOM, 사용자 에이전트 차이는 수동 검토로 남깁니다.
이 페이지의 고유 질문: 보이는 레이블과 지원 범위에서 계산한 접근 가능한 이름이 어떻게 다른가?
로컬 계산 도구
값을 입력해 검사하기
입력값은 브라우저 상태에서만 처리하며 서버·URL·Analytics로 보내거나 저장하지 않습니다.
자동으로 확인하는 범위
- aria-labelledby·aria-label·native label·title·placeholder의 지원 우선순위
- label[for]와 감싼 label
- placeholder-only, 깨진 참조, 중복 ID를 확정 실패와 분리
- 보이는 레이블이 이름에 포함되는지 하위검사
입력값과 단위
- HTML 코드
- 지원 네이티브 폼 요소가 포함된 정적 HTML 조각
판정할 때 지키는 원칙
- 지원한 모든 이름 원천이 비어 있으면 fail입니다. 최신 HTML-AAM의 텍스트형 컨트롤에서는 placeholder가 fallback 이름 후보가 될 수 있습니다.
- placeholder-only는 지속적으로 보이는 레이블·지시문 부족의 potential_issue로 분리합니다.
- 깨진 IDREF와 중복 ID는 fallback 계산을 계속하고 확정 WCAG 실패로 과장하지 않습니다.
- custom widget, CSS 생성 콘텐츠, 실제 발표 결과는 manual_review입니다.
자체 검증 도식
수정 전·후 예제
placeholder와 label
fallback 이름만 있는 상태
<input type="email" placeholder="example@email.com">보이는 label 연결
<label for="email">이메일</label>
<input id="email" type="email" placeholder="example@email.com" autocomplete="email">placeholder는 최신 HTML-AAM에서 이름 후보가 될 수 있지만, 입력하면 사라지므로 항상 노출되는 레이블·지시문을 완전히 대체할 수 없습니다.
보이는 이름과 ARIA 이름
문구 불일치
<label for="name">이름</label>
<input id="name" aria-label="성명 입력">보이는 문구 포함
<label for="name">이름</label>
<input id="name" aria-label="이름 입력">음성 명령 사용자가 보이는 문구로 컨트롤을 찾을 수 있도록 이름 포함 관계를 확인합니다.
실무 판단 가이드
placeholder와 aria-label만으로 충분할까?
placeholder나 aria-label 하나가 있으면 폼의 레이블과 설명 문제가 모두 해결된다.
접근 가능한 이름의 계산과 화면에 지속적으로 보이는 레이블·지시문의 제공은 같은 질문이 아닙니다.
일부 텍스트형 컨트롤은 최신 HTML 접근성 매핑에서 placeholder가 이름 후보가 될 수 있지만, 입력 후 사라지는 안내의 사용성 및 지속적 레이블은 별도로 검토해야 합니다.
판단 순서
- 보이는 레이블과 지시문을 먼저 찾는다.
- label, aria-labelledby, aria-label 등 이름 원천을 확인한다.
- 깨진 IDREF 뒤에 유효한 fallback 이름이 있는지 계산한다.
- 보이는 문구가 접근 가능한 이름에 포함되는지 확인한다.
- 설명·오류를 aria-describedby 등으로 연결하고 실제 발표를 표본 확인한다.
실패했을 때 복구
- 보이는 label을 추가하고 id/for를 고유하게 연결합니다.
- 설명과 오류는 이름을 과도하게 늘리지 말고 설명 참조로 분리합니다.
- 접근성 트리에서 이름과 설명을 확인한 뒤 키보드·화면낭독기 표본을 수행합니다.
회귀 테스트와 검수 증거
아래 fixture는 실제 고객 사례가 아니라 판정 로직이 같은 입력에 같은 결과를 내는지 확인하는 공개 회귀 자료입니다. 현장 사용 경험으로 과장하지 않습니다.
| Fixture ID | 입력 | 기대 결과 |
|---|---|---|
form-explicit-label | <label for="email">이메일</label><input id="email"> | 이름 이메일 |
form-placeholder-only | <input placeholder="이메일"> | 이름 후보 placeholder + 지속 레이블 potential_issue |
form-broken-labelledby | <input aria-labelledby="missing" title="회원 번호"> | 깨진 참조 potential_issue + title fallback |
대표 fixture 검증 기록
- 검사 환경
- 브라우저 및 테스트 환경: 대표 fixture 기반 자동 테스트 및 DOM 파서 검증; 실제 화면낭독기 수동 검사는 미검사
- 예상 결과
- 이름 원천, 깨진 참조, 지속 레이블 신호, label-in-name 결과를 별도로 표시
- 자동 결과
- HTML-AAM 우선순위에 따라 접근 가능한 이름을 계산하고 placeholder-only 및 깨진 IDREF에 대해 주의 신호를 반환합니다. (실제 화면낭독기 발표는 수동 검토 필요)
- 재검사 방법
- 수정 HTML의 이름 후보와 참조 오류가 개선됐는지 다시 검사합니다.
자동 결과 뒤에 남는 검사
- CSS 시각 표시
- 동적 오류 발표
- 브라우저 접근성 트리와 화면낭독기
자동 판정의 한계
- 전체 Accessible Name Computation
- CSS 기반 시각적 숨김과 생성 콘텐츠
- 브라우저·스크린리더별 발표 차이
- 동적 오류, portal, Shadow DOM, iframe
- 문구 자체가 충분한지에 대한 의미 판단
반드시 남는 수동 확인
- 레이블이 화면에서 항상 식별 가능한가?
- 필수값과 입력 형식 설명이 컨트롤에 연결되는가?
- 오류 메시지가 발생한 뒤 프로그램적으로 연결되는가?
- 실제 브라우저 접근성 트리의 이름과 같은가?
공식 상세 근거
- WCAG 2.2 Success Criterion 3.3.2 — Labels or Instructions
- WCAG 2.2 Success Criterion 4.1.2 — Name, Role, Value
- WCAG 2.2 Success Criterion 2.5.3 — Label in Name
이번 공개 검수 범위
HTML-AAM·AccName 부분집합과 WCAG 레이블·이름 조건 대조, Chromium 입력 검수
- 테스트 증거: 명시 label·placeholder·깨진 IDREF·중복 ID 단위 및 Playwright 회귀
- 콘텐츠 검토: placeholder 통념과 네 가지 이름 원천 fixture를 도구 본문에 통합
- 미검사·한계: 전체 AccName 알고리즘 미구현
- 미검사·한계: 실제 화면낭독기 발표 미검사
자주 묻는 질문
aria-label이 있으면 보이는 label은 없어도 되나요?
프로그램적 이름 하위검사와 보이는 레이블·지시문 요구는 별개입니다. 화면 사용자에게 필요한 정보도 확인해야 합니다.
검사 결과가 스크린리더 발표와 항상 같나요?
아닙니다. 정적 분석 후보이므로 브라우저 접근성 트리 및 실제 보조기술 음성 출력으로 표본 재확인이 필요합니다.