Why was Ctrl+Up Arrow removed for Accordion focus relocation?

[mbgower]

Until December, the editor's draft contained a keystroke to relocate the focus to the accordion header/button for the currently focused content (i.e., if I had a tabstop inside accordion content). This was a good workaround for the conflicts with Ctrl+PageUp that exist in some browsers (which moves focus between open tabs in the browser). I raised it as an issue with a jquery implementation, and it resolved the keyboard usability, but as Nico pointed out, the keystroke is no longer in the APG. https://github.com/nico3333fr/jquery-accessible-accordion-aria/issues/13

Just wondering what the rationale was, and if it can be put back in.

[aleventhal]

FWIW, ctrl+up/down are system keys on a Mac, and brings up a thumbnail view of open windows.

I think this is a bad key to recommend for any widget, and if we remove it we should do it for any other widgets as well, such as tree.

[mbgower]

Wow, @aleventhal. That's a pretty surprising key combo for an OS to steal, as it is used in a lot of situations by (Windows-based) word processors (to move between paragraphs) and html elements. What happens in a multi-select listbox when you issue Ctrl+UpArrow to move from a selected option through other options to get to a non-contiguous option you'd like to select? Does the OS steal it there as well or does Mac use another combo to achieve the same thing? If so, I wonder if the APG could still include guidance on this, but just show OS-based differences. My last Mac went to the grave a few years back, so sorry I can't check myself.

[aleventhal]

Yes it steals it in that case. I can't even find a way to select multiple items with the keyboard.

That said, I'd like to take a moment and see that 99.9% of users won't know this ctrl+arrow trick. It's truly much more usable to provide a widget that has a checkbox next to each item. In addition, with the multiselect listbox, if the user presses the wrong thing, they lose their entire selection. With the checkboxes, you can arrow to each item and press spacebar without worrying about losing your work. In fact, I almost never see the multiselect in real life, probably because sites agree that it's not a user-friendly way to go.

Just my opinion -- once you need multiple selection in a list, tree or treegrid, you should be thinking checkboxes. Supporting shift+up/down in addition to that seems like a nice-to-have if users need to select lots of items.

aleventhal commented 7 years ago

I should add that I don't know much about the accordion use case of ctrl+arrow so I'm not sure what the workaround is for this particular issue. I got a little offtrack :)

mbgower commented 7 years ago

I got a little offtrack

The funnest discussions always do. Personally I still use Ctrl and Shift with arrow keys to select stuff (with spacebar). Use fairly frequently. I take your point on checkboxes in a list, although I think that creates more tab effort since checkboxes each typically take a tabstop by default. And then you likely need a mechanism for clearing them. Anyway, getting back to the topic...

In regard to the accordion operation, the challenge is how to get to the accordion header item from within the accordion panel. If a panel has a bunch of interactive content - links, etc -- then it can get tough to get back tot he header. I've even seen implementations where only such links are in the tab order for the panel (the links become the focus point for the accordion). So if you can't issue a keyboard command to get back to the header, you can actually no longer interact with the panel.

In some ways the bigger issue is that we're dealing with trying to add application-like behaviour inside a user agent inside an OS. A lot of potential keyboard conflicts. It would be dreamy if we could just shove the browser into Full Screen mode and take it as given that all keyboard interaction would be controlled by the app until FS mode is exited.

mcking65 commented 7 years ago

@mbgower commented:

I take your point on checkboxes in a list, although I think that creates more tab effort since checkboxes each typically take a tabstop by default. And then you likely need a mechanism for clearing them.

What is meant here is:

1. Representing the selected state with a check box in a multi-select widget, not having a separate checkbox widget.
2. Making the selected state persistent as long as focus remains in the composite, i.e., you do not have to hold shift in a multi-select.

This is the selection style the Authoring Practices recommends for multi-select widgets like listbox and tree. Check out the selection model guidance in the keyboard sections of those patterns.

BTW, we still include the old-school hold-down-shift way in those patterns, but try to down play it.

