When an element is focused via JS, screen readers will usually announce it. However, this isn't always the case with NVDA, especially when the new focus target replaces the triggering element. This is a fairly common pattern that is found on the web, especially within dynamic widgets or single page applications.
Steps to reproduce:
- Go to https://codepen.io/mfairchild365/pen/qBbrwXv
- Activate the 'load' button in each example
- Each example will 'pass' if the new focus target is announced by NVDA
- Observe that most examples fail in NVDA 2020.4
Update: This bug is also present when focus is sent to an element that already exists in the DOM long before the trigging element is removed. This differs from my first example, where the target element is added to the DOM after the triggering element is removed. I tested this new scenario against JAWS, VO (macOS, and iOS), and NVDA. Only NVDA is silent. For example, see https://codepen.io/mfairchild365/pen/OJWydob
Actual behavior:
Some examples fail and other pass. Details of what passed and failed can be found at the end of the codepen.
Expected behavior:
In all examples, I'd expect the new focus target to be announced. Some screen readers do this (such as VoiceOver), and others are inconsistent (such as NVDA).
System configuration
NVDA installed/portable/running from source:
Installed
NVDA version:
2020.4
Windows version:
Windows 10 20H2
Name and version of other software in use when reproducing the issue:
Other information about your system:
Other questions
Does the issue still occur after restarting your computer?
Yes
Have you tried any other versions of NVDA? If so, please report their behaviors.
Yes, I tried older versions of NVDA with similar results.
If add-ons are disabled, is your problem still occurring?
Yes
Did you try to run the COM registry fixing tool in NVDA menu / tools?
No
When an element is focused via JS, screen readers will usually announce it. However, this isn't always the case with NVDA, especially when the new focus target replaces the triggering element. This is a fairly common pattern that is found on the web, especially within dynamic widgets or single page applications.
Steps to reproduce:
Update: This bug is also present when focus is sent to an element that already exists in the DOM long before the trigging element is removed. This differs from my first example, where the target element is added to the DOM after the triggering element is removed. I tested this new scenario against JAWS, VO (macOS, and iOS), and NVDA. Only NVDA is silent. For example, see https://codepen.io/mfairchild365/pen/OJWydob
Actual behavior:
Some examples fail and other pass. Details of what passed and failed can be found at the end of the codepen.
Expected behavior:
In all examples, I'd expect the new focus target to be announced. Some screen readers do this (such as VoiceOver), and others are inconsistent (such as NVDA).
System configuration
NVDA installed/portable/running from source:
Installed
NVDA version:
2020.4
Windows version:
Windows 10 20H2
Name and version of other software in use when reproducing the issue:
Other information about your system:
Other questions
Does the issue still occur after restarting your computer?
Yes
Have you tried any other versions of NVDA? If so, please report their behaviors.
Yes, I tried older versions of NVDA with similar results.
If add-ons are disabled, is your problem still occurring?
Yes
Did you try to run the COM registry fixing tool in NVDA menu / tools?
No