Setting focus to an element: NVDA doesn't announce it, when elements around it are set to aria-hidden!

[jmuheim]

I want to create a proof of concept of a dialog box (without ARIA, only plain HTML and some basic JavaScript).

I want the focus to be set to the title of the dialog as soon as a button "open dialog" is pressed. To make the background invisible to the screenreader while the dialog is open, I set everything around the dialog to aria-hidden="true".

Interestingly, while this works nicely in JAWS and both FF/IE, NVDA seems to have problems with setting stuff to aria-hidden, as it doesn't announce the title of the dialog then (in both FF and IE). When I remove the line in the JavaScript that sets aria-hidden, NVDA announces stuff correctly.

A working demo is on CodePen:

http://codepen.io/jmuheim/pen/eZvyXq

Use the debug view for screenreader testing:

http://s.codepen.io/jmuheim/debug/eZvyXq

Can anybody tell me how I can force NVDA to announce the title even when I set aria-hidden to all elements around the dialog? I don't see any reason why it shouldn't.

[jmuheim]

I have added a delay of 5secs to make sure the items are "really there", but this doesn't seem to solve the problem.

[jcsteh]

In short, this is a bug. :( However, the reason it occurs is a bit obscure (it took me a good 20 minutes to figure it out) and difficult to fix without breaking other use cases. Basically, in browse mode, NVDA reports focus changes only if the browse mode cursor isn't already within the focus. We do this because unlike JAWS, NVDA moves focus as you move the browse mode cursor. While this has some big advantages, we need to make sure we don't handle a focus change caused by moving the browse mode cursor. In this example, when you hide the content, the browse mode cursor snaps to where the hidden content would be placed if it weren't hidden, which is the start of your content area. The dialog heading is at the start of the content area. So, when NVDA compares the browse mode cursor with the position of the heading, they match (the start of the content area), so it doesn't report the focus change. The workaround would be to have some text (even a <br>) at the start of your content area that doesn't get hidden when the dialog appears. However, that's an unacceptable hack. The correct solution is for us to find a way to fix this, but I have no ideas at this stage as to how we can do that. Dev note: We should consider this when looking at #2039 again.

[Laughingthunder]

What if you just make the behavior that you describe optional, even if you leave it enabled by default?

On Mar 22, 2016, at 9:29 AM, James Teh [email protected] wrote:

In short, this is a bug. :( However, the reason it occurs is a bit
obscure (it took me a good 20 minutes to figure it out) and difficult to
fix without breaking other use cases. Basically, in browse mode, NVDA
reports focus changes only if the browse mode cursor isn't already
within the focus. We do this because unlike JAWS, NVDA moves focus as
you move the browse mode cursor. While this has some big advantages, we
need to make sure we don't handle a focus change caused by moving the
browse mode cursor.

In this example, when you hide the content, the browse mode cursor snaps
to where the hidden content would be placed if it weren't hidden, which
is the start of your content area. The dialog heading is at the start of
the content area. So, when NVDA compares the browse mode cursor with the
position of the heading, they match (the start of the content area), so
it doesn't report the focus change.

The workaround would be to have some text (even a
) at the start of
your content area that doesn't get hidden when the dialog appears.
However, that's an unacceptable hack. The correct solution is for us to
find a way to fix this, but I have no ideas at this stage as to how we
can do that.

Dev note: We should consider this when looking at #2039 again.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[jmuheim]

Thanks for this quick answer.

The workaround would be to have some text (even a
) at the start of
your content area that doesn't get hidden when the dialog appears.

I've done this, and it leads NVDA to announce the element as "edit" and switch to focus mode. Not really what I intended. ;-)

See http://s.codepen.io/jmuheim/debug/WwjNoQ

[seanriordan08]

I've found a cross-browser compatible solution like so:

1. Check for windows

isWindows: function () {
  var operating_system = navigator.platform;
  return (operating_system == "Win32");  // If os is windows, return true
}

2. Add a 'dot' matching the background color, just above your revealed text input:

if (this.isWindows()) {
  this.ui.input.before("<div class='nvda_dot' style='color:white;line-height:0'>.</div>");
}

3. Then when you choose to hide the text input, just remove the 'nvda_dot'

if (this.isWindows()) {
  this.ui.input.siblings('.nvda_dot').remove();
}

Cheers

[s-robertson]

I'm experiencing this same bug, as described by @jcsteh. Replacing an element on the page with another element and focusing that element will not cause NVDA to read out of the contents of the new element if it was in the same position as the element being replaced.

Here is a working example, where the new element is being appended, rather than replacing an existing element. NVDA will read the new element out loud.

https://codepen.io/s-robertson/pen/MrVBOG

And here is an example of the bug, where the new element replaces the button you click. NVDA will NOT read the new element:

https://codepen.io/s-robertson/pen/zpWamp

[seancurtis]

Is there any plans to fix this soon? A customer of ours that uses NVDA as their screen reader raised a bug with us relating to our dropdown menus and how bad the keyboard support is. We've built them with accessibility in mind, and the focus issue only occurs once they turn NVDA on :(

I've tested in Narrator and Voiceover but they work perfectly. Could you let us know if there are plans to fix this bug?

[wongvincent]

I'm also experiencing this bug, where an element that is originally hidden, replaces an item in the same position and receives focus. NVDA doesn't read out the contents of this focused element, whereas Voiceover on Mac reads this perfectly. We also build with accessibility in mind and it'll be great if there are plans to fix this!

[seancurtis]

Are there any plans to fix this @jcsteh?

[jcsteh]

I'm no longer a primary developer (I now work for Mozilla), so I'm not the right person to ask about this. Certainly, I'm not likely to get to this any time soon myself.

[seancurtis]

Oh grats!

Maybe I should have mentioned @michaelDCurran, @feerrenrut, @lukaszgo1, or @LeonarddeR instead (just going by recent commit history)

[feerrenrut]

@seancurtis Looking over the history of this issue, despite the fact that we understand the problem it's clear that it will be difficult to fix. Especially considering other use cases. We believe it is important to fix, and have given it an appropriate priority.

[seancurtis]

@feerrenrut thanks for the reply. As a component builder who tries to make things as accessible as possible, focus management is a crucial thing we need to handle. It'd be awesome to have consistent support for things like programatic setting of focus across the various screen readers.

[AlmeroSteyn]

I believe my current situation is related to this issue. In a React application, I am replacing some content with other content showing the result of the action. Because the React reconciler re-uses the DOM elements as far as possible, the net change in the DOM is that the container tags are re-used.

After displaying the result the code then sets focus on the container element. And NVDA does not announce anything. The focus remains inside the container and that is why I believe it is related.

If I set focus outside the container first the focus action is announced just fine.

I drilled it down to the following React code:

import React, { Component, Fragment } from "react";

class Section extends React.Component {
  constructor(props) {
    super(props);

    this.sectionRef = React.createRef();
  }

  componentDidMount() {
    this.sectionRef.current.focus();
  }

  render() {
    return (
      <section tabIndex="-1" ref={this.sectionRef} aria-labelledby="headingId">
        <h2 id="headingId">This should be read out</h2>
      </section>
    );
  }
}

class App extends Component {
  state = { showSection: false };

  onClickHandler = () => {
    this.setState(prevState => ({
      showSection: !prevState.showSection
    }));
  };

  render() {
    return (
      <Fragment>
        {this.state.showSection ? <Section /> : null}
        {this.state.showSection ? null : (
          <section>
            <button type="button" onClick={this.onClickHandler}>
              Show/hide
            </button>
          </section>
        )}
      </Fragment>
    );
  }
}

export default App;

If I remove the conditional render of the second section it also gets announced just fine.

P.S. The section tag around the button element is wrong HTML, I just did this to recreate the issues in as little code as possible.

[epatpol]

Any workarounds you guys have to force NVDA to read the focused element when it's replacing something?

[jcsteh]

This is fixed by #8869 (now in NVDA alpha builds). I've verified the fix for @jmuheim's test case from #5825 (comment) and @s-robertson's test case from #5825 (comment).

[simong]

Is there a possible regression here? When trying @s-robertson's test case with NVDA 2019.1.1 in Firefox NVDA is not reading out the "I am a message". Here's what I'm doing:

• Click anywhere in the result frame
• Hit tab once, the button is now focussed
• Hit enter, the button is now clicked and swaps out the button for the message

Result: The message is not read. Is this expected?

[nmorris2]

I am still having this issue as well, with Firefox and NVDA 2019.1.1.

[lukaszgo1]

It's caused by the fact that #8869 was reverted. This issue probably should be reopened cc @Adriani90

[Adriani90]

Thanks very much for reporting. I am reopening this issue.
cc: @jcsteh, @michaelDCurran

[aloeugene]

Hi all,

I've stumbled upon almost the same situation as described in the initial report, but I have a little bit different elements' behavior. Also, it's reproducing only for NVDA + IE11.

I have the following setup:

In short: when no items are added to comparison, on button click the error block appears and focus is applied to it. If I click/keypress the "X" button, error message is removed from DOM and focus is set back to the "Compare" button. When focus to the button is triggered from "X" icon, error message hides, focus switch happens, but isn't announced.
However, when I don't hide error message OR trigger hiding of this message with setTimeout with 500ms delay - everything works fine, button receives focus and is announced...

My issue doesn't involve setting of aria-hidden, just removing element from the page/DOM.

[JamesCatt]

Is there an ETA on a fix for this? From reading #8869 it sounds like it may be a real challenge to solve.

If there's no ETA that's fine—just trying to decide if I should try to implement a workaround in my code or ignore the issue and wait for it to be fixed in NVDA.

[MIKOLAJW197]

Any fix/workaround for this issue?

[LadynRed]

We have a 2-step dialog/modal and we run into this bug. The first part NVDA reads out fine, but when hiding the 1st 'page' to display the 2nd, NVDA won't announce anything and even though the developer is setting focus to the h2 on this 2nd page, NVDA stays at the button, so you have to back-tab/up arrow to get to the new content to read it. Since I'm the only one testing our apps with NVDA, it makes it difficult to do that testing. I can't confirm NVDA and we have to rely on VoiceOver on Macs (we don't have JAWS) to pass thru the QA process. For this one, we're just using jQuery, no other js libraries.

[chintan97]

Hi all,

I've stumbled upon almost the same situation as described in the initial report, but I have a little bit different elements' behavior. Also, it's reproducing only for NVDA + IE11.

I have the following setup:

In short: when no items are added to comparison, on button click the error block appears and focus is applied to it. If I click/keypress the "X" button, error message is removed from DOM and focus is set back to the "Compare" button. When focus to the button is triggered from "X" icon, error message hides, focus switch happens, but isn't announced.
However, when I don't hide error message OR trigger hiding of this message with setTimeout with 500ms delay - everything works fine, button receives focus and is announced...

My issue doesn't involve setting of aria-hidden, just removing element from the page/DOM.

Thanks for the timeout solution. Unfortunately, it is not working for me. Is there anyone else facing the same issue?

[afercia]

Hello! I do realize this issue is hard to solve, that's clear to me since the first comment by @jcsteh.

I just wanted to report, for what is worth, that this issue is biting WordPress hard on a specific implementation that will be shipped in the next release. Very shortly: some buttons are always rendered in the same DOM positions and although their content changes and they get focused, NVDA doesn't announce anything when it's in browse mode.

Whether we like it or not, as pointed out previously by @AlmeroSteyn, this kind of implementation are more and more common because of React and the like. Any help or suggestions for a simple workaround would be greatly appreciated 🙂

[millertn]

Bumping this thread, we just ran into this issue as well, any plans for a fix?

[AndrewEastwood]

+1

[guyhickling]

I have another situation that I think might be related to this, but with a problem about where NVDA's virtual cursor is left. I currently am testing a Single Page App (SPA). When the content is refreshed, to go to what in an ordinary website would be the next "page", focus is placed on the main h1 heading but it is not announced. That would be explainable by the above bug.

However it doesn't seem to be a simple case of simply not announcing things. I see that the virtual cursor remains at the foot of the new "page", even though keyboard focus has specifically been moved to the top. In other words, when the new page has loaded, if I press the Tab key, focus moves to the first interactive item in the main content, as you would expect.

But if I press the down arrow key after the page load, NVDA moves out of the bottom of the main page content and announces the page footer. (Further down arrow presses then go through the footer menu options.)

So the Browse mode virtual cursor is left at the bottom of the page even though tabbing behaves correctly. Does this sound like part of the above bug?

[RD8388]

the Browse mode virtual cursor is left at the bottom of the page even though tabbing behaves correctly. Does this sound like part of the above bug?

Suffering the same issue after dynamically loading content. The content is being read out as a result of adding aria-live="polite" to the container but if I press the down arrow on the keyboard the reader jumps to the page footer.

[ehollig]

There is a lot of history around this issue, as well as the fix.
When testing the steps in the original Codepen, activating the "Show dialog" button correctly reads the "This is the dialog title" heading.
In order for this heading to automatically read, "Automatically set system focus to focusable elements" must be on.
This can be turned on by pressing NVDA+8, or navigating to NVDA > Settings > Browse Mode and enabling the checkbox.
I am closing this as worksforme. Please open a new issue with clear steps to reproduce if you encounter a similar issue.