- Incorrect or confusing description of aria-required usage #225
- Other aria-* attributes which should not be allowed on HTML elements #241
My understanding of strong native semantics was hand-wavy, so I scrutinized the ARIA spec. It gives us an interlocking set of requirements for web authors, ARIA conformance checkers, user agents, and the host language itself (usually HTML, but could be SVG or MathML).
To help myself understand the subtleties, I reorganized and rephrased these requirements in more formal language. Words in [square brackets] are my additions, but otherwise these are direct quotes from ARIA spec 1.2 (Working Draft 18 December 2019), section 8.5, Conflicts with Host Language Semantics.
How ARIA handles conflicts with a host language
The ARIA spec's requirements for a host language spec (e.g, ARIA in HTML)
[8.5.1 Attribute Conflicts:] Host languages MUST explicitly declare where the use of WAI-ARIA attributes on each host language element conflicts with native attributes for that element.
[8.5.2 Strong Native Semantics:] Host languages MAY document features that cannot be overridden with WAI-ARIA (these are called "strong native semantics").
[8.5.3] Host languages MUST NOT declare strong native semantics that prevent use of the following ARIA features: aria-describedby, aria-label, aria-labelledby
An ARIA requirement for web authors
[8.5.4] When a feature in the host language with identical role semantics and values is available, ... authors SHOULD use the host language features rather than repurpose other elements with WAI-ARIA.
Requirements for ARIA conformance checkers
[8.5.5 (based on 3.4):] [Conformance checkers] SHOULD include a test for [requirement 8.5.4]. [If a conformance checker detects a failure of requirement 8.5.4, it] MUST issue a warning.
[8.5.6] When [an author uses a] WAI-ARIA role ... on [an element] with strong native semantics [as specified in the host language], conformance checkers MAY signal an error or warning.
ARIA requirements for user agents (e.g., browsers)
[8.5.7] Except for the cases outlined below, user agents MUST... use the WAI-ARIA semantics to define how it exposes the element to accessibility APIs, rather than using the host language semantics. [This is true even when an author incorrectly uses] a WAI-ARIA role on [an element] with strong native semantics.
[8.5.8 Attribute Conflicts (exception to 8.5.7):] When a host language declares a WAI-ARIA attribute to be in direct semantic conflict with a native attribute for a given element, user agents MUST ignore the WAI-ARIA attribute and instead use the host language attribute with the same implicit semantic.
[8.5.9 Roles Disallowed by Attribute Conflicts (exception to 8.5.7:] [When a WAI-ARIA] role requires WAI-ARIA states and properties whose [equivalent native] attributes are explicitly forbidden on the native element by the host language, [user agents are not REQUIRED to] use the semantic of the WAI-ARIA role for processing.
[8.5.10 Roles Disallowed on Permanently Presentational Elements (exception to 8.5.7):] [When a host language, such as SVG, documents strong native semantics] that cannot be overridden with WAI-ARIA [and] the native host language semantic is permanently presentational, [and an author uses] a WAI-ARIA role on [an element] with strong native semantics, user agents [are not REQUIRED to] use the value of the semantic of the WAI-ARIA role when exposing the element to accessibility APIs.
Examples
aria-disabled conflicts with the equivalent HTML disabled attribute.<input type=password>Is this clear enough?
If any of this is unclear or incorrect, please let me know and we'll figure out how to fix it. If this leads to filing issues on the ARIA spec, we can make the spec clearer for everybody.
In particular, I interpreted some parts of the spec to say that user agents are "not REQUIRED" to do certain things. The spec is unclear; t's possible that these should actually say "MUST NOT" or "MAY" instead.