본문 바로가기
A11YKR Docs

2.5.3 이름 안의 레이블

(Level A)

요약

Section titled “요약”
목표
컨트롤의 시각적 레이블은 음성 활성화의 도화선이다.
할 일
가능한 경우, 컨트롤의 텍스트 레이블과 이름을 일치시켜야 한다.
중요성
음성 상호작용으로 작업하는 사람은 명령을 내릴 때 시각적 레이블을 사용한다.

의도

Section titled “의도”

이 성공 기준의 의도는 구성요소를 시각적으로 레이블링하는 단어가 프로그램적으로도 해당 구성요소와 연결되도록 보장하는 것이다. 이는 장애인이 구성요소와 상호작용하기 위한 수단으로서 시각적 레이블을 신뢰하고 사용할 수 있도록 돕는다.

대부분의 컨트롤에는 시각적 텍스트 레이블이 수반된다. 이러한 컨트롤은 접근 가능한 이름으로도 알려진 프로그래밍 방식의 이름을 가진다. 컨트롤의 시각적 레이블에 포함된 단어와 문자가 접근 가능한 이름과 일치하거나 그 안에 포함될 때, 사용자는 일반적으로 훨씬 더 나은 경험을 하게 된다. 이들이 일치하면, 음성 입력 사용자(예: 음성 인식 애플리케이션 사용자)는 화면에 나타나는 메뉴, 링크, 버튼과 같은 구성요소의 시각적 텍스트 레이블을 말하여 탐색할 수 있다. 또한 텍스트 음성 변환(예: 스크린리더)을 사용하는 시력이 있는 사용자도 귀로 듣는 텍스트가 화면에서 보는 텍스트와 일치할 때 더 나은 경험을 할 수 있다.

구성요소에 시각적 텍스트 레이블이 없는 경우, 이 성공 기준은 적용되지 않는다.

텍스트 레이블이 존재하고 확립된 저작 관례에 따라 사용자 인터페이스 구성요소에 적절히 연결된 경우, 레이블과 이름은 보통 일치한다. 이들이 일치하지 않으면 시각적 텍스트 레이블을 탐색 또는 선택 수단으로 사용하려는 음성 입력 사용자(예: “비밀번호로 이동”)는 목적을 달성할 수 없다. 사용자가 말한 시각적 레이블이 음성 입력 명령으로 활성화되는 접근 가능한 이름과 일치하지 않거나 그 일부가 아니기 때문에 음성 기반 탐색에 실패하는 것이다. 또한 접근 가능한 이름이 시각적 레이블과 다를 경우, 음성 입력 사용자에 의해 실수로 활성화될 수 있는 숨겨진 명령으로 작동할 수 있다.

컨트롤의 시각적 레이블과 프로그래밍 방식 이름 사이의 불일치는 인지 장애를 동반한 음성 입력 및 텍스트 음성 변환 사용자에게 훨씬 더 큰 문제가 된다. 불일치는 음성 입력 사용자에게 추가적인 인지 부하를 발생시키며, 사용자는 컨트롤에서 보는 시각적 레이블과 다른 음성 명령을 말해야 한다는 사실을 기억해야만 한다. 또한 텍스트 음성 변환 사용자에게도 시각적 레이블과 일치하지 않는 음성 출력을 받아들이고 이해해야 하는 추가적인 인지 부하를 발생시킨다.

사용자 인터페이스 구성 요소에 접근 가능한 이름이 없고(4.1.2 이름, 역할, 값의 실패) 눈에 보이는 텍스트 레이블이 있는 경우에도 이 성공 기준에 실패힌다.

컴포넌트 레이블 텍스트 식별

Section titled “컴포넌트 레이블 텍스트 식별”

레이블 텍스트와 접근 가능한 이름을 일치시키기 위해서는, 우선 화면상의 어떤 텍스트를 특정 컨트롤의 레이블로 간주할 것인지 결정해야 한다. 인터페이스 내에는 특정 컨트롤과 연관될 수 있는 여러 종류의 텍스트 문자열이 있는 경우가 많다. 그러나 레이블을 컨트롤과 아주 가까운 곳에 있는 텍스트로만 보수적으로 해석하는 것이 가장 바람직하며, 여기에는 그럴 만한 이유가 있다.

일반적으로 사용자 인터페이스 구성요소의 레이블은 인접한 텍스트 문자열이다. 왼쪽에서 오른쪽으로 읽는 언어의 일반적인 배치 방식은 다음과 같다.

  • 콤보 박스, 드롭다운 리스트, 텍스트 입력 필드 및 기타 위젯의 바로 왼쪽(또는 왼쪽 레이블이 없는 경우, 각 입력 필드의 바로 위쪽이며 왼쪽 가장자리에 맞춰 정렬함).
  • 체크박스 및 라디오 버튼의 바로 오른쪽.
  • 버튼 및 탭의 내부, 혹은 버튼 역할을 하는 아이콘의 경우 바로 아래쪽.

이러한 규칙 중 일부에 대한 이론적 근거는 G162: Positioning labels to maximize predictability of relationships에 설명되어 있다.

텍스트 레이블로 간주하는 범위를 너무 넓게 해석하면 예측 가능성이 떨어져 이 성공 기준의 가치가 훼손될 수 있으므로, 인접한 텍스트만을 레이블로 취급하는 것이 중요하다. 레이블을 컴포넌트와 아주 가까운 곳에 위치한 단일 문자열로 한정하면 개발자, 테스터 및 최종 사용자가 이 성공 기준에서 평가 대상이 되는 레이블을 더 쉽게 식별할 수 있다. 레이블을 예측 가능하게 해석할 수 있으면 음성 인식 기술 사용자는 관습적인 위치에 있는 레이블을 통해 요소와 상호작용할 수 있고, 스크린리더 사용자는 시각적인 근접 레이블과 음성으로 안내되는 컴포넌트 이름 사이의 일관성을 누릴 수 있다.

입력 필드 내의 플레이스홀더 텍스트는 레이블을 제공하는 적절한 수단으로 간주되지 않는다. HTML 표준은 ‘플레이스홀더 속성을 label 요소의 대체 수단으로 사용해서는 안 된다’고 명시하고 있다. 하지만 해당 문구에서의 ‘레이블’은 코드 괄호로 묶여 label 요소를 연결하고 있다는 점에 주목할 필요가 있다. 본 ‘이름 안의 레이블’ 성공 기준에서 말하는 ‘레이블’은 이러한 프로그래밍적인 의미로 사용되는 것이 아니라, 단순히 컴포넌트에 시각적으로 인접한 곳에 위치한 텍스트 문자열을 의미한다. 따라서 (앞서 언급한 목록과 같이) 주변에 다른 텍스트 문자열이 없는 상황에서 입력 필드에 플레이스홀더 텍스트가 포함되어 있다면, 해당 텍스트는 ‘이름 안의 레이블’ 후보가 될 수 있다. 이는 (나중에 논의할) 접근 가능한 이름 계산 방식에 의해 뒷받침될 뿐만 아니라, 시각적 레이블이 따로 제공되지 않는 경우 음성 입력 사용자가 해당 플레이스홀더 텍스트 값을 입력 필드와 상호작용하기 위한 수단으로 시도할 가능성이 높다.

”인간의 언어로 무언가를 표현하는” 텍스트 레이블

Section titled “”인간의 언어로 무언가를 표현하는” 텍스트 레이블”
기호 텍스트 문자
Section titled “기호 텍스트 문자”

