성공기준 이해 2.5.3:이름 안의 레이블 (Level A)
요약
- 목표
- 컨트롤의 시각적 레이블은 음성 실행을 위한 발동 조건이다.
- 할 일
- 가능한 경우 컨트롤의 텍스트 레이블과 이름을 일치시켜야 한다.
- 중요성
- 음성 상호 작용으로 작업하는 사람들은 눈에 보이는 레이블을 명령에 사용한다.
의도
이 성공 기준의 목적은 구성 요소에 시각적으로 레이블을 지정하는 단어가 프로그램의 구성 요소와 연관된 단어인 것을 보장하는 것이다. 이는 장애가 있는 사용자가 구성 요소와 상호 작용하는 수단으로 눈에 보이는 레이블을 사용할 수 있도록 하는 데 도움이 된다.
대부분의 컨트롤에는 눈에 보이는 텍스트 레이블이 함께 제공된다. 동일한 컨트롤에는 접근 가능한 이름이라고도 하는 프로그램 상의 이름이 있다. 일반적으로 컨트롤의 표시 레이블에 있는 단어와 문자가 접근 가능한 이름에 포함되어 있거나 일치하는 경우 사용자는 훨씬 더 나은 경험을 할 수 있다. 이러한 항목이 일치하면 음성 입력 사용자(예: 음성 인식 애플리케이션 사용자)는 화면에 나타나는 메뉴, 링크, 버튼 등 구성 요소에 표시되는 텍스트 레이블을 말하여 탐색할 수 있다. 텍스트 음성 변환(예: 화면 낭독기)을 사용하는 시력이 있는 사용자는 듣는 텍스트가 화면에서 보는 텍스트와 일치하면 더 나은 경험을 하게 된다.
구성 요소에 눈에 보이는 텍스트 레이블이 없는 경우 이 성공 기준은 해당 구성 요소에 적용되지 않는다.
텍스트 레이블이 존재하고 확립된 저작 방식을 통해 사용자 인터페이스 구성 요소에 적절하게 연결되어 있는 경우 레이블과 이름은 일반적으로 일치한다. 일치하지 않으면 표시되는 텍스트 레이블을 탐색 또는 선택 수단(예: "비밀번호로 이동")으로 사용하려는 음성 입력 사용자는 성공하지 못한다. 사용자가 말한 보이는 레이블이 음성 입력 명령으로 활성화된 접근 가능한 이름과 일치하지 않거나 그 일부가 아니기 때문에 음성 기반 탐색에 실패한다. 또한, 접근 가능한 이름이 보이는 레이블과 다른 경우 음성 입력 사용자가 실수로 활성화할 수 있는 숨겨진 명령으로 동작할 수도 있다.
눈에 보이는 레이블과 컨트롤이 프로그램 상의 이름과 불일치하면 인지 문제가 있는 음성 입력 및 텍스트 음성 변환 사용자에게 훨씬 더 큰 문제가 된다. 불일치는 컨트롤에 표시되는 레이블과 다른 음성 명령을 말해야 하는 음성 입력 사용자에게 추가적인 인지 부하를 생성한다. 또한 텍스트 음성 변환(TTS) 사용자가 눈에 보이는 레이블과 일치하지 않는 음성 출력을 받아들이고 이해하기 위해 추가적인 인지 부하를 생성한다.
사용자 인터페이스 구성 요소에 접근 가능한 이름이 없고(4.1.2 이름, 역할, 값의 실패) 눈에 보이는 텍스트 레이블이 있는 경우에도 이 성공 기준에 실패힌다.
레이블 텍스트와 접근 가능한 이름이 일치하려면 먼저 화면의 어떤 텍스트가 지정된 컨트롤의 레이블로 간주되어야 하는지 결정해야 한다. 사용자 인터페이스에는 컨트롤과 관련된 여러 텍스트 문자열이 있는 경우가 많다. 그러나 레이블을 단지 근접한 텍스트로만 보수적으로 해석하는 것이 가장 좋은 이유가 있다.
일반적으로 사용자 인터페이스 구성 요소의 레이블은 인접한 텍스트 문자열이다. 왼쪽에서 오른쪽으로의 일반적인 언어 배치는 다음과 같습니다.
- 콤보 상자, 드롭다운 목록, 텍스트 입력 및 기타 위젯의 바로 왼쪽(또는 왼쪽 레이블이 없는 경우 각 입력의 왼쪽 가장자리 바로 위에 정렬됨)
- 체크박스와 라디오 버튼 바로 오른쪽
- 버튼과 탭 내부 또는 버튼 역할을 하는 아이콘 바로 아래
이러한 규칙 중 일부에 대한 이론적 근거는 G162: Positioning labels to maximize predictability of relationships에 설명되어 있다.
텍스트 레이블을 구성하는 요소에 대한 자유로운 해석은 예측 가능성을 줄여 이 성공 기준의 가치를 위태롭게 할 수 있으므로 인접한 텍스트만 레이블로 처리하는 방향으로 편향되는 것이 중요하다. 레이블을 구성 요소에 근접한 단일 문자열로 분리하면 개발자, 테스터 및 최종 사용자가 이 성공 기준에서 평가할 대상 레이블을 더 쉽게 식별할 수 있다. 레이블의 예측 가능한 해석을 통해 음성 인식 기술 사용자는 기존에 배치된 레이블을 통해 요소와 상호 작용할 수 있으며, 화면 낭독 기술 사용자는 근처에 보이는 레이블과 표시된 구성 요소 이름 간의 일관성을 누릴 수 있다.
텍스트 입력 필드 내의 자리 표시자(placeholder) 텍스트는 레이블을 제공하는 적절한 방법으로 간주되지 않는다. HTML5 사양에 따르면 자리 표시자 속성은
<label> 대체 수단으로 사용되어서는 안 된다고 명시한다. 그러나 HTML5 명세에서 "레이블"은 코드 괄호 안에 있으며
label 요소로 연결된다. 이 이름 안의 레이블 성공 기준에서는 "레이블"이 프로그래밍적 의미로 사용된 것이 아니라 구성 요소와 시각적으로 가까운 텍스트 문자열을 의미한다. 따라서 앞서
설명한 대로 다른 가까운 텍스트 문자열이 없는 경우, 입력 필드에 자리 표시자 텍스트가 포함되어 있다면 해당 텍스트는 이름 안의 레이블에 적합한 후보가 될 수 있다. 이는 접근 가능한 이름 계산(나중에 설명)과
실제로 시각적 레이블이 제공되지 않은 경우, 음성 입력 사용자가 자리 표시자 텍스트 값을 상호 작용 수단으로 사용할 가능성이 높기 때문이다.
"인간의 언어로 무언가를 표현하는" 텍스트 레이블
기호 텍스트 문자
이 성공 기준의 목적에 따라 텍스트는 WCAG의 텍스트 정의에 따라 인간의 언어로 직접 표현하는 것이 아니라 상징적인 방식으로 사용되는 경우 눈에 보이는 레이블로 간주되어서는 안 된다. 예를 들어, 1.4.5 텍스트 이미지에서는 "기호 텍스트 문자"에 대한 고려 사항을 설명한다. 텍스트 예의 이미지에서 "B", "I" 및 "ABC"는 텍스트 편집기의 아이콘에 표시되며 각각 굵게, 기울임꼴 및 철자 기능을 상징한다. 이러한 경우 접근 가능한 이름은 눈에 보이는 기호 문자가 아닌 버튼이 제공하는 기능(예: "맞춤법 검사" 또는 "맞춤법 검사하기")이어야 한다. 유사한 텍스트 편집기가 아래 그림에 나와 있다.
마찬가지로, 저자가 오른쪽 화살표의 모양을 모방하기 위해 보다 큼 기호(">")를 사용한 경우 텍스트는 인간 언어로 무엇인가를 전달하지 않는다. 이 시나리오에서는 "재생" 버튼이나 "다음" 화살표에 사용되는 아이콘을 모방하기 위한 기호이다.
구두점 및 대문자
레이블에 구두점과 대문자를 사용하는 것도 같은 이유로 선택 사항으로 간주될 수 있다. 예를 들어, 관례적으로 입력 레이블 끝에 추가되는 콜론은 인간의 언어로 무엇인가를 표현하지 않으며, 레이블에 있는 각 단어의 첫 글자에 있는 대문자는 일반적으로 단어의 의미를 바꾸지 않는다. 이는 주로 음성 인식 사용자를 대상으로 하기 때문에 이 성공 기준의 맥락에서 특히 관련이 있다. 사용자가 컨트롤과 상호 작용하는 수단으로 레이블을 말할 때 대문자와 대부분의 구두점은 종종 무시된다.
접근 가능한 이름에 콜론과 대문자를 포함하는 것은 확실히 오류가 아니지만 "이름"의 계산된 이름이 "이름:"의 실패로 간주되어서는 안 된다.
마찬가지로 버튼에 시각적으로 표시되는 "다음…"은 액세스 가능한 이름으로 "다음"을 가질 수 있다.
의미 있는 시각적 레이블이 존재하는지 확실하지 않은 경우 접근 가능한 이름에 해당하는 문자열을 정확하게 일치시켜야 한다.
수학적 표현 및 공식
수학적 표현은 기호 문자에 대한 이전 하위 섹션의 예외이다. 수학 기호를 레이블로 사용할 수 있다. 예를 들어 "11×3=33"과 "A>B"는 의미를 전달한다.
접근 가능한 이름에 레이블을 덮어쓰면 안 되며, 동일한 수식을 표현하는 방법이 다양하므로 수식이 사용되는 단어의 대체는 피해야 한다. 예를 들어, "11 곱하기 3은 33과 같다"라는 이름을 지정하면 "11
곱하기 3은 33"이라고 말한 사용자가 일치하지 않을 수 있다. 레이블에 사용된 공식을 그대로 두고 사용자가 음성 소프트웨어에 대해 잘 알고 있는지 확인하는 것이 가장 좋다. 또한 수학 공식 레이블을 철자가
표시된 접근 가능한 이름으로 변환하면 번역 문제가 발생할 수 있다. 이름은 레이블의 수식 텍스트와 일치해야 한다. 저작자가 고려해야 할 사항은 공식에 적절한 기호를 사용하는 것이다. 예를 들어
11x3(소문자 또는 대문자 X 포함), 11*3(별표 기호 포함) 및 11×3(× 기호 포함)은 모두 시력이 있는 사용자가 동일한 수식을
의미하는 것으로 해석하기 쉽다. 음성 인식 소프트웨어에서는 "11 곱하기 3"과 모두 일치하지 않을 수도 있다. 적절한 연산자 기호(이 경우에는 times 기호)를 사용해야 한다.
접근 가능한 이름 및 설명 계산 명세
접근 가능한 이름이 어떻게 파생되는지 이해하는 것이 중요하다. 접근 가능한 이름 및 설명 계산 1.1과 HTML 접근성 API 맵핑 1.0은 접근 가능한 이름이 계산되는 방법, 계산시 고려되는 속성, 우선 순위 등을 설명한다. 구성 요소에 접근 가능한 이름으로 사용할 수 있는 속성 값이 여러 개 있는 경우 해당 값 중 가장 우선하는 값만 계산된다. 우선 순위가 낮은 다른 값은 이름에 포함되지 않는다. 대부분의 경우 레이블과 컨트롤 사이에 존재하는 확립된 프로그래밍 관계가 명세에 의해 강화된다.
올바르게 코딩되어 화면에 표시되는 다른 텍스트는 보통 1.3.1: 정보와 관계를 충족하는 데 필요한 UI 구성 요소의 접근 가능한 이름 계산에 저자의 개입(ARIA 레이블링 기법을 통한) 없이는 고려되지 않는다. 가장 일반적인 것은 다음과 같다:
- 제목과 지시문
- 구성 요소 세트에 대한 그룹 레이블(예:
legend/fieldset또는group,radiogroup역할과 함께 사용)
이러한 텍스트 정보는 구성 요소 설명의 일부를 구성할 수 있다. 따라서 프로그래밍 관점과 레이블만 "인접 텍스트"로 간주하는 보수적인 측면에서 볼 때 일반적으로 제목, 지침, 그룹 '레이블' 중 어느 것도 이 성공 기준의 목적에 따라 레이블로 간주되어서는 안 된다.
명세에서는 저작자가 기본 의미 체계를 통해 계산된 이름을 재정의할 수 있다는 점에 유의하는 것이 중요하다. aria-label 및 aria-labelledby는
모두 이름 계산에서 우선 순위를 가지며, 표시되는
텍스트 레이블이 프로그래밍 방식으로 컨트롤과 연결되어 있는 경우에도 표시되는 텍스트를 접근 가능한 이름으로 재정의한다. 이러한 이유로 눈에 보이는 레이블이 이미 존재하는 경우에는
aria-label을 피하거나 주의해서 사용해야 하며, aria-labelledby는 보충을 위해 주의해서 사용해야 한다.
마지막으로 aria-describedby는 접근 가능한 이름 계산에 포함되지 않는다(대신 접근 가능한 설명 계산의 일부이다). 관례적으로
aria-describedby를 통한 컨트롤과 관련된 텍스트는 화면 낭독기에 의해 접근 가능한 이름 바로 뒤에 표시된다. 따라서 제목, 지시문 및 그룹 레이블의 맥락은 접근 가능한 설명을
통해 제공되어 음성 인식 소프트웨어를 사용하여 탐색하는 사용자의 경험에 영향을 주지 않고 화면 낭독기 사용자를 지원할 수 있다.
참고: 이 섹션에서 "괄호"라는 용어는 문자 그대로 둥근 괄호() 안에 표시되는 텍스트를 설명한다. 이는 "관련 정보"라는 보다 추상적인 의미로 사용되지 않는다.
접근 가능한 이름과 설명의 맥락에서 레이블에 괄호 텍스트를 언급하는 것이 중요하다. 일반적인 사용법에서 괄호 안의 텍스트는 부차적인 것으로 간주되지만 의미와 관련이 있다. 음성 인식 사용자는 일반적으로 입력 이름의 일부로 괄호 안의 텍스트를 표시하지 않는다. 이러한 이유로 괄호 안의 텍스트는 선택적으로 설명으로 간주되어 접근 가능한 이름에서 제외될 수 있다.
그러나 괄호 안에 있는 정보가 필수 필드 표시 또는 입력 허용 항목에 대한 제한과 같은 중요한 맥락을 제공하는 경우 해당 정보가 접근 가능한 이름의 일부로 포함되지 않은 경우 이 정보는 프로그래밍 방식으로
다른 방식으로 사용자에게 제공되어야 한다. 예를 들어 "이름(필수)" 및 "날짜(YYYY-MM-DD)"에는 "이름" 및 "날짜"를 접근 가능한 이름으로 사용할 수 있다. 그러나 1.3.1 정보와 관계를
통과하려면 저작자는 필수 상태와 허용되는 데이터 형식 제한(이 예에서는 YYYY-MM-DD 패턴에 맞는 8개의 정수)을 프로그래밍 방식으로 드러내야 한다. "필수" 상태는 HTML
required 속성을 통해 또는 aria-required="true"를 사용하여 표시될 수 있다. 허용되는 데이터 형식은
aria-describedby 속성을 사용하여 참조함으로써 드러낼 수 있다.
이점
- 음성 입력 사용자는 급격한 초점 변경을 최소화하면서 페이지에서 컨트롤을 직접 활성화할 수 있다.
- 텍스트 음성 변환 사용자는 듣는 레이블이 화면에 보이는 텍스트 레이블과 일치하기 때문에 더 나은 환경을 갖게 된다.
예제
- 접근 가능한 이름이 보이는 레이블과 일치: 컨트롤의 접근 가능한 이름과 보이는 레이블이 일치한다.
- 접근 가능한 이름이 보이는 레이블로 시작: 접근 가능한 이름 "Search for a value"은 보이는 레이블인 "Search"의 텍스트로 시작된다.
관련 자료
자료는 정보 제공 목적으로만 제공되며 보증을 암시하지 않는다.
기법
이 섹션에서 번호가 매겨진 각 항목은 WCAG 실무 그룹이 이 성공 기준을 충족하기에 충분하다고 간주하는 기법 또는 기법의 조합을 나타낸다. 그러나 이러한 특정 기법을 사용할 필요는 없다. 다른 기법 사용에 대한 자세한 내용은 WCAG 성공 기준에 대한 기법 이해, 특히 "기타 기법" 섹션을 참고하라.
충분 기법
조언 기법
준수를 위해 필수는 아니지만 콘텐츠에 더 쉽게 접근할 수 있도록 다음과 같은 추가 기술을 고려해야 한다. 모든 기술을 사용할 수 없거나 모든 상황에서 효과적인 것은 아니다.
- G162: Positioning labels to maximize predictability of relationships
- If an icon has no accompanying text, consider using its hover text as its accessible name (Potential future technique)
오류
다음은 WCAG 실무 그룹에서 이 성공 기준의 실패로 간주하는 일반적인 실수이다.
- F96: Failure due to the accessible name not containing the visible label text
- F111: Failure of Success Criteria 1.3.1, 2.5.3, and 4.1.2 due to a control with visible label text but no accessible name
- Accessible name contains the visible label text, but the words of the visible label are not in the same order as they are in the visible label text (Potential future technique)
- Accessible name contains the visible label text, but one or more other words are interspersed in the label (Potential future technique)
점검 규칙
다음은 이 성공 기준의 특정 측면에 대한 점검 규칙이다. WCAG 준수 여부를 확인하기 위해 이러한 특정 점검 규칙을 사용할 필요는 없지만 이것은 정의되고 승인된 검사 방법이다. 점검 규칙 사용에 대한 자세한 내용은 WCAG 성공 기준에 대한 점검 규칙 이해를 참고하라.