[focusgroup] Action of the Home and End keys

[benbeaudry]

trafficstars

Someone suggested to me that the HOME and END keys move the focus to the first/last focusable element within a focusgroup when pressed while the focused element is a focusgroup item.

Thoughts?

[benbeaudry]

@travisleithead

[scottaohara]

@benbeaudry if this has not already been answered outside of this thread, this would be quite welcome functionality

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[travisleithead]

Current plan:

• Add default handing for 'Home' and 'End' keys to move to the beginning/end of the set of focusgroup candidates.

[gfellerph]

Would this be 'Command + ArrowLeft' for 'Home' and 'Command + ArrowRight' for 'End' on a Mac?

[css-meeting-bot]

The Open UI Community Group just discussed [focusgroup] Action of the Home and End keys, and agreed to the following:

• RESOLUTION: Home and End keys (or platform equivalent) work by default for linear focusgroups to move focus to the start and end.

The full IRC log of that discussion

<Travis> scribe: argyle
<argyle> scribe: argyle
<argyle> scribenick: argyle
<argyle> scribenic: argyle
<keithamus> scribe?
<argyle> scribe argyle
<argyle> scribe me
<argyle> @Travis
<argyle> @travis: a linear focus group is a list of focusable items, the arrows move focus a expdcted. should home and end keys work to move to end and beginning?
<masonf> q?
<masonf> q+
<dandclark> q+
<argyle> @masonf i would have assumed it was automatic yes
<masonf> ack mason
<argyle> @Travis i dont believe so. will note, in aria practices guide, they mention if the list is wrappable (no begin and end) then home and end don't make sense. there surely is a beginning and end, but thats my opinion.
<argyle> @masonf are focusgroups wrappable by default or opt in?
<scotto_> q+
<argyle> @Travis opt in by default. not rolodex style, where it would cycle, it gets to the bottom and focus goes to the top
<masonf> ack dan
<argyle> @dandclark lets agree, do it for nonwrappable ones. wrappable ones, lets go with the guidance and not do it.
<masonf> ack scott
<argyle> @scotto_ reiterating previous points, top and bottom ends, focusgroup makes sense where it already happens. but if it's a list of links, that's not what would be expected, rather scrolling the browser would need those. lets not break this pattern of top and bottom of page. yes with caviats.
<argyle> @Travis a grid pattern came up, a grid of links, you can use home and end to get around. footers with lots of links may be nice to not have a tab stop for each one of them. but it's at the bottom for a reason
<argyle> @scotto_ the grid is a good example of the contention between ewhat's useful and whats' not. nvda and jaws may enter forms mode, and those cells may or may not tell you whats inside. link or not, may not know. if you do nav by links. screen readers may get confused. arrow keys may operate in a conflincting way. catch 22, where arrows will help for patterns, we'll be running into issues where screen readers and focus groups with arrows may be
<argyle> battling. folks would have to know what theyre in and undo features, just so it works correctly
<argyle> masonf: is there something the UA could do to fix this up? to remove the work from AT and into the browser for a more natural flow?
<argyle> scotto_: good Q, last i understood, each AT handles this on their own. they've made their decisions based on elements. then there's VO and narrator that do different things.
<argyle> masonf: if they're already keying on the element type, they'll need taught was a focusgroup is no matter what
<argyle> masonf: i thought there was an easy resolution, but i'm less sure now. travis?
<keithamus> argyle: in a nested scroll area does home/end work contextually or resolve to the page?
<Travis> PROPOSEDRESOLUTION: Home and End keys work by default for linear focusgroups to move focus to the beginning and end
<argyle> my testing shows nesting scrollers dont handle home and end keys as we suspected
<argyle> scotto_: not saying no, but we should figure it out and make sure folks understand it (nested links for example)
<philippg> q+
<argyle> masonf: with select, the browser can detect when you're doing it wrong and hitn them to some education. here's why and what to do. could be the path here
<argyle> scotto_: yes, even with those warning tho, i'm dealing with developers and they ignore them
<argyle> @scotto_ instances where, the ACT rules that are being written to check accessibility, so many times these things that popup are being dropped because of a 1% use case it would be considered a false positive. so we dont bring it up at all.
<argyle> @scotto_ i'm worried these warnings popup and developers cast it aside because it's not blocking
<argyle> @masonf no way around that, even in the 1% warning case
<argyle> @masonf one other thing, browser lighthouse score, one of the things should be that you dont have any of these warnings
<argyle> @scotto_ a non-negligence score?
<argyle> @Travis if you really wanna elevate it, put a star in the address bar. they'll do wehatever it takes
<argyle> @scotto_ yeah we can warn people, but lets open a different issue about this, so we can talk through what to do here. is it really a warning or is there something we can get buy in from various groups. we want it to work for everybody
<argyle> @dandclark not an objection, for mac is this cmd+arrow right to do the same thing? answer is yes. not sure if there's a platform agnostic way to articulate the key bindings. i support resolution but we should investigate a platfrom agnostic key set
<Travis> PROPOSED RESOLUTION: Home and End keys (or platform equivalent) work by default for linear focusgroups to move focus to the start and end.
<Travis> RESOLUTION: Home and End keys (or platform equivalent) work by default for linear focusgroups to move focus to the start and end.