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
Comments
Comment 1 by jteh on 2013-07-03 03:55 |
Comment 2 by hhillen on 2013-09-24 00:36 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. |
Attachment nvda_fieldset_announcement.html added by hhillen on 2013-09-24 00:38 -----------------------------71042442332265 on |
Comment 3 by jteh on 2013-09-24 01:08 |
Comment 4 by hhillen on 2013-09-24 13:55 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? |
Comment 5 by spanchang02 on 2013-11-14 19:20 |
This bugs also happens in firefox with nvda, but seem to fails randomly. Any news about this? |
Please fix. |
Perhaps the rule could be something like:
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. |
Yes. This issue occurs in Firefox & IE. Thanks |
P2 because this causes users to miss important information they would normally receive when tabbing. |
I found a workaround. You can indicate to NVDA that it should go into forms mode by wrapping the fieldset in a div.
....
|
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? |
This issue has already been fixed. If you can still reproduce it, please provide a test case and steps to reproduce. Thanks.
|
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). |
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. |
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
As per the bug about which this issue is concerned: seems fixed to me with latest NVDA! |
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. |
This commit fixes nvaccess#709 by expanding the check introduced in nvaccess#3321 for property pages.
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.
The text was updated successfully, but these errors were encountered: