레이블과 네임 - by. UXKM

관련 용어 설명

• 레이블

  웹 페이지에서 사용자와 상호작용하는 요소에 표시되는 텍스트를 말합니다.
  예를 들어, 버튼에 "제출"이라고 쓰여 있거나, 입력창 옆에 "이메일"이라고 표시된 텍스트가 레이블입니다. 이러한 텍스트는 사용자가 해당 요소가 무엇을 하는지 이해하는 데 도움을 줍니다.
  참고로 <input> 요소와 짝을 이루는 <label> 요소만을 이야기하는 것이 아닙니다.

• 접근 가능한 이름 (네임)

  보조 기술이 상호작용 가능한 웹 콘텐츠 구성 요소를 인식하고 설명하는 데 사용하는 이름입니다. 이 이름은 시각적으로 보이는 레이블과 동일하거나, 시각적으로 표시되는 레이블에 포함될 수 있습니다.

• 상호작용 요소

  사용자 인터페이스 구성요소는 사용자가 특정 기능을 사용하기 위해 상호작용할 수 있는 버튼, 입력창, 링크 등과 같은 웹페이지 요소를 말합니다.

• 접근 가능한 이름 계산 알고리즘

  접근 가능한 이름은 보조기술 사용자가 웹 콘텐츠의 구성 요소를 인식할 수 있도록 제공되는 중요한 정보입니다. 이를 계산하는 방법을 이해하는 것이 중요합니다.
  예를 들어, aria-label, aria-labelledby, alt, title, placeholder와 같은 속성들이 중복으로 제공될 수 있는데, 이러한 경우에는 우선 순위를 가지고 계산합니다.

  [접근 가능한 이름 계산 방법 및 우선순위]

  1. aria-labelledby

     다른 요소를 참조하여 이름을 제공하는 방식입니다. 가장 우선순위가 높으며, 강력한 접근 가능한 이름을 제공합니다.

  2. aria-label

     요소에 직접적으로 이름을 지정합니다. aria-labelledby 다음으로 높은 우선순위를 가집니다.

  3. 요소 속성 (value, alt)

     <button>, <input type="submit">, <input type="reset">의 경우 value 속성,
     <input type="image">, <img>, <area> 요소의 경우 alt 속성이 접근 가능한 이름으로 사용됩니다.
     aria-label보다 낮은 우선순위를 갖습니다.

  4. 텍스트 콘텐츠 또는 label 요소 연결

     요소에 직접 포함된 텍스트나 label 요소로 연결된 텍스트를 접근 가능한 이름으로 사용합니다.

  5. title 속성

     요소에 대한 툴팁 정보를 제공하는 title 속성은 위의 방법들이 없을 때 이름으로 사용됩니다. 우선순위는 낮습니다.

  6. placeholder 속성 (<input> 요소에 한함)

     입력 필드에 대해 안내용으로 제공되며, 가장 낮은 우선순위를 가집니다.

  7. 모든 방법이 적용되지 않을 경우

     접근 가능한 이름이 없는 것으로 판단합니다.

관련 WCAG 2.2 성공 기준

2.5.3 Label in Name (Level A) WAI - Understanding Label in Name Accessible Name and Description Computation MDN - aria-label

기대효과

• 음성 입력(speech-input) 사용자는 시각적으로 표시되는 텍스트를 사용하여 사용자 인터페이스 구성요소를 제어할 수 있습니다.
• 텍스트 음성 변환(TTS: Text-to-Speech) 사용자는 보조기술을 통해 음성으로 전달되는 텍스트와 시각적으로 표시되는 텍스트가 일치하기 때문에 해당 사용자 인터페이스 구성요소를 혼란 없이 보다 쉽게 인지하고 활용할 수 있습니다.

필요성

음성 입력 사용자는 화면에 보이는 레이블을 그대로 사용하여 명령을 내립니다.
따라서 보조기술 사용자가 일관되고 명확하게 콘텐츠를 이해하고 상호작용할 수 있도록, 화면에 표시된 사용자 인터페이스(UI) 구성 요소의 눈에 보이는 레이블이 접근 가능한 이름(accessible name)과 일치하거나 포함되도록 해야 합니다.

