Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Develop example of window splitter design pattern #130

Open
mcking65 opened this issue Oct 16, 2016 · 37 comments
Open

Develop example of window splitter design pattern #130

mcking65 opened this issue Oct 16, 2016 · 37 comments

Comments

@mcking65
Copy link
Contributor

@mcking65 mcking65 commented Oct 16, 2016

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

Note that this issue depends on issue #129.

@mcking65 mcking65 added this to the 1.1 PR milestone Oct 16, 2016
@mcking65 mcking65 modified the milestones: 1.1 Rec, 3Q17 Working Draft Oct 11, 2017
@mcking65 mcking65 mentioned this issue Jun 1, 2018
4 of 4 tasks complete
@lifeiscontent
Copy link

@lifeiscontent lifeiscontent commented Oct 8, 2018

@mcking65 any updates?

@ZoeBijl ZoeBijl self-assigned this Feb 14, 2019
@ZoeBijl
Copy link
Contributor

@ZoeBijl ZoeBijl commented Feb 14, 2019

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
Copy link
Contributor

@ZoeBijl ZoeBijl commented Feb 25, 2019

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

@lifeiscontent
Copy link

@lifeiscontent lifeiscontent commented Feb 26, 2019

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

@MrGrigri
Copy link

@MrGrigri MrGrigri commented Mar 28, 2019

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
Copy link
Contributor

@ZoeBijl ZoeBijl commented Apr 15, 2019

@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
Copy link

@MrGrigri MrGrigri commented Apr 15, 2019

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

@lifeiscontent
Copy link

@lifeiscontent lifeiscontent commented Apr 15, 2019

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

@mcking65 mcking65 modified the milestones: 1.1 APG Release 4, 1.2 CR Aug 14, 2019
@mcking65 mcking65 modified the milestones: 1.2 Release 1, 1.2 Release 2 Dec 9, 2019
@captainKAIO
Copy link

@captainKAIO captainKAIO commented May 3, 2020

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
Copy link

@lifeiscontent lifeiscontent commented May 3, 2020

@captainKAIO
Copy link

@captainKAIO captainKAIO commented May 3, 2020

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?

@lifeiscontent
Copy link

@lifeiscontent lifeiscontent commented May 3, 2020

@captainKAIO I don't think it makes sense to make it change in a responsive layout.

In the case of a window splitter, you have fixed viewport panes, and if the layout was to change based off screen size I think it would be confusing from both a technical perspective (developer would find it unreasonable) and also from a UX perspective.

I think what you have is perfect, just making it respond to touch would be ideal.

@captainKAIO
Copy link

@captainKAIO captainKAIO commented May 4, 2020

It's done. I didn't manage the swipe, but it works for a finger movement.

@lifeiscontent
Copy link

@lifeiscontent lifeiscontent commented May 4, 2020

@captainKAIO now the mouse interactions are broken.

@captainKAIO
Copy link

@captainKAIO captainKAIO commented May 4, 2020

It's a little bug, It's fixed now.

@captainKAIO
Copy link

@captainKAIO captainKAIO commented May 6, 2020

Finally, I implemented the swipe gesture like the "end" and "home" keys, it's funny

@lifeiscontent
Copy link

@lifeiscontent lifeiscontent commented May 6, 2020

@captainKAIO Nice job! The UX is perfect. The only other note I'd suggest is having the vertical splitter not be an H1, it should be a splitter itself no?

@captainKAIO
Copy link

@captainKAIO captainKAIO commented May 6, 2020

Ok, I added a "pane" paragraph to explain the screen disposition.
The window splitter pattern needs two panes for the separator and I think H1 couldn't have been a splitter itself.

@captainKAIO
Copy link

@captainKAIO captainKAIO commented Sep 13, 2020

I have a question to finalize my example with the F6 key. Is F6 used to browse all the panes present in the page or only the two associated panes?

@StommePoes
Copy link

@StommePoes StommePoes commented Sep 14, 2020

You'll need to test which browsers already use F6, because I recall some do to move around browser chrome (address bar etc). For example Chrome on Windows uses it, and I have no idea what Appley things do.

I recall Slack had to pair the F6 key with something else, or it was the reason why they also have CTRL+grave-accent, for a more cross-browser keystroke pair.

@carmacleod
Copy link
Contributor

@carmacleod carmacleod commented Sep 14, 2020

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
Copy link

@StommePoes StommePoes commented Sep 16, 2020

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
Copy link

@sinabahram sinabahram commented Sep 16, 2020

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
Copy link
Contributor

@carmacleod carmacleod commented Sep 16, 2020

@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
Copy link
Contributor

@carmacleod carmacleod commented Sep 16, 2020

@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
Copy link

@sinabahram sinabahram commented Sep 16, 2020

@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
Copy link
Contributor

@carmacleod carmacleod commented Sep 16, 2020

@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
Copy link

@sinabahram sinabahram commented Sep 17, 2020

@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
Copy link

@StommePoes StommePoes commented Sep 19, 2020

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
Copy link
Contributor

@carmacleod carmacleod commented Sep 22, 2020

@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
Copy link

@StommePoes StommePoes commented Sep 23, 2020

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
Copy link
Contributor

@carmacleod carmacleod commented Sep 23, 2020

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
Copy link

@captainKAIO captainKAIO commented Sep 27, 2020

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
Copy link
Contributor

@carmacleod carmacleod commented Sep 28, 2020

@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
Copy link

@captainKAIO captainKAIO commented Sep 28, 2020

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
Copy link
Contributor Author

@mcking65 mcking65 commented Sep 30, 2020

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
Copy link
Contributor

@ZoeBijl ZoeBijl commented Sep 30, 2020

@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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants