#29838 closed defect (bug) (fixed)
Post editing area: keyboard accessibility, tab order and focus
Reported by: | afercia | Owned by: | rcreators |
---|---|---|---|
Milestone: | 6.7 | Priority: | normal |
Severity: | normal | Version: | 4.0 |
Component: | Editor | Keywords: | has-patch commit has-screenshots |
Focuses: | ui, accessibility | Cc: |
Description
This ticket aims to focus on a specific area of the UI, let's call it "Post editing area", the one that starts with the "Title" field and ends with the editor area, both in "Visual" and "Text" mode.
Related: #27553 while researching we noticed:
joedolson: outstanding issues surrounding tab order, but this are long-standing and not relevant to this specific patch and issue; that needs to be raised separately.
There's room for accessibility improvements here, especially when it comes to tab order and focus management. To fully understand what's going on you should stop for a while being a "nervous clicker" :) and:
- apply the patch from #27553
- unplug your mouse and disable your trackpad :)
- use just your keyboard
- tab around, both forwards and backwards
It would be great to test also switching off your display and using a screen reader, I would recommend Firefox and NVDA.
Two main issues:
Focus.
When you're in the "Title" field and then you tab forwards, focus is moved directly inside the editor area skipping all what's in between.
While this *may* be useful for sighted keyboard users (they save a few key presses, say 1 second?), it's a very critical experience for screen reader users: when they tab forwards, they get that right after the title there's the editor. But when they tab backwards, they get many more elements that "weren't there before". more details on 27553 comments.
Tab order.
The "tabbing experience" in Visual and Text mode should match as much as possible. Ideally, there should be a better logical sequence in the markup. When editing the title, the next logical step is editing the content, all the other controls (Add Media button, additional buttons provided by plugins and themes, etc.) should not be placed between the Title and the editor. The CEUX project proposed something similar at some point.
There is ongoing research and development on the editing experience, see for example Editor Focus/DFW in #29806 and the idea to review relevant parts of the UI, see explore moving the Publish | Save | Preview buttons out of the metabox, etc. so it would be a great opportunity to explore this ticket too.
Attachments (8)
Change History (64)
#2
@
10 years ago
This ticket is a lot to absorb! I'm going to read through all of the associated tickets and test this myself so that I have a better understanding of the behavior the ticket is describing. I'll reply back here afterwards. I'd love to help work some of these issues out :)
This ticket was mentioned in IRC in #wordpress-ui by _Redd. View the logs.
10 years ago
This ticket was mentioned in IRC in #wordpress-ui by _Redd. View the logs.
10 years ago
This ticket was mentioned in IRC in #wordpress-ui by _Redd. View the logs.
10 years ago
#6
@
10 years ago
Just to keep track of the changes related to the tab order in this area, now the WP editor "toggle tabs" are focusable, see changeset 30002
#7
@
10 years ago
Interesting also for the user experience on desktop, see the video posted by Mark Jaquith. I couldn't agree more, especially about his comment on the section on the top, in the last 30 seconds.
Post editing experience on iPhone 6
https://make.wordpress.org/flow/2014/11/11/post-editing-experience-on-iphone-6/
#8
@
10 years ago
Related: #29989
See also Ryan Boren's post:
https://make.wordpress.org/flow/2014/10/16/a-survey-of-media_buttons-macnchrome-iphone-5-4-1-alpha-20141015/
This ticket was mentioned in Slack in #design by afercia. View the logs.
10 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
10 years ago
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
9 years ago
#12
@
9 years ago
New related post by Ryan Boren:
The location of Add Media on phones
This ticket was mentioned in Slack in #core by afercia. View the logs.
9 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
9 years ago
This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.
8 years ago
#19
@
8 years ago
- Milestone changed from Awaiting Review to Future Release
Discussed this during today's accessibility bug scrub and it is definitely something we'd like to discuss at WCEU, maybe also a good candidate for a feature project.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
#23
@
7 years ago
For similar issues related to the new Editor project (Gutenberg), see https://github.com/WordPress/gutenberg/issues/467
This ticket was mentioned in Slack in #design by afercia. View the logs.
7 years ago
This ticket was mentioned in Slack in #accessibility by nrqsnchz. View the logs.
4 years ago
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
11 months ago
#28
@
11 months ago
- Keywords needs-patch added
- Milestone changed from Future Release to 6.5
- Owner set to joedolson
- Status changed from new to accepted
#29
@
11 months ago
Per conversation with @alexstine in an accessibility bug scrub, he'd like to see this happen. He comments (with reference to the classic editor):"I think we should push for the improvement. To date, it's how blind people still use self-hosted WordPress."
Practically, if this is the primary tool for a group of people, we should still explore beneficial changes.
#31
@
8 months ago
- Milestone changed from 6.5 to 6.6
Given the lack of activity & patch I am punting this to 6.6 for now.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
5 months ago
#33
@
5 months ago
- Owner changed from joedolson to rcreators
- Status changed from accepted to assigned
@rcreators has offered to dive in and work on this, so I'm assigning it to him.
#34
@
5 months ago
A while ago I did start some exploration but didn't have time to move on.
29838.diff is to illustrate what I was exploring. Don't trust the code in the patch, don't commit it :) It's purely for exploration and maybe a good starting point.
Most notably, the first things I explored are:
- Remove the code meant to skip native tab stops from the post title to the post content.
- Add a new function in
tinymce/plugins/wordpress/plugin.js
to make Shift + Tab move focus from the post content to the TinyMCE toolbar. - Remove
tabfocus_elements
from the TinyMCE config. See the TinyMCE documentation for more details on what this config param is about.
I was also experimenting with selection and scroll position but that was very experimental.
#35
@
5 months ago
@afercia Not sure why, but not able to apply this patch. Giving me error at line no 51. Looking at that line looks fine to me. Just have
Index: src/js/_enqueues/wp/editor/base.js
Looks good. Stil getting errors. Can anyone try to apply this on the latest fork/branch?
#36
@
5 months ago
@rcreators sorry I was not clear. I was working on that patch a few months ago. It may not apply cleanly any longer. I uploaded 29838.diff to this ticket only to give some suggestions on where to start. I wouldn't recommend to try to apply the patch. Rather, I'd suggest to have a look at the code and get some inspiration from there.
@
5 months ago
@afercia 's patch updated to run for new wordpress. So can use to check for starting point and direction for next development.
#37
@
4 months ago
Updated patch fixes a problem with the patch formatting in 29838.patch, adds missing focus state on selected editor toggle, adds aria-pressed
attributes to report selected editor toggle, and starts adding some handling to prevent the focus change that sets the cursor position in the editor if a user switches the editor using the keyboard. (Not fully functional yet.)
#39
@
4 months ago
- Keywords needs-patch added; has-patch needs-testing removed
Restoring workflow keywords. @shailu25 Just a note; if the comment specifically says that the patch isn't fully functional yet, it's better to leave it as "needs patch", since the patch still needs to be finished.
This ticket was mentioned in Slack in #accessibility by rcreators. View the logs.
4 months ago
#41
@
4 months ago
- Milestone changed from 6.6 to 6.7
The patch still needs work, so I'm moving this to milestone 6.7. Please feel free to move it back to 6.6 if there is a ready-to-commit patch before the end of the beta phase.
#42
@
4 months ago
Accessibility Testing on: 6.6-beta2-58392-src
@joedolson The last version works fine for the Keyboard. I can switch the focus of all elements by using the keyboard. Currently the cursor inside the Classic Text Editor jumps inside the text Editor not to the focus Text button. It needs to change it as well.
For example: If you choose an image, than the cursor jumps after the image HTML Tag and not to the text Button.
This ticket was mentioned in PR #6877 on WordPress/wordpress-develop by @Benjamin_Zekavica.
4 months ago
#43
- Keywords has-patch added; needs-patch removed
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
2 months ago
#45
@
5 weeks ago
Updated patch separates the event handling between keyboard & non-keyboard events so that it's possible to avoid refocusing content on keyboard activation of the toggle.
This is still incomplete; the code in dfw.js
fires execCommand
when the editor is switched, and this forces a focus on the editor if that screen option is enabled.
Additionally, the first initiation of the editor forces focus, so if the editor initiates on the HTML editor, then is switched by keyboard to the visual editor, the editor will still focus.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
5 weeks ago
This ticket was mentioned in Slack in #accessibility by rcreators. View the logs.
4 weeks ago
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
8 days ago
#49
@
8 days ago
Following discussion in the accessibility bug scrub, we're going to revert the changes that are intended to prevent focusing on the editor, as they are a) proving to be very difficult and b) not a clear improvement, since the user intent on choosing an editor may well be to *use* the editor.
#50
@
4 days ago
Updated patch removes the code that attempted to isolate keypresses from click events in the editor toggle.
Changes now include:
- Removes code that shifted focus from title input to post content, bypassing the media and editor controls.
- Sets
aria-pressed
states on editor buttons to communicate current selection. - Makes focus state visible on unselected editor button
- Removes
wp_keep_scroll_position
conditional check since IE is no longer supported. - Adds
role="presentation"
to the table in the status info bar
I removed a chunk of code that was added by @afercia in the original explorations. It looked like it was intended to enable passing focus into internal toolbars using shift+tab
, but didn't work. I was able to fix listener and find the toolbar, but the focus handling inside those toolbars is absent, so that became a larger task. It's an accessibility improvement, but probably should be handled in a separate ticket, if at all.
Amended code, from line 1077 of /tinymce/plugins/wordpress/plugin.js
:
editor.on( 'keydown', function( event ) { if ( event.keyCode === 9 && event.shiftKey ) { var toolbar = $( 'body > .mce-toolbar-grp' )[0]; if ( toolbar ) { toolbar.focus(); } } });
As the only changes I've made since @Benjamin_Zekavica's tests are to remove the parts that weren't working, I'm considering this already tested.
This ticket was mentioned in PR #7506 on WordPress/wordpress-develop by @joedolson.
4 days ago
#51
Trac ticket: https://core.trac.wordpress.org/ticket/29838
#52
@
2 days ago
- Keywords needs-screenshots added
To provide users with the option of skipping directly to the editor, I've added a skip to editor link after the title field. This allows users to skip directly to editing, more similar to the previous experience, while keeping the tab order predictable.
Screenshots incoming.
#53
@
2 days ago
- Keywords commit has-screenshots added; needs-screenshots removed
Marking for commit.
@joedolson commented on PR #6877:
2 days ago
#55
In r59188
@joedolson commented on PR #7506:
2 days ago
#56
In r59188
This is definitely an important issue; regardless of any screen reader questions, the experience for a keyboard-dependent user in the editor is simply confusing; it's extremely hard to predict where you're going to go next or figure out how to get to certain controls via the keyboard.