이 성공 기준의 목적상, 텍스트가 WCAG의 텍스트 정의에 따라 인간 언어로 무언가를 직접 표현하지 않고 상징적인 방식으로 사용된 경우에는 시각적 레이블로 간주해서는 안 된다. 예를 들어, 1.4.5 텍스트 이미지에서는 “상징적 텍스트 문자”에 대한 고려 사항을 설명한다. 텍스트 이미지 예시에서 텍스트 편집기의 아이콘에 나타나는 “B”, “I”, “ABC”는 각각 굵게(Bold), 기울임꼴(Italics), 맞춤법 검사(Spelling) 기능을 상징하기 위한 것이다. 이러한 경우, 접근 가능한 이름은 시각적으로 보이는 상징적 문자가 아니라 해당 버튼이 제공하는 기능(예: “맞춤법 검사”)이어야 한다. 이와 유사한 텍스트 편집기가 아래 그림에 제시되어 있다.

제목, 굵게, 기울임꼴, 인용문, 코드, 링크를 포함한 텍스트 변환 아이콘과 순서 있는 목록 및 순서 없는 목록 및 기타 컨트롤에 대한 아이콘

그림 1 GitHub의 리치 텍스트 편집기 상세 모습. 텍스트 문자와 유사한 아이콘을 포함하여 레이블이 없는 다양한 아이콘을 보여준다.

이와 마찬가지로, 저작자가 오른쪽 화살표 모양을 흉내 내기 위해 ‘크다’ 기호(”>“)를 사용한 경우, 해당 텍스트는 인간 언어로 무언가를 전달하는 것이 아니다. 이는 상징이며, 이 시나리오에서는 ‘재생(Play)’ 버튼이나 ‘다음(Next)’ 화살표에 사용되는 아이콘을 흉내 내기 위한 기호이다.

문장 부호 및 대문자 표기
Section titled “문장 부호 및 대문자 표기”

레이블에 사용된 문장 부호와 대문자 표기 역시 동일한 이유로 선택 사항으로 간주할 수 있다. 예를 들어, 입력 레이블 끝에 관례적으로 추가되는 콜론(:)은 인간 언어로 무언가를 표현하는 것이 아니며, 레이블의 각 단어 첫 글자를 대문자로 표기하는 것도 보통 단어의 의미를 바꾸지 않는다. 이는 특히 음성 인식 사용자에게 중점을 두는 이 성공 기준의 맥락에서 유의미하다. 사용자가 컨트롤과 상호작용하기 위해 레이블을 말할 때 대문자와 대부분의 문장 부호는 자주 무시되기 때문이다.

접근 가능한 이름에 콜론이나 대문자 표기를 포함하는 것이 결코 오류는 아니지만, 계산된 이름이 “이름”이라고 해서 “이름:“의 오류로 간주해서는 안 된다.

이와 마찬가지로, 버튼에 시각적으로 “다음…”이라고 표시되어 있더라도 접근 가능한 이름은 “다음”으로 설정할 수 있다.

판단이 모호할 때는 의미 있는 시각적 레이블이 존재한다면, 접근 가능한 이름의 문자열을 시각적 레이블과 정확히 일치시켜야 한다.

수식 및 공식
Section titled “수식 및 공식”

수식은 상징적 문자에 관한 이전 소절의 예외에 해당한다. 수학 기호는 레이블로 사용할 수 있으며, 예를 들어 “11×3=33”과 “A>B”는 의미를 전달한다.

접근 가능한 이름에서 레이블을 덮어쓰지 않아야 하며, 수식이 사용된 경우 단어로 대체하는 것은 피해야 한다. 동일한 방정식을 표현하는 방법은 여러 가지가 있기 때문이다. 예를 들어, 이름을 “11 곱하기 3은 33과 같다”라고 설정하면, “11 곱하기 3은 33”이라고 말하는 사용자와 일치하지 않을 수 있다. 수식은 레이블에 사용된 그대로 두고, 사용자가 자신의 음성 소프트웨어에 숙달되어 일치 항목을 찾아낼 수 있도록 맡기는 것이 최선이다. 또한, 수학 공식 레이블을 철자로 풀어서 쓴 동등한 내용의 접근 가능한 이름으로 변환하면 번역 시 문제가 발생할 수 있다. 이름은 레이블의 공식 텍스트와 일치해야 한다. 저작자가 고려해야 할 사항은 공식에 적절한 기호를 사용하는 것이다. 예를 들어 11x3(소문자 또는 대문자 X 사용), 11*3(별표 기호 사용), 11×3(× 기호 사용)은 모두 시각 이용 사용자가 동일한 공식으로 해석하기 쉽지만, 음성 인식 소프트웨어가 모두 “11 곱하기 3”으로 일치시키지 못할 수도 있다. 이 경우 적절한 연산자 기호(여기서는 곱셈 기호)를 사용해야 한다.

