4.1.2 이름, 역할, 값

(Level A)

요약

목표

보조 기술을 사용하는 사용자는 모든 구성요소를 이해한다.

할 일

구성요소에 올바른 이름, 역할, 상태, 값을 지정해야 한다.

중요성

보조 기술은 코드가 적절하게 작성되어야만 제대로 동작한다.

성공 기준(SC)

모든 사용자 인터페이스 구성요소(폼 요소, 링크, 스크립트로 생성된 구성요소 등을 포함하지만 이에 한정되지 않음)에 대해

• 이름(name)과 역할(role)은 프로그래밍 방식으로 판별 가능해야 한다.

• 사용자가 설정할 수 있는 상태(states), 속성(properties), 값(values)은 프로그래밍 방식으로 설정 가능해야 한다.

• 이러한 항목의 변경 사항은 사용자 에이전트(보조 기술 포함)에 제공되어야 한다.

  참고

  이 성공 기준은 주로 자체 사용자 인터페이스 구성요소를 개발하거나 스크립트로 구현하는 웹 저작자를 대상으로 한다. 예를 들어, 표준 HTML 컨트롤은 명세에 맞게 사용할 경우 이 성공 기준을 이미 충족한다.

의도

이 성공 기준의 목적은 보조 기술(AT)이 콘텐츠 내 사용자 인터페이스 컨트롤에 대해 적절한 정보를 수집하고, 이를 활성화(또는 설정)하며, 상태 변화를 지속적으로 파악할 수 있도록 보장하는 데 있다.

접근성 기술의 표준 컨트롤을 사용하는 경우, 이 과정은 비교적 단순하다. 사용자 인터페이스 요소를 명세에 따라 사용하면 이 조항의 조건은 충족된다. (아래 성공 기준 4.1.2의 예시 참고)

그러나 사용자 정의 컨트롤을 생성하거나, 인터페이스 요소의 일반적인 역할 및 기능과 다른 동작을 하도록 코드나 스크립트로 프로그래밍하는 경우에는 추가적인 조치가 필요하다. 이때 컨트롤은 보조 기술에 중요하고 적절한 정보를 제공해야 하며, 보조 기술을 통해 제어될 수 있어야 한다.

어떤 역할(role)과 상태(state)를 보조 기술에 전달해야 하는지는 해당 컨트롤이 무엇을 나타내는지에 달려있다. 이러한 정보의 세부 사항은 WAI-ARIA와 같은 별도의 명세나 관련 플랫폼 표준에서 정의된다. 또한 명세된 정보가 실제 보조 기술에서 충분히 접근성 지원을 받는지도 고려해야 한다.

사용자 인터페이스 컨트롤에서 특히 중요한 상태는 초점(focus) 여부이다. 컨트롤의 초점 상태는 프로그램적으로 판별 가능해야 하며, 초점의 변경이 사용자 에이전트와 보조 기술에 전달되어야 한다. 그 밖의 사용자 인터페이스 컨트롤 상태의 예시로는 체크박스나 라디오 버튼의 선택 여부나, 확장/축소 가능한 트리 뷰 또는 아코디언의 펼침/접힘 상태가 있다.

참고

성공 기준 4.1.2는 모든 사용자 인터페이스 구성요소에 대해 프로그램적으로 판별 가능한 이름을 요구한다. 이름은 시각적으로 표시될 수도 있고 표시되지 않을 수도 있다. 이름이 시각적으로 표시되는 경우 이를 레이블(label)이라 한다. 자세한 내용은 용어집의 이름(name) 및 레이블(label) 정의를 참고한다.

이점

• 모든 사용자 인터페이스 구성요소에 역할, 상태, 값 정보를 제공하면 장애인이 사용하는 스크린 리더, 화면 확대기, 음성 인식 소프트웨어와 같은 보조 기술과의 호환성이 확보된다.

예제

접근성 API

Java 애플릿이 해당 언어에서 정의한 접근성 API를 사용한다.

관련 자료

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

• Dynamic Accessible Web Content Roadmap
• Role Taxonomy for Accessible 적응 가능성 Applications
• Web Accessibility Initiative - Accessible Rich Internet Applications (ARIA)

기법

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

충분 기법

아래에서 귀하의 콘텐츠와 일치하는 상황을 선택하라. 각 상황에는 해당 상황에 충분하다고 알려져 있고 문서화된 기법 또는 기법의 조합이 포함된다.

상황 A: If using a standard user interface component in a markup language (e.g., HTML):

• ARIA14: Using aria-label to provide an invisible label where a visible label cannot be used
• ARIA16: Using aria-labelledby to provide a name for user interface controls
• G108: Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes using technology-specific techniques below:
  • H91: Using HTML form controls and links
  • H44: Using label elements to associate text labels with form controls
  • H64: Using the title attribute of the iframe element
  • H65: Using the title attribute to identify form controls when the label element cannot be used
  • H88: Using HTML according to spec

상황 B: If using script or code to re-purpose a standard user interface component in a markup language:

• Exposing the names and roles, allowing user-settable properties to be directly set, and providing notification of changes using one of the following techniques:
  • ARIA16: Using aria-labelledby to provide a name for user interface controls

상황 C: If using a standard user interface component in a programming technology:

• G135: Using the accessibility API features of a technology to expose names and notification of changes using technology-specific techniques below:
  • PDF10: Providing labels for interactive form controls in PDF documents
  • PDF12: Providing name, role, value information for form fields in PDF documents

상황 D: If creating your own user interface component in a programming language:

• G10: Creating components using a technology that supports the accessibility notification of changes using technology-specific techniques below:
  • ARIA4: Using a WAI-ARIA role to expose the role of a user interface component
  • ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface component
  • ARIA16: Using aria-labelledby to provide a name for user interface controls

오류

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

• F59: Failure of Success Criterion 4.1.2 due to using script to make div or span a user interface control in HTML without providing a role for the control
• F15: Failure of Success Criterion 4.1.2 due to implementing custom controls that do not use an accessibility API for the technology, or do so incompletely
• F20: Failure of Success Criterion 1.1.1 and 4.1.2 due to not updating text alternatives when changes to non-text content occur
• F68: Failure of Success Criterion 4.1.2 due to a user interface control not having a programmatically determined name
• F79: Failure of Success Criterion 4.1.2 due to the focus state of a user interface component not being programmatically determinable or no notification of change of focus state available
• F86: Failure of Success Criterion 4.1.2 due to not providing names for each part of a multi-part form field, such as a US telephone number
• F89: Failure of Success Criteria 2.4.4, 2.4.9 and 4.1.2 due to not providing an accessible name for an image which is the only content in a link

점검 규칙

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

• ARIA attribute is defined in WAI-ARIA
• ARIA state or property has valid value
• Button has non-empty accessible name
• Element with aria-hidden has no content in sequential focus navigation
• Element with presentational children has no focusable content
• Form field has non-empty accessible name
• Image button has non-empty accessible name
• Link has non-empty accessible name
• Menuitem has non-empty accessible name
• Role attribute has valid value
• ARIA required ID references exist
• ARIA state or property is permitted
• Element with role attribute has required states and properties
• Iframe element has non-empty accessible name
• Iframe elements with identical accessible names have equivalent purpose