Develop example of window splitter design pattern

[mcking65]

The window splitter design pattern is at:
http://w3c.github.io/aria-practices/#windowsplitter

Note that this issue depends on issue #129.

[lifeiscontent]

@mcking65 any updates?

[ZoeBijl]

Given the lack of updates and my need for this—I’ve self-assigned this one.

Work on this can be followed over at Codepen.

Todo:

• Keyboard support
• Drag support
• Test test test

[ZoeBijl]

I’m struggling with drag support. Anyone that has experience with this up for a collab?

[lifeiscontent]

@MichielBijl I can help, want to send me an invite to a github repo?

[MrGrigri]

I've got a working drag example on CodePen. I was working on the drag part first and then I was going to add the keyboard interaction. I'm using CSS variables to control the width of the sidebar.

[ZoeBijl]

@lifeiscontent do you have a CodePen account? I can invite you to my example there. If not, I can put it in a repo.

@MrGrigri excellent! I’ll have a look at that, looks to be working well!

[MrGrigri]

Thanks @ZoeBijl. My example utilizes CSS Variables...so I'm not sure what the minimum requirements for W3C examples are.

[lifeiscontent]

@ZoeBijl I have an account, my username is the same as GitHub

[captainKAIO]

If I can help, I have done a complete example on codepen
https://codepen.io/captainKAIO/pen/yLYPPxX.
A note, I had a hard time defining what the valuemax was.

[lifeiscontent]

This isn’t complete. It’s completely broken on mobile.

…

On Sun, May 3, 2020 at 10:48 AM captainKAIO ***@***.***> wrote: If I can help, I have done a complete example on codepen https://codepen.io/captainKAIO/pen/yLYPPxX. A note, I had a hard time defining what the valuemax was. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABMFYZG72GCBKLQELHG2PDRPWU6LANCNFSM4CTAQAKA> .

[captainKAIO]

My intention was to implement the pattern as described. The management of "touch" or "drag" events is not one of them, but I will integrate them, it's a good idea. On the other hand, responsive design would like the splitter to reposition itself under the element. Therefore, the orientation changes. Wouldn't this change of arrow keys be disturbing for a blind person?

[carmacleod]

Firefox also uses F6, and if you type Ctrl+H to open the History side panel, you will see that F6 cycles between the Firefox URL bar, the document body, and the History panel. Last time I checked, Firefox also cycled through old (deprecated!) <frame> elements if there were any on the page. I don't recall if they also included <iframe> elements in the cycle, or maybe that was Chrome (or both).

Anyhow, I'm not sure whether the APG advice to use F6 for cycling between splitter panes is final.
So, given that it is optional, it might be best to leave it out for now.

However, I would definitely recommend the following for your particular example:

• change the <div id="pane1"> (i.e. the "Table of contents") to <nav id="pane1">
• change the <div id="pane2"> to <main id="pane2">
• maybe change the <div id="primary"> to <header id="primary"> ? (maybe with the h1 inside the header?)

That way, the panes will all be landmarks, and screen reader users will be able to navigate to any one of them using their screen reader's landmark navigation commands. Keyboard users who are not using a screen reader can navigate to landmarks using the Landmarks plugin, and someday browsers will figure out that landmark navigation is useful, and they will provide a native keyboard shortcut. ;)

[StommePoes]

Can I respectfully disagree?
As a sighted and mostly-keyboard user, who has had the sad experience of navigating dashboards... as much as I hate (in-browser) Slack's unfriendliness as far as being able to see things and scroll things at my zoom level (okay, actually, I can't. Slack's unusable if I don't have access to a yuuuge monitor), it is absolutely a godsend to be able to move between panes in whatever browser I'm in, even someone else's computer or a public (library) machine.

I feel so long as developers continue to insist on recreating desktop application windows on the web, they're required to make them work with keyboard in an approximate amount of efficiency as desktop application windows. I feel panes/panels should have a conventional or nearly-conventional set of keystrokes that allow focus to be moved between them and not rely on all keyboarders being screen reader users or happening to have administrative privileges to add plugins or other modifications to software to avoid the Thousand Tabs of Death.

I mean vimperator was nice but I can't imagine telling students in a school they need to stick to a particular browser so they can use a website. We already have that problem regarding AT-browser compatibility :(

[sinabahram]

