Copyright © 2025-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
CSS Accessibility API Mappings (CSS-AAM) defines how user agents map CSS [CSS] pseudo-elements and properties to platform accessibility application programming interfaces (APIs). It leverages and extends the Core Accessibility API Mappings 1.2 and the Accessible Name and Description Computation 1.2 for use with the CSS language. 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.
This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index.
This document is subject to change without notice.
This document was published by the Accessible Rich Internet Applications Working Group as an Editor's Draft.
Publication as an Editor's Draft does not imply endorsement by W3C and its Members.
This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress.
This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 18 August 2025 W3C Process Document.
This section is non-normative.
This specification defines how CSS user agents respond to and expose role, state and property information provided for Web content.
Accessibility APIs covered by this document are:
If user agent developers need to expose information using other accessibility APIs, it is recommended that they work closely with the developer of the platform where the API runs, and assistive technology developers on that platform.
For more information regarding accessibility APIs, refer to section 1.1 Accessibility APIs of the Core Accessibility API Mappings 1.2.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key word MUST in this document is to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, it appears in all capitals, as shown here.
Normative sections provide requirements that user agents and assistive technologies MUST follow for an implementation to conform to this specification.
Non-normative (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.
There are currently no deprecated requirements.
Most CSS accessibility API mappings cannot be expressed in terms of WAI-ARIA semantics. However, there are some exceptions such as a pseudo-element which has generated content and alternative text. Where a CSS property or pseudo-element specifies default WAI-ARIA semantics, it MUST be exposed to the platform accessibility APIs in a way that conforms to General rules for exposing WAI-ARIA semantics in the Core Accessibility API Mappings 1.2.
CSS pseudo-class selectors are not directly exposed to accessibility APIs and have no direct impact on the accessibility tree. However, when a pseudo-class selector matches, this may cause additional CSS properties to apply to elements or pseudo-elements. These must be exposed to accessibility APIs as described in other sections of this specification. In addition, many pseudo-class selectors match based on element states; e.g. the enabled, disabled, required and focused states. These should be mapped as described in the Accessibility API Mappings specification for the host language such as [HTML-AAM].