Add keyboard shortcuts à la Slack to jump through the main UI sections #467
Comments
afercia
added
[Focus] Accessibility (a11y)
|
OK the last two points are a bit more clear now that I had the opportunity to have a look at more mockups on https://wpcoredesign.mystagingwebsite.com/gutenberg/ 🙂 |
|
Good list, thank you.
Just to confirm, this relates to the markup, correct? Thankfully since we're exploring absolute and fixed position for this, it should be no trouble to move the toolbar markup below the editor content markup. Incidentally as I'm typing this, @afercia confirmed that yes, it was markup specific in chat.
Visually the publish button won't be changing its location from the old editor. It's still in the top right corner.
Here's a blueprint of the design: The action buttons are Undo, Redo, Insert. The editor toggles are preview and post settings, the latter which opens the sidebar. The sidebar is visible by default, by the way.
This would still be after the "Add Media" one, in the top. Since that is fixed and scrolls with you down the page, it's always accessible. There's also an inserter inline in the text: #323
Not currently, but I will definitely add it to the list. Where would you put it? I really appreciate the detailed and actionable input you have on accessibility, please keep providing that. I would also ask for a faith, as the bet on a block-first UI might appear a departure from how post editors have traditionally worked. Inserting media, for example, is radically being rethought as inserting blocks, of which media is simply a type. This is not to say the new editor can't be made accessible — nothing gets merged unless it's accessible — just that we are treading new ground in places. We are racing towards a plugin that we can test on real users, including screen readers. Hopefully that will help inform the best next steps to take. |
Ah ok, I was assuming it was closed by default, as in the screenshot posted on Slack.
That WCAG requirement just says visual and tab order should match, i.e. if you put the toolbar on the top then it should be before the editor in the markup. That makes thing a bit more complicated 🙂 absolute positioning won't solve the issue, same for other CSS techniques. See https://www.w3.org/TR/WCAG20-TECHS/C27.html
I have no idea 🙂 Users would expect to find it in the usual place, but that's not possible here. On the other hand, the current Help and Screen Options placement in WordPress is far from ideal. Wondering if it is worth considering some refactoring. I've just realized there's one important thing missing in the new editor screen: the main Thanks for your clarifications and the additional mockups, they helped me a lot to better understand some of the things here that were not so obvious at first sight 🙂 |
Wouldn't that be the optional title in this mockup? |
|
No, that it's inside the editable region and empty for a new post. The main h1 is actually used for navigating content, see https://make.wordpress.org/core/2015/10/28/headings-hierarchy-changes-in-the-admin-screens/ |
|
I'm assuming we can't display: none that one either. One of the goals of the rearranging of UI is to free up space. There are SO very very very many features in the editor, a decade of cruft that's built up, some which isn't even used widely anymore, like trackbacks. It is a noble goal to have an editor where every single aspect is 100% accessible, but the reason I'm asking for some faith in a few of the things we're doing is that we have to balance this against modernizing the UI, which means de-emphasizing some features in favor of a better overall editor experience. No, that doesn't mean those deprecated features can't be made accessible, but I do hope we can be open-minded about where they might sit in the editor structure. Would it be possible, at a later date, for you to take part in a quick zoom video chat about this? I'd love to try and explore solutions together in a higher bandwidth format than only text. |
|
Having a cleaner UI helps accessibility too so I'm definitely OK with that effort :) However that shouldn't happen at the expenses of removing fundamental accessibility features.
Maybe, it could use |
|
In light of how people are sharing content nowadays, a forced H1 input field is a stumbling block for many who just want to take a photo and upload it to their site. Or maybe they just want to share a quote, or link, or audio track... In many of these instances, the user may not want a title (h1). While I understand this is helpful for screen readers, I'm opposed to making it a requirement for posting. The way it's currently being explored (as an optional heading within the content) seems like a good solution to educating the user, but not forcing them to do it. I'm curious to see how this is solved. :) |
|
@mapk I'm not speaking about headings within the content 🙂 By the way, the headings issue is secondary on this issue. The main scope here is the order and grouping of controls in the toolbar, which is not ideal in my opinion. I'd greatly appreciate this could be discussed by the design team. |
|
@afercia Sorry about that, my mistake. Thanks for the clarification. Would something like this solve the issue? I've added the word "Editor:" to the Toolbar. That word could be an H1, but styled to match the surrounding interface. The dropdown "Visual" would not be part of it, and not affect the H1. Seems like it might fit nicely with tab order too. |
|
Cross posting from #503 :) ... together with re-considering the ordering and grouping of controls. I'd also like to see this being discussed by the design team and be open to the community feedback. As far as I know, a real, broad, discussion hasn't happened yet. One more potential issue is about controls that use icons only. Icons don't have a universal meaning. I don't fully understand why some controls have only icons and other have icons plus some visible text. What't the reasoning behind that? Also to consider, there are functions in WP that provide labels to be used by CPTs for this screen. Integrating such a change wouldn't be so easy. |
|
One more issue: I see in the mockups a "by author" UI component places immediately below the toolbar:
I guess this is meant to be the author select. However, having it in the tab order right after the toolbar is not so ideal from an a11y and usability perspective, where controls should be grouped logically. Wondering if it should go in the sidebar, together with all the other metaboxes. |
|
See also #1375 (comment) |
|
Based on @afercia argument for a more logical grouping of elements @moorscode and I made this mockup. Gains:
|
|
I'd add that the "Save" and "Preview" controls are strictly related, for example: |
|
This is a very important interface, as it is literally the top level bar. It is not easy to get right, and I like what someone said on another thread: it's good to explore many interfaces, then discard many of them, so only the best remains. However as it is, I'm trying to figure out how to best address issues, because there are a lot of different considerations to balance, which I'll go into in a second. As such, I consider the key purpose of this ticket to ensure the editor bar is accessible. I understand that logical grouping is key to this. But I would ask that as we discuss what makes a specific grouping "logical", that we consider the future as well as the past, and mobile, as well as desktops. Reading through this thread many times, I can't help but feel like you can make arguments for why almost any grouping of items is "logical", and as such I feel like accessibility and mobile should be the razors to which we decide which way to go. Let's go over the considerations. 1. Editor type/mode switcher This is, I feel, a weak design in its current implementation. We are tracking separately how this can be improved. There's also a separate issue to ensure there's a heading for the editor, whether visible or not. But such a header could inform the left side of the editor, it could perhaps even help inform a good design for the editor type switcher. 2. Save state indicator This is above all else an affordance for describing the save status of the document, and show errors when auto-saving fails for whatever reason. The grand idea here is that in modern web-apps, there exists no save button. Documents are automatically saved in the background, and all you need to know is that yes — it's saved, it says so right there. I feel like we should all consider the "Save" action to be vestigial and transitional, something that should eventually not need to exist at all, except for edgecases like when saving fails (Retry?) or you're offline. Admittedly there are issues with how saving works right now, including an issue with autosave not actually working. These issues obviously need to be fixed separately. But though computational design we can save the user from having to think about the document being saved, or having to click a button all the time. If we agree this is a desireable future, then we shouldn't optimize any designs for a save button, we should optimize for a save state indicator. Incidentally keeping this in mind, it helps present an answer for the very real and specific issue that Andrea brings up — that saving and previewing are tied together. To me the solution that presents itself is that the preview button should never be disabled, because the document is "always saved". I know that isn't the case right now, but given that being the end goal, a non-disabled preview button on a completely fresh document should then simply save the document, then preview it, when you click the button and the document is unsaved. See also:
3: Publish button We shouldn't always reinvent the wheel when it comes to interfaces. It's important to design according to established patterns. In this case, the publish button sat in the top right corner in the old editor. It was a splash of blue, and it remains a splash of blue. It follows the pattern of many online editors, and even offline editors where "Share" is the closest equivalent, and often sits in the top right as "the final action" — the Enter key on the right side of the keyboard. To me it makes the most sense to put it here, next to Preview and Settings, as those three are likely to be actions you utilize after writing your document. Preview and Settings are both grouped together because I can easily see "Preview" not being just an external link, but indeed a toggle, just like Settings is today. It's a button that has an active state, and that active state could be split screen preview (untoggles the settings bar), or a modal that lets you resize an iframe preview to various device sizes to preview on mobile, tablet, or desktop. As such it would be grouped with the Settings button because they'd behave the same. 4. Undo, redo, insert Keeping in mind that the editor is document level actions, it makes sense to have an area that contains such buttons. You could imagine future plugin hooks letting you add more buttons here. As such, these feel like they should be grouped together somehow, simply by virtue of the fact that they "manipulate the body content". These are right-aligned to mimic the mobile pattern of having an "app bar" with title on the left (or centered on iOS), and action buttons on the right. Responsive On a meta level it's extra important that we get the groupings right, because on mobile, all labels, and even some buttons (undo/redo/plugin actions) get hidden. And so as you scale down a viewport it's important that when buttons/labels "pop off", what remains still feels like it's placed in the right locations. Then what Given all that background (sorry for the wall of text, but it's important), and all those considerations, I'm personally biased that what we have now works pretty well, and is worth launching with. This is an interface that I've worked on for 6 months, and is influenced from wp.com learnings, so it hasn't come together from nothing. But that doesn't mean it has to be this way. I do expect this editor bar, including grouping, to be honed and changed and tuned a fair bit as we go, and I'm not at all opposed to changes. If anything, the only suggested changed I'd be against, is optimizing the interface for a "Save" button. IMO we should do everything we can to improve this interface by eliminating it. Take the publish button on the left — this feels like a WordPress branding change. Look at the old editor and squint: you'll see black bars left and top, a white area center, and a blue button in the top right corner. This is largely intact in the new editor, intentionally so. But that doesn't mean it can't be done. Windows has close buttons on the right, and MacOS has close buttons on the left, after all ;) |
|
Thanks for clarifying, Joen! it's great to hear all the ambient context that's not formally documented per se but that informs your design process. Good points about the save button and preview behaviour. We designed the above for what is there now because we didn't know what the intention behind everything was. Knowing now, we'd love to help refine the toolbar further (in a new issue). You're right, let's keep this a11y-focused. |
|
Wall of text, much words. Good!
Totally agree, thank you for making this point. 2. Save state indicator 3: Publish button
Our approach was based on the principle that, in left-to-right based languages people are scanning from left-to-right in most situations. Having the "most important" button being introduced in subconscious focus makes it very easy to locate whenever somebody is done. Though this argument would better suit the "save" functionality, as you might want to do that before visiting the "settings" or "preview".
Having a more "Customizer"-like experience for previewing sounds like a really good concept. As such it would be grouped with the Settings button because they'd behave the same. As I see a possible user flow for writing a new post would be:
This suggests that the Preview, Settings and Publish / Finish functionalities should logically be placed together. We put the "Publish" button on the left, because is feels very boxed in on the right, especially with the settings opened: In the current design, it has much more breathing room and stands out much more: This was one of the itches that we tried to resolve in our conceptual proposal. 4. Undo, redo, insert
The concept is clear, but on mobile the screen is much smaller and the buttons will always be in range of the place where they have actual influence.
Then what
Our intention is not to destroy or ignore anything that has made this come together at all.
Yes, yes, yes! It is absolutely usable and workable for anybody, but one of the things that people are not very comfortable with is change. So it would be nice to point out any elements that might not be optimal and see if we can give them the space, attention and location they deserve without making it a change in a future release when people are already used to where and how they are placed. One of the selling points (if not -the-) is that WordPress is so easy to use. Though I think we should not fixate on keeping things exactly as they are now.
You have convinced me that the publish button might not have to be on the left, but honestly I think the whole Gutenberg approach is a WordPress branding change, thus it feels a bit of a non-argument to use in this context. |
|
@jasmussen I kindly disagree 🙂
That's not exactly correct:
Actually, Gutenberg is not following an established pattern. Instead, it's changing it placing the Publish button before the editor. As I've mentioned in the related PR #1963 I think it's something to experiment but I feel it's not an ideal solution, we're not still there. I'm not so convinced the "Publish group" should be on the top left. However, it makes a lot of sense to me to group it with actions or state indicators that are logically related. If in the future the "save" button/indicator will disappear, that's good! Currently, it's there and we have to deal with it. Ideally, Id like to see anything that comes before the title and the content just disappear. When I think at what I see as an ideal editing workflow, I'd like to be able to:
I think this is an established pattern, as for years and years any web interface based on forms has a submit button at the end of the form. The Customizer has the Save button on the top and over time we've received lots of complaints about that. Re: too many things at the top, I'd recommend again to have a look at the feedback on the core Ticket I've posted above: where two influential voices of this project express doubts about all the controls that come before the editor, especially on mobile. Not to mention on mobile devices my hands are at the bottom of the screen.
You've convinced me. This is one more reason why they shouldn't be mixed together with all the other controls that are more related to the editing tool or the publish state.
wp.org has some learnings too :) |
|
Really good discussions here. Impressed by the level of discourse 👏 I will digest and respond more in-depth later. Wanted to quickly address two quick points. First off, I didn't mean to dismiss past WP.org learnings, nor that any changes are off the table now or long-term. Secondly,
I'm still thinking on how to address the tab order issues the top bar introduces, and have been since you opened the ticket for it. Questions on that:
I've been looking at other patterns to take inspiration from. Google Docs appears to set focus on the editable area first, and then on to the top toolbar after. Is this kosher? Are there examples of great and accessible online editors where publish/share/done-editing actions visually live above the content? |
Yes, visual order should always match tab order. Aside: not only a WCAG requirement, also the CSS Flexbox and CSS Grid specs explicitly state this.
No it doesn't 🙂 that's why #1963 doesn't fully convince me yet. I like the grouping there, though.
Not so much, but elements are in the right order, it's more like setting initial focus in a form with a very specific task to accomplish. Google Docs maybe is not the best example though, since it is designed more like a desktop application than a web app. The provide the very-easy-to-remember shortcut
None that I'm aware of (I mean I don't know of any online editor that's fully accessible). Just imagine you're using the keyboard and your post has 30 or even more blocks. You're on the last block, and then you have to publish... 😎 |
|
Worth considering also the discussion about pluggable areas, see #1352 |
|
Still thinking about this one. I still do understand why this is important (so you don't have to tab through all the browser chrome, then invoke a "Skip to content" link so you can get to publish). I'm also still not convinced that actually having the toolbar be only at the bottom is the solution. Please also bear with me if the following is a bad idea, this is why I'm asking for your expertise. Thanks for your patience and input. |
I'd be happy if at least the Publish button was after the content in the markup 🙂 Or, maybe, add a second Publish button at the end of the content, in the area close to the second Inserter button. If I remember correctly, the presence of the Paragraph and Image block buttons there was still something to make a final decision about:
We're also missing one important point: the Settings button should be immediately followed by the sidebar (always speaking about order in the source). However, in the spirit of trying to find a balance between different needs, I've been thinking at an option I'd like to discuss with you and anyone interested (designers, a11y team, etc.). 1 keyboard users: Move focus to the next section: Control + backtick Of course, we shouldn't use backtick because it's not available on all keyboard layouts. 2 screen reader users Landmarks allow screen reader users to quickly jump from one section to another section and WordPress is already using it. We should re-organize them in the Gutenberg screen, which is already using one landmark: For example, the whole sidebar could be Pending discussion with the team 🙂
|
|
A publish button after the content could be an option. But the keyboard shortcuts for moving between sections idea seems like it could be an amazing enhancement regardless of other improvements.
Just because it was quick to draw up, would the following design potentially help with that? CC: @melchoyce
|
|
Yep the button new position would help! Then we should try to move the whole sidebar in the source before the content #riskylife As per the shortcuts à la Slack and the landmarks, that should be paired with a well documented an well communicated help section. |
|
Per the Slack discussion on 8/7/2017, the accessibility team agrees that implementing a keyboard shortcut similar to what Slack does to navigate between the major regions within Gutenberg is definitely worth pursuing. Using the backtick as the Ctrl + {trigger} is problematic, due to the lack of a backtick character on many international keyboard layouts. Given that Gutenberg is not yet using any keyboard shortcuts, determining this shortcut should be part of the overall discussion on adding keyboard shortcuts in #71. ARIA Landmark roles should be used to provide screen reader navigation between regions. The sidebar should definitely be an The top toolbar is more complicated. It would be nice to give it a role of Giving the top toolbar a role of |
|
@joen I'm cool with that mockup ^ |
|
Cross-reference to #1963 : link to recommendations and backing research here |
afercia
changed the title
|
Agreed during last G. meeting to rename this issue to better reflect what's needed here. ARIA landmarks were added in #2380 and they allow assistive technologies users to quickly jump through the toolbar, editor, sidebar:
A similar mechanism should be made available to keyboard users and shortcuts à la Slack seem the best option. They should allow to jump through the ARIA landmarks above. A strong indication of focus when jumping to a section would also greatly help, exactly like Slack does. All the interface content should be inside one of these 3 regions. To get a rough idea of what Slack does, here's the region you can jump to pressing Cmd?ctrl + backtick:
As per the toolbar controls order and grouping, there's a lot going on at the moment and discussion is happening on separate issues. |
Reference: looking at the screenshot posted on Slack on https://wordpress.slack.com/archives/C02QB2JS7/p1492621873449513
The toolbar:
The order and logical grouping of controls/links/info is fundamental for accessibility, and also usability. There are many things to consider here, will try to highlight some general issues.
The Publish button:
The Editor experience should be a
type type typeexperience. For accessibility, add to that sometab tab tabexperience. 🙂 Keyboard users and screen reader users will expect the Publish button to be after the editing area. That's the convention for any form. Placing it before the editing area would repeat the same mistake done in the Customizer with the "Save" button. Forcing users to tab backwards or explore the content to find the Publish button would be extremely confusing and annoying.For keyboard and screen reader users, navigating content is a linearized experience that follows the order of elements in the markup. So the Publish button should come after the editor in the markup.
Worth also noting that the WCAG state the visual order should match the tab order.
I'd say this is also an usability issue, since the logical workflow when editing a post is:
Enter the title > Enter the content > Publish
The other controls/info etc:
The position of the other controls should be carefully considered too. Probably some of them can be placed before the editor. However, the most important thing here is they should be logically grouped.
I know this is just a first implementation and many things are probably temporary, but worth considering that currently these controls are a bit mixed up and there's no a clear, logical grouping.
Trying to list their different purposes:
I may be wrong on some of them 🙂 but my goal here is to highlight they have a different nature and purpose, so they should be grouped accordingly. Off the top of my head, a possible grouping could be:
I'd say the group 1. should be placed as close as possible to the content, in a place that's very easy to reach when tabbing. These are controls that get used often while editing content so reaching them should require a minimal effort.
Groups 2. and 3. are probably going to be used not so often as the first group. I'm curious about the plus "+" control though, since it's a bit unclear what it will reveal when pressed. Same for the "Post Settings".
Some of the issues about "what's around the Editor" were discussed also on https://core.trac.wordpress.org/ticket/29838 where one of things considered was to remove anything that comes before the editor and place it elsewhere. This is especially true when it comes to mobile devices. I'd recommend everyone to follow the links in the ticket and watch the videos / read the posts by Mark Jaquith and Ryan Boren.
Additional considerations:
The text was updated successfully, but these errors were encountered: