Focus V2: Separate out the DFW button from the rest of the TinyMCE editor buttons

[sharonaustin]

Using 4.1-beta2-30490 Firefox 30.0 Also related to #29838
Post editing area: keyboard accessibility, tab order and focus

I was working with a friend who has multiple disabilities, who relies on both Dragon Naturally Speaking (version 12.5) and his poor vision in order to navigate around the editor.

We went into the Distraction Free Mode to work. As he has vision problems, I saw that it was easier for him to concentrate on the task at hand because only the essential screen was presented to him (kudos to Focus V2). The problem came when he tried to "save/publish" his work.

When he first got onto the page, he instructed Dragon Naturally Speaking to tab through the page--the Distraction Free Writing button never received focus.

He considered using "mouse grid" but this is a painful, slow process to go through all the buttons in the TinyMCE bar. He would have had to do this because his vision is poor, the icons were blurry and had little meaning to him. All the icons carried the same "weight" in significance to him. Rather than face the daunting task of going through each of the icons, he chose to try to save/publish his work by going to the browser bar.

Recommendations:

Make the DFW button focusable. Move the Distraction Free Writing button up out, and away, from the rest of the editing buttons in the TinyMCE editor bar (but before the editor, so that there is a logical sequence in the tab order). Make the DFW button much different, visually speaking, than the other buttons in the TinyMCE, because all those other buttons function INSIDE the editor--the DFW has a different function in allowing one to see the components of the interface OUTSIDE the editor. This will provide stonger visual cues to those with poor vision that this button does something "different" than the rest of them, and allow them to target their limited resources to working the editor.

[sharonaustin]

Screenshot of working with Focus V2, normal vision. Note that the button with the most contrast in the TinyMCE bar is actually the "Insert Read More Tag", and the icon with the most density is the "Toolbar Toggle" button. Because of this, both of these buttons would be the ones most likely seen by those with poor vision..

[sharonaustin]

Approximation of what a person with weak vision sees when looking at the editor.

[iseulde]

Hi sharonaustin! Thanks for the feedback.
Doesn't moving the mouse out of the editor or tabbing out of it make everything fade back in so you can reach the publish button? Or what's the reason for deactivating it if it's often used by the user?

[afercia]

Replying to sharonaustin:

Make the DFW button much different, visually speaking, than the other buttons in the TinyMCE, because all those other buttons function INSIDE the editor--the DFW has a different function in allowing one to see the components of the interface OUTSIDE the editor.

From a UI perspective, I agree with @sharonaustin: the Focus button shouldn't be inside the TinyMCE toolbar since all the buttons in the TinyMCE toolbar are related to actions that take place *inside* the editor while the Focus button toggles a general feature of the UI as a whole and has nothing to do with something that happens inside the editor. They shouldn't be grouped in the same set of controls.

Theoretical considerations apart, perhaps a keyboard shortcut could mitigate this issue. The old DFW had its own shortcut, FocusV2 hasn't. I'd propose to give keyboard users a handy keyboard shortcut as a "global" UI switch, so it should work either when inside the editor and when outside.
I've tried and came up with something, not sure "Alt+Shift+W" is still ok about "Alt+Shift+F" but seems "Alt+Shift+W" is still in use and not sure if I've messed up something :) Thoughts?

[joedolson]

For clarity, the DFW button *is* focusable, but it suffers from the same focus order issue that is global to all the editor buttons, in that the controls are skipped over when tabbing forward, so it can only be reached by tabbing backwards after entering the editor.

However, the DFW mode is disabled immediately on exiting the editor, so a single tab forward from the editor should disable it.

The DFW button is only for disabling whether or not the mode will automatically turn on, not for turning it on and off, unlike the old DFW, so I'm not convinced that this is necessary.

This ticket raises a question for me:

Does DFW mode fail to turn itself off in this environment when the user tabbed forward after writing their post? If so, knowing more about the environment would be helpful.

Otherwise, I think it's just a learning question, knowing that the way out of DFW is to simply press tab.

From that perspective, I think that the 'tab' key is already the keyboard shortcut for disabling DFW, although it doesn't disable the mode entirely, just the active behavior of the mode.

[afercia]

Replying to joedolson:

For clarity, the DFW button *is* focusable, but it suffers from the same focus order issue that is global to all the editor buttons, in that the controls are skipped over when tabbing forward, so it can only be reached by tabbing backwards after entering the editor.

No :) Once you're in the editor you have to press Alt+F10 to move focus to the editor toolbar, and then you can tab through the editor toolbar buttons.

[joedolson]

Oh, of course. You're talking about the visual editor. I always forget about that.

[afercia]

And I always forget the text one :) sorry.

[sharonaustin]

Replying to afercia:

I've tried and came up with something, not sure "Alt+Shift+W" is still ok about "Alt+Shift+F" but seems "Alt+Shift+W" is still in use and not sure if I've messed up something :) Thoughts?

@afercia I've incorporated your patch on my test site, and it works extremely well. (Blown away by your code as usual) The environment for testing is (4.1-beta2-30532) which is a "WordPress Latest" from this site ​http://wordpress.org/nightly-builds/wordpress-latest.zip with the WordPress Beta tester ​https://wordpress.org/plugins/wordpress-beta-tester/ set to bleeding edge nightlies.

If a different environment other than above is required for testing patches, I would appreciate it if you (or anyone) would, please, direct me to a good source of information for doing so, and I'll set it up in the proper environment and test again.

Your patch works well, of course, but it opened to full screen, rather than staying the size of the original editor area, and it did it more quickly than the default version of Focus V2. I don't have a "feel" for what it would mean to him to open up to a full screen rather than stay within the original size of the editor box. The friend I tested with is away for the Thanksgiving holiday, and I would really like his feedback on this. I worry that there is a change of size in the editing area because he often has several windows up when he works, but he may also see it as an advantage--he may very well welcome a larger screen. As soon as he gets back, I'll ask for feedback on it. It will make his day to be able to contribute to this.

If there are any additional volunteers with low-vision workers who would be willing to test, that would be a terrific opportunity to get some more feedback on it.

@afercia, Thank you for the amazing patches.

[sharonaustin]

Replying to avryl:

Hi sharonaustin! Thanks for the feedback.
Doesn't moving the mouse out of the editor or tabbing out of it make everything fade back in so you can reach the publish button? Or what's the reason for deactivating it if it's often used by the user?

Hi avryl, thank you so much for your amazing work on the plugin; it blows me away and I think it has some really great implications for the future--not just for accessibility, but for usability.
Here's the issue: Yes all those features you mentioned "work". In the particular case of the friend, he "can" use a mouse, but it is physically painful for him to do so, and it is physically challenging for him to do so. It literally took us over an hour to open everything up and get situated....to write just one sentence. So, people like my friend rely on visual communications to take hints as to "how" to proceed through an interface.

