This document describes how [=user agents=] should expose semantics of PDF content to accessibility APIs. This helps users with disabilities to obtain and interact with information using assistive technologies. Documenting these mappings promotes interoperable exposure of roles, states, properties, and events implemented by accessibility APIs and helps to ensure that this information appears in a manner consistent with author intent.

The Accessible Rich Internet Applications Working Group seeks feedback on any aspect of the specification. When submitting feedback, please consider issues in the context of the companion documents. To comment, file an issue in the W3C pdf-aam GitHub repository. If this is not feasible, send email to public-aria@w3.org (comment archive). In-progress updates to the document may be viewed in the publicly visible editors' draft.

Introduction

TBD. Some from Core-AAM.

Accessibility APIs

TBD. Should we duplicate or cross-reference this content from the corresponding Core-AAM section?

Comparing Accessibility APIs

TBD. Should we duplicate or cross-reference this content from the corresponding Core-AAM section?

Accessible Names and Descriptions

TBD. Should we duplicate or cross-reference this content from the corresponding Core-AAM section?

RFC-2119 Keywords

RFC-2119 keywords are formatted in uppercase and contained in a strong element with class="rfc2119". When the keywords shown above are used, but do not share this format, they do not convey formal information in the RFC 2119 sense, and are merely explanatory, i.e., informative. As much as possible, such usages are avoided in this specification.

Normative and Informative Sections

The indication whether a section is normative or non-normative (informative) applies to the entire section including sub-sections.

Informative sections provide information useful to understanding the specification. Such sections may contain examples of recommended practice, but it is not required to follow such recommendations in order to conform to this specification.

Important Terms

TBD. Can we add only PDF-specific terms here and cross-reference the others from common dir?

term 1

definition 1

term 2

definition 2

Mapping WAI-ARIA to Accessibility APIs

TBD. Should we duplicate or cross-reference this content from the corresponding Core-AAM section?

Role mapping

TBD. Should we duplicate or cross-reference this content from the corresponding Core-AAM section?

General rules

TBD. Should we duplicate or cross-reference this content from the corresponding Core-AAM section?

Role Mapping Tables

example

ARIA Specification example
MSAA + IAccessible2 Role: ROLE_SYSTEM_EXAMPLE
UIA Control Type: Example
ATK/AT-SPI Role: ROLE_EXAMPLE
AX API[Note 1] AXRole: AXxample
AXSubrole:

[Note 1] Footnote content

State and Property Mapping

This section describes how to expose PDF states and [=ARIA/properties=].

General rules

TBD. Should we duplicate or cross-reference this content from the corresponding Core-AAM section?

State and Property Mapping Tables

Not Mapped

There are a number of occurrences in the table where a given state or property is declared "Not mapped". In some cases, this occurs for the default value of the state/property, and is equivalent to its absence. User agents might find it quicker to map the value than check to see if it is the default. For computational efficiency, user agents MAY expose the state or property value if doing so is equivalent to not mapping it. These cases are marked with an asterisk.

In other cases, it is mandatory that the state/property not be mapped, since exposing it implies a related affordance. An example is aria-grabbed. Its absence not only indicates that the accessible object is not grabbed, but further defines it as not grab-able. These cases are marked as "Not mapped" without an asterisk.

aria-example=true

ARIA Specification aria-example=true
MSAA + IAccessible2 Object Attribute: example: true
UIA Property: example: true
ATK/AT-SPI Object Attribute: example:true
AX API Property: AXExample: YES

Special Processing Requiring Additional Computation

TBD. Should we duplicate or cross-reference this content from the corresponding Core-AAM section?

Actions

TBD. Should we duplicate or cross-reference this content from the corresponding Core-AAM section?

Privacy considerations

TBD. Should we duplicate or cross-reference this content from the corresponding Core-AAM section?

Security considerations

This specification introduces no new security considerations.

Change Log

TBD. Should we duplicate or cross-reference this content from the corresponding Core-AAM section?

Acknowledgments

The following people contributed to the development of this document.