Conflicts with host language property and aria-level

[kengdoj]

Regarding 8.5 Conflicts with Host Language Semantics, browsers seem to be handling this part of the spec differently:

When WAI-ARIA states and properties correspond to host language features that have the same implicit WAI-ARIA semantic, it can be particularly problematic to use the WAI-ARIA feature. If the WAI-ARIA feature and the host language feature are both provided but their values are not kept in sync, user agents and assistive technologies cannot know which value to use. Therefore, to prevent providing conflicting states and properties to assistive technologies, host languages MUST explicitly declare where the use of WAI-ARIA attributes on each host language element conflicts with native attributes for that element. 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.

We checked the accessibility tree in Chrome and Firefox for the heading level of this sample code: <h2 role="heading" aria-level="3">

• Both accessibility trees showed heading level of 3.
• Our understanding of the spec, given the conflict and host language h2, was that heading level should be 2.

Is our understanding of the spec incorrect?

[scottaohara]

yeh, can get why you could come away with that initial understanding here, but no this isn't a conflict with a native attribute of the given element. There is no native 'level' attribute for heading elements where it would take precedent over the aria-level attribute. the level is implicit based on the tag name, but you essentially need both the aria attributes to consistently overwrite the role/level.

This is not the same as something like a native checkbox where there is an attribute and specific functionality for the checked state of the control that could conflict with the aria-checked attribute.

closing as i think this addresses your question, and this does not represent an issue with this specification.

[JAWS-test]

See also: https://github.com/w3c/aria/issues/1433

[JAWS-test]

@scottaohara

This is not the same as something like a native checkbox where there is an attribute and specific functionality for the checked state of the control that could conflict with the aria-checked attribute.

This is not so easy even with a checkbox:

• input type=checkbox aria-checked=true has no HTML attribute and yet aria-checked is ignored.
• input type=checkbox checked aria-checked=true has matching ARIA and HTML attributes, which are both ignored once the checkbox has been clicked

And so far just the theory: Chrome and Edge only pay attention to the ARIA attribute aria-checked and ignore the explicit or implicit checked status coming from HTML. This is of course only a bug of the two browsers and not the specification

[scottaohara]

yes @JAWS-test, my mention of "...there is an attribute and specific functionality..." was a very high level allusion to what you mention without needing to restate how checkboxes work.

i'm not really sure I follow why you mention "This is not so easy even with a checkbox"... as that's sort of the point. aria-level and aria-checked shouldn't be looked at as the same as there's no strong semantics / functionality with a level/heading where there'd be an opportunity for conflict. aria-checked and the checked state (whether that be the attribute itself or the checked state from user interaction) have strong native semantics/functionality, and that is the type of thing the ARIA spec is pointing out where host language behavior/semantics win out over ARIA.

With that said, I think we can stop here. I'd rather not have to elaborate on questions that were already answered, unless the OP asks for additional clarity.

[JAWS-test]

@kengdoj The paragraph you quoted only says that in case of possible conflicts between ARIA and the host language, the corresponding specification must specify how these conflicts are resolved. This is in the case of HTML: https://w3c.github.io/html-aria/ And there it does not say for the heading elements that in case of conflict aria-level should be ignored, whereas for checked there is a prohibition to use aria-checked at the same time. So the requirements of the ARIA specification are fulfilled.

[kengdoj]

@scottaohara and @JAWS-test, thank you both!