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.

Sign up for GitHub

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

Jump to bottom

Unable to edit blocks once they've been inserted into content while using a screen reader #29526

Closed
amandarush opened this issue Mar 3, 2021 · 25 comments · Fixed by #33627
Closed

Unable to edit blocks once they've been inserted into content while using a screen reader #29526

amandarush opened this issue Mar 3, 2021 · 25 comments · Fixed by #33627
Assignees
@alexstine
Labels
Needs Accessibility Feedback Need input from accessibility [Priority] High Used to indicate top priority items that need quick attention [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Comments

@amandarush
Copy link

Please fill out ALL required sections. Bug reports with missing information will
be closed.

Before submitting a bug report:

  • Check if the bug has already been fixed by updating WordPress and/or Gutenberg.
  • Check if the bug is caused by a plugin by deactivating all plugins except Gutenberg.
  • Check if the bug is caused by a theme by activating a default theme e.g. Twenty Twenty.
  • Check if the bug has already been reported by searching https://github.com/WordPress/gutenberg/issues.

If this is a security issue, please report it in HackerOne instead:
https://hackerone.com/wordpress
-->

Description

As of WordPress V. 5.6 and including 5.6.1 and 5.6.2, screen reader users are unable to edit blocks after they have been inserted into a post or page. NVDA will allow some flaky editing of some of the less advanced blocks, but not things like the table block, Narrator allows editing of zero of the blocks, reporting "unable to take focus", and Jaws for Windows reads all text as blank whether you tab from the title field or down-arrow from it. The only thing that will read with Jaws is the blocktype: ("block heading group", "block paragraph group", ETC.).

Step-by-step reproduction instructions

Open the "add new post" or "add new page" or "edit post" or "edit page" screen. Press "E" to navigate to the title field and then press enter on this to enter forms mode or your screen reader's equivalent. Tab or arrow to the content area where already-entered content is.

Expected behaviour

Expectation is that I should be able to read the text within blocks, select, copy, cut, and paste as in either the Classic Editor or any other form field on the web.

Actual behaviour

Screen reader speaks the word "blank" while navigating through what I know for a fact to be entered text. This can be determined by exiting forms mode and then arrowing through the page. Block types are the only things that read: "block heading group" "block paragraph group" ETC.).

Screenshots or screen recording (optional)

Code snippet (optional)

WordPress information

  • WordPress version:
  • Gutenberg version: Version shipping with stable WordPress
  • Are all plugins except Gutenberg deactivated? Yes.
  • Are you using a default theme (e.g. Twenty Twenty-One)? Yes.

Device information

  • Device:
  • Operating system:
  • Browser: Firefox 86.0 and two versions back, Google Chrome 88 and two versions back, Microsoft Edge shipping with latest stable build of Windows 10, screen readers: Jaws 2021, Jaws 2020, Jaws 2019, NVDA 2020.4, NVDA 2020.3, Narrator shipping with latest stable build of Windows 10

See issue #23892 #23892 where multiple members of the WordPress Accessibility Team as well as outside accessibility experts and ordinary users of assistive technology and/or low-vision users warned that playing around with the focus outlines for blocks would produce results like this.
@alexstine alexstine added the Needs Accessibility Feedback Need input from accessibility label Mar 3, 2021
@alexstine
Copy link
Contributor

Follow-up from report on TRAC here: https://core.trac.wordpress.org/ticket/52687

While I myself don't use JAWS and primarily a NVDA/Voiceover user, it is important to ensure Gutenberg works with all screen readers. Would be great to get some further testing here to see why NVDA/Voiceover work sort of well with editing basic blocks and JAWS/Narrator fails.

I will say that the UX with editing more advanced blocks such as the table block is very bad. When I inserted a table block with NVDA yesterday I found that you actually have to select the number of columns and rows first followed by selecting Add Table button. Initially focus is placed in an empty section of the table block making users think it is okay to start typing right then instead of reading a description such as "Please select number of rows and columns to begin." There is certainly room for UX improvement here across the board.