• 시각적 텍스트와 보조기술을 통한 음성 안내 간 불일치 시 사용자 혼란이 발생합니다.
• 동일 UI에서 시각적 텍스트는 “삭제”, 스크린 리더가 읽는 이름은 “제거”인 경우 → 사용자는 동일한 기능이라고 인식하기 어렵습니다.
• 일관된 이름(label과 name) 사용은 신뢰도, 사용성, 접근성 향상에 직결됩니다.

웹 사이트나 애플리케이션을 개발할 때, 사용자 인터페이스 구성 요소에는 시각적인 레이블과 접근 가능한 이름이라는 두 가지 개념이 존재합니다.

• 시각적인 레이블 : 사용자가 화면에서 볼 수 있는 텍스트.
• 접근 가능한 이름 : 보조 기술(예: 화면 낭독 프로그램)이 인식하고 사용자에게 전달하는 이름.

일반적으로 시각적 레이블이 HTML 표준 연결 방법(예: label 요소, aria-labelledby 속성 등)을 통해 사용자 인터페이스 구성 요소와 적절하게 연결되면, 레이블과 접근 가능한 이름이 일치합니다.
그러나 연결이 올바르지 않거나, 시각적 레이블과 접근 가능한 이름이 일치하지 않을 경우, 다음과 같은 문제가 발생할 수 있습니다.

• 화면 낭독 프로그램을 함께 사용하는 저시력 사용자 :
  시각적인 레이블과 스크린 리더가 읽어주는 이름이 다르면, 사용자는 올바른 버튼이나 링크를 찾았는지 확신할 수 없어 혼란을 겪게 됩니다. 특히 인지 장애를 복합적으로 가진 경우 그 정도가 더욱 심합니다.
• 음성 명령 사용자 :
  화면에 보이는 레이블을 말했는데, 실제 요소의 접근 가능한 이름과 일치하지 않으면 음성 명령이 제대로 작동하지 않습니다.

따라서 시각적 레이블과 접근 가능한 이름의 일치는 접근성을 보장하고 사용자 경험을 향상시키는 데 매우 중요합니다.
다만, 디자인 제약이나 기술적 한계로 인해 완전한 일치가 어려운 경우도 있습니다. 이러한 경우에는 최소한 접근 가능한 이름에 시각적 레이블을 포함하고, 가능하면 해당 레이블을 접근 가능한 이름의 앞부분에 배치하는 것이 좋습니다.

예를 들어, '구매하기'라는 텍스트 버튼이 아래 예시 처럼 구성되면, 보조기기 사용자는 '선물하기'라는 잘못된 정보를 전달받아 원하는 작업을 수행할 수 없게 됩니다

대상

체크리스트

• UI 구성 요소에 시각적으로 표시된 레이블이 있는가?
• 접근 가능한 네임(name)에 시각적 레이블이 그대로 포함되어 있는가?
• aria-label, aria-labelledby, alt, title 등으로 name을 설정할 경우 시각 텍스트와 일치하는가?

테스트 방법

• 버튼, 링크, 입력필드 등의 시각적 텍스트를 확인합니다.
• 보조기술(스크린 리더) 사용 시 해당 UI 이름을 읽는지 확인합니다.
• 눈으로 보이는 텍스트와 음성으로 출력되는 텍스트가 동일한지 비교합니다.

QA 지표

• 시각적 텍스트와 네임 일치율
• 네임 누락 또는 불일치 항목 수
• 스크린 리더 사용자 테스트 일치도

개발방법

점검 기준

• 모든 시각적 레이블이 접근 가능한 이름에도 포함되어 있는가?
• aria-label, alt, title 등을 사용할 경우 시각적 텍스트와 같은가?

점검 방법

• DOM 요소에 정의된 텍스트 및 aria-*, alt 속성을 확인합니다.
• 스크린 리더(NVDA, JAWS 등)로 네임을 읽는지 테스트합니다.
• 디자인 화면과 실제 UI 요소 간 텍스트 불일치 여부를 비교합니다.

준수/미준수 사례

미준수 사례

접근 가능한 이름에 포함되지 않는 레이블

