This section is normative.
WAI-ARIA processing by the user agent MUST NOT interfere with the normal operation of the built-in features of the host language.
If a CSS selector includes an ARIA attribute (e.g. input[aria-invalid="true"]), user agents MUST immediately update the visual display of any elements matching (or no longer matching) the selector any time the attribute is added/changed/removed in the DOM. The user agent MAY alter the mapping of the host language features into an accessibility API, but the user agent MUST NOT alter the DOM in order to remap WAI-ARIA markup into host language features.
A conforming user agent which implements a Document Object Model MUST include the WAI-ARIA roles, states, and properties in the DOM as specified by the author, even though processing may affect how the elements are exposed to accessibility APIs. Doing so ensures that each role attribute and all WAI-ARIA states and properties, including their values, are in the document in an unmodified form so other tools, such as assistive technologies, can access them. A conforming W3C DOM meets this criteria.
When a web application maintains a local representation of accessibility information through WAI-ARIA roles, states, and properties, the user agent MUST provide a method to notify the web application when a change occurs to any of the states or properties. For example, if any software other than the web application (such as user agents, assistive technologies, or plug-ins) were to change the aria-activedescendant attribute of a tablist, the user agent could fire a change event so that the web application can be notified and display the appropriate tabpanel. Likewise, web application authors SHOULD detect DOM changes when possible and update the web application appropriately.
Any application or script verifying document conformance or validity SHOULD include a test for all of the normative author requirements in this specification.