Accessibility regression: Firefox and NVDA don't announce the blocks in navigation mode any longer

[afercia]

Describe the bug

In WordPress 5.5 beta 3, the blocks aren't announced any longer by Firefox+NVDA in the block editor navigation mode.

Since WordPress 5.4, the block "breadcrumbs", i.e. the buttons used to navigate through the blocks when the editor is in "navigation mode", have gone through a substantial refactoring. To my understanding, they now use a Slot/Fill implementation where a Slot is placed above the blocks list and "filled" with the buttons. The focus is then moved to the buttons to allow navigation through the blocks. This still works with other screen readers but doesn't work any longer with Firefox+NVDA.

Here's two animated GIF to compare the behavior. The GIFs don't have audio but you can see what the screen reader announces in the visible "Speech viewer" on the right.

WordPress 5.5: only the first block encountered when entering the list of blocks is announced, all the other ones are ignored:

WordPress 5.4: all blocks are announced correctly:

To reproduce

• create a post with some blocks
• on Windows, use latest Firefox and latest NVDA
• navigate to the list of blocks
• one on a block, press Escape to switch the block editor to its own "navigation mode"
• you may need to press Escape twice: 1) to exit the screen reader "focus mode", 2) to switch the editor to "navigation mode"
• once in "navigation mode", press the Tab key or Shift + Tab to navigate through the blocks
• see the blocks are not announced
• repeat the steps above on WordPress 5.4
• see all the blocks are announced correctly

[afercia]

I spent a good amount of time in the last couple days trying to find a workaround for this issue.

This seems related to the way NVDA works internally, which is basically a bug. See nvaccess/nvda#5825 and many similar reports on the nvaccess GitHub.

However, the new Slot/Fill implementation is triggering the bug. So this is a de facto regression in the level of accessibility of the bock editor. Worth noting a couple things:

• It appears pretty clear that the new implementation hasn't been tested thoroughly with various browsers and screen readers combinations: this is unfortunate, because this feature has been designed to specifically help keyboard users and assistive technology users and it's now broken.
• The accessibility team warned countless times that "playing" with the DOM in a way that element that visually belong to the same UI are actually very far each other in the DOM is an anti-pattern for accessibility. The editor team decided to not follow this recommendation and continues to use Slot/Fill implementations so that in the DOM all these elements are very far each other.

Assistive technologies are sometimes very delicate tools. Playing with the DOM this way exposes to the risk of triggering bugs and unexpected behaviors. This is one of these cases.

I don't fully understand all the implications of the bug described on the NVDA issue, but here's what I tried as workarounds so far:

• tried to set focus on another element and then move focus to the buttons: no success
• tried to set focus on the buttons after some timeout: no success
• tried to alter the buttons container HTML adding a line break or other empty elements: no success
• tried to force NVDA to switch to its own "focus mode" by setting some ARIA widget role: this works because the screen reader isn't in "browse mode" any longer but it's incorrect and can't be used

Given WordPress 5.5 is in Beta 3 now and given this is a huge regression in a feature that was specifically designer for accessibility reasons, I'm afraid at this point I don't see other ways to fix this issue other than reverting the change.

[alexstine]

I can confirm this bug. When in "Navigation" mode, Tab does not work until NVDA is switched to focus/edit mode, NVDA Modifier+Space. Once in focus/edit mode, Tab will once again announce the blocks as it should.

[mcsf]

• repeat the steps above on WordPress 5.4
• see all the blocks are announced correctly

For the record, I don't see the block changes announced in 5.4.2:

[youknowriad]

Removing from WP 5.5 Must Have as it doesn't seem to be a regression of WordPress 5.5

[afercia]

For the record, I don't see the block changes announced in 5.4.2:

I don't know how you're testing. I can reproduce consistently: on 5.4 the announcement works. On 5.5 it doesn't.

This was also confirmed by @alexstine who's a member of the accessibility team, accessibility professional and NVDA user.

When specialists in their field report something is wrong, a bit more trust would be appreciated.

I also indicated what is the root cause of the issue, so I'd expect this to be fixed instead of closed after some apparently too quick testing from non specialists. Reopening.

[afercia]

For the record, I don't see the block changes announced in 5.4.2:

@mcsf based on your GIF you tested on 5.5. In 5.4, the Row was not part of the string being announced.

(Actually, I meant to reopen the issue. I guess I misclicked something)

[youknowriad]