다음은 더 많은 콘텐츠를 불러올 수 있는 버튼이 눈에 보이는 레이블과 접근 가능한 이름이 서로 상이한 사례입니다.
다음 사례에서 눈에 보이는 레이블은 “SHOW MORE”로 되어 있으나, 접근 가능한 이름은 “Load more Instagram posts”로 되어 있습니다.
사람이 인식하는 레이블과 소프트웨어가 인식하게 되는 이름이 서로 다르기 때문에 음성 명령 사용자나 화면 낭독 프로그램 사용자는 컨트롤을 활성화시키지 못하거나 커뮤니케이션에서 혼란을 느끼기 쉽습니다.

개선 방법

접근 가능한 이름을 눈에 보이는 레이블과 일치되도록 aria-label을 삭제하거나, aria-label에 눈에 보이는 레이블이 포함되도록 수정하셔야 합니다.

준수 사례

눈에 보이는 텍스트 레이블과 일치하는 접근 가능한 이름 제공

접근 가능한 이름을 눈에 보이는 텍스트와 일치하게 제공해야 합니다.
다음은 버튼의 접근 가능한 이름을 눈에 보이는 레이블과 일치하게 제공하는 가장 일반적인 사례입니다.

눈에 보이는 레이블을 포함하여 접근 가능한 이름 제공

눈에 보이는 레이블이 접근 가능한 이름에 포함되도록 제공해야 합니다.
다음은 “상세 정보”라는 레이블을 가진 버튼이 있는 페이지의 사례입니다. 여러 목록에서 동일한 레이블의 버튼이 반복되기 때문에, 시각을 활용하기 어려운 사용자가 무엇에 대한 상세 정보 버튼인지 명확히 구분할 수 있도록 정보를 조합하여 접근 가능한 이름을 제공할 수 있습니다.

텍스트가 기호를 상징하는 기호 문자로 사용된 경우

에디터에서 'B', 'I'와 같이 텍스트가 상징적인 의미를 가지는 경우, 'B'가 아닌 '굵게'로 해당 버튼이 제공하는 기능에 대해 접근 가능한 이름을 제공해야 합니다.

관련 영상

출처 : 리베하얀

접근성 테스트 도구 활용 점검방법 자세히 보기

요약 설명

웹 및 모바일 애플리케이션의 접근성을 평가하고 개선하기 위한 다양한 도구와 방법을 소개합니다.
Lighthouse와 WAVE와 같은 웹 접근성 분석 도구를 사용하면 웹 페이지의 접근성을 점검할 수 있고, Android와 iOS에서 활용되는 접근성 도구를 통해 앱의 접근성을 테스트하고 개선할 수 있습니다.
여러 접근성 테스트 도구를 활용하고 웹 및 앱을 지속적으로 개선함으로써, 장애인을 포함한 모든 사용자에게 보다 편리한 환경을 제공할 수 있습니다.

접근성 트리 뷰(Accessibility Tree)

스크린 리더와 같은 보조 기술은 크로미움의 접근성 API를 사용해 웹콘텐츠와 상호 작용합니다. 접근성 API의 기본 모델은 접근성 트리입니다. 접근성 객체의 트리를 통해 보조 기술은 각 속성과 실제 속성값을 탐색하고 필요한 작업을 수행할 수 있습니다. 웹 개발자는 주로 HTML에서 ARIA 속성과 같은 DOM 속성값을 통해 접근성 트리를 만들고 이를 다룹니다.
크롬 개발자 도구에서는 개발자에게 콘텐츠가 보조 기술에 어떤 식으로 전달되는지 이해할 수 있게 접근성 창을 제공하고 있습니다. DOM 트리 뷰어에서 노드를 선택하면 해당하는 접근성 노드의 속성 정보가 상위 노드, 직계 자식 노드와 함께 창에 표시됩니다.

사용법

1. 개발자 도구에서 Elements 항목을 선택하고 오른쪽 창에서 Accessibility를 선택하면 “Enable full-page accessibility tree” 항목을 체크합니다.

   

2. 해당 노드 선택 후 검사

   

VSCode 확장 접근성 검사(axe Accessibility Linter)

VSCode 사용 시 별도 확장 설치 후 소스 코드에서 잘못 작성된 부분을 사전에 감지하여 수정할 수 있습니다.