Bugzilla

(In reply to James Teh [:Jamie] from comment #20)
> (In reply to Tim Nguyen :ntim from comment #19)
> > I'm curious, where is the code that currently implements the behaviour making the results list the child of the textbox in the a11y tree ? I'm asking this, since XUL/XBL markup-wise, the autocomplete popup isn't a child of the autocomplete textbox in most cases where we use them.
> 
> Yeah, I was trying to figure this out myself. I finally found it:
> https://searchfox.org/mozilla-central/source/browser/components/search/content/searchbar.js#715
> It's done with aria-owns. Removing that would stop it from being a child. However, it would also completely disassociate the results list from the input as far as a11y is concerned.

Ah nice, thanks for figuring this out!

> > It would really be nice not having to maintain the textbox wrapper that we currently have.
> 
> Can you explain the reasons for this? I'm lacking a lot of context here and understanding more details here might help me come up with a better solution for a11y.

There are 2 main reasons I want to get rid of the textbox wrapper:
- Having the [attribute/property/event/method call forwarding](https://searchfox.org/mozilla-central/source/toolkit/content/widgets/textbox.xml) from the container to the input around means this stuff needs to be covered by tests.
- There's [a lot of CSS](https://searchfox.org/mozilla-central/search?q=textbox.css&case=false&regexp=false&path=) that simply forwards the styling from the input to the container that could be removed. There are also a bunch of reftests that just check that an unstyled XUL textbox looks like an unstyled HTML input to make sure the default CSS works correctly.

It would be nice to be able to clean up most of this stuff (if not all) once all textbox usages are gone (see bug 1513325).

> For example, is there any reason consumers couldn't see it as an input tag, but internally (inside its shadow root), it has a wrapper with an input inside that wrapper?

This would still have the problems that I've mentioned above unfortunately, since you'd have to implement attribute/property/event/method call forwarding, and potentially styling too. 

But from what you mentioned, I think we can simply add those wrappers manually (i.e. without any custom elements) exclusively for a11y like this:

For home.inc.xul/editBookmarkPanel.inc.xul:
```html
<box aria-owns="PopupAutocomplete">
  <html:input id="..." is="autocomplete-input" [...] />
</box>
```
For searchbar.js, we don't even need to add an extra wrapper, since <searchbar> is already a wrapper itself that only contains elements relevant to it, meaning we can probably just change `this.textbox.setAttribute("aria-owns", this.textbox.popup.id);` to `this.setAttribute("aria-owns", this.textbox.popup.id);` and preserve the same tree.

What do you think ?

(In reply to James Teh [:Jamie] from comment #20)
> (In reply to Tim Nguyen :ntim from comment #19)
> > I'm curious, where is the code that currently implements the behaviour making the results list the child of the textbox in the a11y tree ? I'm asking this, since XUL/XBL markup-wise, the autocomplete popup isn't a child of the autocomplete textbox in most cases where we use them.
> 
> Yeah, I was trying to figure this out myself. I finally found it:
> https://searchfox.org/mozilla-central/source/browser/components/search/content/searchbar.js#715
> It's done with aria-owns. Removing that would stop it from being a child. However, it would also completely disassociate the results list from the input as far as a11y is concerned.

Ah nice, thanks for figuring this out!

> > It would really be nice not having to maintain the textbox wrapper that we currently have.
> 
> Can you explain the reasons for this? I'm lacking a lot of context here and understanding more details here might help me come up with a better solution for a11y.

There are 2 main reasons I want to get rid of the textbox wrapper:
- Having the [attribute/property/event/method call forwarding](https://searchfox.org/mozilla-central/source/toolkit/content/widgets/textbox.xml) from the container to the input around means this stuff needs to be covered by tests.
- There's [a lot of CSS](https://searchfox.org/mozilla-central/search?q=textbox.css&case=false&regexp=false&path=) that simply forwards the styling from the input to the container that could be removed. There are also a bunch of reftests that just check that an unstyled XUL textbox looks like an unstyled HTML input to make sure the default CSS works correctly.

It would be nice to be able to clean up most of this stuff (if not all) once all textbox usages are gone (see bug 1513325).

> For example, is there any reason consumers couldn't see it as an input tag, but internally (inside its shadow root), it has a wrapper with an input inside that wrapper?

This would still have the problems that I've mentioned above unfortunately, since you'd have to implement attribute/property/event/method call forwarding, and potentially styling too. 

But from what you mentioned, I think we can simply add those wrappers manually (i.e. without any custom element/shadow dom involved) exclusively for a11y like this:

For home.inc.xul/editBookmarkPanel.inc.xul:
```html
<box aria-owns="PopupAutocomplete">
  <html:input id="..." is="autocomplete-input" [...] />
</box>
```
For searchbar.js, we don't even need to add an extra wrapper, since <searchbar> is already a wrapper itself that only contains elements relevant to it, meaning we can probably just change `this.textbox.setAttribute("aria-owns", this.textbox.popup.id);` to `this.setAttribute("aria-owns", this.textbox.popup.id);` and preserve the same tree.

What do you think ?