접근 가능한 이름 및 설명 계산 명세

Section titled “접근 가능한 이름 및 설명 계산 명세”

접근 가능한 이름이 어떻게 도출되는지 이해하는 것은 중요하다. 접근 가능한 이름 및 설명 계산 1.1과 HTML 접근성 API 맵핑 1.0은 어떤 속성이 계산에 고려되는지, 그리고 어떤 우선순위에 따라 계산되는지를 포함하여 접근 가능한 이름이 산출되는 방식을 설명한다. 만약 하나의 구성요소에 접근 가능한 이름으로 사용될 수 있는 여러 개의 속성값이 있는 경우, 그중 우선순위가 가장 높은 값만 계산에 반영된다. 우선순위가 낮은 다른 값들은 이름의 일부가 되지 않는다. 대부분의 경우, 레이블과 컨트롤 사이에 기존에 확립된 프로그래밍 방식의 관계는 이 명세에 의해 더욱 강화된다.

1.3.1 정보와 관계를 충족하도록 올바르게 코딩되어 화면에 표시된 다른 텍스트들은 저작자의 개입(ARIA 레이블링 기법 등)이 없는 한, 통상적으로 사용자 인터페이스(UI) 구성요소의 접근 가능한 이름 계산에 포함되지 않는다. 이러한 텍스트 중 가장 일반적인 예는 다음과 같다.

  • 제목 및 지시 사항
  • 구성요소 세트에 대한 그룹 레이블 (예: legend/fieldset과 함께 사용되거나 group 또는 radiogroup 역할을 가진 경우)

이러한 텍스트 정보는 구성요소 설명의 일부를 구성할 수 있다. 따라서 프로그래밍 방식의 관점과 레이블을 오직 “인접한 텍스트”로만 간주하는 보수적인 전략 모두에서 제목, 지시사항, 그룹 ‘레이블’은 통상적으로 이 성공 기준의 목적상 레이블로 간주해서는 안 된다.

명세에 따라 저작자가 기본 의미를 통해 계산된 이름을 덮어쓸 수 있다는 점에 유의하는 것이 중요하다. aria-label과 aria-labelledby는 모두 이름 계산에서 우선권을 가지며, 시각적 텍스트 레이블이 컨트롤과 프로그래밍 방식으로 연결되어 있더라도 시각적 텍스트를 대신하여 접근 가능한 이름으로 덮어쓴다. 이러한 이유로 시각적 레이블이 이미 존재하는 경우, aria-label 사용은 피하거나 신중해야 하며, aria-labelledby는 보충 수단으로서 주의해서 사용해야 한다.

마지막으로, aria-describedby는 접근 가능한 이름 계산에 포함되지 않는다(대신 접근 가능한 설명 계산에 포함된다). 관례적으로 aria-describedby를 통해 컨트롤과 연결된 텍스트는 스크린리더에서 접근 가능한 이름 바로 다음에 안내된다. 따라서 제목, 지시사항, 그룹 레이블의 맥락을 접근 가능한 설명으로 제공하면, 음성 인식 소프트웨어를 사용하여 탐색하는 사용자에게 영향을 주지 않으면서 스크린리더 사용자를 도울 수 있다.

괄호 안의 텍스트

Section titled “괄호 안의 텍스트”

참고: 이 섹션에서 “괄호”라는 용어는 말 그대로 둥근 괄호 () 안에 나타나는 텍스트를 설명한다. 이는 “관련 정보”라는 추상적인 의미로 사용된 것이 아니다.

