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.

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

Fieldsets that contain a checkbox grouping does not read the legend at times #3321

Closed
nvaccessAuto opened this issue Jul 1, 2013 · 18 comments · Fixed by #7435
Closed

Fieldsets that contain a checkbox grouping does not read the legend at times #3321

nvaccessAuto opened this issue Jul 1, 2013 · 18 comments · Fixed by #7435
Labels
bug p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority z 2017webfix (archived)
Milestone

Comments

@nvaccessAuto
Copy link

Reported by nshah9 on 2013-07-01 19:41
I have 2 pages with checkbox groupings.

On one of the pages, when the grouping receives focus, the screen reader reads the legend as expected. On this page, the checkbox grouping is surrounded by a series of other inputs.

However, on the second page, when the grouping receives focus, the screen reader does not read the legend, which I think is an NVDA bug. If the grouping receives focus from the bottom, i.e (Shift+Tab), the screen reader reads the legend correctly. On this page, the checkbox grouping has a link before it and other inputs after it.

@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2013-07-03 03:55
Are you saying the legend isn't announced when the link gets focus? If so, this probably happens because groupings aren't announced in browse mode, but focusing links doesn't trigger focus mode. Normally, a user would use the cursor keys rather than tab when in browse mode, so reading the grouping would be redundant. However, we might need to make some sort of exception for this case.

@nvaccessAuto
Copy link
Author

Comment 2 by hhillen on 2013-09-24 00:36
The reporter is saying that the legend isn't announced when a checkbox inside of it receives focus after tabbing from a link. The reason for this is that, as you said, fieldset legends are only announced in focus mode. When tabbing into a fieldset with checkboxes from a link, focus mode was already off and the legend will not be announced, When tabbing into a fieldset from a text field or button, focus mode was on and the legend is announced, even though the focused checkbox immediately triggers browse mode again. However, lets say I have two adjacent groups of checkboxes, each wrapped in its own fieldset. If I tab from one checkbox group into the other, NVDA does not announce the change of context even though it should in my opinion. The only way to achieve this is to force focus mode by pressing INS + Space, but I don't think it's acceptable to expect this from the average user. I've created a test case for the checkbox scenario at https://dl.dropboxusercontent.com/u/573324/testcases/bugreports/NVDA/nvda_fieldset_announcement.html (also see attached file).

I think having some redundancy here is less of problem than missing an important change of context. Maybe power users would turn off browse mode before tabbing through a form, but wouldn't the average user just stay in browse mode? Especially since NVDA does a good job of automatically switching to focus mode for controls that need it. My preference would be that fieldset legends are always announced consistently when keyboard focus moves into them, regardless of the current mode. Alternatively, would it be possible to somehow distinguish between a user moving into the fieldset using virtual navigation commands (e.g. by pressing the arrow keys), and by moving keyboard focus (e.g. by tabbing into the fieldset)? For example, could NVDA treat the act of navigating into a fieldset virtually as an actual change of context, preventing the legend from being announced a second time when focus is moved to a control inside of it? That way, the user would hear the legend text only once, in either navigation style. At the moment it just feels buggy that legends are announced seemingly inconsistently, depending on whether the previously focused element triggered focus mode or not. I understand it's by design and why, but I don't think a user necessarily would.

@nvaccessAuto
Copy link
Author

Attachment nvda_fieldset_announcement.html added by hhillen on 2013-09-24 00:38
Description:

-----------------------------71042442332265
Content-Disposition: form-data; name="replace"

on

@nvaccessAuto
Copy link
Author

Comment 3 by jteh on 2013-09-24 01:08
FWIW, I agree that there needs to be a fix here, which is why the ticket is still open. Unfortunately, I haven't figured out a way of fixing this without introducing a huge amount of redundancy when cursoring. Distinguishing the various cases is not as simple as it sounds in this case.

@nvaccessAuto
Copy link
Author

Comment 4 by hhillen on 2013-09-24 13:55
Thanks for your quick response Jamie. I understand it's difficult to distinguish between cases. Initially I was going to suggest to only announce the legend when actual keyboard focus is moved to the link or checkbox, but looking closer I noticed that in browse mode NVDA actually does move keyboard focus to those elements when navigating by cursor keys as well, so that idea wouldn't work.

If this can't be figured out in a way that's ideal, perhaps this could be something that's determined by a verbosity setting? E.g. there could be a setting called "always announce groups". This would cause groups to be announced in either mode when keyboard focus is moved into it.

In addition, enabling this setting could include an announcement whenever the user moves out of a group (something like "leaving personal details" or "end of personal details"). Currently there is no way of knowing whether the field you tabbed to is still in the same fieldset or adjacent to it.

Of course my preference would be to have such a setting enabled by default, to be turned off by more experienced users.

What do you think?

