Capture keyboard / reader requirments

[bkardell]

the prototype does them I think (sans open issues with #3 and #4) but I don't think we've documented them.

Also need to find a way to explain the underlying dom with the tablist/tabproxy elements for styling and explaining management of focus for sighted users (focus is transferred, for example, when your view changes because of a resize or something and the tab or panel header you are on disappears).

[LJWatson]

I think these are the basic keyboard requirements...

For panels:

• The paneltitle is in the tab order.
• Pressing the tab key when focus is on a paneltitle moves focus to the remove/close control (if it is present), otherwise it moves focus to the start of the panel content.

Panel sets:

• Only the active paneltitle is in the tab order.
• Pressing the left/up cursor keys moves focus to the previous paneltitle in the set, and activates that panel.
• Pressing the left/up cursor keys when focus is on the first paneltitle in the set, moves focus to the last paneltitle in the set and activates that panel.
• Pressing the right/down cursor keys moves focus to the next paneltitle in the set, and activates that panel.
• Pressing the right/down cursor keys when focus is on the last paneltitle in the set, moves focus to the first paneltitle in the set and activates that panel.
• Pressing the tab key when focus is on a paneltitle moves focus to the remove/close control (if it is present), otherwise it moves focus to the start of the panel content.

[bkardell]

Do you think that the selectNext / selectPrevious style method of panelset should reflect this wrap-around behavior as well? I'd think so so that you can use it to define what's happening here, but currently I've spec'ed and implemented a stop at the end based on all of the examples I've seen. Is there an example in aria-example land that shows this wrap-around behavior?

[LJWatson]

@bkardell Some examples of tabs with wrap-around navigation.

jQueryUI: https://jqueryui.com/tabs/

Open AJAX Accessibility: http://oaa-accessibility.org/example/34/

Gov.UK: https://www.gov.uk/apply-first-provisional-driving-licence

[chaals]

It makes some sense for the prototype to provide some default keyboard interaction. But to be honest I think it is important to define navigation that should be available, but a bad idea to try and link it to particular keystrokes or interactions.

The wrap-around (or not) thing depends on a lot. How tab works isn't the most valuable thing to say - it would be more useful to describe the kind of navigation that would be provided as an improvement, i.e. like Léonie has done with keystrokes, but as a set of navigation options for any given focus point.

One of the issues with arrow keys is if there is e.g. a set of inputs within a given panel, which seems an entirely reasonable use case. When does that get confusing?

[bkardell]

@chaals these seem like norms that, if you don't do, you've actually made them inaccessible - they're laid out in the aria docs IIRC, so it does feel to me like part of what makes them 'them'.

also - re: "one of the issues with arrow keys" -- is that really an issue? For example, web browsers have tabs and web pages are full of content which may contain arrow key handling, my understanding is that this works because you are given notice that you are on the tabs part vs the actual content (they're announced) and right thing in terms of handling seems to be well established, no?

[bkardell]

@LjWatson interesting.. I can certainly tweak the demo to wrap around. Does this mean that the dom APIs that allow you to select next and select previous should effectively wrap around too? It's funny, you know, a select box is a very similar selection concept and it doesn't wrap around.... strange?

[chaals]

@bkardell The right thing for keyboard is tricky - in general if you have browser functions then javascript functions somewhat randomly overlap them.

FWIW having them in ARIA turns out IMHO to be a really bad idea since they are framed as things the developer should write JS functions for, assuming that each developer manages the interaction. Which is an assumption that leads to broken interactions all over the place. :(

[chaals]

Note that this issue is a subset of #7