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 a WAI-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.
Editorial: The PFWG is considering removing this section due to incomplete implementation of DOM mutation events, and due to requests by members of the DOM and HTML working groups.
Assistive technologies, such as voice recognition systems and alternate input devices for users with mobility impairments require the ability to control a web application in a device-independent way. WAI-ARIA states and properties reflect the current state of rich internet application components. The ability for assistive technologies to manipulate WAI-ARIA states and properties, such as aria-expanded, and have the web application be notified and respond to these changes is essential because it allows these alternative input solutions to control an application without being dependent on the standard input device which the user is unable to effectively control directly.
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 the 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.
Many state and properties can be changed by assistive technologies through existing accessibility APIs for responding to a default action event. For example, the aria-expanded state of a treeitem in tree or the aria-selected state of a tab in a tabpanel can be changed by triggering the default action of the element.
Any application or script verifying document conformance or validity SHOULD include a test for all of the normative author requirements in this specification. If testing for a given requirement, conformance checkers MUST issue an error if an author "MUST" requirement isn't met, and MUST issue a warning if an author "SHOULD" requirement isn't met.