Accessibility of web content requires semantic information about widgets, structures, and behaviors, in order to allow assistive technologies to convey appropriate information to persons with disabilities. This specification provides an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and interoperability of web content and applications. These semantics are designed to allow an author to properly convey user interface behaviors and structural information to assistive technologies in document-level markup. This version adds features new since WAI-ARIA 1.1 [[wai-aria-1.1]] to improve interoperability with assistive technologies to form a more consistent accessibility model for [[HTML]] and [[SVG2]]. This specification complements both [[HTML]] and [[SVG2]].
-This document is part of the WAI-ARIA suite described in the WAI-ARIA Overview.
+This document is part of the WAI-ARIA suite described in the WAI-ARIA Overview.
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 ARIA GitHub repository. If this is not feasible, send email to public-aria@w3.org (comment archive). In-progress updates to the document can be viewed in the publicly visible editors' draft.
+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 ARIA GitHub repository. If this is not feasible, send email to public-aria@w3.org (comment archive). In-progress updates to the document can be viewed in the publicly visible editors' draft.
Operating systems and other platforms provide a set of interfaces that expose information about objects and events to assistive technologies. Assistive technologies use these interfaces to get information about and interact with those widgets. Examples of accessibility APIs are Microsoft Active Accessibility [[MSAA]], Microsoft User Interface Automation [[UI-AUTOMATION]], MSAA with UIA Express [[UIA-EXPRESS]], the - Mac OS X Accessibility Protocol [[AXAPI]], the Linux/Unix Accessibility Toolkit [[ATK]] and Assistive Technology Service Provider Interface [[AT-SPI]], and IAccessible2 [[IAccessible2]].
+Operating systems and other platforms provide a set of interfaces that expose information about objects and events to assistive technologies. Assistive technologies use these interfaces to get information about and interact with those widgets. Examples of accessibility APIs are Microsoft Active Accessibility [[MSAA]], Microsoft User Interface Automation [[UI-AUTOMATION]], MSAA with UIA Express [[UIA-EXPRESS]], the + Mac OS X Accessibility Protocol [[AXAPI]], the Linux/Unix Accessibility Toolkit [[ATK]] and Assistive Technology Service Provider Interface [[AT-SPI]], and IAccessible2 [[IAccessible2]].
Typically, the author will use host language semantics to put the widget in the Tab sequence (e.g., tabindex="0" in HTML) and aria-activedescendant to point to the ID of the currently active descendant. The author, not the user agent, is responsible for styling the currently active descendant to show it has keyboard focus. The author cannot use :focus to style the currently active descendant since the actual focus is on the container.
More information on managing focus can be found in the Developing a Keyboard Interface section of the WAI-ARIA Authoring Practices.
+More information on managing focus can be found in the Developing a Keyboard Interface section of the WAI-ARIA Authoring Practices.