Even stripped away to only the editor, the visual components speak unintended volumes, and he relies very heavily on the organization of visual elements to guide him through the interface because he does not have the luxury of time of using the mouse (physically painful, and he can't see the text of the tool-tip anyhow), or "mouse grid" (way way too slow), or tabbing through each button individually to see what it does (focus problem). In order to try to get through the day in a timely manner, he takes a guess out of what he is supposed to do by the layout and hierarchy of the visual components in place. This is "how" he approaches interfaces of any sort.

Visually speaking, there is no "sense" from the buttons in the TinyMCE editor that one button does something different than the other buttons. They're all gray and in a line--visually speaking, there's no "cue" that different things are going on in the buttons. Again, you know that and I know it, because we read text, and can mouse over easily, and tab in and out without losing our place, but none of that is so easy for my friend. Also, please note, that the challenges I speak about apply not only to my friend, but to many of the aged population, who are not normally considered disabled.

In visual communications, if you want to say that something is different from the rest of a group, it's a good idea to not only separate it out--i.e., move it away from the rest of the TinyMCE buttons--but to make it look different too. For example, make it "round" instead of rectangular, and just by doing those two things alone, you will be sending visual cues to people like my friend that something different is going on with the Focus button.

I'll try to put together a Photoshop image to show you what I'm talking about.

Thank you again for all your amazing work with this amazing functionality. Hugely appreciated.

[sharonaustin]

Example of a visually distinct icon meant to convey to those with vision problems that something different happens when this button is selected. The visual cues are provided because the button is a different shape than the others, and it is in a different location than the others. Without any text help, the user interface is providing information that this button is different.

[sharonaustin]

The visual cues provided by the change in the button would allow even those with poor vision to understand that something is different. This is a great boon to those who have a difficult time reading text, such as those with poor vision, or those with mobility problems.

[sharonaustin]

Replying to joedolson:

Appreciate the input and feedback, Joe, thank you!

[afercia]

Replying to sharonaustin:

@afercia I've incorporated your patch on my test site, and it works extremely well. (Blown away by your code as usual) The environment for testing is (4.1-beta2-30532) which is a "WordPress Latest" from this site ​http://wordpress.org/nightly-builds/wordpress-latest.zip with the WordPress Beta tester ​https://wordpress.org/plugins/wordpress-beta-tester/ set to bleeding edge nightlies.

If a different environment other than above is required for testing patches, I would appreciate it if you (or anyone) would, please, direct me to a good source of information for doing so, and I'll set it up in the proper environment and test again.

Hi Sharon, thank you I'm really not a great coder :) but I really appreciate your kind words.
As developers we usually set up a development environment on our local machines and use Subversion, more information here: ​http://codex.wordpress.org/Using_Subversion but it's mainly for development purposes.

[sharonaustin]

Replying to afercia:

As developers we usually set up a development environment on our local machines and use Subversion, more information here: ​http://codex.wordpress.org/Using_Subversion but it's mainly for development purposes.

Well then! When in Rome, we must do as the Romans do! I'll visit this link over the Thanksgiving holidays. I want this to be done correctly so that I am not wasting other peoples' work with the patches.

Thanks again, and have a good holiday!

[iseulde]

But the question is, do you really need to get to that button for this? If DFW is on, it will stay on for that user. When you start to write, it will fade out the rest of the UI, and when you tab out of the editor, it will fade everything back in. No need to use the mouse. Or is something broken for you?

[joedolson]

I had the same question; but didn't get a response. https://core.trac.wordpress.org/ticket/30450#comment:4

[azaozz]

30450.2.patch tweaks 30450.patch:

• Reuse the Alt+Shift+W shortcut for new DFW.
• Bind/unbind it to the Text editor only when editor scrolling is enabled. The shortcut works only while either the Visual or the Test editor is focused.
• Some small cleanups.

[afercia]

Replying to azaozz:

30450.2.patch tweaks 30450.patch:

Thanks very much @azaozz :)
P.S. the comment still says "Alt+Shift+F"

[azaozz]

In 30593:

Editor: use the Alt+Shift+W keyboard shortcut for new DFW from both the Visual and Text editors. Props afercia, fixes #30450.

[sharonaustin]

Replying to joedolson:

I had the same question; but didn't get a response. https://core.trac.wordpress.org/ticket/30450#comment:4

Hi Joe, I wasn't ignoring you, I had taken @afercia's response "as" a response and did not want to add to the "noise" in the ticket. Thanks again for your input, if I'm quiet I'm just trying to make sure I understand everyone correctly--not that I'm disregarding anyone. Thanks again.

[sharonaustin]

Replying to avryl:

But the question is, do you really need to get to that button for this? If DFW is on, it will stay on for that user. When you start to write, it will fade out the rest of the UI, and when you tab out of the editor, it will fade everything back in. No need to use the mouse. Or is something broken for you?

My apologies for the delay in response; I was waiting for him to get back from the holidays for more of his feedback to these questions. I see the ticket is closed now, and he'll be glad to hear about the work done on the ticket. We're both extremely appreciative of all the work went on with this ticket. Thank you!