It is obvious by the design of the UI that @mcsf tested on 5.4 too. And I'd be curious to define who is specialist and who is not ;). The issue was not closed in the first place :)

[afercia]

It is obvious by the design of the UI that @mcsf tested on 5.4 too. And I'd be curious to define who is specialist and who is not ;). The issue was not closed in the first place :)

I think I know a couple things when it comes to accessibility and assistive technologies. Based on that, I think your previous comment is inappropriate for the standards of this community and disrespectful.

[mcsf]

When specialists in their field report something is wrong, a bit more trust would be appreciated.

Transcribing my comment on Slack here:

My testing the issue to reproduce the bug is the first step that I take as a developer if I want to fix it. And so I took that first step. When I took it, I couldn’t reproduce the issue, and so I noted that. That’s it. You’ll also note that I didn’t question your report nor your authority — I plainly stated “this is what I am observing”.

The fact that I tested was never motivated by distrust in your original report. How dysfunctional would that be?

[youknowriad]

I think I know a couple things when it comes to accessibility and assistive technologies. Based on that, I think your previous comment is inappropriate for the standards of this community and disrespectful.

I was actually referring to your previous comment #24121 (comment) where you suggest that @mcsf's testing is not good because he's not a specialist. Without mentioning the fact that we don't really know @mcsf's background, that's quite dismissing to contributors. I don't allow myself to judge whether folks are specialists or not.

[youknowriad]

Can you clarify what Slot/Fill refactor you're referring to?

AFAIK, the refactor for the BlockToolbar Slot/Fill happened before 5.4 and is included in 5.4. Is there a specific PR/issue you're referring to?

[enriquesanchez]

Tested on WP 5.4.2, with Firefox 78.0.2 with NVDA 2019.3.1

I also saw the issue where only the first block is announced when 'Select' mode is enabled:

[alexstine]

Hello,

When in navigation mode, blocks with Tab key work fine with NVDA in edit or browse mode.

WordPress Version: 5.4.2
Firefox Version: 78.0.2
NVDA Version: 2020.1

As soon as I activate the latest Gutenberg plugin it breaks. When in navigation mode with Gutenberg and NVDA is in browse mode, Tab does not work.

I am certain that this was a regression between the versions of WordPress.

Thanks, Alex

[enriquesanchez]

I tested again on WP 5.4.2, Firefox 78.0.2 but this time with NVDA 2020.2, with and without the Gutenberg plugin.

In both cases, I see the error of only the first block being announced when the editor is in Select mode and I tab through the blocks.

I wonder what other factor might be at play here?

[youknowriad]

So I've spent some time (a lot) on this issue trying to find the best path forward. Here's what I've found:

After reading the original bug on NVDA tracker, it seems to relate to the DOM order and sometimes NVDA is not capable of detecting that the focus changed. So I tried things like:

• Rendering random elements before the focused element (BlockSelectionButon) or rendering a number of elements equivalent to the selected block position before that button. Both these solutions didn't have any noticeable impact for me.

• I also tried moving the block toolbar in the DOM between the blocks, this had some impact here, the resulting behavior was a bit random and dependent on the blocks used. Tabbing generally announced the changes to the focused element, shift tabbing never announced these and sometimes tabbing stops announcing the changes as well.

• The last thing I tried is using live regions to manually announce the change to the selected block (wp.a11y.speak), this works pretty consistently but it does create duplication in announcements for screen readers that do work properly without bugs: Voiceover and other windows screenreaders.

@alexstine So I was wondering how acceptable would be the double announcement. We could limit it to windows users as detecting NVDA is not possible and even not recommended.

Even if it's a hack, I personally think it's a good solution given that the original issue is an NVDA bug and that markup changes don't seem to fix it consistently.

[alexstine]

@youknowriad I'd have to hear it to make a clear decision. I just don't understand why it works in 5.4.2 for me. I know others can replicate the same bug which makes me wonder what is different about my system.

I'd like to record an audio snippet but don't really have the tools to do it. I've not found anything that can record my screen reader audio and record my screen that is accessible.

I for one have a very unpopular opinion, but I always develop for NVDA because JAWS is not cheap and NVDA is free for all to use. I have never been in support of companies that charge crazy amounts of money to allow someone who has a lack of sight to use the computer, hints the reason I push for NVDA to always work.

Best way forward maybe is to setup a Zoom or Google Meeting and maybe I can figure out how to rout my audio through it. Maybe someone else can spot the difference I am missing about why it works just fine for me in 5.4.2.

