standards-support
standards-support copied to clipboard
FreedomScientific
Possible regression: new focus target is not always announced
Summary
When an element is focused via JS, screen readers will usually announce it. However, this isn't always the case with JAWS, 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.
Example:
- 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 JAWS
- Observe that all examples fail in JAWS 2021
- Observe that some examples pass in JAWS 2020 (such as example 4)
Expected result
In all examples, I'd expect the new focus target to be announced. Most screen readers do this (such as VoiceOver and NVDA). (Edit: NVDA used to be inconsistent, but they have released a fix)
Actual result
New focus target is not announced.
Additional Information
JAWS version and build number
- 2021.2102.34
- 2020.2008.24
Operating System and version
Windows 10: 20H2
Browser and version:
- Chrome 89
- FF 86
I'm also noticing that JAWS 2021 fail to read things in Chrome 89 that JAWS 2020 does read. I have an incredibly simple case here where I create a new element and focus it: https://jsfiddle.net/c4szpu2v/1/
JAWS 2020 reads "I'm the new element!" and JAWS 2021 reads nothing.
Excuse me but I'm quite new to this. Is there a way to up vote issues so that they might be given a higher priority for fixing?
I believe this to be a very important bug. It is a very common accessibility approach these days to move focus to the main h1 heading when a page opens, anticipating that screen readers will read the heading and the user will know where they are. This is particularly important when there is no HTML page load (as there often isn't) and the screen reader doesn't announce the page title. This typically also happens in other cases when new content is generated and focus is moved to it such as when a search is done and focus is moved to the results statement "showing xxx of nnn results for ***". Up until JAWS 2021 we could rely on the screen reader making this announcement but now it doesn't and you get silence. Worse still, the first down arrow after the focus move will read the next element, so the user may not come across the main heading.
Can this issue be prioritized for fixing?
This still occurs in JAWS 2022 and is a critical issue for most web apps.
Note: when I first opened this issue, NVDA was inconsistent. They have since fixed the issue. The JAWS issue persists.
@stevefaulkner any chance we could flag anyone else to have this reviewed faster? I have only just started testing accessibility recently only to run into this issue when comparing behavior with NVDA and JAWS... I don't understand how such a critical issue can be overlooked for almost a year.
@warriotox Am discussing internally with the engineers. Do you expect all of the test cases to work or just a subset?
@stevefaulkner appreciate the fast response! I am bit confused, which test cases are you referring to? I was just trying to say that I have recently joined a team that reviewes accessibility on websites and we use NVDA and JAWS and I ran into this issue where with NVDA focus was moved in one component after a button was clicked, but with JAWS it did not. I strongly believe it should work the same way as in NVDA which is why I said I dont understand how this issue is being overlooked by the JAWS team for almost a year. Hope that makes sense.
@warriotox was referring to the test cases from https://github.com/FreedomScientific/VFO-standards-support/issues/508#issue-827867752 Do you have a test case we can use to reproduce what you are experiencing?
I don't understand how such a critical issue can be overlooked for almost a year.
It's not so much it has been overlooked, its more that it is a hairy problem to solve as fixing the immediate issue can have negative effects on user experience in other scenarios. I did some testing of the various test cases provided by @mfairchild365 and found that NVDA and JAWS both had problems with the majority of the tests and unfortunately the failures were on different tests. what would be good is if there can be some consensus reached on design pattern(s) which should be supported and what the expected behaviour is.
@stevefaulkner all examples now work in NVDA and VO (MacOS). Here is my PR that fixed the issue in NVDA https://github.com/nvaccess/nvda/pull/12252. Are you still observing that some scenarios fail in the latest version of NVDA?
The use case I'm experiencing is pretty simple - user presses enter on a button with the virtual cursor active. The button uses the JavaScript focus() method to focus a div. The issue occurs with and without a tabindex on the target div. The issue also occurs with and without properties such as aria-controls used on the button referring to the div. The issue occurs with and without a setTimeout moving focus. The issue occurs in unit test field and in real world use.
It's a pretty straight forward issue and when vendors demo their products and JAWS doesn't announce the change customers assume it's an issue in the vendors products - when it's not. It's obviously also an issue for users who don't get feedback when focus moves.
@warriotox was referring to the test cases from #508 (comment) Do you have a test case we can use to reproduce what you are experiencing?
I can share one as we are currently working with LevelAccess to fix accessibility in some of our custom components we built a demo page where they can review our progress. Please go to https://www.idc.com/QA_test_section/accessibility-remediation and under the "Expandable Text Remediation" heading you will find two text expand components. This is something we are trying to make accessible even though the HTML is pretty obscure.. Focus is moved to the displayed content with JS and it works as expected with NVDA but with JAWS nothing is announced.
Are you still observing that some scenarios fail in the latest version of NVDA?
not after NVDA update... (1-11 work fine, test 12 no)
@warriotox thanks the test cases are helpful. I am working with @ggordon-vispero to get a fix for this prioritized, will provide update ASAP.
@stevefaulkner by test 12, I assume you mean example 9? (sorry for the silly numbering there)
What browser are you using with NVDA? All examples work fine in Chrome. Example 9 does not work in Firefox. This makes me suspect firefox for the failure of example 9.
@mfairchild365
I assume you mean example 9?
yes, does not work nvda/firefox
This has now been filed as a high priority bug in the internal JAWS bugzilla [JAWS Bug 129948 NEW] New: Possible regression: new focus target is not always announced. Will let you all know on progress, hopefully it will be resolved in the next 1 or 2 months. thanks to all for the feedback.
@mfairchild365 @mraccess77 @warriotox Here are the test case results for JAWS 2022.12 private beta (i believe this will be in the next public update (April/May)) + chrome Version 100.0.4896.75 (Official Build) (64-bit) / Firefox 100.0b4 (64-bit) : example 0: pass example 0.1: pass ('loading heading level 2') example 0.2: ? ('named region') - would not expect the content of a named region to be announced automatically example 1: pass example 2: pass example 3: pass example 4: fail (silence)/ sometimes pass example 5: pass example 6: pass example 7: pass example 8: pass example 9: pass