I must agree with @StommePoes on this issue. I also do not feel it is appropriate to ignore a pattern that has existed for decades, which helps keyboard users save so very many keystrokes. F6 is a wonderful affordance that facilitates this. While it is true that Apple is making their laptops less usable and less accessible to keyboard users by making function keys far harder to access, I hope we don't fall into a pattern where the suboptimal (in my opinion) usability decisions of one manufacturer adversely affects the entire web for all. I bring that up as it is the usual objection to including f6 advice.

[carmacleod]

@StommePoes

Can I respectfully disagree?

Absolutely! And thank-you for making me go take a closer look at the Slack markup... I thought that their "F6 desktop/Ctrl+F6 web" behavior was navigating strictly through landmarks (that mostly happen to be in panes). Now that I look more closely, I see that even though 3 of their "panes" are indeed marked up as <nav>, <div role="navigation">, and <div role="main">, they are "cheating" in a couple of other places and just jumping to div-things that are not properly marked up as landmark regions. I will grump at them for that. They need to make those be <section> or <div role="region"> and give them an accessible label so that screen reader users can use their landmark navigation keys to get to them.

We actually agree with each other, you and I, but I have an ulterior motive. ;)
Sorry I didn't explain it earlier.

Here's the back story: I would like the browsers to support keyboard landmark navigation. All of them. Natively. For everybody.
I will be working more on this in the near future, but for now, here's a github issue that has a bit of a summary (feel free to give it a thumbs-up 😄): WebWeWant/webwewant.fyi#63

In the web-a11y slack, there's also this post: https://web-a11y.slack.com/archives/C042TSFGN/p1596129362456100

The most likely keystroke to use for landmark navigation on the web would be Ctrl+F6 (and Ctrl+Shift+F6 for reverse). Browsers have already taken F6/Shift+F6... and even though the behavior is similar-ish, it probably doesn't make sense to overload it. Also, between the platforms and the browsers, there's not a lot of other possible keystrokes. Maybe some combination of backtick (grave-accent), as you mentioned. Note that Slack's Alt+backtick goes directly to the message text input, and does not navigate through the landmarks.

So, back to the Window Splitter pattern discussion in this issue, and my ulterior motive. Since F6 is pretty much taken by browsers, I was worried that Ctrl+F6 might come up in this conversation, and I very much want to keep that one available as a possible keystroke for native landmark navigation. Mind you, if it's possible to use F6 (and Shift+F6) to successfully navigate through the browser trim and then through the web content (panes, frames, and maybe iframes) and then back through browser trim, and if that doesn't feel weird, then by all means use F6 (without the Ctrl modifier) to do so. Come to think of it, it would be a good experiment to try it with the current example, as long as it's tested in Chrome, Edge, FF, and Safari. It would be great to know whether or not that works out.

On a related note, looking at the APG advice for Window Splitter panes, I see that there's no semantic markup suggested for the panes themselves (other than they happen to be elements that have a splitter between them), and I think we should be giving advice for panes to be semantically marked up as landmarks, because that's really what they are.

[carmacleod]

@sinabahram I noticed your comment as I was finishing up my response to @StommePoes - hopefully I have explained my thinking well enough, above.

However, now I have a follow-on question for both of you:
Do you actually use F6 on the web? If so, where? (other than just "go to URL bar", "go to body")?

[sinabahram]

@carmacleod that does help a lot, but I think we should be careful, as you stated, not to conflate f6 and ctrl+f6 with your absolutely wonderful mission to promote landmark navigation. I feel like those can be thought of as similar goals but not until recently would people maybe map them as such. For example, you saw that with Slack. I've flagged those unlabeled regions to them several times to no avail, by the way, so good luck to you friend and thanks for reporting them (more voices make a difference).

In addition to Slack, we used f6 really affectively to make the various areas of the WeScheme blocks project accessible. That's the treeview example with the online IDE whose link I sent into the Zoom on our previous to last ARIA deep dive call, "Trees, part 2". In that context, the students could use f6 to navigate between the definitions area, code area, and error messages from the compiler, which totally freed us up to use tab, shift+tab, and other keystrokes to facilitate better accessibility within their respective sections. Plus, f6 was necessary as tab is super-tricky when we talk about editors that must implement indent support like in a REPL where you want to use tab for autocompletion and then shift+f6 into the console output, then f6 back to the editing area.