@mbgower commented:

the challenge is how to get to the accordion header item from within the accordion panel. If a panel has a bunch of interactive content - links, etc -- then it can get tough to get back tot he header.

Yes, this is why the pattern includes keys for moving focus to headers.

@mbgower commented:

I've even seen implementations where only such links are in the tab order for the panel (the links become the focus point for the accordion). So if you can't issue a keyboard command to get back to the header, you can actually no longer interact with the panel.

I don't fully understand your description of this experience. On the surface, just sounds like bad design. But, bad design that the key for moving focus to the header could help overcome.

@mbgower commented:

In some ways the bigger issue is that we're dealing with trying to add application-like behaviour inside a user agent inside an OS. A lot of potential keyboard conflicts. It would be dreamy if we could just shove the browser into Full Screen mode and take it as given that all keyboard interaction would be controlled by the app until FS mode is exited.

I agree that we could get some benefit from a web-app-automatically-takes-all paradigm in full screen mode. However, even without that kind of paradigm, when focus is in specific web application contexts, there is nothing wrong with the web app capturing all keys appropriate for the context. There are so many ways to operate the chrome of a browser that material conflicts are exceedingly rare.

In the case of the accordion pattern, using ctrl+PageUp and ctrl+PageDown when focus is in the accordion context is not a real conflict. The browsers that support using ctrl-PageUp and ctrl-PageDown for switching browser tabs also support ctrl+tab and ctrl+shift+tab to move among browser tabs as well as some form of ctrl+number to go to specific tabs + many browsers have yet other ways of navigating their tab list, etc.

Why ctrl+PageUp/Down instead of ctrl+Up/Down? Because it is consistent with expectations based on similar behaviors in similar widgets.

The task force is attempting to promote consistency across patterns by leveraging similarities with desktop conventions. The goal is for different web widgets with similar functionality to feel similar to one another and to also feel like desktop widgets. Ideally, they will feel familiar and natural so users don't have to care where the software lives. You shouldn't have to think something like "oh ya, I'm on the web now so we do it this way out here."

Admitedly that is a slightly weird thing to say here given that accordions are pretty much a web thing. But, there are enough similarities between this function and the function of moving to the next tab panel that it doesn't seem like a huge leap. Because of what ctrl+up/down normally do, they didn't seem like as natural a choice.

That said, I don't recall this being a big discussion topic that is well-documented. So, this issue is rather helpful in that regard. And, there may be other task force members that may recall additional rationale or other arguments.

Judgments like this involve subjectivity and compromise. Building as much consensus as we can in open discussion is one of the most important goals of the practices task force.

Generally speaking, accordions are rather loosely defined and not one of the most common patterns. So, in my wildest dreams, it is hard to picture accordions in company A being highly consistent with accordions at company B, C, and Z.

For these less common widgets, very few people are going to be able to guess which keys will and will not work. In the long run, finding better ways of contextually surfacing key assignments would be very helpful. In this particular case, I don't think aria-keyshortcuts is appropriate ... but that is potentially debatable.

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[aleventhal]

I should add that I don't know much about the accordion use case of ctrl+arrow so I'm not sure what the workaround is for this particular issue. I got a little offtrack :)

[mbgower]

I got a little offtrack

The funnest discussions always do. Personally I still use Ctrl and Shift with arrow keys to select stuff (with spacebar). Use fairly frequently. I take your point on checkboxes in a list, although I think that creates more tab effort since checkboxes each typically take a tabstop by default. And then you likely need a mechanism for clearing them. Anyway, getting back to the topic...

In regard to the accordion operation, the challenge is how to get to the accordion header item from within the accordion panel. If a panel has a bunch of interactive content - links, etc -- then it can get tough to get back tot he header. I've even seen implementations where only such links are in the tab order for the panel (the links become the focus point for the accordion). So if you can't issue a keyboard command to get back to the header, you can actually no longer interact with the panel.

