Re: [w3ctag/design-reviews] Incubation: Scoped Focusgroup (Issue #1152)

janewman left a comment (w3ctag/design-reviews#1152)

Thanks @matatk, these are great questions, my responses to each are below.
**_1. Orientation of certain types of construct, and aria-orientation don't seem to be mentioned - is orientation something the group considered?_**
My thinking has been that focusgroup should not be used as an input for aria-orientation. Today, the aria-orientation can be derived from the role, and focusgroup plays nicely here with the concept of a minimum role. By default, a *linear focusgroup uses both of the arrow-key axis to enable movement between items, though authors may decide to restrict this to a single axis to enable the other axis to be used for other purposes, such as scrolling, activating items, etc. Since focusgroup will never impact the actual orientation of a control, I have felt that authors should continue to use aria-orientation as they would today, and take care to either use the default, or ensure they restrict to the proper axis for the behavior or role they have chosen.
_*In the current proposal, all of the behaviors listed are linear.

**_2. Is there a reason why tree and treegrid controls are not mentioned? (grid is mentioned as future work)_**
Grid was specifically called out as future work as a previous version of the proposal had spent considerable time detailing the behavior, though this latest proposal moved it out into this future section due to complexity. 
Tree and treegrid controls would both make sense as future non-linear "behaviors" alongside grid that focusgroup could be used to support in the future.

**_3. Do you intend that the behavior tokens will always have the same names as their ARIA role counterparts?_**
My intention when adding the concept of behavior was to ensure that a focusgroup would be accessible-by-default, and to choose names that are already familiar and clear to developers. I wouldn't be against behaviors not sharing a name with the ARIA role it maps to, as long as the usage was clear to developers and accessible-by-default. 
As a **hypothetical** example, when considering how [treegrid](https://www.w3.org/WAI/ARIA/apg/patterns/treegrid/examples/treegrid-1/) could be implemented, if there was consensus that the cell vs row focus priority would be best captured by the behavior name, we might end up with "row-treegrid", "cell-treegrid", where both behaviors would map to the same role. For clarity, I might advocate that this distinction should be captured in an optional modifier, but this works as an example of the kinds of situations where there might be an interest to not have the behavior share a name with an ARIA role that it maps to.

**_4. Do you foresee adding anything that is not currently covered by ARIA?_**
When I consider the future of focusgroup, I see it following and helping to codify these common patterns, and as I see it, ARIA has a similar goal. 
While I can imagine a situation where a new role/pattern is codified in ARIA and then implemented by a corresponding focusgroup behavior, I find it difficult to imagine a situation where the reverse could be true while still maintaining a default-good accessible experience.

__________________
Please let me know if anything isn't clear, if you have additional questions, or if there are any concerns.
Thanks!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1152#issuecomment-3609300702
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1152/3609300702@github.com>