이 문서는 사용자
에이전트가 웹 콘텐츠 언어의 의미론을 접근성 API에 어떻게 노출해야 하는지를 설명한다. 이는 장애가 있는 사용자가
보조 기술을 사용하여 정보를 얻고 상호작용하는 데 도움이 된다. 이러한
매핑을 문서화하면 접근성 API가 구현하는
역할, 상태, 속성 및 이벤트의 상호운용 가능한 노출을 촉진하고, 이 정보가 작성자의 의도와 일관된 방식으로 나타나도록 보장하는 데 도움이 된다.
이 핵심 접근성 API 매핑 명세는
일반적인 키보드 탐색 지원 및 Web
콘텐츠에서
WAI-ARIA
[WAI-ARIA-1.2]를 통해 제공되는
범용 역할, 상태 및 속성의 매핑을 포함하여 여러 콘텐츠 기술에 걸쳐 적용되는 지원을
정의한다. 다른 접근성 API 매핑 명세는
네이티브 기술 기능 및 WAI-ARIA
확장을 포함한 특정 기술을 위해 이 핵심 명세에 의존하고 이를 확장한다. 이 문서는 핵심 접근성 API 매핑 1.1 [CORE-AAM-1.1] W3C
권고안의 지침을 갱신하며, 최종적으로 이를 대체할 것이다. 이는
WAI-ARIA 개요에서 설명하는
WAI-ARIA 모음의 일부이다.
이 문서의 상태
이 절은 이 문서가
발행된 시점의 상태를 설명한다. 현재 W3C
발행물 목록과 이 기술 보고서의 최신 개정판은
W3C 표준 및 초안
색인에서 찾을 수 있다.
후보 권고안으로 발행되었다고 해서
W3C 및 그 회원들이 이를 승인한다는 의미는 아니다. 후보 권고안 초안은
Working
Group이 이후의 후보 권고안 스냅샷에 포함하려는 이전 후보 권고안의
변경 사항을 통합한다.
이 문서는 초안 문서이며 언제든지 다른
문서로 갱신, 교체 또는 폐기될 수 있다. 진행 중인 작업이 아닌 다른 것으로 이 문서를 인용하는 것은 부적절하다.
이 문서는
W3C
특허
정책에 따라 운영되는
그룹에서 제작하였다.
W3C는
그룹의 산출물과 관련하여 이루어진
모든 특허 공개의 공개 목록을 유지한다.
해당 페이지에는
특허를 공개하기 위한 지침도 포함되어 있다. 개인이
필수 청구항을 포함한다고 믿는
특허에 대한 실제 지식을 가지고 있는 경우, 그 개인은
W3C 특허 정책 제6절에 따라 정보를 공개해야 한다.
WAI-ARIA 저작 실무
가이드는 웹 콘텐츠 개발자가 WAI-ARIA를
사용하여
접근 가능한 리치 인터넷
애플리케이션을 개발하는 방법을 설명한다. 주로 웹 애플리케이션 개발자를 대상으로 하지만 사용자 에이전트 및
보조 기술 개발자에게도 유용한 자세한 조언과 예제를 제공한다.
사용자 에이전트 개발자가 다른 접근성 API를 사용하여 정보를 노출해야 하는 경우,
해당 API가 실행되는 플랫폼의 개발자 및
그 플랫폼의 보조 기술 개발자와 긴밀히 협력할 것이 권장된다.
1.2 접근성 API 비교
다양한 기술적 및 역사적 이유로, 접근성 API는 모두 같은 방식으로 동작하지 않는다.
많은
경우, 각 API가 역할, 상태 및 속성을 보조 기술에 이름 붙이거나
노출하는 방식 사이에는 단순한 일대일 관계가 없다. 다음 하위 절들은 일부 API의 몇
가지 구별되는 특징을 설명한다.
1.2.1 ATK/AT-SPI
MSAA, IAccessible2, UIA 및 AX
API는 각각 콘텐츠와 대화형
구성 요소에 관한 정보를 노출하는 소프트웨어 애플리케이션과 그 정보를 소비하는 보조
기술 모두가 공유하는 API를 정의한다. 반대로 Linux/GNOME은
이러한 공유 인터페이스를 두 측면으로 분리하며, 각 측면은 서로 다른 접근성 API인 ATK 또는 AT-SPI로
표현된다.
ATK는 접근성 정보를 노출하기 위해 소프트웨어가 구현하는 인터페이스를
정의하는 반면, AT-SPI는 활성 애플리케이션에서
접근성 정보를 수집하고 이를 관심 있는 다른 애플리케이션, 일반적으로 보조 기술에 전달하는
데스크톱 서비스이다.
예를 들어, GNOME GUI 툴킷 [GTK]는 각 위젯(메뉴,
콤보박스, 체크박스 등)에 대해 ATK의 관련 측면을 구현하여
GTK 위젯이 자신에 관한 접근성 정보를 노출하도록 한다. 그러면 AT-SPI가
GTK로 구축된 애플리케이션에서 정보를 획득하고 이를 관심 있는 당사자에게 제공한다.
ATK는 구현자에게 가장 관련이 있는 반면, AT-SPI는 소비자에게 관련이 있다. WAI-ARIA
역할, 상태 및 속성 매핑의 맥락에서
사용자 에이전트는 구현자이며 ATK를 사용한다.
보조 기술은 소비자이며 AT-SPI를 사용한다.
1.2.2 UIA (UI Automation)
UI Automation은 애플리케이션 사용자 인터페이스의 모든 요소를 자동화 요소로 표현한다.
자동화 요소는 애플리케이션 접근성 트리의 노드를 형성하며, 자동화 클라이언트가
질의하고, 순회하고, 상호작용할 수 있다.
UI Automation의 중심이 되는 몇 가지 개념은 다음과 같다.
자동화 요소 - 컨트롤과 일부 애플리케이션 콘텐츠는 자동화 요소로 제시된다.
요소 속성 - 자동화 요소에는 모든 자동화 클라이언트가 이해할 수 있는 불특정 방식으로
네이티브 프레임워크 요소 특성을 설명하는 여러 공통 속성이 있다.
아래에 설명된 것처럼 요소 속성 값에 접근하는 몇 가지 방법이 있다.
컨트롤 패턴 - 서로 다른 프레임워크의 일부 공통 상호작용성은 UIA에서
컨트롤 패턴으로 표현되어, 서로 다른 자동화
클라이언트가 공통 프로그래밍 인터페이스를 사용하여 컨트롤과 상호작용할 수 있게 한다.
이벤트 - 다른 접근성 API와 유사하게, 자동화 요소는 자동화 제공자가
중요한 상태 변경을
클라이언트에 알릴 수 있게 하는 다양한 이벤트를 지원한다.
모든 자동화 요소는 IUIAutomationElement 인터페이스에서 상속되며, 특정 컨트롤 패턴에
특화되지 않은 모든 속성은 해당 인터페이스를 통해 질의할 수 있다. UI Automation 요소 속성에 접근하는 방법에는
몇 가지가 있다.
현재 값에 대한 직접 속성 접근자 - Current{PropertyName}, 예:
Name 속성의 경우 IUIAutomationElement::CurrentName
캐시된 속성 접근자 - Cached{PropertyName}, 예:
Name 속성의 경우 IUIAutomationElement::CachedName. 제공자와
클라이언트가 원격 환경에서 사용되는 경우 캐시된 값을 사용하는 것이 선호된다.
GetCurrentPropertyValue와 해당 속성에 대응하는 UIA Property ID 열거 값을 전달하여 현재 값을 얻는 방법, 예:
Name 속성의 경우
IUIAutomationElement::GetCurrentPropertyValue(UIA_NamePropertyId).
GetCachedPropertyValue와 해당 속성에 대응하는 UIA Property ID 열거 값을 전달하여 캐시된 값을 얻는 방법, 예:
Name 속성의 경우
IUIAutomationElement::GetCachedPropertyValue(UIA_NamePropertyId).
특정 UIA 컨트롤 패턴의 속성은 관련 컨트롤 패턴 인터페이스를
사용하여 같은 방식으로 질의된다. Toggle Pattern을 예로 들면, ToggleState 속성을 질의하기 위해
클라이언트는 현재 값을 얻는 데 IUIAutomationTogglePattern::CurrentToggleState 또는
IUIAutomationTogglePattern::GetCurrentPropertyValue(UIA_ToggleToggleStatePropertyId)를 사용할 수 있다.
이 명세의 속성 매핑은 {PropertyName}을 제공하며, 속성 값에 접근하는
모든 구체적인 방법을 명시하지 않는다. 자동화 클라이언트는 특정 요구와 코딩 스타일
관례에 따라 위에서 설명한 관례를 사용하여 현재 값 또는 캐시된 값에 접근할 수 있다.
1.2.3 Android 접근성 API
Android 접근성 서비스와 애플리케이션은 모두 사용자 인터페이스 요소를
AccessibilityNodeInfo 객체의 트리로 표현한다. 접근성 서비스는 이벤트를 받고,
AccessibilityNodeInfo 트리를 순회하며, 속성을 검색하고, 노드에서 동작을 수행한다.
반대로 Android 애플리케이션은 뷰 또는 컴포저블을 구성하거나
AccessibilityNodeProvider를 통해 직접 구성함으로써 AccessibilityNodeInfo 트리를
간접적으로 구축한다. 그런 다음 이후에 이벤트를 발생시키고 동작을 처리한다.
WAI-ARIA 구현자에게 특히
관심 있는 것은 AccessibilityNodeInfo와
AccessibilityEvent의 속성, 동작 및 이벤트로의 매핑이다.
1.2.4 접근 가능한 이름
및 설명
각 플랫폼 접근성 API에는
접근 가능한
이름과
접근 가능한 설명
속성을 접근 가능한 객체에 할당하고 검색하는 방법이 포함되어
있으며,
이 객체는
접근성 트리에서 생성된다. 이러한
속성이 어떻게 구현되고 무엇이라고 불리는지는 API에 따라 달라진다.
예를 들어, MSAA에서는 모든 접근 가능한 객체가
객체의 접근
가능한 이름을 저장하는
accName 속성을 지원한다. 객체가
접근 가능한 설명도 지원하는 경우,
MSAA는 이 속성을 객체의
accDescription 속성에 저장한다.
ATK를 사용하는 소프트웨어는 객체의
accessible-name 및 accessible-description 속성을 읽고 쓸 수 있다. 이어서 AT-SPI는
atspi_accessible_get_name 및
atspi_accessible_get_description 함수를 통해 해당 속성의 값을 질의할 수 있다.
UIA 접근성 트리의 자동화 요소에는
Name 속성이 있다. 객체가
접근 가능한 설명도 지원하는 경우,
UIA는 이 속성을 객체의
FullDescription 속성에 저장한다.
비규범적으로 표시된 절뿐만 아니라 이 명세의 모든 저작 지침, 도식, 예제 및 참고는 비규범적이다.
이 명세의 그 밖의 모든 것은 규범적이다.
이 문서의 핵심 단어 MAY, MUST, MUST
NOT, SHOULD 및 SHOULD NOT은
BCP 14
[RFC2119] [RFC8174]에
설명된 대로 해석되어야 하며, 여기 보인 것처럼 모두
대문자로 나타날 때에만 그렇게 해석된다.
규범적 절은 구현이 이 명세에 적합하기 위해 사용자 에이전트와 보조 기술이 반드시 따라야 하는
요구사항을 제공한다.
비규범적(정보성) 절은 명세를 이해하는 데 유용한 정보를 제공한다. 이러한
절에는 권장 실무의 예제가 포함될 수 있지만, 이 명세에 적합하기 위해
그러한 권장 사항을 따를 필요는 없다.
2.1 WAI-ARIA에서 폐기 예정인 기능
WAI-ARIA 명세는 일부 기능을 폐기 예정으로 나열한다.
이것은 작성자가 그러한 기능을 사용하지 않도록 권장된다는 뜻이지만, 해당 기능이 레거시 콘텐츠에서
여전히 사용될 수 있음이 예상된다. 따라서 사용자 에이전트가
이러한 기능을 접근성 API에 계속 매핑하는 것이 중요하며, 그렇게 하는 것은
이 명세에 대한 준수의 일부이다. 향후 버전의 WAI-ARIA 명세가 이러한 기능을
폐기 예정에서 제거됨으로 변경하면, 해당 기능은 매핑에서도 제거되며 사용자 에이전트는
더 이상 이러한 기능에 대한 지원을 계속하도록 요구받지 않을 것이다.
3. WAI-ARIA를 접근성 API에 매핑
3.1 WAI-ARIA 의미론을
노출하기 위한 일반 규칙
플랫폼 접근성 API에서 지원되는 경우, 사용자 에이전트는 데스크톱 접근성
API의 표준 메커니즘을 통해 WAI-ARIA
의미론을 노출한다. 예를 들어
WAI-ARIA 위젯의 경우, 해당
위젯이 유사한 데스크톱 위젯에서 어떻게 노출되는지를 비교한다. 일반적으로 대부분의
WAI-ARIA 위젯 기능은 접근성
API의 역할, 값, Boolean 상태 및
관계를 통해 노출된다.
WAI-ARIA 1.0 및 1.1과 관련하여,
접근성 API는 한 방향으로만 동작한다.
사용자 에이전트는 접근성 API를 통해
WAI-ARIA
정보(역할, 상태 및 속성)를 게시하고, AT는 같은
API를 사용하여 해당 정보를 얻을 수 있다.
그러나 반대 방향은 지원되지 않는다. WAI-ARIA 1.0 및 1.1은
보조 기술이 WAI-ARIA 정보를 직접 수정하기 위한 메커니즘을
정의하지 않는다.
WAI-ARIA 역할, 상태 및 속성은
이러한 의미론을 가진 네이티브 호스트 언어
요소를 사용할 수 없을 때
의미론적 정보를 추가하기 위한 것이며,
일반적으로 자체 네이티브 의미론이 없는 요소에 사용된다. 또한 의도한 객체와 유사하지만
동일하지는 않은 의미론을 가진 요소에도 사용할 수 있다(예를 들어, 중첩 목록을
트리 구조를 표현하는 데 사용할 수 있다). 이 방법은
WAI-ARIA
구현이 없는 오래된 브라우저를 위한 대체 전략의 일부가 될 수 있거나, 재사용된 요소의 네이티브 표현이 필요한
스타일 및/또는 스크립트의 양을 줄이기 때문일 수 있다. 아래에 설명된 경우를 제외하고, 사용자 에이전트는 MUST
호스트 언어 의미론을 사용하는 대신, 요소를 접근성 API에 어떻게 노출할지를 정의하기 위해
항상 WAI-ARIA 의미론을 사용해야 한다.
호스트 언어에는 역할에 대응하는 암시적
WAI-ARIA 의미론을 가진 기능이 있을 수 있다.
접근성
API에 대응하는 역할이 있는
WAI-ARIA 역할이 제공된 경우, 사용자 에이전트는 MUST
해당 역할이 호스트 언어에 의해 네이티브 요소에서 명시적으로 금지된 속성의
WAI-ARIA 상태 및 속성을 요구하지 않는 한,
네이티브 의미론이 아니라 WAI-ARIA 역할의 의미론을
처리에 사용해야 한다. 역할의 값은 상태와 속성의 값과 같은 방식으로 충돌하지 않으며,
작성자는 일반적으로 재사용되지 않을 요소에 대해서도
WAI-ARIA 역할을 제공할 타당한 이유가 있을 것으로 기대된다.
예를 들어, 스핀 버튼은 대부분의 기본 키보드 지원을 얻기 위해
텍스트 필드(<input type="text">)로 구성되는 경우가 많다. 그러나 네이티브 역할인 “text field”는
스핀 버튼의 추가 기능을 제대로 전달하지 않기 때문에 올바르지 않다. 작성자는 컨트롤이 접근성
API에서 올바르게 매핑되도록
WAI-ARIA 역할
spinbutton(<input type="text" role="spinbutton" ...>)을 추가한다.
접근성 API에 대응하는 역할이 없는
WAI-ARIA 역할이 제공된 경우, 사용자 에이전트는 MAY 네이티브 의미론을
WAI-ARIA 역할에 추가로 노출할 수 있다.
호스트 언어 요소가 네이티브 호스트 언어 의미론이나 그 의미론의 하위 클래스와 동등하지 않은 의미론 또는 구조를 가진
WAI-ARIA 역할로 재정의된 경우,
Allowed Accessibility Child Roles로 지정된 역할을 가진 모든 자식 요소를
presentation 또는
none으로 처리한다.
참고
위의 텍스트는 WAI-ARIA 명세와 약간 다르다.
사용자 에이전트가 네이티브 역할 대신
WAI-ARIA 역할을 노출해야 한다는 요구사항은,
WAI-ARIA 역할에서 접근성
API의 대응하는 역할로 직접 매핑이 있는 경우에만
적용되도록 의도되었다. 그러나 WAI-ARIA 명세에서 해당 요구사항의
문구는
명확하지 않으며, 구현자들에 의해 다르게 해석되어 왔다. 여기서는
요구사항을 명확히 하고, 접근성 API의 역할로
직접 매핑이 없는 경우 사용자 에이전트가 네이티브 의미론을 노출할 수 있음을 나타내는 추가 문장을 더했다.
구현들이 서로 다르기 때문에, 작성자에게는 자체 의미론을 가진 네이티브 요소에 그러한
WAI-ARIA 역할을 추가하지 말도록
WAI-ARIA 저작 실무 가이드에서 권고할 것이다.
WAI-ARIA 상태 및 속성이 같은 암시적
WAI-ARIA 의미론을 가진 호스트 언어 기능에 대응하는 경우,
값이 동기화되지 않으면 문제가 될 수 있다. 예를 들어,
HTML checked 속성과
aria-checked 속성은 서로 충돌하는 값을 가질 수 있다. 따라서 보조 기술에
충돌하는 상태와 속성을 제공하는 것을 방지하기 위해, 호스트 언어는
호스트 언어 요소에서 WAI-ARIA 속성의 사용이
해당 요소의 네이티브 속성과 충돌하는 위치를 명시적으로 선언할 것이다. 호스트 언어가 특정 요소에 대해
WAI-ARIA 속성이
네이티브 속성과 직접적인 의미론적 충돌을 가진다고 선언하는 경우, 사용자
에이전트는 MUST 해당 WAI-ARIA 속성을 무시하고, 대신 같은 암시적 의미론을 가진
호스트 언어 속성을 사용해야 한다.
호스트 언어는 WAI-ARIA로 재정의할 수 없는 기능도 문서화할 수 있다
(이를 “강한 네이티브 의미론”이라고 한다). 이는 암시적
WAI-ARIA 의미론을 가진 기능일 수도 있고,
WAI-ARIA로 의미론이 변경될 경우 처리가
불확실해지는 기능일 수도 있다. 적합성 검사기는
WAI-ARIA 역할이 강한 네이티브 의미론을 가진 요소에 사용될 때
오류나 경고를 표시할 수 있지만, 사용자 에이전트는 요소를
접근성 API에 노출할 때 여전히
WAI-ARIA 역할의 의미론 값을 MUST
사용해야 한다.
3.3 접근성 API 속성에 직접
매핑되지 않는 속성 노출
플랫폼 접근성 API에는
WAI-ARIA에 없는 기능이 있을 수 있다. 마찬가지로
WAI-ARIA는 발행 시점에 접근성
API가 지원하지 않는 기능을 노출한다. 일반적으로 모든
WAI-ARIA 속성과
플랫폼 접근성 API 사이에 일대일 관계가 있는 것은 아니다.
WAI-ARIA 역할, 상태 및 속성이
접근성 API에 직접 매핑되지 않고,
해당 API에
WAI-ARIA 역할, 상태, 속성 및
그 값을 노출하기 위한 메커니즘이 있는 경우, 사용자
에이전트는
MUST 다음과 같이 그 메커니즘을 사용하여
WAI-ARIA 데이터를 노출해야 한다.
IAccessible2 및 ATK/AT-SPI에서는 객체 속성을 사용하여
API에서 직접 지원되지 않는
의미론을 노출한다. 객체 속성은
이름-값 쌍으로,
느슨하게 명시되어 있으며 접근성 API에 특정 인터페이스가 없는 항목을
노출하는 데 매우 유연하다. 예를 들어,
현재 aria-live
속성은 접근성
API에 사용 가능한 그러한 속성이 없기 때문에 객체 속성을 통해 노출될 수
있다.
객체 속성 이름-값 쌍을 노출하기 위한 구체적인 규칙은 이
문서 전반에 설명되어 있으며, 일반적인 경우에 대한 규칙은 상태 및
속성 매핑에 있다.
Microsoft UIA에서는 컨트롤 형식에서 직접
지원되지 않는 의미론을 노출하기 위해 AriaRole 및
AriaProperties 속성을 사용한다.
참고
MSAA는
API에 직접 매핑되지 않는
속성을 노출하기 위한 메커니즘을 제공하지 않으며, 구현자들 사이에서도 이를 어떻게 수행할지에 대한
합의가 없다.
사용자 에이전트는 MUST 이 메커니즘을 통해 전체 역할 문자열도 노출해야 하며,
MAY 접근성 API에 직접 매핑이 있는
경우에도 이 메커니즘을 통해 WAI-ARIA 속성과 값을
노출할 수 있다.
브라우저 구현자는 관련 정보를 노출하기 위한 자신의 API 메서드를 공개적으로 문서화할
것이 권장된다.
이를 통해
보조 기술 개발자가
사용자 기능을 지원하기 위해 해당 API를 사용할 수 있다.
3.4 역할 매핑
플랫폼 접근성 API는 전통적으로 해당
플랫폼의
보조 기술이 기대하는
미리 정의된 역할의 유한한 집합을 가지고 있었고,
하나 또는 두 개의 역할만 노출될 수 있었다. 이와 달리
WAI-ARIA는 여러 역할을 공백으로 구분된
유효한 역할 토큰의 순서 있는 집합으로 지정할 수 있게 한다. 추가 역할은
첫 번째 선택 글꼴 형식이 지원되지 않는 경우 여러 글꼴을 지정하는 개념과 유사한
대체 역할이다.
3.4.1 일반 규칙
사용자 에이전트는 WAI-ARIA 역할 문자열을 노출하는
메커니즘을 API가 지원하는 경우, 그 역할 문자열을
MUST 노출해야 한다. 이를 통해 보조 기술은 역할에 대해 자체적인 추가 처리를
수행할 수 있다.
MSAA:
지원되지 않음. 사용자 에이전트는
MSAA의 accRole 속성에 사용자 지정 역할을
노출해서는 SHOULD
NOT 된다.
IAccessible2: 객체 속성 쌍(xml-roles:"string")으로 노출한다
UIA: AriaRole 속성으로 노출한다.
AriaRole property는 공백을 구분자로 사용하여 보조 역할도 지원할 수 있다.
ATK/AT-SPI: 객체
속성 쌍
(xml-roles:"string")으로 노출한다
3.4.2 계산된 역할
요소의 computedrole은 브라우저 엔진이 계산한 요소의 역할을 나타내는 문자열이다.
computedrole은 주로 개발자
도구와 명세 준수 및 상호운용성 테스트의 목적으로 사용된다.
요소에 역할이 있지만 요구되는 컨텍스트에 포함되어 있지 않은 경우(예를 들어, 역할이
list인 필수 접근성 부모가 없는 고아
listitem), 이는 작성
오류이지만 사용자 에이전트 동작은 단일 규칙으로 명시되어 있지 않다. 대부분의 역할에 대해 사용자
에이전트는 역할을 무시하여 오류를 복구하거나, 구현이 무해하다고 판단한 시나리오에서는 작성자의 의도한 역할을
존중할 수 있다. 엔진이 작성자 역할 오류를 처리하는 방식에서의 이러한 허용성은 [HTML-AAM]과
같은 언어별 매핑
문서에서 재정의될 수 있음에 유의하라.
호스트 언어 요소가 유효하고 추상적이지 않은 역할에 대한 정확하거나 동등한 매핑을 갖지 않는 경우,
관련 접근성 API 매핑
확장 명세는 상호운용성 테스트 목적의 반환 값으로 고유한
computedrole 문자열을 MAY 명시할 수 있다. 예를 들어
[HTML-AAM]의
<video> -> "html-video"가 있다.
그러나 작성자는 토큰이 유효하고 정의된 역할(예:
dpub-chapter)에도 일치하지 않는 한,
role 속성에서 호스트 언어 접두사가 붙은 어떤
computedrole 문자열도(예:
html-video) 사용해서는 MUST NOT 된다. 사용자 에이전트는
추상 역할 토큰이나 유효하지 않은 역할 토큰을 MUST
무시해야 한다.
AXRole: AXTable AXSubrole: <nil> AXColumnHeaderUIElements: columnheader 요소에 대한
포인터 목록 AXHeader: 해당 columnheader 요소를 포함하는 row 또는 group에 대한
포인터 AXRowHeaderUIElements: rowheader 요소에 대한 포인터
목록
지정된 허용 접근성 자식이 있는 객체(예: gridcell 자식이 있는 grid,
listitem 자식이 있는 list)의 경우, 그리고 그 하위 항목이
접근성
트리 안에 있는 경우, 이를 IA2_ROLE_TEXT_FRAME으로 노출한다. 사용자
에이전트는 빈 하위 항목을
접근성
트리에서 제거해야 SHOULD 한다.
UIA
지정된 허용 접근성 자식이 있는 객체(예: gridcell 자식이 있는 grid,
listitem 자식이 있는 list)의 경우, 그리고 그 하위 항목이
접근성
트리 안에 있는 경우, 이를 text 패턴을 사용하여 노출한다. 사용자
에이전트는 빈 하위 항목을
접근성
트리에서 제거해야 SHOULD 한다.
ATK/AT-SPI
지정된 허용 접근성 자식이 있는 객체(예: gridcell 자식이 있는 grid,
listitem 자식이 있는 list)의 경우, 그리고 그 하위 항목이
접근성
트리 안에 있는 경우, 이를 ROLE_SECTION으로 노출한다. 사용자
에이전트는
빈 하위 항목을
접근성
트리에서 제거해야 SHOULD 한다.
지정된 허용 접근성 자식이 있는 객체(예: gridcell 자식이 있는 grid,
listitem 자식이 있는 list)의 경우, 그리고 그 하위 항목이
접근성
트리 안에 있는 경우, 이를 AXGroup으로 노출한다. 사용자 에이전트는
빈 하위 항목을 접근성
트리에서 제거해야 SHOULD 한다.
지정된 허용 접근성 자식이 있는 객체(예: gridcell 자식이 있는 grid,
listitem 자식이 있는 list)의 경우, 그리고 그 하위 항목이
접근성
트리 안에 있는 경우, 이를 IA2_ROLE_TEXT_FRAME으로 노출한다. 사용자
에이전트는 빈 하위 항목을
접근성
트리에서 제거해야 SHOULD 한다.
UIA
지정된 허용 접근성 자식이 있는 객체(예: gridcell 자식이 있는 grid,
listitem 자식이 있는 list)의 경우, 그리고 그 하위 항목이
접근성
트리 안에 있는 경우, 이를 text 패턴을 사용하여 노출한다. 사용자
에이전트는 빈 하위 항목을
접근성
트리에서 제거해야 SHOULD 한다.
ATK/AT-SPI
지정된 허용 접근성 자식이 있는 객체(예: gridcell 자식이 있는 grid,
listitem 자식이 있는 list)의 경우, 그리고 그 하위 항목이
접근성
트리 안에 있는 경우, 이를 ROLE_SECTION으로 노출한다. 사용자
에이전트는
빈 하위 항목을
접근성
트리에서 제거해야 SHOULD 한다.
지정된 허용 접근성 자식이 있는 객체(예: gridcell 자식이 있는 grid,
listitem 자식이 있는 list)의 경우, 그리고 그 하위 항목이
접근성
트리 안에 있는 경우, 이를 AXGroup으로 노출한다. 사용자 에이전트는
빈 하위 항목을 접근성
트리에서 제거해야 SHOULD 한다.
AXRole: AXTable AXSubrole: <nil> AXColumnHeaderUIElements: columnheader 요소에 대한
포인터 목록 AXHeader: 해당 columnheader 요소를 포함하는 row 또는 group에 대한
포인터 AXRowHeaderUIElements: rowheader 요소에 대한 포인터
목록
사용자 에이전트는 MUST 관리되는 상태인 managed statesVISIBLE/INVISIBLE, SHOWING/OFFSCREEN 등을 계산해야
한다.
이는 일반적으로 WAI-ARIA 속성이 없는 일반적인
요소와 같은 방식으로 수행된다.
FOCUSABLE/FOCUSED 상태는 aria-activedescendant의 영향을 받을 수 있다.
사용자 에이전트는 호스트 언어가 명시적
WAI-ARIA 재정의를 허용하는 경우를
제외하고, WAI-ARIA 상태 및 속성 의미론에
더하여 네이티브 의미론을 계속 노출해야 MUST 한다.
예를 들어, HTML 체크박스는
aria-labelledby 속성을
가질 수 있지만, 네이티브 HTML 의미론은 여전히
노출되어야 한다.
사용자 에이전트는 역할 매핑 표에 정의된 대로 특정
역할에 대한 추가 상태를 노출해야 MUST 한다.
사용자 에이전트는 관련 WAI-ARIA 속성에 대한
상태를 계산하고, 접근성 API에
상태 및 속성 매핑 표에 명시된 대로 매핑해야
MUST 한다. 관련
WAI-ARIA 속성을 결정하려면
역할의
정의 [WAI-ARIA-1.2]]를
참조하라. 작성자가 필수 속성에 대한 값을 제공하지 않은 경우, 사용자 에이전트는 기본값이 제공된 것처럼
처리해야 SHOULD 한다.
일부 WAI-ARIA 속성은 전역이 아니며,
특정 역할에서만 지원된다. 전역이 아닌
WAI-ARIA 상태 또는 속성이 지원되지 않는
위치에서 사용된 경우, 사용자 에이전트는 주어진
WAI-ARIA 속성을 플랫폼 접근성
API에 매핑하지 않아야
SHOULD NOT 한다. 예를 들어,
aria-checked="true"가 <div role="grid">에 지정된 경우, 이는
MSAA 구현에서
STATE_SYSTEM_CHECKED로 노출되어서는 안 된다.
표에는 주어진 상태 또는 속성이 "매핑되지 않음"으로 선언되는 경우가 여러 번 있다. 어떤 경우에는
이것이 상태/속성의 기본값에 대해 발생하며, 그 부재와 동등하다. 사용자 에이전트는
그것이 기본값인지 확인하는 것보다 값을 매핑하는 것이 더 빠르다고 판단할 수 있다. 계산 효율성을 위해,
그렇게 하는 것이 매핑하지 않는 것과 동등하다면 사용자 에이전트는 MAY
상태 또는 속성 값을 노출할 수 있다. 이러한 경우는 별표로 표시된다.
다른 경우에는 상태/속성을 매핑하지 않는 것이 필수적이다. 이를 노출하면 관련된 어포던스가
암시되기 때문이다. 예는
aria-grabbed이다.
그 부재는 접근 가능한 객체가 잡혀 있지 않음을 나타낼 뿐만 아니라, 더 나아가 그것이
잡을 수 없는 것임을 정의한다. 이러한 경우는 별표 없이 "매핑되지 않음"으로 표시된다.
객체 속성: atomic:true 객체 속성:
container-atomic:true 객체 속성: 모든
자손에 container-atomic:true 관계: 이 요소(atomic root)를 가리키는
IA2_RELATION_MEMBER_OF 참조: 문서 콘텐츠 또는
노드 가시성 변경
객체 속성: atomic:true 객체 속성:
container-atomic:true 객체 속성: 모든
자손에 container-atomic:true 관계: 이
요소(atomic root)를 가리키는 RELATION_MEMBER_OF 참조: 문서 콘텐츠 또는
노드 가시성 변경
매핑되지 않음*, 그러나
매핑하는 경우: 객체 속성: atomic:false 객체 속성:
container-atomic:false 객체 속성: 모든
자손에 container-atomic:false 관계: 이 요소(atomic root)를 가리키는
IA2_RELATION_MEMBER_OF 참조: 문서 콘텐츠 또는
노드 가시성 변경
매핑되지 않음*, 그러나
매핑하는 경우: 객체 속성: atomic:false 객체 속성:
container-atomic:false 객체 속성: 모든
자손에 container-atomic:false 관계: 이
요소(atomic root)를 가리키는 RELATION_MEMBER_OF 참조: 문서 콘텐츠 또는
노드 가시성 변경
속성: accDescription:
<value> 관계: 참조된 객체가 접근성 트리 안에 있는 경우,
IA2_RELATION_DESCRIBED_BY는 IDREF와 일치하는 접근 가능한
노드를 가리킴 역방향 관계: IA2_RELATION_DESCRIPTION_FOR는
요소를 가리킴 참조: 이름
계산 및 추가
관계 매핑
속성: Description:
<value> 관계: 참조된 객체가 접근성 트리 안에 있는 경우,
RELATION_DESCRIBED_BY는 IDREF와 일치하는 접근 가능한
노드를 가리킴 역방향 관계: RELATION_DESCRIPTION_FOR는
요소를 가리킴 참조: 이름
계산 및 추가
관계 매핑
AX API
accessibilityCustomContent API에서
{ label: "description" }를 가진
AXCustomContent 객체로 노출하고, `value`를 설명
문자열로 설정한다.
- 참조: 이름
계산
속성: accName:
<value> 관계: 참조된 객체가 접근성 트리 안에 있는 경우,
IA2_RELATION_LABELLED_BY는 IDREF와 일치하는 접근 가능한 노드를
가리킴 역방향 관계: IA2_RELATION_LABEL_FOR는
요소를 가리킴 참조: 이름
계산 및 추가
관계 매핑
UIA
속성: Name:
<value> 속성: LabeledBy: 참조된 객체가 접근성
트리 안에 있는 경우, IDREF와 일치하는 접근 가능한 노드를 가리킴 참조: 이름
계산
ATK/AT-SPI
속성: Name:
<value> 관계: 참조된 객체가 접근성 트리 안에 있는 경우,
RELATION_LABELLED_BY는 IDREF와 일치하는 접근 가능한 노드를
가리킴 역방향 관계: RELATION_LABEL_FOR는
요소를 가리킴 참조: 이름
계산 및 추가
관계 매핑
AX API
속성: AXTitle:
<value> 속성: AXTitleUIElement는 접근성
트리 안에 있는 참조된 요소가 하나인 경우, IDREF와 일치하는 접근 가능한
노드를 가리킴 참조: 이름
계산
속성: Value.IsReadOnly: true,
요소가
IValueProvider를
구현하는 경우. 속성: RangeValue.IsReadOnly:
true, 요소가
IRangeValueProvider를
구현하는 경우. 속성: AriaProperties.readonly:
true
ATK/AT-SPI
상태: STATE_READ_ONLY 상태: 텍스트 입력 역할에서 STATE_EDITABLE 노출되지
않음 상태: aria-checked를
지원하는 역할에서 STATE_CHECKABLE 노출되지 않음 상태: radiogroup에 사용된 경우 radio 자손에서
STATE_CHECKABLE 노출되지 않음
속성: Value.IsReadOnly: false,
요소가
IValueProvider를
구현하는 경우. 속성: RangeValue.IsReadOnly:
false, 요소가
IRangeValueProvider를
구현하는 경우. 속성: AriaProperties.readonly:
false
어떤 요소의 ID가 다른 요소 안의 속성에 의해 참조될 때
역방향 관계가 존재한다. 역방향 관계를 지원하는
API의 경우, 어떤 요소의 ID가 다른
요소의 관계 속성에 의해 참조되고 참조된 요소가 접근성 트리 안에 있으면, 사용자 에이전트는
상태 및 속성 매핑 표에 정의된 매핑을 사용해야
MUST 한다. 모든 WAI-ARIA 참조는 접근성 트리 안에서
접근 가능한 객체로 노출되는 요소를 가리켜야 한다. 참조된 객체가 접근성 트리 안에 노출되지 않은 경우
(예: 숨겨져 있기 때문),
참조는 null이다. aria-labelledby 및 aria-describedby에는 추가
기능이 있으며,
이 기능은 참조된 요소에서 평탄화된 문자열을 가져와 접근성
API의 이름 또는 설명 필드를 채울 수
있게 한다. 이 기능은
이름 및 설명 절에 설명되어 있다.
특수 사례: aria-labelledby와
HTML
<label for= … >가 모두 사용된 경우, 사용자 에이전트는
WAI-ARIA 관계를 사용해야
MUST 하며
HTML label 관계를 무시해야
MUST 한다.
aria-describedby는 사용자가
콘텐츠의 여러
섹션으로 이동하기를 원하는 구조화된 정보 또는 상호작용 정보를 참조할 수 있다는 점에 유의하라.
사용자 에이전트는
aria-describedby가
참조하는 구조화된 정보로 사용자가 이동할 수 있는 방법을 제공할 수 MAY
있으며, 보조 기술은 그러한 방법을
제공해야 SHOULD 한다.
3.6.2.2 암시적 역방향
관계
WAI-ARIA 속성으로 정의된 명시적
관계 외에도, 두 가지 다른 상황에서 역방향 관계가 암시된다:
조상이
aria-owns 속성을 갖지 않는
role="treeitem"을 가진 요소와,
aria-atomic
속성을 가진 요소의 자손이다.
현재 treeitem이 aria-level을
사용하는 경우, 더 낮은
aria-level을
가진 treeitem을 찾을 때까지 트리에서 뒤로 이동한
다음,
RELATION_NODE_CHILD_OF를 그 요소로 설정한다. 트리의 맨 위에 도달한 경우,
RELATION_NODE_CHILD_OF를 트리 요소 자체로 설정한다.
aria-level이
treeitem 또는 comment역할의 요소에 제공되거나 상속되지 않은 경우,
IAccessible2 또는 ATK/AT-SPI를 구현하는 사용자 에이전트는
명시적 또는 계산된 RELATION_NODE_CHILD_OF 관계를 따라 이를 계산해야
MUST 한다.
이러한 값은 1 기반이므로, 계산에 현재 항목을 포함한다. aria-posinset의 경우,
현재 항목과, DOM에서 현재 항목보다 앞에 있는 경우 다른 그룹 항목을
포함한다. aria-setsize의 경우, 여기에
DOM에서
현재 항목 뒤에 있는 같은 그룹의 항목 수를 더한다.
작성자가 aria-setsize 및 aria-posinset 중 하나 이상을 제공하는 경우,
집합 안의 모든 요소에 이를 제공하는 것은 작성자의 책임이다. 이 경우 사용자 에이전트가 누락된 값을
보정하는 것은 정의되지 않는다.
문서 변경 처리는 WAI-ARIA와 관계없이 중요하다. 아래 표에 설명된
이벤트는 사용자 에이전트가 접근성 트리를 통해 DOM의 변경을 AT에 알리는 데 사용된다. 이 표준에 대한 적합성 목적상,
사용자
에이전트는 웹 페이지의 동적 콘텐츠에 WAI-ARIA 속성이
적용될 때마다 이 절에
설명된 동작을 구현해야 MUST 한다.
각 API에서 발생시켜야 하는 문서 변경 시나리오 및
이벤트 표
시나리오
MSAA + IAccessible2 이벤트
UIA 이벤트
ATK/AT-SPI 이벤트
AX API 알림
텍스트가 제거될 때
IA2_EVENT_TEXT_REMOVED
EVENT_OBJECT_LIVEREGIONCHANGED
text_changed::delete
라이브 영역 안에 있는 경우
AXLiveRegionChanged. aria-errormessage 안에 있는 경우,
AXValidationErrorChanged.
텍스트가 삽입될 때
IA2_EVENT_TEXT_INSERTED
EVENT_OBJECT_LIVEREGIONCHANGED
text_changed::insert
라이브 영역 안에 있는 경우
AXLiveRegionChanged. aria-errormessage 안에 있는 경우,
AXValidationErrorChanged.
텍스트가 변경될 때
IA2_EVENT_TEXT_REMOVE 및 IA2_EVENT_TEXT_INSERTED
EVENT_OBJECT_LIVEREGIONCHANGED
text_changed::delete 및 text_changed::insert
라이브 영역 안에 있는 경우
AXLiveRegionChanged. aria-errormessage 안에 있는 경우,
AXValidationErrorChanged.
문제의 노드가 요소이며 접근 가능한 객체를 가진 경우의 노드
변경에 대해서는 다음 이벤트를 발생시킨다. 노드의
접근성 하위트리는 접근 가능한 객체가
접근성
트리 안에 있는 것과, 그 모든
접근성
자손이다. 여기에는
그 트리에서 부모-자식 외의 관계를 가진 객체는 포함되지 않는다. 예를 들어, 그러한 객체가
aria-flowto를 통해 연결되어 있더라도 접근성 트리의 자손이기도 한 경우가
아니라면 포함되지 않는다.
EVENT_OBJECT_HIDE
MSAA 이벤트인
EVENT_OBJECT_DESTROY는 안정성 문제의 이력이 있고 보조 기술이 이를 피하기 때문에
사용되지 않는다. 어쨌든 사용자의 관점에서는 어떤 것이 숨겨진 것과 파괴된 것 사이에 차이가 없다.
AutomationElement..::.StructureChangedEvent
children_changed::remove
AXUIElementDestroyed
라이브 영역 안에 있는 경우, AXLiveRegionChanged
접근성 하위트리가 제거될 때
EVENT_OBJECT_REORDER
MSAA 이벤트인
EVENT_OBJECT_DESTROY는 안정성 문제의 이력이 있고 보조 기술이 이를 피하기 때문에
사용되지 않는다. 어쨌든 사용자의 관점에서는 어떤 것이 숨겨진 것과 파괴된 것 사이에 차이가 없다.
AutomationElement..::.StructureChangedEvent
children_changed::remove
AXUIElementDestroyed
라이브 영역 안에 있는 경우, AXLiveRegionChanged
접근성 하위트리가 표시될 때
EVENT_OBJECT_SHOW
children_changed::add
AXUIElementCreated
라이브 영역 안에 있는 경우, AXLiveRegionChanged
접근성 하위트리가 삽입될 때
EVENT_OBJECT_REORDER
children_changed::add
AXUIElementCreated
라이브 영역 안에 있는 경우, AXLiveRegionChanged
접근성 하위트리가 이동될 때
한 위치에서의 제거 및 다른 위치로의 삽입으로 처리한다
한 위치에서의 제거 및 다른 위치로의 삽입으로 처리한다
한 위치에서의 제거 및 다른 위치로의 삽입으로 처리한다
AXUIElementDestroyed/ AXUIElementCreated
라이브 영역 안에 있는 경우, AXLiveRegionChanged
접근성 하위트리가 변경될 때(예: replaceNode)
제거 및 삽입으로 처리한다
제거 및 삽입으로 처리한다
제거 및 삽입으로 처리한다
AXUIElementDestroyed/ AXUIElementCreated
라이브 영역 안에 있는 경우, AXLiveRegionChanged
어떤 경우에는 노드가 요소가 아니거나 접근 가능한 객체가 없는 곳에서 노드 변경이 발생할 수 있다.
예를 들어, 번호 매기기 목록의 불릿("12.")은 접근성 트리에는 노드가 있을 수 있지만
DOM 트리에는 없을 수 있다. HTML에서 <strong>으로 표시된 단락 안의
텍스트의 경우, <strong> 요소는 DOM 트리에는 노드가 있지만
접근성 트리에는 없을 수 있다.
텍스트 자체는 물론 접근성 트리 안에 있으며, strong으로 서식 지정된 텍스트 범위의 식별도 함께 있다.
위 표에 설명된 변경 중 하나가 그러한 노드에서 발생하는 경우, 사용자 에이전트는 위에 설명된 관련 텍스트
변경 이벤트를 계산하고 발생시켜야 SHOULD 한다.
사용자 에이전트는 프로세스 안에서 실행 중인 보조 기술이 노드가 제거되기 전에 제거 알림을 받을 수 있도록
해야 SHOULD 한다. 이를 통해 스크린 리더와 같은 보조 기술은 삭제되는 해당
DOM 노드를 다시 참조할 수 있다. 이는 제거가 중요한 라이브 영역에서 중요하다. 예를 들어,
스크린 리더는 다른 사용자가 채팅방을 나갔음을 사용자에게 알리고자 할 수 있다.
MSAA의 이벤트는 EVENT_OBJECT_HIDE가 된다.
ATK/AT-SPI에서는
children_changed::remove가 된다. macOS에서는 이벤트가
AXLiveRegionChanged이다. 또한 이를 위해 사용자 에이전트는 제거되는 고유한 노드를 식별하는
고유 ID를
접근성 API 알림에 제공해야 한다.
위에 언급한 변경 이벤트를 발생시킬 때, 해당 변경이 사용자 입력으로 인해 발생했는지(페이지 로드에서 시작된
timeout 등과 반대로)에 대한 정보를 제공하는 것은 매우 유용하다. 이를 통해 보조 기술은 사용자 동작으로
인한 변경과 실제 세계에서 비롯된 변경을 서로 다른 규칙으로 표시할 수 있다. 마우스 호버는 마우스를
우발적으로 건드려 발생할 수 있으므로 명시적 사용자 입력으로 간주되지 않는다.
변경이 사용자 입력으로부터 발생했는지를 노출하려면:
ATK/AT-SPI에서는 사용자가 변경을
일으키지 않은 경우 이벤트 이름에 문자열
":system"을 추가하여 제공할 수 있다.
스크린 리더가 일반적으로 같은 스레드의 프로세스 안에서 접근하는 IAccessible2에서는 사용자가 변경을
일으킨 경우 이벤트에 대한 접근 가능한 객체에 객체 속성 event-from-user-input:true를
노출하는 것이 모범 사례이다.
변경의 맥락에 대한 추가적인 유용한 정보 노출:
ATK/AT-SPI 및 IAccessible2에서,
접근성 이벤트의 대상 접근 가능한 객체에 있는
RELATION_MEMBER_OF 관계는
aria-atomic="true"를
가진 조상(있는 경우)을 가리켜야 SHOULD 한다.
ATK/AT-SPI 및 IAccessible2에서,
container-live,
container-relevant, container-busy, container-atomic
객체 속성은 접근성 이벤트 객체에 노출되어야 SHOULD 하며, 관련
WAI-ARIA 속성에 대한 계산된 값을
제공한다. 계산된 값은 가장 가까운 조상의 값이다. 기본값이 사용되는 경우에는 객체 속성을 노출하지 않는
것이 권장된다.
추가 MSAA 이벤트가 필요할 수 있다:
ROLE_SYSTEM_ALERT의 매핑된 MSAA 역할을
가진 조상 안에서 어떤 것이 변경되는 경우,
alert에 대해
EVENT_SYSTEM_ALERT 이벤트를 발생시켜야 SHOULD 한다.
alert 역할은
aria-live
속성에 대해 "assertive"라는 암시적 값을 가진다.
현재 상태는
IUIAutomationElement::CurrentIsKeyboardFocusable에 반영되며,
UIA_IsKeyboardFocusablePropertyId 속성 식별자를 사용하여
IUIAutomationElement::GetCurrentPropertyValue 메서드로 검색할 수 있다.
현재 상태는 IUIAutomationElement::CurrentHasKeyboardFocus에 반영되며,
UIA_HasKeyboardFocusPropertyId 속성 식별자를 사용하여
IUIAutomationElement::GetCurrentPropertyValue 메서드로 검색할 수 있다.
STATE_FOCUSED
boolean AXFocused
포커스 이벤트
EVENT_OBJECT_FOCUS
클라이언트는 IUIAutomationFocusChangedEventHandler 콜백 인터페이스를 사용하여
IUIAutomation::AddFocusChangedEventHandler로 구독할 수 있다
사용자 에이전트는
EVENT_OBJECT_SELECTIONWITHIN을 발생시킬 수 MAY 있다.
이 이벤트가 발생된 경우, 위에 언급된 다른 이벤트는 성능을 위해 생략될 수 MAY 있다.
선택되거나 선택 해제된 각 요소에 대해 현재 컨테이너에서 SelectionItem 컨트롤
패턴: UIA_SelectionItem_ElementAddedToSelectionEventId 또는
UIA_SelectionItem_ElementRemovedFromSelectionEventId를 발생시킨다. 사용자 에이전트는
Selection 컨트롤 패턴 Invalidated 이벤트를 발생시키도록 선택할 수 MAY 있으며, 이는 컨테이너
안의 선택이 크게 변경되어
InvalidateLimit 상수가 허용하는 것보다 더 많은 추가 및 제거 이벤트를 보내야 함을
나타낸다.
사용자 에이전트는 성능을 위해 여러 이벤트 대신 컨테이너에서 단일
object:selection-changed 이벤트를 발생시킬 수 MAY
있다.
선택이 변경된 모든 자손 접근 가능한
객체에서
object:state-changed:selected:
일부 API는 메뉴가 열리거나 닫힐 때마다 특수
이벤트를 제공한다. 사용자 에이전트는 아래 표에
설명된 이벤트를 제공해야 SHOULD 한다. 제공되는 경우, 메뉴는 다양한 기법을 사용하여 표시되거나 숨겨질 수 있으므로, 사용자
에이전트는 이벤트가 중첩되고 대칭적이도록 보장해야 MUST 한다.
흔히 menubar는 메뉴 계층을 구성하는 데
사용된다. 이러한 경우, menubar는 연결된 menuitem들의
DOM 부모이거나, aria-owns로 정의된 부모여야 MUST 한다.
다른 경우에는 menubar가 관여하지 않는다. 예를 들어, menu가
toolbar 버튼과 연결되어 있거나 컨텍스트 메뉴인 경우가 그렇다.
그럼에도 관련 메뉴 이벤트는 다음 표에 설명된 대로 제공된다.
메뉴 이벤트
시나리오
MSAA
Microsoft UIA
AX API
menubar가 현재 활성 상태가 아니며, 사용자가 다른 곳에서 menubar로 포커스를 이동하여 이를
활성화한다. 그 결과 menubar 안의 menuitem이 포커스된다.
menubar를 활성화하고 menubar의 접근 가능한 객체에서 EVENT_SYSTEM_MENUSTART를
발생시킨다.
메뉴의 접근 가능한 객체에서 MenuModeStartEvent.
AXMenuOpenedNotification
menubar가 활성화되어 있는 동안 menuitem에 포커스하거나, menu 안의 menuitem에 포커스한다.
EVENT_OBJECT_FOCUS
AutomationFocusChangedEvent
AXMenuItemSelectedNotification
메뉴 팝업이 표시됨(menu가 열림).
메뉴가 닫혔다가 다시 열릴 때까지 한 번만 발생해야 한다.
EVENT_SYSTEM_MENUPOPUPSTART
MenuOpenedEvent, 그 다음 menuitem에서 focus 이벤트.
AXMenuOpenedNotification
메뉴 팝업이 숨겨짐(menu가 닫힘).
접근 가능한 menu 객체에 대해 한 번만 EVENT_SYSTEM_MENUPOPUPEND, 그리고
EVENT_SYSTEM_MENUPOPUPSTART가 그것에 대해 발생된 경우에만.
MenuClosedEvent
AXMenuClosedNotification
하위 메뉴를 포함한 열린 모든 메뉴가 닫히고, 사용자가 menubar 밖으로 포커스를 이동한다;
menubar가 비활성화된다.
priority가 "high"이면 mapped_priority를
NotificationProcessing_ImportantAll로, 그렇지 않으면
NotificationProcessing_All로 둔다.
node, NotificationKind_ActionCompleted,
mapped_priority, announcement, 및 빈 문자열을 사용하여
UiaRaiseNotificationEvent를 호출한다.
참고
플랫폼 접근성 구현이 node가 UIA
Control
view 또는
Content
view에 표시되지 않는다고 판단하는 경우, 사용자 에이전트는 대신
UIA Control로 표시되는
가장 가까운 조상에서 알림 이벤트를 발생시켜야 SHOULD 한다.
그러한 조상이 없으면, 사용자 에이전트는 Control 또는 Content view에 없는 요소의 이벤트를 무시하는
보조 기술도 알림을 받을 수 있도록 문서 루트(이러한 view 중 하나에 있을 것으로 예상됨)에서
이를 발생시켜야 SHOULD 한다.
ATK
priority가 "high"이면 mapped_priority를
Atk.Live.ATK_LIVE_ASSERTIVE로, 그렇지 않으면
Atk.Live.ATK_LIVE_POLITE로 둔다.
node, "notification", announcement, 및
mapped_priority를 사용하여 g_signal_emit_by_name을
호출한다.
ATK 2.50.0 이전의 오래된 Linux 접근성 스택에서는
사용자 에이전트가 fallback을 사용할 수 MAY 있다. fallback 참고를 참조하라.
AT-SPI
priority가 "high"이면 mapped_priority를
ATSPI_LIVE_ASSERTIVE로, 그렇지 않으면 ATSPI_LIVE_POLITE로
둔다.
node, "announcement", announcement, 및
mapped_priority를 사용하여 DBUS 신호
ATSPI_DBUS_INTERFACE_EVENT_OBJECT를 보낸다.
AX API
priority가 "high"이면 mapped_priority를
NSAccessibilityPriorityHigh로, 그렇지 않으면
NSAccessibilityPriorityMedium으로 둔다.
userInfo를 다음 키를 가진 NSDictionary로 둔다:
NSAccessibilityAnnouncementKey를 announcement로
NSAccessibilityPriorityKey를 mapped_priority로
node,
NSAccessibilityAnnouncementRequestedNotification, 및
userInfo를 사용하여
NSAccessibilityPostNotificationWithUserInfo를
호출한다.
참고
적절한 플랫폼 알림 API를 사용할 수 없는 경우(예: 더 새로운 알림
신호가 없는 ATK 2.50.0 이전의 오래된 Linux 접근성 스택,
또는 Windows에서 사용자 에이전트가 UIA를 사용할 수 없는
경우), 사용자 에이전트는 aria notify 알림을 전달하기 위해 접근성 트리에 임시의
보조 기술 전용 라이브 영역을 합성할 수 MAY 있다. 이러한
fallback 노드는 웹 콘텐츠에 노출되거나 웹 콘텐츠에서 감지될 수 없으며, 이 동작은 필수가 아니다.
5. 개인정보 보호 고려사항
Web Platform
Design Principles에 따라, 이 명세는 정보가 보조 기술에 의해 사용되고 있는지를 판별하는 프로그래밍 방식의
인터페이스를 제공하지 않는다. 그러나 이 명세는 작성자가 보조 기술 사용자에게, 보조 기술을 사용하지 않는 사용자에게
제공되는 정보와 다른 정보를 표시할 수 있도록 허용한다. 이는 ARIA 및 CORE-AAM 명세의 여러 기능을 사용하여
가능하며, 웹 기술 스택의 다른 많은 부분을 사용해서도 가능한 것과 같다. 이러한 콘텐츠 불일치는 보조 기술 사용자의
능동적 핑거프린팅을 수행하는 데
악용될 수 있다.
이 출판물은 부분적으로 미국 교육부, National Institute on Disability, Independent Living, and Rehabilitation Research
(NIDILRR)의 미국 연방 기금으로 지원되었으며, 초기에는 계약 번호 ED-OSE-10-C-0067, 그 다음에는 계약 번호
HHSP23301500054C, 현재는 HHS75P00120P00168에 따라 지원되었다. 이 출판물의 내용이 반드시 미국 교육부의
견해나 정책을 반영하는 것은 아니며, 상표명, 상업 제품 또는 조직의 언급이 미국 정부의 승인을 의미하지도 않는다.