On desktop applications, it's obviously widely used, and as @StommePoes points out, devs are replicating desktop experiences on the web, and have been for years, so I want to at least have the same mediocre level of accessibility we all have on desktop, not something worse on the web sad but hopeful smile. Hope that helps.

[carmacleod]

@sinabahram So, with WeScheme, were you able to take over the F6 key without anyone getting upset with you for stealing their favorite "go to URL bar" shortcut? Or did you somehow (maybe by selectively calling event.preventDefault() in the F6 key event handler??) manage to incorporate the browser's F6 navigation ring into the WeScheme panes navigation ring?
If you stole the key, then were you able to tell people "Sorry, we stole the F6 key for our app, so you'll just have to get used to using Ctrl+L/Cmd+L to go to the browser's URL bar"? I'm just not sure that's going to fly if all web apps start doing that. People get used to their shortcut keys. :)

However, your point is taken that we should be careful not to conflate f6 and ctrl+f6 with the mission to promote landmark navigation. :)

We should run a contest for the best keystroke suggestion for landmark navigation. Has to be something that's not already used by the platform, or the browsers, or any screen readers or other AT. Need to be able to pair it with Shift key for reverse navigation. Likely can't use Alt key (without stealing), because Mac already stole most (all??) of the Alt key combinations for entering special characters into text fields, and we want to be able to navigate out of those. Ideally shouldn't use function keys because of recent Mac keyboards only having virtual function keys. Should be ergonomically feasible on at least a majority of keyboards of all languages. If anyone out there knows of such a key shortcut, please pass along the knowledge!

I'm only half-kidding about the contest. Winner gets recognition and lots of appreciation and they get to proudly say, "That's my key shortcut!". ;)

[sinabahram]

@carmacleod, we were targeting Chrome rather heavily for that project, just due to Chromebooks and other reasons, but I remember checking that there were at least three other ways to get to the address bar e.g. alt+d, ctrl+l, and even with shift+tab from top of document. I don't know if I have a good sense of how many folks use f6 to get to the address bar as opposed to those methods instead, but wen three other ways existed, it felt like an acceptable trade off.

As for not using function keys because of Mac, I'm really troubled by this. I'm deeply frustrated by a similar notion that came from our treeview conversation that we must use the same keys across platforms. That one regarded enter and space. I find this a losing proposition doomed to absolute mediocrity in the best case, and it just goes downhill from there.

My Frustration:
Apple removes function keys, so the billions of devices in the world with function keys now just don't get any benefit from them on the web anymore, full stop?

Why does a single vendor's design decision get to limit the affordances for an audience with already limited affordances. I truly reject this constraint as being a defacto constraint, but for some reason a lot of folks seem ok with it, which puzzles me.

If you have function keys on your platform, then use them, and if you don't, then map to something more appropriate. Is the lack of availability of home/end without modifiers on a Mac next? Will it simply be wrong to support home and end moving to beginnings or ends of lists? This is simply a race to the bottom where we are letting competing design decisions amongst vendors slowly carve away anything other than the most simplistic affordances in the name of cross-platform compatibility. That feels deeply wrong to me and I reject it.

Perhaps off topic for this issue, but also not off topic because of your keystroke request. And, please note, my frustration is in no way with you but with this notion of universality of keystroke constraint.

[StommePoes]

I was away :) I'm personally a ctrl-L person for reaching the address bar, but F6 allows me access to the OTHER thingies in the browser chrome, like plugins.

I was working with a team at $previousEmployer where we were trying for F6 (or more likely, ctrl+F6) for a multi-pane dashboardy thing for teachers. Each "pane" wasn't necessarily a landmark, but each section had either a heading or a hidden heading; almost everything was some kind of form control or group of form controls, for creating content, pop quizzes and whatnot. This meant each area had just a crap-ton of focusables, so moving quickly to whole areas was necessary, and I had picked F6 because of its desktop history and somewhere in some guideline there is a single, brief mention :)

[carmacleod]

@sinabahram You are not alone in your frustrations about keyboard shortcuts. I tried not to be frustrated when I was writing down all the constraints for the "ideal" shortcut key, but what I was thinking is that there are no "ideal" shortcut keys available any more. 😢

As for not using function keys because of Mac, I'm really troubled by this.

