Re: [WICG/webcomponents] [a11y]: permit aria-hidden=true on focusable shadow elements in FACE (Issue #1014)

I mulled this over for a couple of hours. 

 * **I would stay with exposed inner `<input>`**. The "correct" solution is to build your own element and replace native controls, The *sane* solution is to just use the native control elements (`<input>`, `<textarea>`, `<select>`). I decided to see how much would be worth to rewrite [all](https://github.com/clshortfuse/materialdesignweb/tree/main/components) my components the "correct" way. Simple elements seem okay, like `checkbox`, `role`, `switch`, but for the most part, you're better off staying with the native input. Things like `<input type=range>` gets some things you can't possibly polyfill, like tracking pointer position even though the pointer has left the bounding box. On a related note, a wrapped `<a>` element is AFAIK, the only way to properly show some native characteristics like the tooltip and the browser context menu showing "Open link in new window". That happens because you're tapping into native controls, not emulating them.

* **I would not risk marshalling focus state.** I would not really mess with trying to manage focus between two elements with a non-exposed internal `<input>` element. I agree that it would get unwieldly.  I remember both Firefox and Chromium bugs dealing with FACE related to focus. They are now fixed, but I can imagine hidden input focus unearth some bugs on some browser / screen-reader combinations.

* **CEs are better as containers rather than directly interactive elements.** This is more of an evolution I've noticed having worked on this for some time now. Perhaps coincidence, but all the CEs that do use a role on the host are containers: `toolbar`, `figure`,  `navigation`, `tabpanel`, `tooltip`. All my FACEs that don't use a native control (eg: `<input>`) are essentially containers as well. They set `formAssociated` to use `:disabled` state and disable inner elements (eg: cards as `figure`) or because they expose one singular form value: (eg: `listbox`). 

* **CEs as containers allows more complexity.** Given the `<fancy-input>` example, if it's just a host-level interactive element, you will run into some issues trying to tap into more complex paradigms. For example, if you want to make it an combobox, with a drop down, you *should* include a clickable button the AXTree. That clickable button should not be *inside* your combobox. It should be adjacent to it. If your host-level role is `combobox`, then you can't do it. But if it's `role=none`, then you can present the `combobox` AX Node and the `button` AXNode next to each other as siblings. I can imagine other interactive icons like `Clear input` or `Show Password` would have similar container-like constructs.

-----------------

My current, evolved interpretation of FACE is they:

1. Are containers that can read `:disabled` state
2. should have an ARIA role that match their container type.
3. Can unifyingly set a single form value representing the value within the container
4. *Can have labels passed to it.
5. *Can have an AXLabel
6. *Can have an AXDescription

The starred points are the points of issue. Yes, a label and description can be passed, but we have no ability to pass that value down to whatever element of our choosing (if any) in the Shadow Root.  I need to stress that there is a difference between the textContent of a label from `.labels` and the AXLabel. We cannot just take the textContent because a label can be like this:

````html
<label for=foo>
  <i class=font-icon aria-hidden=true>person</i>Name
</label>
<fancy-input name=foo></fancy-input>
````

That means we need more than just text, we need the actually AXLabel to be passed down. Using `.labels` is not enough because `textContent` isn't safe.  I've experimented with observing `aria-labelledby` and `aria-describedby`, finding the nodes, and putting a mutation observer, cloning in the shadowRoot and then referencing them, but it's a hacky solution and considering those nodes may not exist at the time the attribute is created, it's unreliable.

------

I took a look at https://github.com/alice/aom/blob/gh-pages/semantic-delegate.md and it seems it could satisfy my current issues with using external labels for some FACEs. My other concern is a singular element to receive all the ARIA attributes. I haven't had the use case for it yet off the top of head, but I wouldn't like to be restricted between using `aria-label` and `aria-describedby` to the same shadowed element. If I have a container-like FACE, `aria-label` can reference one element, but `aria-controls` may refer to another. As the author, I would like to choose where I use them. Of course, that doesn't mean extra attributes or `ElementInternals` properties can't be added later.



-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1014#issuecomment-1614821874
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1014/1614821874@github.com>