@nvaccessAuto
Copy link
Author

Comment 5 by spanchang02 on 2013-11-14 19:20
Admitted that a checkbox' state can be toggled without exiting browse mode (i.e. forms mode turned off). But the legend text is necessary to fully comprehend the purpose of the checkbox choices and should always be announced when one tabs to them.
At present, NVDA announces legend text for the first form control in a fieldset (if there's no anchor between legend text and form control) and also when one shift-tabs into the fieldset. So NVDA should continue doing this for checkbox groups too.
As the legend text should always be exposed (for the first field in the group when tabbing and for the last field in the group while shift-tabbing), I do not think users need an option to turn off legend announcement.
Here is an example file:
http://mars.dequecloud.com/demo/FF-legend.htm
I think it covers the situations being discussed. Regards,
Sailesh

@afiorenza
Copy link

This bugs also happens in firefox with nvda, but seem to fails randomly. Any news about this?

@weboverhauls
Copy link

Please fix.
I can also reproduce with NVDA/Firefox.

@RichCaloggero
Copy link

Perhaps the rule could be something like:

  • if last keyboard event was generated via arrow key, assume browse mode and do not announce group label
  • otherwise always announce

This would seem to take in to account the case where focus was shifted via javascript into the group (in which case label should be announced), or when tabbing (also should be announced). If last key pressed was arrow key then assume the user does not need the group label announced.

@HerinHentry
Copy link

Yes. This issue occurs in Firefox & IE. Thanks

@jcsteh jcsteh added the p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority label Mar 15, 2017
@jcsteh
Copy link
Contributor

jcsteh commented Mar 15, 2017

P2 because this causes users to miss important information they would normally receive when tabbing.

@JLastort
Copy link

I found a workaround. You can indicate to NVDA that it should go into forms mode by wrapping the fieldset in a div.

....

@grahamarmfield
Copy link

P2 because this causes users to miss important information they would normally receive when tabbing.

This for me makes the issue quite important. The legend not being read out can cause confusion to users, and potentially lead to incorrect choices.

Is there any likelihood of a solution for this?

@jcsteh
Copy link
Contributor

jcsteh commented Sep 28, 2018 via email

@StommePoes
Copy link

StommePoes commented Oct 2, 2018

I still don't hear the legend: http://www.stommepoes.nl/work/k-12/fieldsets.html (test #3)

We just figured we had to hope users would wander around and manage to get into forms mode. :(

That said I noticed I hear I'm going out of focus mode when getting to any checkboxes, anywhere (so our larger test case also has an "I accept your demand for my firstborn terms and conditions" type thing).

@AlmeroSteyn
Copy link

Applying the pattern suggested above by @StommePoes to radio buttons and checkboxes the result is this:

http://debonair-scissors.surge.sh

It appears that NVDA goes out of forms mode when encountering checkboxes.

@RichCaloggero
Copy link

RichCaloggero commented Oct 2, 2018

It appears that NVDA goes out of forms mode when encountering checkboxes.

This makes sense since the only reason for forms mode (non-virtual or real mode) is to turn off all screen reader keyboard processing so the browser can use all the keys. This is necessary, for instance, in a text input field where you want arrows to move the caret, delete / backspace to delete characters, etc. A checkbox and button have no such requirements, so the screen reader does not turn off virtual mode when encountering these. Radio buttons, however, do require the arrow keys to move among them and check the currently selected one. Note that radio buttons, in order to be seen by the browser as a single group, need to all be associated with the same name attribute:

<!-- note that headings can now be children of legend -- very convenient and some situations -->
<!-- see http://validator.w3.org/nu/ -->
<fieldset><legend><h2>radio buttons</h2></legend>
<label>radio button 1 <input type="radio" name="group"></label>
<label>radio button 2 <input type="radio" name="group"></label>
</fieldset>

As per the bug about which this issue is concerned: seems fixed to me with latest NVDA!

@StommePoes
Copy link

StommePoes commented Oct 2, 2018

Fixed as in, you hear legends now when coming from an error link? Because errors as links going to the errant fields is the current recommendation for forms, and here it breaks (2018.3 with at least one update though I think I got the other one after testing).

Although it's true that traditionally, HTML did not expect checkboxes or radios to have errors. But the things we ask in forms demands it now, so in a way it's a hackish thing but required.

codeofdusk added a commit to codeofdusk/nvda that referenced this issue Jan 2, 2019
This commit fixes nvaccess#709 by expanding the check introduced in nvaccess#3321 for property pages.
michaelDCurran pushed a commit that referenced this issue Jan 7, 2019
…9116)

* Fixed #709.

This commit fixes #709 by expanding the check introduced in #3321 for property pages.

* Update what's new.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority z 2017webfix (archived)
Projects
None yet
10 participants