No worries - I was just saying "ideally". In reality, we still need to use function keys. My Mac has physical function keys, so I have no experience with the new Mac Touch Bar... so I googled how VoiceOver works with it, and function keys are at least doable. The Touch Bar works kind-of like an iPhone - the user can hold down the Fn key (bottom left of keyboard) and either swipe or slide over the touch bar to select which function key to type, then double-tap to type it. It's sub-optimal (particularly while trying to hold down shift and command), but still possible.

I looked into some modifier+backtick/accent_grave key shortcuts, and they seem to be taken (in Chrome DevTools for go to console, and as a reserved shortcut on Mac... sigh - that's another type of constraint I forgot about earlier). Anyhow, I'm pretty sure that the only keys that even remotely make sense for landmarks are Ctrl/Cmd+F6 and Shift+Ctrl/Cmd+F6... which is why I am jealously protecting those keys. ;)

I'm deeply frustrated by a similar notion that came from our treeview conversation that we must use the same keys across platforms. That one regarded enter and space.

The initial motivation for that was #1438, but we should keep that discussion over in w3c/aria#1311. :)

we were targeting Chrome rather heavily for that project, just due to Chromebooks and other reasons, ...

That makes sense. I got in trouble years ago for using Ctrl+L (Cmd+L on Mac) as the shortcut for "Go to Line" in our online code editor (I had reasoned that there were other ways to get there, like F6 and Alt+D... but apparently Cmd+L is the only way in Safari). A user made a scathing remark about us stealing the URL bar shortcut, so I guess I'm a bit sensitive about it. :)

@StommePoes

Each "pane" wasn't necessarily a landmark, but each section had either a heading or a hidden heading; almost everything was some kind of form control or group of form controls...

But they could've been landmarks, right? Given that a section with a heading (and an aria-labelledby pointing to the heading) is a landmark, and a form with an accessible name is a landmark, could all of those panes have been marked up as landmarks? Even the groups could have been wrapped in a div with role region and an aria-label?

@captainKAIO
Sorry about the tangent! I'll try to circle back to the current issue about window splitter and F6...

In comment 68 in the FF landmarks issue, Marco Z said:

F6 already is being used in Firefox to switch between several major browser components, so cannot be used to also switch between landmarks on a page, or this will become very confusing.

So I'm guessing that he would say the same thing about using F6 for navigating between panes.

However, if you're up for it, it might be interesting to at least know whether F6 could somehow be integrated into the browser's "F6 ring" so that it would navigate to panes AND into (and out of) the browser trim (url bar, sidebar(s), tablist, bookmarks, etc). I'm only guessing that this might be doable by moving to the next/previous pane in an F6 key event handler and then calling event.preventDefault() unless you were in the last pane on the page moving forward, or the first pane on the page moving backward.

I haven't tried this, and I'm sure there's something I haven't thought of, but if it could be made to work, maybe it would be an acceptable compromise because it's technically not stealing F6... just augmenting it with a few panes. :)

[StommePoes]

But they could've been landmarks, right?

Only if it's okay to have like 20 landmarks on a page :)

But complex rocket-driving dashboards aren't web pages so some of these rules we tell each other don't land neatly (another complex dashboard I ran into was in an audit and yes it was used by, among others, NASA)

[carmacleod]

Only if it's okay to have like 20 landmarks on a page :)

Heh, good point, but might be better to have 20 landmark hops than 100 tabs. ;)

some of these rules we tell each other don't land neatly

Agreed. The 2014 WebAIM survey indicated that somewhere between 4-6 landmarks was "optimal", although some folks said more than 10.

But by the time you have a header, footer, main, a couple of navs and an aside, you're already at 6... so if that was a hard limit, many pages would have no room left for anything app-specific in custom regions. Those app-specific regions might ultimately be the most useful ones of all with regard to jumping back and forth between all the dashboardy bits and panes that someone is actually using to get real work done.

I do wonder if keeping "pane navigation" separate from "landmark navigation" would be useful, or just complicate things. I don't know the answer... just asking the question out loud. :)

[captainKAIO]

I think that HTML5 element and WAI-ARIA landmark roles easily navigable in Firefox discussion is usefull for this issue. F6 seems to be used for "level 1" landmarks, Panes can be "level 1" landmarks or not. Must we use F6 key for panes?

