[focusgroup]: should focusgroup require the use of a modifier key? or ??? for unexpected patterns

[scottaohara]

Back in August 2023, the ARIA WG discussed the focusgroup proposal. My apologies for taking so long to make this issue.

The following questions/concerns were raised:

Since focusgroup could apply to focusable content, including content that generally does not have wide expectations to be navigable via arrow keys (e.g., hyperlinks), what considerations can be/should be made to ensure that:

1. assistive technology will handle this correctly (e.g., JAWS/NVDA in their default 'automatic forms mode' have behaved oddly (at least last time tested) when navigating focusgroup elements that aren't expected to keep a user in forms mode
2. that sighted keybord users will be able to readily understand when website A has used focusgroup for their primary navigation, but website B uses traditional tab navigation.

While I know the example in this linked comment is not necessarily meant to demonstrate how someone should use focusgroup, it being a potential valid example demonstrates both a markup pattern that could result in the JAWS/NVDA in/out of forms mode behavior I mentioned, as well as significantly buck user expectations for how such standard content should be navigated.

Outside of having screen readers be able to support arrow key behavior on elements that have not ever had an expectation of default arrow key navigation, and how to visually communicate this to people in general... is overriding standard arrow key behavior actually a good idea outside of the patterns (which are largely not native to the web platform and require someone use ARIA to build them now) where arrow key navigation is expected?

Take arrow key navigation through an accordion for example. On its surface this seems like something people might immediately think to do - allow for arrow key navigation to jump between the triggering elements for each accordion panel. The issue with this though is that an accordion panel can contain lots of content - and may/may not contain other focusable elements for the user to navigate to.

In the scenario where an accordion does contain focusable element (such as hyperlinks), what then is the expectation for the next tab key press if the accordion triggers are all part of the focus group? Should tab key go to the next accordion trigger, since it would have been the next focusable element if not for the focusgroup behavior? Or, would tab focus move to the next focusable element AFTER all the accordion triggers that participate in the focusgroup?

Next, let's consider an accordion that doesn't have any focusable content within its panels. While this might seem like a non-issue for people using large viewport sizes, people who have to zoom in to read content (1.4.4 Text Resize or 1.4.10 Reflow WCAG SCs) or who may just generally be on smaller screens but require the use of keyboard to navigate their device (bluetooth keyboards for touch devices). Arrow keys should allow these users to scroll the viewport so they can read the content. But if arrow key navigation is overwritten to instead move focus between the accordion triggers, then you get something like this - https://codepen.io/scottohara/pen/abMaxNx - where at the simulated Reflow viewport size, parts of the content cant be scrolled into view because arrow keys jump between the accordion buttons.

Too many words scott, again, what do you want?

The idea that some of these concerns could be resolved if arrow keys alone were not used as the default way to navigate focusgroup content (edit for clarity: specifically content that does not have a history of using arrow keys for navigation). (browsers could potentially include a toggle to allow users to make their own choice about whether they wanted to navigate focusgroup content by [modifier key} + arrow keys, or arrow keys alone).

Going this route would open the potential for both currently expected keyboard navigation to coexist with the modified and improved (regardless of all the concerns mentioned, the ARIA wg does want this proposal to succeed and acknowledges the need for it) focusgroup navigation.

This wouldn't necessarily resolve the discoverability issue, but arguably if people are made aware of this new feature / even purposefully opt into it, then they can start to expect it. E.g., it would be less frustrating to come to a website navigation and find that tab key doesn't work, and have to determine that they need to switch keyboard navigation methods to get to the page they want to - than it would to come to a web page and check to see if (for example) ctrl + arrow key works, and if it does great, and if it doesn't, well they then know the tab key will work.

If this solution doesn't hold water for some reason, that's fine. But, we do need to have a longer think on how to resolve the concerns mention in my word mess, above. I have other (lesser, imo) ideas of what could be done... but I'll save those for another time.

[o-t-w]

Going this route would open the potential for both currently expected keyboard navigation to coexist with the modified and improved (regardless of all the concerns mentioned, the ARIA wg does want this proposal to succeed and acknowledges the need for it) focusgroup navigation.
This wouldn't necessarily resolve the discoverability issue

I'm a bit confused by this. Accessibility resources have said for years that menus should be navigable by arrow keys. Are you saying that this is actually not expected and suffers from a discoverability issue? Some of the other issues sound like an education problem (MDN and other resources can tell developers the appropriate and inappropriate use cases. Using focusgroup on a accordion sounds like a bad idea. Ditto putting form elements in a focusgroup).

[gfellerph]

I'm wondering how many people will use the benefits of focusgroup if they have to learn to press a modifier key or change a default setting in their browser (and then do that on every different device they are using for every different browser they are using). Arrow keys in OS menus work without modifier and they should do the same on the web.

As for the accordion example, this is my understanding of how it should work:
If there are focusable (visible) elements contained in the accordion content that are excluded from the focusgroup behaviour, then a tab press should honor DOM order (or natural focus order) and jump from the accordion heading to the content and out of the focusgroup. Only another tab press will return back to the focusgroup. Arrow keys presses should not be handled by the focusgroup if a non-candidate has focus.

<style>
  /* Only headings are part of the focusgroup, syntax might be wrong */
  accordion-heading { focusgroup-name: auto; }
</style>

<accordion-wrapper>
  <accordion-heading>Heading 1</accordion-heading>
  <accordion-panel>
    <p>This is the first panel with a <a href="https://google.com">link to google</a>.</p>
  </accordion-panel>

  <accordion-heading>Heading 2</accordion-heading>
  <accordion-panel>...</accordion-panel>
</accordion-wrapper>

If the headers are the only focusable elements in the accordion, a tab press would jump to the next focusable element outside of the accordion. Or at least this would be the default behaviour.

Here are some ideas:

• We could specify a new option for the focusgroup that does not interfere with tab navigation, making all focusgroup candidates tabbable, like <div focusgroup="tabbable">. This would give authors the possibility to enhance a group of elements with arrow key navigation without interfering with tab expectations. Or do the opposite and make tab skipping behaviour opt-in with something like <div focusgroup="skip-tabs">.
• We could specify a modifier key that opts out of focusgroup behaviour to re-enable normal arrow key behaviour. This could help adoption of the new focusgroup feature as it's on by default but can be disabled when needed. I'm aware that this approach suffers from the same discoverability and learning issue the focusgroup suffers in general.
• There will be people who'll write <body focusgroup>. In my naive world, the benefits overweigh the drawbacks the new tool will bring, it just highlights how important documentation and education is.

[scottaohara]

I'm a bit confused by this. Accessibility resources have said for years that menus should be navigable by arrow keys. Are you saying that this is actually not expected and suffers from a discoverability issue?

@o-t-w i can see why you're asking this question. but no, the feedback i posted was meant to be specific to elements/components that do not have expectations for arrow key navigation. i've added an edit to my original post to hopefully clarify this a bit more.

@gfellerph, hopefully my answer to Oliver helps add some clarity per your response as well. Since you both jumped to talking about menus (so i obviously didn't do a good job at making people consider the actual problems the I and the ARIA wg were concerned with.)

We could specify a new option for the focusgroup that does not interfere with tab navigation...
We could specify a modifier key that opts out of focusgroup behaviour to re-enable normal arrow key behaviour...

those sounds similar to what my comment was asking to be considered, so yes, let's all talk about these more - so long as there is a way for users to be in control and opt in/out, I think that'd be a reasonable path forward.

There will be people who'll write <body focusgroup>...

I would hope people wouldn't go and do stuff like that. but also, i've seen a number of websites where developers - thinking they were 'helping' - would put aria-hidden=true on the body element (when their custom modal dialog opened), and instead they made their entire web page inaccessible.

the main bit of this feedback i really wanted to resonate with people was that though this idea has a lot of potential to make keyboard navigation easier for components where such behavior is expected - it also has a lot of potential to make things unpredictable (and potentially broken - per my comments about screen reader behavior last time I tested) for situations where arrow key navigation is not expected.

so per your comment:

I'm wondering how many people will use the benefits of focusgroup if they have to learn to press a modifier key or change a default setting in their browser

i guess i'd counter that and say how many people (users) will see the benefit in focusgroup if it results in common UI patterns (e.g., navigations, or arbitrary focusable elements within a web page) no longer being predictable for them to navigate? If there was a way to consistently visually call out the change in navigation behavior - or if focusgroup was limited in its use to the patterns where arrow key navigation was expected - this entire issue would probably be moot. But there isn't (at least, not yet?)

Again, apologies that my original comment made it seem like I was advocating for the use of a modifier key for patterns where there is already arrow key navigation expectations. But the point here is that while I think we all want this to make keyboard navigation easier to implement for the patterns where this navigation would be expected, it being used on anything outside of that has the potential to make navigation more confusing for the people it should be helping. And, much like putting aria-hidden=true on the body element, the developers who do this would likely be none the wiser (it's not like there isn't a bunch of documentation/education on ARIA out there)... and misuse / unexpected use has the potential to hinder the people (users) this feature is supposed to help. So yeah. I want to try and prevent that as much as possible.

[travisleithead]

@scottaohara thanks for taking the time to write up the discussion outcomes from the ARIA WG, and for sharing the feature with them in the first place!

Let me replay the feedback in my own words to make sure I've got it correctly:

1. Assistive Technology (or WCAG) navigation expectations could be disrupted by the presence of unexpected focusgroups (i.e., focusgroup applied to elements other than those trying to behavior like typical form control patterns)
   • 1.a. example: issues with JAWS/NVDA behaving oddly with regard to auto forms mode when running into a focusgroup-enabled element (maybe: failing to automatically drop out of forms mode? I would like to dig into this more...)
   • 1.b. example: changed expectations around how standard content is to be navigated (interactions/conflicts with Tab key) cite: case of an accordion UI containing forms in a panel.
   • 1.c. example: arrow key navigation among focusgroup candidates overrides default page scrolling (when content overflows and users need to scroll the page/region to see all the content per WCAG criterion).
2. Sighted users need to be able to discover the focusgroup navigation feature if it steps on/overrides traditional tab navigation.

---

Those are some excellent points.

I too, am a bit nervous about how focusgroup + AT navigation will be impacted because I know there are a lot of heuristics and assumptions made in ATs for navigating HTML (which can be fragile) and that focusgroups enable the use of arrow keys in places not previously expected. I'd love to dig into the specific issues you found while testing the chromium prototype as I think that will be helpful in predicting what we might expect when pairing focusgroups and ATs.

• Generally, I'm optimistic that most AT issues would be quickly resolvable assuming that 1) the platform exposes the presence of a focusgroup attribute to the accessibility layer (or the AT scrapes it from the DOM) and 2) the AT intercepts and drives the interaction on the web page (through the accessibility APIs), so arrow-key presses would be able to be handled by the AT first, and not necessarily trigger unexpected behavior in the browser.
• Arrow keys and scrolling behavior is something we need to look seriously at. I'm hopeful that it could be solved by making focusgroup smarter: something potentially elaborate like "if element is part of a focusgroup and the element is in a scrollable region, and the next target for the arrow key press is not 'in view' then don't move focus, and instead trigger the scrolling behavior (until the target element is in view)"
• 1.b and case 2 above are examples of why I really do not want to mess with traditional tab navigation--it's even more risky considering the accessibility expectations for the tab key as a navigation agent. In the current draft of the explainer, focusgroups absolutely do not impact tab navigation at all. In order to add a 'memory' to a focusgroup, I am proposing a slight tweak to tab navigation order but only in one very limited case that would not cause any of the problems described in the accordion example mentioned previously.

Generally, I would hope we can address this feedback without needing to add an additional modifier key for use, though if not, then having an opt-out key combo would be my preference (moves things forward by default, which can be more painful initially, but is the right long-term solution for the web IMO).

Finally, a thought on discoverability--elements that use ARIA to mock-up a form control and add keyboard accessibility (or fail to do so) rarely offer any discoverability of the keyboard behavior--rather the pattern's role and built-in semantics of the element set the expectation for users. I would expect this to continue to be true for use of focusgroup. If focusgroup is used in an erroneous way (e.g., <body focusgroup>) where there is no expectation of having default keyboard semantics, then I would not expect any users to discover it (in fact, it might feel like a bug depending on the context of use). If that case poses a problem for ATs (see points 1.a) then we need to fix that, but otherwise, I'm not sure I see how the extra keyboard behavior introduces a problem (except that its "unexpected") and thus doesn't need to be made overly discoverable in some UI form.

[scottaohara]

just quicky responding, will come back with more later:
re: "Assistive Technology (or WCAG) navigation expectations" - just general expected UX for common patterns as well. again, a website navigation is not generally expected to be navigable via arrow keys. Having this be a developer-by-developer, website-by-website decision on whether or not to make the navigation a focusgroup navigation means that any keyboard user going to any website has no clue on what to expect for just standard page navigation. It now becomes a whack-a-mole trial and error on each web page, and for anything that bucks the norm, they have to keep track of that so when they return they remember "oh, this website is navigated differently because LOL"

elements that use ARIA to mock-up a form control and add keyboard accessibility (or fail to do so) rarely offer any discoverability of the keyboard behavior

yes and no? if ARIA is used correctly on the component and standard expectations for that component are properly implemented by the developer, then screen readers can absolutely make those commands known. E.g., JAWS has UX hints to tell people how to navigate common controls based on their established patterns.

Visually, and to some of the points that were made in the previous comments, menus, grids, tablists - they often follow common visual styling patterns, so they can be recognizable to users. Focusgroup going on whatever, including patterns where there is no uniform expectation for behavior (lol focusable cards... as if that term actually meant anything)

[travisleithead]

I've been thinking about this today, as well as some of the content in the "Why CSS toggles are too hard" paper, and thinking about it in terms of focusgroup. E.g., what are the accessibility semantics of focusgroup? How should we deal with conflicts with default element semantics? What about conflicts with ARIA roles? Would love to hear thoughts from @mfreed7 and @dbaron too. I'm wondering if focusgroup will end up meeting the same fate as CSS Toggles for similar reasons.

Here's a random dump of thoughts:

Focusgroup semantics

Putting a focusgroup attribute on an element does convey some tiny bit of semantics, IMO. Something like "this element (whatever its original semantics) is also now a container for an arbitrary group of related focusable controls that can be reached via keyboard arrow keys". Is that useful for accessibility...? In the feature's current state, I would strongly recommend a best practice of also including a suitable 'role' attribute to beef up the semantic meaning and related expectations.

• We could go a step further and require a role to be present in order for focusgroup to work? This has its own drawbacks, of course.
• We could try to add more semantic meaning into focusgroup. In fact, we do this already, but only in one specific case: focusgroup=grid. Perhaps we need to require more semantics for the other "linear" focusgroup use cases by making them explicit, such as focusgroup=listbox or any number of other patterns, e.g., "menu", "menubar", "radiogroup", "tablist", "toolbar", "tree", "treegrid", in addition to "grid". This might also provide two additional benefits: 1) discourage use of focusgroup outside of established patterns (like on the body element as noted), and 2) automatically imply the associated role on the given element (if not already provided). Conflicts between role and focusgroup semantic could be a problem.

