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

Feedback using Gutenberg with VoiceOver the screenreader on Mac OS X #18561

Open
tbdalgaard opened this issue Nov 16, 2019 · 4 comments
Open
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes).

Comments

@tbdalgaard
Copy link

I have now used Gutenberg for a few hours on Safari on Mac OS X 10.15.1 with the screenreader VoiceOver.

There are many good thoughts behind Gutenberg regarding accessibility, but here are a few thoughts:

  • Add blocks even when using the code editor

When working with the visual editor VoiceOver mentions the different blocks as I arrow up or down. If I switch to the code editor I can still see the blocks with some kind of Wordpress code before the HTMl. Here it would be easier for me if I could add blocks and see the corresponding Wordpress codes while I added HTML or Markdown without having to change the style of the editor..

  • Keyboard shortcuts conflicts with keyboard layouts and VoiceOver shortcuts

When looking at the keyboard shortcuts they in many cases conflict with the same keyboard shortcuts as VoiceOver uses to navigation and other functions. For instance control-option-h is supposed to show the keyboard shortcuts, but this does not work when VoiceOver is turned on. When pressing control-option-h this shortcut trickers a VoiceOver-help-command, so in order to get this command through to Safari i have to bypass VoiceOver-keyboard shortcuts by pressing control-option-tab. And some other keys does not work on a Non US keyboard. For instance the control - accent key doesn't move focus as it should regarding the keyboard shortcuts.

It would be a great help if this list of shortcuts could be opened in a new tab/new browser window instead of a small dialog which is gone when another action is performed in the Gutenberg editor.

  • Disabling the visual editor seems to shut down Gutenberg

If I go into my user profile and check the box: Disable the visual editor when writing I can not see any blocks in Gutenberg anymore. Is this expected behaviour?

  • Changing format of a block is harder in Gutenberg

I much prefer working in a code editor where I can see what a block does. If I before switching to the code editor insert a few blocks I can see some nice looking Wordpress codes. I wish this was possible to add directly from the code part of the editor since it is quite slow to change a heading via the visual editor. Great that some basic Markdown is supported though. Wish it could be ported over to the code editor part of Gutenberg as well.

The main issue for me with Gutenberg is that there are so many small elements that pops up and if I by accident move away from a field like a URL when inserting a link this take too much time for me to find again. If I could use Markdown and stil add blocks and see the code structure this could speed up my workflow, and I would know what is happening in my content area.

I can see that you have made great efforts to get Gutenberg accessibility to be great, but at the moment I find it harder to use, because I have to tab and move around a big area where many of the shortcuts either doesn't work, because my keyboard isn't English or the shortcuts conflicts with VoiceOver Therefor I hope you can add something to the code part of Gutenberg so we can get the best of both worlds and insert blocks and watch the corespondent codes as we publish our content.

I will be happy to test any future development regarding Gutenberg accessibility, so please let me know if any changes are coming.

@Soean Soean added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Nov 17, 2019
@tbdalgaard
Copy link
Author

Have tested some more, and want to make a few more comments:

  • When arrowing up or down inside the editor inside the contents of a block the keyboard focus moves from block to block. If the user edits a long document this can be a little confusing, since one keypress too much will move focus to the previous or next block depending on the position inside the block in focus.

  • When adding block headings it is not possible for VoiceOver to get the heading level. This makes editing and orientation in longer pages/posts harder to manage.

  • Keyboard shortcuts which could be nice to have at hand:

    • Move current block up or down.
    • Select one or more blocks from the keyboard.
    • Changing the current block from e.g. a paragraph to something else. The reason why is explained below.
  • Adding blocks by typing the / in an empty paragraph block: Like the idea but in some cases I have to know exactly what I need if I type /but I may look for "button," but if I arrow up or down to see the different results, my focus is taken into the block itself, and nothing did change. So I may have to memorise blocks I need or just add them manually.

@afercia
Copy link
Contributor

afercia commented Nov 19, 2019

@tbdalgaard thanks for your feedback, much appreciated. Will try to answer a few points:

1

Keyboard shortcuts conflicts with keyboard layouts and VoiceOver shortcuts

Unfortunately this is a known problem that still need to be addressed. Regarding the specific conflicts with VoiceOver shortcuts there's already an open issue, see:

Keyboard shortcuts that use the access modifier don't work with VoiceOver
#11154
Created on on 27 Oct 2018, didn't get prioritized so far.

On a more general note, the accessibility team recommended several times to implement a mechanism to allow users to remap keyboard shortcuts. It's basically impossible to find available shortcuts that don't conflict with the browser ones or the ones from a specific assistive technology. Not to mention different keyboard layouts as you pointed out. For this reasons, the only way to solve the problem would be a remapping mechanism. See this open issue:

Allow users to customize keyboard shortcuts
#3218
Also in this case, I'd like to remark this issue was created more than two years ago on October 28, 2017 and didn't get prioritized so far.

2
Disabling the visual editor seems to shut down Gutenberg

Yes this is the expected behavior: the editor turns in a simple textarea, much like the Classic Editor used to do.

3
Ability to add blocks directly from the Code Editor:

This is an interesting idea, not sure the Gutenberg team has ever considered ways to improve the Code Editor. I heard there are plans to consider a third editor mode in addition to Visual and Code. That would be an editor with syntax highlighting and maybe some tools to add and manage blocks. However, I doubt that syntax-highlighting libraries are accessible: the ones I tested completely mess up the markup making it a sort of old-style HTML soup, hardly understandable for assistive technologies..

4
There are so many small elements that pops up

Yes, I'm aware of this and as accessibility team we tried several times to outline this is a serious problem for assistive technology users. Elements, buttons, toolbars that continuously appear and disappear depending on what the user is doing in that moment may appear a "smart" interaction mode for some users, but are extremely confusing for other users. I'd say that also from an usability perspective, the continous appearing/disappearing adds cognitive load to the interface as users are continuously exposed to visual changes in the UI while they're typing. It appears the Gutenberg team, the design team, and the accessibility team have pretty different opinions on this matter and I'm not sure there will be significant changes soon.

5
Typing slash in an empty paragraph

if I arrow up or down to see the different results, my focus is taken into the block itself

i'm not able to reproduce this using Safari and VoiceOver. When I type a slash and I get, for example, 5 results, I'm able to go through them using the Up or Down arrow keys and focus stays on the 5 suggestions. It never goes to the block until I select one of the suggested blocks. When you have a chance, could you please describe the exact steps you follow to reproduce this unexpected behavior? Thank you!

@tbdalgaard
Copy link
Author

Sorry that I never got back to you. Now this is several versions later, and I have a few things to follow-up:

  • I really like that I can switch between edit - and navigation-mode. I wish though that I could find a consistent way to get the help messages spoken by VoiceOver.
  • I really think some documentation specifically for users of screenreaders is needed. I have found a few tips and tricks within Gutenberg myself, but I really wish that the screenreader was mentioned somewhere. How can I help in this area?
    I recently created the issue "Contain text cursor inside block checkbox does not restrict the cursor when editing text" Contain text cursor inside block checkbox does not restrict the cursor when editing text #42659 if the documentation was published I would not have needed to create this issue.
    I really want to help, but I am by no means a programmer, I am just a Danish accessibility trainer who teaches blind and visually impaired people how to use their screenreader and other assistive technologies, but I think this area is very important.

@annezazu
Copy link
Contributor

I really think some documentation specifically for users of screenreaders is needed. I have found a few tips and tricks within Gutenberg myself, but I really wish that the screenreader was mentioned somewhere. How can I help in this area?

If you are open to helping with documentation, that would be awesome. You can open an issue here with a recommendation: https://github.com/WordPress/Documentation-Issue-Tracker/issues You can also get involved with the docs team here: https://make.wordpress.org/docs/ and the accessibility team here: https://make.wordpress.org/accessibility/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes).
Projects
None yet
Development

No branches or pull requests

4 participants