[carmacleod]

@captainKAIO Did you mean to link to https://bugzilla.mozilla.org/show_bug.cgi?id=670928 ?
If so, which comment were you referring to?

[captainKAIO]

I'm refering to comment 59 which present F6 and ctrl+F6 key on firefox.
if a pane has no focus, where F6 key goes ?

[mcking65]

I just raised issue #1546 with a proposal for addressing the key assignment issue aspect of the window splitter pattern as well as several other similar patterns.

[ZoeBijl]

@mcking65 I asked around and it turns out that Esc is supposed to bring focus back to the main content area if you’re in the browser chrome on macOS. This is implemented in Safari but not Chrome. Which makes me think that’s a Chrome bug.

Steps to reproduce:

1. Open Safari
2. Navigate to any page
3. Use the Tab key to navigate to some random element
4. Press Command+L to go to the address bar
5. Press Esc to close the suggestion panel
6. Press Esc to return focus to the element that last had focus on the page

[captainKAIO]

I have changed my html code to have landmark panes. I implemented also fixed panes on my example.
Note : To toggle with the mouse or touch on fixed pane, I chose to apply the following effect: if the movement exceeds half of the pane then toggle

[patrickhlauke]

Randomly, I came across a test implementation that seemed to follow the pattern described in https://www.w3.org/WAI/ARIA/apg/patterns/windowsplitter/ ... but unfortunately it didn't work well at all in Chrome/Firefox and Jaws/NVDA (and the various combinations thereof). with tabindex="0" on the splitter, to actually make it focusable, neither AT went into forms mode by themselves, so had to be manually switched into it to make the cursor keys work. Jaws outright refused to announce the current value, and did not announce any change to it. So real-world support for this seems a bit flakey at best at the moment.

[MrGrigri]

I've got a working drag example on CodePen. I was working on the drag part first and then I was going to add the keyboard interaction. I'm using CSS variables to control the width of the sidebar.

I have updated my example to be fully keyboard compliant. I believe that a couple of things should be added to the specification. I have added an aria-orientation to the separator as mine will dynamically shift between vertical and horizontal depending on the viewport's width. The other thing could be some sort of step value. I move the separator every five pixels, but this is customizable. And from what I have researched there isn't an aria-stepvalue attribute to indicate to the user the amount that each arrow key would nudge the separator.

[patrickhlauke]

Randomly, I came across a test implementation that seemed to follow the pattern described in https://www.w3.org/WAI/ARIA/apg/patterns/windowsplitter/ ... but unfortunately it didn't work well at all in Chrome/Firefox and Jaws/NVDA (and the various combinations thereof). with tabindex="0" on the splitter, to actually make it focusable, neither AT went into forms mode by themselves, so had to be manually switched into it to make the cursor keys work. Jaws outright refused to announce the current value, and did not announce any change to it. So real-world support for this seems a bit flakey at best at the moment.

Incidentally, we ended up ditching role="separator" and instead turned it into a conceptual role="slider" (with an appropriately descriptive aria-label to convey it's a splitter/separator, and changing the aria-orientation to be perpendicular to the direction of the separator ... although not all SRs actually announce the orientation anyway, so might as well omit that and double-up keyboard behaviour so that left and down decrement, and up and right increment, regardless of actual visual orientation). this then finally got Jaws to actually announce the current value and any changes, and it makes Jaws and NVDA go into forms mode when focused.

Long story short: the currently documented pattern here has really flaky/broken real-world support. This should be noted in the pattern, and ideally be fed back to SRs.

[JAWS-test]

Related: FreedomScientific/standards-support#237 and FreedomScientific/standards-support#489

[george-cz]

Hello @patrickhlauke, I've been recently building a resizable panel library for a major Microsoft product and we ran into the same issue. I was initially using the role="separator" on the handle, however a quick investigation showed that the support for this role among VO, NVDA and Jaws is sub-par compared to the "slider" to the point where it's unusable.

For now we've gone with the "slider" role, however I want to follow up on your note "the currently documented pattern here has really flaky/broken real-world support. This should be noted in the pattern, and ideally be fed back to SRs.".

Are you aware of any work in progres for any of the mentioned screen readers to fix the support for "separator"? Have you followed up with the SRs on any capacity?

Thanks!