[EDIT - forked off issue #995 with the former additional thoughts in this comment]

[css-meeting-bot]

The Open UI Community Group just discussed [focusgroup]: should focusgroup require the use of a modifier key? or ??? for unexpected patterns.

The full IRC log of that discussion

<gregwhitworth> Travis: let me give you a summary of what focusgroup is
<gregwhitworth> Travis: it is an attribute that produces a scope that any focusable element under that tree will be navigable
<gregwhitworth> Travis: it will not move selection (eg: via arrow keys, etc). It's been compared with roving tabindex but that often does fancy things with tab order but this doesn't do that
<gregwhitworth> Travis: what we want to do today is a set of open issues on the explainer
<gregwhitworth> Travis: I tried to capture the key points and key suggestions on how to resolve and we can take time to get feedback/thoughts
<gregwhitworth> Travis: first are a11y related and are usually the most knarly to look into
<gregwhitworth> Travis: I saw scotto_ on the call so I'll hopefully sum these up well
<keithamus> q+
<gregwhitworth> Travis: with it being a global attribute it may end up being put on elements that have no expectation of working with focus engagement
<gregwhitworth> Travis: will you be able to know that a element can you use arrow key navigation, and tab navigation may result in broken behavior from site to site depending on whether they use it
<gregwhitworth> Travis: how would they be able to use it, etc
<gregwhitworth> Travis: there is a case of a form content navigation in an accordion are you going to not be able to get to them?
<gregwhitworth> Travis: I think that may be a misunderstanding of the feature but we can discuss it a bit more
<gregwhitworth> Travis: third, ATs normally have two modes. 1.) being to navigate around content and the 2.) being to enter the content and does this automatically based on surrounding context
<gregwhitworth> Travis: in the case of focusgroup that may cause some problems
<gregwhitworth> Travis: can we switch into auto forms mode or out of it, etc and there were some bugs found in the forms prototype
<gregwhitworth> Travis: in wicag there is a requirement to be able to scroll content that has overflowed its container
<gregwhitworth> Travis: if you zoom something really big you need to be able to scroll it
<gregwhitworth> Travis: if you have a focusgroup it has hijacked the arrow key functionality from focusgroup area to another one
<gregwhitworth> Travis: I've been noodling on the semantics of a focusgroup element
<gregwhitworth> Travis: this came from reading David and Mason's toggle proposal
<gregwhitworth> Travis: what are we saying semantically when you add it? Does it have the same problems
<gregwhitworth> Travis: I'll try and cover the suggestions briefly
<masonf> q+
<gregwhitworth> Travis: issue 990 could be a modifier key
<gregwhitworth> Travis: rather than overriding arrow keys, the con of this is it will be hard to discover
<luke> q+
<gregwhitworth> Travis: regarding the zoomed in scenario we could introduce some smarts that if the next focusable item is not in the viewport we will scross rather than move to that item
<gregwhitworth> Travis: is there a way to provide a default UA stylesheet for a focusgroup that will result in people being able to understand that they are in a focus group
<gregwhitworth> Travis: lastly, the semantics of focusgroup; if you put it on typical listboxes, etc then maybe we require the atribute be paired with a specific role rather than blindly on anything
<gregwhitworth> Travis: just a thought
<gregwhitworth> Travis: maybe we change syntax so that you assign the semantic role to it. In one case I'll do grid but the linear one is a semantic list vs grid and it may be a toolbar, accordion, listbox, etc
<scotto_> q+
<gregwhitworth> ack keithamus
<brecht_dr> q+
<gregwhitworth> keithamus: so I think I've written the last three impl on github so I'm quite invested in this area and go through my thoughts
<gregwhitworth> keithamus: I think we can probably restrict it to how it's applicable to certain nodes
<gregwhitworth> keithamus: jumping forward to your role statement we have many roles that can also have a focusgroup
<gregwhitworth> keithamus: there are a lot of attributes in focusgroup that are valuable on their own and I believe they're unrelated
<gregwhitworth> keithamus: we use focusgroup on our role tablist and menu
<gregwhitworth> keithamus: if I were going to do a 6th implementation at Github is the way that you enter a focusgroup area
<gregwhitworth> keithamus: I would want to show the focus on the entire group that shows the focus area and then the arrow will move the focus along
<gregwhitworth> keithamus: I'd probably tag on the word focusgroup to the aria description
<gregwhitworth> keithamus: I don't think modifier keys are a good step forward
<gregwhitworth> ack masonf
<gregwhitworth> masonf: I like the general idea of the feature, it happens on the web and if used correctly it can be helpful
<gregwhitworth> masonf: the difficulty is mostly around accessibility and expectations by keyboard users
<gregwhitworth> masonf: I'm glad to see dbaron on the queue
<gregwhitworth> masonf: this is less about semantics and more about roles and keyboard behavior
<gregwhitworth> masonf: for toggles we had a bunch of heuristics that tried to figure out what you were trying to build and so it resulted in a complicated matrix
<gregwhitworth> masonf: that's where I would want to start
<gregwhitworth> masonf: you said many times that it doesn't disrupt tab navigation and it seems like it takes many tabstops and reduces them to one which would impact tab nav
<gregwhitworth> Travis: the way it works is it converts all tab elements into traversable by arrow keys in a focusgroup but tab is unaffected
<gregwhitworth> Travis: however you can make a true focus group by having one tab stop in that group and have tabindex=-1
<gregwhitworth> masonf: if you have numerous inputs in there that don't have tab on them you can get to them correct?
<masonf> q+ sasha
<gregwhitworth> Travis: yes
<gregwhitworth> ack luke
<masonf> ack sasha
<gregwhitworth> luke: I likewise implemented focusgroups and did it twice at my last job and there are quite a bit different usecases
<gregwhitworth> luke: I would prefer for the feature to be verbose rather than having to do some type of magic to do the right thing
<gregwhitworth> luke: I think that also will make it more difficult for the end user
<gregwhitworth> luke: regarding scrolling, if you can focus a scrollable area then arrow navigating should always scroll you. That is the one area where it may do some differences
<gregwhitworth> luke: if you put a focusgroup on a navigable area and it should be a no-op and just scroll
<gregwhitworth> luke: I think it would be good to just NOT allow it on body or html
<gregwhitworth> luke: if it's a scrollable container then it shouldn't have a focusgroup
<gregwhitworth> luke: one issue is a listbox
<gregwhitworth> q+
<masonf> q+ sasha
<gregwhitworth> luke: one of the benefits of focusgroup is that you don't need complicated javascript
<gregwhitworth> luke: the scrollable aspects you may be able to potentially solve
<gregwhitworth> dbaron: a few thoughts
<gregwhitworth> dbaron: one is that I think some of your statements about focusgroup doesn't do this/that
<gregwhitworth> dbaron: especially about tabbing is one of the reasons why people were excited so kind of dissapointed that it doesn't do that
<gregwhitworth> dbaron: making it so that you can have a mechanism that does roving tabindex would be valuable
<gregwhitworth> dbaron: and I think it would be good to have it in this proposal
<gregwhitworth> dbaron: with relation to CSS toggles I don't think they apply to this
<gregwhitworth> dbaron: some of the concerns about toggles allows you to say, "you're building a state machine that looks like radio buttons so you should have this different focus behavior that is different"
<gregwhitworth> dbaron: your scenarios is one or two more ways more specific than that and so I think it won't hit the same issues
<gregwhitworth> dbaron: toggles was trying to determine across many different widgets and that is what we wrote in the document
<gregwhitworth> ack dbaron
<gregwhitworth> ack scotto_
<gregwhitworth> scotto_: thanks for going over all of this Travis
<gregwhitworth> scotto_: point of clarity and I updated my post
<gregwhitworth> scotto_: make it more understandable why some of the issues I brought up were brought up
<gregwhitworth> scotto_: the ARIA working group wants this
<gregwhitworth> scotto_: they want arrow key navigation with single stop and arrow keys is a common pattern and normally has the same visuals
<gregwhitworth> scotto_: where the group was getting concerned was that someone may put this on a navigation and they go to wordpress site A vs site B that look the same and the other doesn't and the keyboard user can't get through the site
<gregwhitworth> scotto_: this makes the user feel stupid since it isn't obvious when they're trying to commonly solve that
<gregwhitworth> scotto_: we've done it on products on Microsoft and we've gotten feedback that ask why we did that
<gregwhitworth> scotto_: sara higgly has done a lot of research on this
<gregwhitworth> scotto_: a lot of studies where they can't tab through cards but they can with arrow keys which is confusing
<gregwhitworth> scotto_: the stuff that this could be placed on anything and we may have un-intended consequences
<gregwhitworth> scotto_: the dev may think they're doing something good but they may not
<gregwhitworth> scotto_: the modifier key would allow you to do that. It could possibly be the opposite and if there is an opt-out then that would allow them to get the experience that they need
<gregwhitworth> scotto_: I like keithamus idea on the focus ring on a focusgroup
<gregwhitworth> ack gregwhitworth
<gregwhitworth> scotto_: the only worry I have with focusgroup behavior and roles is that using any aria attribute shouldn't change HTML attribute
<gregwhitworth> scotto_: I kind of like the idea of maybe focusgroup not being universal where it can be used everywhere and so this would result in a grid
<gregwhitworth> scotto_: then there is the scenario of if someone is using a custom element then it will need to be global, I understand that
<gregwhitworth> scotto_: point of clarity on focusing between accordion triggers and small viewport size
<gregwhitworth> scotto_: specifically to text resizing and reflow for wicag, if you zoom in or on a mobile but the arrow keys can move around
<gregwhitworth> scotto_: I was simulating the issue I see commonly come up
<gregwhitworth> scotto_: when they try to do roving tab index and you're zoomed in and you can't get to it so someone using keyboard can't get to it unless you turn on caret browsing but Safari doesn't support that
<gregwhitworth> ack brecht_dr
<gregwhitworth> brecht_dr: one thing about it being available when in a focusgroup and I would love to not need a javascript solution for focustrapping
<gregwhitworth> brecht_dr: different writing modes, I do a bunch of RTL; so when you think of a grid - it will follow the grid direction correct?
<gregwhitworth> brecht_dr: there are some caveats there and discuss visual verse DOM order
<gregwhitworth> brecht_dr: I can see this getting messy quite heavily
<gregwhitworth> brecht_dr: it would be good to discuss this even if it's the developer's problem
<gregwhitworth> brecht_dr: could this be used for button group navigation?
<gregwhitworth> brecht_dr: where you can use your arrows on the buttongroup which is done on the aria site itself
<gregwhitworth> Travis: we will get to i18n in our next topic
<gregwhitworth> ack sasha
<gregwhitworth> sasha: I haven't been too focused on it, fieldset what would happen if you set tab to it?
<masonf> q+
<gregwhitworth> sasha: that I believe is what we're talking about moving around within a scroller and it seems like we want to make accommodation to have scrolling occur over focusgroup
<gregwhitworth> s/sasha/travis
<gregwhitworth> sasha: the other question was will you make it tab stoppable so that you can jump from one group to another using arrows
<gregwhitworth> sasha: if you're within the focusgroup you can then move within that one using arrows
<gregwhitworth> Travis: that is a good question and not something I've considered
<gregwhitworth> sasha: this is a common UI scenario I deal with
<gregwhitworth> Travis: interesting. Yeah the roving index pattern would be what would allow you to jump from focusgroup to focusgroup; I think that scenario would cover that case but it wouldn't be using the arrow keys
<gregwhitworth> ack masonf
<gregwhitworth> masonf: two quick things
<scotto_> the use case of navigating from group to group to group was one of the use cases that i mentioned sarah having some user feedback on where users generally found it confusing :(
<gregwhitworth> masonf: you may have to maintain special behavior within a scroller. I think that also applies to text inputs and textareas so the behavior remains the same
<gregwhitworth> masonf: there does seem to be a big question of whether a focusgroup becomes a single tab stop or numerous tab stops
<gregwhitworth> masonf: there seems to be a tension there. As the developer I want this experience for my customers and I know it will be accessible
<gregwhitworth> Travis: maybe I didn't explain it, but both of those scenarios can be achieved declaratively
<keithamus> q+
<gregwhitworth> Travis: they can design the interaction model to match the experience they want and they set the focus using tabindex and focusgroup can still give you navigation among them
<gregwhitworth> Travis: if you want tab and arrow key that is still completely possible
<gregwhitworth> keithamus: so you just set tabindex=-1 on every element and the focusgroup index will be maintained
<gregwhitworth> keithamus: that begs the question do we need a focusgroup index?
<gregwhitworth> keithamus: tabindex anything over 0 is usually not recommended
<gregwhitworth> Travis: that is what I was trying to solve with memory that we'll get to later
<gregwhitworth> ack keithamus
<keithamus> q+
<gregwhitworth> Travis: tab will be adhered to in only one case when entering a focusgroup and that's assuming you haven't been there before and we remember that you've been there so you rever to the prior behavior
<gregwhitworth> ack keithamus
<gregwhitworth> keithamus: if you made the entire focusgroup focusable it would be the first thing that would move you to it
<gregwhitworth> q+
<gregwhitworth> keithamus: it would result in allowing you to sidestep a lot of the issues to make it a focusable element
<gregwhitworth> ack gregwhitworth
<gregwhitworth> keithamus: before it enters into the arrow key state
<gregwhitworth> q+
<gregwhitworth> ack gregwhitworth

[travisleithead]

From the above minutes:

masonf: there does seem to be a big question of whether a focusgroup becomes a single tab stop or numerous tab stops
..: there seems to be a tension there. As the developer I want this experience for my customers and I know it will be accessible

I put together a document to provide a bit more clarity on the above question: https://docs.google.com/document/d/1cOxjjZdvFfpexiN1x-MpNJLXrmbrR0xp1sRCTbaQ29c/

[travisleithead]

A digest of the CG discussion above:

• I thought focusgroup did single tab stop/roving tab index--you're saying it doesn't/confusing for page navigations? (@mfreed7, @dbaron, @scottaohara)
  • See https://docs.google.com/document/d/1cOxjjZdvFfpexiN1x-MpNJLXrmbrR0xp1sRCTbaQ29c/ for [hopefully] helpful clarification.
• Probably worth restricting focusgroup application to certain nodes (@keithamus, @lukewarlow, @scottaohara) -- e.g., not <body> or <html>
  • Moved to new issue: [focusgroup] Restrict usage of focusgroup on certain elements #1007
• Visual indicator seems valuable for the whole focusgroup area (@keithamus, @scottaohara). See also a demo by Ryan Mulligan: https://codepen.io/hexagoncircle/pen/QWMZBve
  • Support copied to existing issue [focusgroup] create a default visual indicator? #993.
• Add the word 'focusgroup' into the aria description (@keithamus )
• The concerns around feature semantics and meeting a similar fate to CSS Toggles are likely unfounded; it is more about roles and behavior (@mfreed7, @dbaron)
• Preference to more verbosity in the feature than "magic" for enabling things to work right/ don't tie the feature to ARIA roles (@lukewarlow, @scottaohara)
• focusgroups on elements with a navigable area (scroll container) should be a no-op and just scroll--but role=listbox might be an exception? Accomodate scroll over focusgroup? (@lukewarlow, sasha, @mfreed7)
  • Moved to a new issue: [focusgroup] clarify and handle cases where scrollable regions have focusgroups (accessiblity) #1008
• Would love a no-JS solution for focus-trapping (@brechtDR)
  • [Travis] focus-trapping is different from focusgroups, right? See also this proposal for focus trapping (blocking elements): Expose a stack of blocking elements whatwg/html#897
• RTL navigation order questions (@brechtDR)
  • See existing [focusgroup] i18n: should arrow key navigation follow text direction? #522
• When a focusgroup container is focused is there a way to jump to the next focusgroup from there? Users may have found it confusing. (sasha, @mfreed7)
• Make the entire focusgroup focusable (by default) so that it's always a tab stop (another alternative to tricky memory/tabindex behavior changes) (@keithamus)
  • Idea copied into existing issue [focusgroup] Why not include memory of last focused item in group? #537

[kbrilla]

Roving tabindex with focusgroup (take 2)
Needs ability to opt out from memory mechanism as for example common pattern is using tabindex=0 on selected option and when you tab into/tab back into you always want that selected item to be first focused not the last item where you were (for example using arrows). From what I understand this will not be possible as memory mechanism takes priority before tabindex=0

[travisleithead]

@kbrilla that makes sense. I'll add this note to issue #537 and think about what the opt-out will look like.

[DanielHerr]

There will be people who'll write <body focusgroup>...
I would hope people wouldn't go and do stuff like that.

a website navigation is not generally expected to be navigable via arrow keys

I would like to point out that these assertions are at best accurate only on desktops and laptops.

In particular, for smart TVs and game consoles, directional keys/buttons are the primary method of focus traversal. Tab key navigation does not apply. Therefore having the entire page be a focusgroup or utilize either a custom JS implemented or system provided directional focus system is a big improvement for the user experience when using a web browser, and an absolute requirement for building apps optimized for the platform and submitted to a store.

Reference: https://developer.amazon.com/docs/fire-tv/design-and-user-experience-guidelines.html#navigation-and-input

[scottaohara]

having worked on such interfaces, i understand your point - but also it should not require someone actually put a focusgroup on the entire body of a web page that is being used to create content that people would not know is actually web technology under the hood (unless of course they were using a screen reader with that platform - and then there are typically additional features provided by that AT which then one would also not want to have conflict with a focusgroup's behavior)