접근 가능한 이름과 설명의 맥락에서 레이블 내의 괄호 텍스트를 언급하는 것은 중요하다. 일반적인 용법에서 괄호 안의 텍스트는 부차적이지만 의미와 관련이 있는 것으로 간주된다. 음성 인식 사용자는 일반적으로 입력 이름의 일부로서 괄호 안의 텍스트를 발음하지 않는다. 그러한 이유로 괄호 텍스트는 선택적으로 설명으로 간주될 수 있으며, 접근 가능한 이름에서는 제외될 수 있다.

그러나 필수 필드 표시나 입력 허용 범위 제한과 같이 괄호 안의 정보가 중요한 맥락을 제공하는 경우, 해당 정보가 접근 가능한 이름의 일부로 포함되지 않는다면 다른 방식으로 사용자에게 프로그래밍 제어를 통해 제공해야 한다. 예를 들어, “이름(필수)” 및 “날짜(YYYY-MM-DD)“는 각각 “이름”과 “날짜”를 접근 가능한 이름으로 가질 수 있다. 하지만 1.3.1 정보와 관계를 충족하기 위해서는 저작자가 필수 상태와 데이터 형식 제한(이 예시에서는 YYYY-MM-DD 패턴에 맞는 8자리 숫자)을 프로그래밍 방식으로 노출해야 한다. “필수” 상태는 HTML의 required 속성이나 aria-required="true"를 사용하여 노출할 수 있으며, 허용된 데이터 형식은 aria-describedby 속성을 사용하여 참조함으로써 노출할 수 있다.

이점

Section titled “이점”
  • 음성 입력 사용자는 초점의 예기치 않은 변화를 줄이면서 페이지의 컨트롤을 직접 활성화할 수 있다.
  • 텍스트 음성 변환 사용자는 귀로 듣는 레이블이 화면에서 보는 시각적 텍스트 레이블과 일치하므로 더 나은 경험을 할 수 있다.

예제

Section titled “예제”
  • 접근 가능한 이름과 시각적 레이블의 일치: 컨트롤의 접근 가능한 이름과 시각적 레이블이 일치한다.
  • 접근 가능한 이름이 시각적 레이블로 시작함: 접근 가능한 이름인 “Search for a value”이 시각적 레이블인 “Search”이라는 텍스트로 시작한다.

관련 자료

Section titled “관련 자료”

자료는 정보 제공 목적으로만 제공되며 보증을 암시하지 않는다.

기법

Section titled “기법”

이 섹션의 각 번호가 매겨진 항목은 접근성 지침 실무 그룹이 이 성공 기준을 충족하기에 충분하다고 판단하는 기법 또는 기법의 조합을 나타낸다. 기법은 기준의 최소 요구 사항을 넘어설 수 있다. 이러한 기법에서 포괄하지 않은 기준 충족의 다른 방법이 있을 수 있다. 다른 기법 사용에 대한 정보는 WCAG 성공 기준에 대한 기법 이해, 특히 “기타 기법” 섹션을 참조하라.

충분 기법

Section titled “충분 기법”

조언 기법

Section titled “조언 기법”

준수를 위해 필수는 아니지만 콘텐츠에 더 쉽게 접근할 수 있도록 다음과 같은 추가 기술을 고려해야 한다. 모든 기술을 사용할 수 없거나 모든 상황에서 효과적인 것은 아니다.

오류

Section titled “오류”

다음은 접근성 지침 실무 그룹에서 이 성공 기준의 실패로 간주하는 일반적인 실수이다.

점검 규칙

Section titled “점검 규칙”

다음은 이 성공 기준의 특정 측면에 대한 점검 규칙이다. WCAG 준수 여부를 확인하기 위해 이러한 특정 점검 규칙을 사용할 필요는 없지만 이것은 정의되고 승인된 검사 방법이다. 점검 규칙 사용에 대한 자세한 내용은 WCAG 성공 기준에 대한 점검 규칙 이해를 참고하라.

의견 남기기