This issue, #27521, is also related as far as more complex blocks go. I've not had time to troubleshoot it further.

@annezazu annezazu added the [Type] Bug An existing feature does not function as intended label Mar 5, 2021
@annezazu
Copy link
Contributor

annezazu commented Mar 5, 2021

Thank you for writing this up 🙇🏼 I've flagged it for a few contributors to see if someone can dig in further!

@annezazu annezazu added the [Priority] High Used to indicate top priority items that need quick attention label Mar 12, 2021
@jamiepalatnik jamiepalatnik mentioned this issue Mar 25, 2021
Open
@ggordon-vispero
Copy link

Reporting in from the JAWS development side, this is because JAWS currently doesn't offer proper edit semantics for ContentEditable="true" when paired with certain ARIA roles. In particular, role="group". Starting with 5.6 this role seems to be gratuitously assigned to ContentEditable

elements. These elements along with

already have proper edit semantics and do not need a specific ARIA role assigned. In fact assigning the wrong role breaks JAWS and I suspect Narrator as well.

I'm running a build with a more relaxed condition and editing now works fine with JAWS. But it's going to take a really long time for any JAWS build with this fix to hit all of the people running older JAWS versions with WordPress. Would you consider removing role="group" from these editable items? If you feel compelled to explicitly assign a role, document or paragraph would be good ones to use.

We'd love a closer working relationship with the Gutenberg team and I personally would be happy to be ping'ed about issues.

@ggordon-vispero
Copy link

Seems that using HTML tags in comments gets them stripped out when posted. My previous comment refered to role=group being assigned to paragraph elements in 5.6+. These along with divs already have proper ContentEditable semantics and do not need a role explicitly assigned for them to work.

@alexstine
Copy link
Contributor

@ggordon-vispero You are saying that all that needs to happen is removing:

role="grid"

and then this will work with JAWS? I just tried this while using NVDA in the browser inspector and I cannot notice it causing any issues. Happy to make a code change and see if others spot issues in testing.

Would be great to get this fully working. Is there anything JAWS users can do right now to help with this issue? Settings change, update?

Appreciate your input.

Thanks.

@alexstine alexstine self-assigned this Jun 11, 2021
@ggordon-vispero
Copy link

ggordon-vispero commented Jun 11, 2021 via email

@alexstine alexstine mentioned this issue Jun 18, 2021
Closed
7 tasks
@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Jun 18, 2021
@alexstine
Copy link
Contributor

Hello @ggordon-vispero

Sorry about the delay here, I got busy with other tasks in my personal life. I made a PR which removes role="group" from the blocks. Could you please test with JAWS and let me know the results? You can test by clicking the link below.

https://gutenberg.run/32799

Also, if you are available @amandarush , the more testing, the better.

Thanks.

@ggordon-vispero
Copy link

ggordon-vispero commented Jun 22, 2021 via email

@annezazu
Copy link
Contributor

@ggordon-vispero

Seems that Gutenberg.run has been offline since the weekend. I thought it would right itself when someone else noticed, but that hasn’t happened as of yet.

Can you clarify what issues you're running into? I just used Gutenberg.run on a few PRs and didn't have any issues so wanted to check in :)

@alexstine
Copy link
Contributor

@ggordon-vispero Sorry, that's my fault. This link should work.

http://gutenberg.run/32799

I will work on changes to add role="document" but it will take me some time.

Thanks.

@ggordon-vispero
Copy link

ggordon-vispero commented Jun 22, 2021 via email

@alexstine
Copy link
Contributor

@ggordon-vispero I am a very low-level contributor and couldn't answer the question. My best guess is you found a bug in writing flow. Writing flow is fairly detrimental to screen readers, so you can turn it off. At least one part of writing flow, the ability to keep your text cursor contained in one block at a time.

  1. Go to Options.
  2. Open Preferences.
  3. Select Blocks tab.
  4. Check the option Contain text cursor inside block.

Does this make it work any better?

Thanks.