The only thing I can think of that may be different is I am running Windows 7. I am not sure if the way NVDA works is different in Windows 10, but maybe it's a clue.

I do understand the complicated NVDA focus issues, it's very hard to solve. Often times I find that timeout functions with at least 300ms work, but not sure if that could solve our problem as I am not entirely sure how the markup looks for block modes.

Thanks.

[youknowriad]

I totally trust that it works for you on 5.4.2 but the fact that other persons (we're three on this thread) reproduce it reinforces my conviction that it's not something we can fix consistently by moving to an old version of any particular code on Gutenberg.

Maybe it's Windows's version, I'm also wondering if you have other plugins on your install and they could impact the markup, thus impacting the behavior.

If you think optimizing for NVDA is the way to go, we can do something like:

if ( isWindows ) { 
   wp.a11y.speak( blockLabel );
}

Some suggestions on the NVDA thread also implemented similar hacks. In the ideal world, NVDA fixes the issue but as the thread suggests, they tried and had to revert so I'm not sure I'd be very optimistic about a change there soon.

[alexstine]

Yeah, it's a bare bones multisite. Nothing but Gutenberg plugin and I activate/deactivate when needed.

Anyway, let's try that method in your last comment and give it a test. I am hopeful that could work.

Can you or someone else in the thread make the PR? I am still trying to wrap my head around how React works in this project, really just not there yet.

Thanks.

[youknowriad]

I can definitely make a PR for that 👍

[afercia]

I'm not in favor of using wp.a11y.speak() to remediate to this issue as it would lead to duplicate announcements for other combos, as rightfully mentioned above. Also, it doesn't solve the real root cause of the issue which is: the block "breadcrumb" it's now always rendered in the same position in the DOM.

The accessibility team has pointed out several times that rendering pieces of the same UI way for in the DOM each other is an anti-pattern for accessibility so I'd expect other contributors to acknowledge this and remediate accordingly.

[youknowriad]

As I mentioned above, I tried rendering the breadcrumb in a different position but it didn't solve the issue.

[afercia]

Here's two more quick videos. No audio because I don't have a setup to decently record audio. You can observe the NVDA Speech Viewer though.

Gutenberg block breadcrumbs WordPress 5.4
https://www.youtube.com/watch?v=B9ksxyAjifE

Gutenberg block breadcrumbs WordPress 5.5
https://www.youtube.com/watch?v=seYjDm_dxss

[joedolson]

In some extended testing, I found that there are some odd quirks that are introduced based on the blocks in use. If the post being navigated includes blocks that trigger NVDA's autoswitching to focus mode behavior, that will also temporarily create a situation where navigation mode will read the block names. The Title block triggers this switch, which means that the first navigation point after the title is always read.

But when you have numerous blocks that do this - such as groups or columns - the behavior can become very confusing.

By intent, NVDA automatically switches into focus mode if you tab to a control that requires it, and tabbing to a control that does not require it will turn NVDA back to browse mode. This isn't represented in the test examples above, but it appears that groups (and possibly columns) are handled separately from other blocks, and seem to trigger focus mode. I don't know the underlying reason for that, but including groups and any similar contexts in the normal Gutenberg navigation mode might help to make the navigation more consistent & reduce the variables being raised in testing.

The focus mode navigation works just fine; but having browse mode fail to work consistently is very disconcerting; and as a visual user, it's very easy to lose track of which mode you're in, which may have contributed to some of the testing inconsistencies here. I agree that there's no clear reversion here; the older versions do not work reliably, so until we can identify exactly what the variation in this is, I don't see reverting as a solution.

I screwed it up myself in my first set of testing, because I had changed my NVDA settings to alter the NVDA function key, so when I thought I was switching modes, I wasn't actually doing anything at all!

[afercia]

Update: this is now patched with a workaround for Windows in #24299 and it's included in the commits to backport to WordPress 5.5 RC2, thanks!

In the latest related discussion on Slack, the accessibility team agreed the workaround in #24299 can be only considered a temporary measure, given WordPress 5.5 was already in RC phase. The audible message added as workaround produces also a double announcement of other screen readers, which isn't ideal. Keeping the double announcement "forever" is far from ideal and a more perfect solution should be explored soon in the next release cycle.

[desnum]

One of our users mentions usability issues using a screen reader in Firefox. They say "I do not hear my screen reader reading the things I posted to the home page." In addition, content isn't going into the predicted places and navigation is unpredictable.

[alexstine]

The code around this has changed quite a bit since this was opened. Closing this out.