2046886 - ElementInternals `role` not used when calculating ARIA presentational roles conflict resolution

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[Steven Lambert [:Steven]]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36

Steps to reproduce:

Define a custom element with ElementInternals attached and define a role, add the element to the DOM with an explicit role of none or presentation, then either set the element as focusable (through use of tabindex) or assign a global ARIA attribute.

<my-button tabindex="0">btn</my-button>

<my-button tabindex="0" role="none">btn none focusable</my-button>

<my-button aria-haspopup="true" role="none">btn none global attr</my-button>
<script>
  customElements.define(
    'my-button',
    class MyButton extends HTMLElement {
      constructor() {
        super();
        this._internals = this.attachInternals();
        this._internals.role = 'button';
      }
    }
  )
</script>

Actual results:

The first element has a role of button (expected). The next two elements have a role of generic (unexpected).

Expected results:

All elements should have a role of button. The presentation role conflict resolution algorithm should look at the implicit role of the element when there is a presentational role conflict, and the internals role should be treated as the implicit role in this case. https://html.spec.whatwg.org/multipage/custom-elements.html#accessibility-semantics states that the role property is the "default ARIA role" which should be the same as the implicit role.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Disability Access APIs' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[James Teh [:Jamie]]

This is interesting. Thanks for filing.

The spec itself is IMO quite vague on this point. HTML AAM has a section for autonomous custom elements, but it only mentions the role attribute, not ElementInternals. ARIA in HTML is the closest thing I could find, which states that autonomous custom elements should treat the author defined ElementInternals role as the implicit ARIA role, but that spec is more about authoring rules, not user agent mapping.

This is relevant because it seems like Firefox is not the only browser with this bug. I tested with Chromium and got exactly the same result. I think spec clarification would probably help here.

Comment 3

[James Teh [:Jamie]]

I guess we could fix this by explicitly checking if we have role none/presentation/invalid around here. If we do, we'd need to explicitly check the role in GetARIADefaults to see if it is valid.

Comment 4

[Garbee]

We have an upstream WPT issue to try and discuss this. https://github.com/web-platform-tests/wpt/issues/60563

Comment 5

[Botond Ballo [:botond]]

Attachment: Bug 2046886 - Let sticky axis locking on Mac ride the trains. r=mstange

Comment 6

[Phabricator Automation]

Comment on attachment 9604362 [details]
Bug 2046886 - Let sticky axis locking on Mac ride the trains. r=mstange

Revision D310424 was moved to bug 2046884. Setting attachment 9604362 [details] to obsolete.