@ggordon-vispero
Copy link

ggordon-vispero commented Jun 22, 2021 via email

@alexstine
Copy link
Contributor

@ggordon-vispero I just received my own copy of JAWS and gave this a test. When I tried without any roles, JAWS announced that the paragraph block contained text but did not read the text. When I added:

role="document"

JAWS just read "blank, blank, blank" every time I pressed arrow keys inside the block.

Is it possible that there is some type of update that hasn't gone public yet that is allowing this to work for you but not me?

Thanks.

@amandarush
Copy link
Author

@ggordon-vispero alexstine As of Jaws 2020.2107.12 adding role="document" to paragraph tags with contenteditable="true" produces the same result reported by Alex, everything reads "blank blank blank" inside blocks.

@ggordon-vispero
Copy link

ggordon-vispero commented Jul 21, 2021 via email

@alexstine
Copy link
Contributor

@ggordon-vispero When might you be available to have a meeting? I can block out time this week but next week will be limited.

Thanks.

@ggordon-vispero
Copy link

ggordon-vispero commented Jul 21, 2021 via email

@alexstine
Copy link
Contributor

Sent an email to try to schedule a meeting. I'll update this issue once I have new information. :)

@alexstine
Copy link
Contributor

I wanted to update this after the meeting I had with @ggordon-vispero . During our testing, there was a new bug found with:

role="document"

effecting blocks in navigation mode. The JAWS version 2021.2107.12 seems to work fine for me. Whenever you enter a paragraph block, it will read the text as it should and allow you to edit the text.

I am still having a problem navigating blocks in navigation mode. If you are in a paragraph block and you press escape, this puts you in virtual cursor JAWS mode. If you press escape again and land in Gutenberg navigation mode, using arrows or tab key does not allow you to move through the list of blocks. This is something that NVDA has no problem with and I suspect JAWS simply doesn't like all the changing roles. One thing I noticed with NVDA is when Gutenberg is in navigation mode and NVDA is in edit mode (same as JAWS forms mode), navigating the blocks works fine. I wonder if there is a way to keep JAWS in forms mode but put Gutenberg in navigation mode.

I'll play around with this and see where I end up, but it is clear that my PR is no longer viable. If that got merged in, it would make the JAWS situation worse, so probably best to avoid. The sad news is older JAWS versions will not receive a fix, at least not at this point in time.

In summary, I think JAWS and Gutenberg have a love/hate relationship and a lot of work needs to be done before anyone can call it perfect. I think NVDA works much better with the editor as of now. It may be wise to have an open JAWS testing session and open up a fresh issue for other problems found as this one is getting a bit long.

Let me ask around and test in the next few days and we'll determine where this GitHub issue will end up.

Thanks.

@alexstine
Copy link
Contributor

Here's a bit more information.

When working with Gutenberg, I've found Google Chrome to be way more stable. Actually, as a side comment, Firefox is painfully slow even on this very GitHub issue. Not sure why, but Chrome is certainly without a doubt faster.

One thing I noticed is for some reason when tabbing through the block list in Gutenberg navigation mode, the aria-live region is not picking up the block labels. This is something I'm going to look in to because I thought this was done as a fix for NVDA.

I found 2 work arounds to get from block to block using JAWS.

  1. Pressing Insert+F5 will open up a list of form elements where you can find the block you want to edit. Pressing Enter will successfully put JAWS in forms mode inside the block.
  2. Alt+Shift+O will open the Gutenberg blocks list view. I will say this really isn't as helpful because it doesn't read the text of the blocks. However, it does work if you need to jump from block to block. Once inside the blocks list, use b or Shift+b to move forwards and backwards in the list of buttons. Press Enter to go to the block. If in Gutenberg navigation mode, you will need to press Enter on the block to go in to Gutenberg edit mode and JAWS forms mode.

If it were me, I would choose option 1 for now because the UX for option 2 are confusing.

JAWS Keyboard Shortcuts: https://www.freedomscientific.com/training/jaws/hotkeys/