In some ways the bigger issue is that we're dealing with trying to add application-like behaviour inside a user agent inside an OS. A lot of potential keyboard conflicts. It would be dreamy if we could just shove the browser into Full Screen mode and take it as given that all keyboard interaction would be controlled by the app until FS mode is exited.

[mcking65]

@mbgower commented:

I take your point on checkboxes in a list, although I think that creates more tab effort since checkboxes each typically take a tabstop by default. And then you likely need a mechanism for clearing them.

What is meant here is:

1. Representing the selected state with a check box in a multi-select widget, not having a separate checkbox widget.
2. Making the selected state persistent as long as focus remains in the composite, i.e., you do not have to hold shift in a multi-select.

This is the selection style the Authoring Practices recommends for multi-select widgets like listbox and tree. Check out the selection model guidance in the keyboard sections of those patterns.

BTW, we still include the old-school hold-down-shift way in those patterns, but try to down play it.

@mbgower commented:

the challenge is how to get to the accordion header item from within the accordion panel. If a panel has a bunch of interactive content - links, etc -- then it can get tough to get back tot he header.

Yes, this is why the pattern includes keys for moving focus to headers.

@mbgower commented:

I've even seen implementations where only such links are in the tab order for the panel (the links become the focus point for the accordion). So if you can't issue a keyboard command to get back to the header, you can actually no longer interact with the panel.

I don't fully understand your description of this experience. On the surface, just sounds like bad design. But, bad design that the key for moving focus to the header could help overcome.

@mbgower commented:

In some ways the bigger issue is that we're dealing with trying to add application-like behaviour inside a user agent inside an OS. A lot of potential keyboard conflicts. It would be dreamy if we could just shove the browser into Full Screen mode and take it as given that all keyboard interaction would be controlled by the app until FS mode is exited.

I agree that we could get some benefit from a web-app-automatically-takes-all paradigm in full screen mode. However, even without that kind of paradigm, when focus is in specific web application contexts, there is nothing wrong with the web app capturing all keys appropriate for the context. There are so many ways to operate the chrome of a browser that material conflicts are exceedingly rare.

In the case of the accordion pattern, using ctrl+PageUp and ctrl+PageDown when focus is in the accordion context is not a real conflict. The browsers that support using ctrl-PageUp and ctrl-PageDown for switching browser tabs also support ctrl+tab and ctrl+shift+tab to move among browser tabs as well as some form of ctrl+number to go to specific tabs + many browsers have yet other ways of navigating their tab list, etc.

Why ctrl+PageUp/Down instead of ctrl+Up/Down? Because it is consistent with expectations based on similar behaviors in similar widgets.

The task force is attempting to promote consistency across patterns by leveraging similarities with desktop conventions. The goal is for different web widgets with similar functionality to feel similar to one another and to also feel like desktop widgets. Ideally, they will feel familiar and natural so users don't have to care where the software lives. You shouldn't have to think something like "oh ya, I'm on the web now so we do it this way out here."

Admitedly that is a slightly weird thing to say here given that accordions are pretty much a web thing. But, there are enough similarities between this function and the function of moving to the next tab panel that it doesn't seem like a huge leap. Because of what ctrl+up/down normally do, they didn't seem like as natural a choice.

That said, I don't recall this being a big discussion topic that is well-documented. So, this issue is rather helpful in that regard. And, there may be other task force members that may recall additional rationale or other arguments.

Judgments like this involve subjectivity and compromise. Building as much consensus as we can in open discussion is one of the most important goals of the practices task force.

Generally speaking, accordions are rather loosely defined and not one of the most common patterns. So, in my wildest dreams, it is hard to picture accordions in company A being highly consistent with accordions at company B, C, and Z.

For these less common widgets, very few people are going to be able to guess which keys will and will not work. In the long run, finding better ways of contextually surfacing key assignments would be very helpful. In this particular case, I don't think aria-keyshortcuts is appropriate ... but that is potentially debatable.