Hope this helps.

Thanks.

@alexstine alexstine mentioned this issue Jul 22, 2021
Merged
7 tasks
@alexstine
Copy link
Contributor

@ggordon-vispero I think I finally got this working.

What happens when you are pressing Tab in Gutenberg navigation mode is the button is dynamically changing under the screen reader cursor. I also found the wordpress/a11y.speak() function was ultimately not working, so turns out this would have also broken NVDA if NVDA was still having dynamic content issues. This is what I did.

  1. I added aria-live="assertive" to the block button so now every time you press Tab in Gutenberg navigation mode, it should read the updated content.
    2.I switched to role="document" so older JAWS versions can work. I finally figured out the role seemed to play no factor in this remaining issue, so I went ahead and added this in as a bonus.

If you want to give it a test, the new link is below.

http://gutenberg.run/33627

It works fine with NVDA, JAWS, and Voiceover. I think this is as cross-platform as it's going to get without major UX work.

In a perfect world, I'd have the navigation mode rewritten so you were actually tabbing down a list of buttons instead of having the button dynamically replaced on each Tab key press, but beggers can't be choosers and I think I made a solution that's 99% full proof.

Open to any feedback and hopefully getting this one closed out. 🎆 😃

Thanks for your time. This has been quite the research/trial and error project.

@ggordon-vispero
Copy link

@alexstine Thanks for spending so much time with this. I did test your change and it seems to work with both JAWS 2020 and 2021.
My tests with JAWS 2020 on a stock WordPress 5.7.2, though continuing to fail in edit mode, worked in block navigation mode once I was able to successfully get into that mode. That's no easy process because of how JAWS handles forms mode and how WordPress edit and navigation modes seem to relate. If you're in JAWS Forms Mode and editing you're actually on a contenteditable element. When you hit escape, WordPress sees it, switches to navigation mode and moves focus to a button. Meanwhile JAWS detects that focus is now on a button and switches out of forms mode. In JAWS virtual navigation mode, you can actually still arrow to the contenteditable paragraphs and press enter to go back into Forms Mode at which time you're actually back in edit mode, not in navigation mode. All that navigation mode seems to be is a button with content that changes when the button detects arrow key or tab key input, but it doesn't hide the contenteditable paragraphs and a JAWS user can easily arrow down into them. This makes it nearly impossible for someone who doesn't know WordPress well to get completely lost when using JAWS and these two modes. Now that I understand this better thanks to @alexstine, I can work to improve the JAWS user experience with this. A workaround for JAWS users in the meantime if you want to use navigation mode is to, while editing a post, turn off the virtual cursor with JawsKey+Z (insert+z on desktop, CapsLock+z on laptop). This passes all keys through to the application and will cause JAWS to more accurately honor the WordPress switch between navigation and edit modes.

@amandarush
Copy link
Author

Sent an email to try to schedule a meeting. I'll update this issue once I have new information. :)

I will send an email later today to try and schedule a time, can work on this next week. Will try the other steps listed in further comments after the one that I left.

@afercia afercia mentioned this issue Jul 5, 2022
Open
@alexstine alexstine mentioned this issue Oct 20, 2022
Open
@afercia afercia mentioned this issue Feb 14, 2023
Closed
@afercia
Copy link
Contributor

afercia commented Feb 14, 2023

I cycled back to this issue while investigating more weirdness in the various blocks and wanted to thank everyone for the discussion on this issue. It's a long reading but it's very enlightening ❤️
Related: #42158 where it is pointed out that the underlying issue is some highly undesirable inconsistency in the markup and attributes across the different types of blocks. Some high level feedback from assistive technology makers there would be greatly welcomed. 🙏 Will ping there as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@alexstine alexstine

Labels
Needs Accessibility Feedback Need input from accessibility [Priority] High Used to indicate top priority items that need quick attention [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix some JAWS bugs
Remove role group from blocks to see if I can fix JAWS.
5 participants
@afercia @amandarush @alexstine @ggordon-vispero @annezazu