Skip to content

BrowseModeDocumentTextInfo.getControlFieldSpeech: Report the name of groupings (such as fieldsets) for quicknav and focus jumps, similar to how landmark labels are reported.#7435

Merged
michaelDCurran merged 5 commits into
masterfrom
i3321
Aug 29, 2017

Conversation

@michaelDCurran

@michaelDCurran michaelDCurran commented Jul 24, 2017

Copy link
Copy Markdown
Member

Link to issue number:

Fixes #3321
Fixes #6979

Summary of the issue:

When jumping by quicknav or focus in browseMode, legends on fieldsets are not reported.

Description of how this pull request fixes the issue:

Announce the name of the fieldset (grouping) similar to how we announce the label of landmarks, but only do this for reason_focus so that we do not double speak the name due to it also being reachable by the caret within the content.

Known issues with pull request:

This will happen fr all groupings with a name in browseMode. Would there be some groupings that have badly calculated names that should not be spoken? Should we limit this specifically to fieldset somehow?
This works in Firefox and Chrome. But not in Edge as they do not correctly set the name of their fieldset groupings. A bug has been filed. This does not work in IE as we would have to add code to calculate the name of a fieldset from its legend ourselves. Is this worth doing?

Change log entry:

Section: changes
In Browse mode for Firefox and Chrome, the name of form field groups are now announced when moving into them with quick navigation or when tabbing.

…groupings (such as fieldsets) for quicknav and focus jumps, similar to how landmark labels are reported.
@michaelDCurran michaelDCurran requested a review from jcsteh July 24, 2017 04:37

@jcsteh jcsteh left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. I think the "grouping" role should be reported. This makes it more consistent with reporting in focus mode.
  2. Consider moving this into speech.getControlFieldSpeech. You could put this near the code to support tables (around line 1160).

@michaelDCurran

Copy link
Copy Markdown
Member Author

@jcsteh: ready for another review. But: I noticed this PR introduces double speaking if you are in focus mode due to a field needing passThrough, then tabbing directly into a grouping, where the focus lands on a field that does not require passthrough. E.g. Starting on an edit field, and then tabbing into a fieldset and landing on a checkbox. The grouping is announced twice. This is because focusEntered is processed before switching back to browseMode for the focus. Do we care about this? We'd have to stop focusEntereds when switching to browseMode, but we may have originally done this for a particular reason.

@jcsteh jcsteh left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While double speaking is better than what we have now (not speaking potentially important info), i can see this becoming a common gripe, so I think we should fix it now.

We'd have to stop focusEntereds when switching to browseMode, but we may have originally done this for a particular reason.

I don't think there was any reason other than there being no code to prevent it. The issue is that we get the focusEntered events before the mode switch, since the mode switch happens in gainFocus. We have explicit code to replay focus entered events when switching to focus mode because we ignore focusEntered events if passThrough is False. However, we always handle them when passThrough is True. One approach could be to always ignore them and always let gainFocus handle replay for focus mode.

Comment thread source/browseMode.py Outdated

def getControlFieldSpeech(self, attrs, ancestorAttrs, fieldType, formatConfig=None, extraDetail=False, reason=None):
textList = []
role=attrs.get('role')

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is no longer necessary.

@michaelDCurran

Copy link
Copy Markdown
Member Author

The double speaking is not at all limited to this grouping case. This can be also reproduced with a list. However, it is even worse as the problem will only happen the first time, due to yet another issue where focusing a control that requires passThrough, the textInfo speech cache for the treeInterceptor is not updated, thus when it hits another control that uses browse mode, the controlFields are compared with the last browse mode position.
STR:
Rename
test.html.txt
to html and open in Firefox.
Tab through the controls. First the test link, then the edit field, then the website link.
The website link is in a list.
Notice that the list is spoken both as a focus ancestor, and as semantic info in browse mode.
Shift tab back to the edit field and forward to the website link again.
Notice this time that only the list as a focus ancestor is announced, not the semantic info in browse mode.
Now shift tab back past the edit field to the test link. Notice that "out of list" is announced once reaching the test link.
This very last point will be fixed when #2591 is fixed.
My feeling would be to handle all these issues separately from grouping announcement.

@jcsteh

jcsteh commented Aug 1, 2017

Copy link
Copy Markdown
Contributor

My feeling would be to handle all these issues separately from grouping announcement.

Fair enough, though it's worth noting that tabbing is more likely (or at least users are more likely to listen to most of the info) in a form, so encountering this for groupings is arguably more problematic than for lists. In other words, I'm suggesting that groupings might perhaps raise the priority of fixing that problem.

…lse by default. If true, then speakTextInfo will process/cache controlFields and indenting info etc, but not actually speak anything. This is needed to allow browseMode to update its speech cache when moving around in focus mode, so that the next browseMode speech has the latest controlFields.

* BrowseMode: Ensure that browseMode's textInfo speech cache is updated even when moving around in focus mode, so that when switching back to browse mode, NVDA does not inappropriately announce entering/exiting controlFields from before focus mode.
* BrowseMode: don't speak new focus ancestors via focusEntered event when speaking focus in browseMode straight after being in focus mode.
@michaelDCurran michaelDCurran requested a review from jcsteh August 1, 2017 06:01

@jcsteh jcsteh left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. If possible, I'd prefer to see REASON_ONLYCACHE used rather than a separate onlyCache argument for consistency. If this causes major problems, though, I could probably be convinced to let this fly. :)

Comment thread source/browseMode.py
if obj==self.rootNVDAObject:
self._enteringFromOutside = True
if self.passThrough:
nextHandler()

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'd be good to have a comment here explaining that we ignore these events here, but event_gainFocus will replay them if appropriate.

…peech.speakTextInfo rather than requiring a new argument. Also comment why BrowseModeDocumentTreeInterceptor.event_focusEntered drops all events.
michaelDCurran added a commit that referenced this pull request Aug 1, 2017
@michaelDCurran michaelDCurran merged commit c4c3da6 into master Aug 29, 2017
@nvaccessAuto nvaccessAuto added this to the 2017.4 milestone Aug 29, 2017
seanbudd pushed a commit that referenced this pull request May 15, 2026
…A grids in focus mode. (#20091)

Fixes #17750.
Summary of the issue:

When moving to an ARIA grid cell in focus mode in web browsers, NVDA previously reported both the row and column headers even if only the row or only the column changed.
Description of user facing changes:

When moving to an ARIA grid cell in focus mode in web browsers, NVDA no longer reports both the row and column headers even if only the row or only the column changed.
Description of development approach:

Previously, there were two problems:

    After c4c3da6 (BrowseModeDocumentTextInfo.getControlFieldSpeech: Report the name of groupings (such as fieldsets) for quicknav and focus jumps, similar to how landmark labels are reported. #7435), Browse mode was updating the speech properties cache before speaking the focused object, even in focus mode. That meant that the row and column coordinates for the newly focused cell were already cached before NVDA spoke it, which made NVDA behave as if the coordinates never changed. The fix is to update the cache from the TextInfo after speaking the focused object.
    Virtual buffers just used the IA2 unique id as the table id, but NVDAObjects use both the window handle and id, meaning that these didn't compare correctly in the speech cache. The fix is to make the vbuf normalize table ids to windowHandle and id.
Boumtchack pushed a commit to France-Travail/nvda that referenced this pull request May 18, 2026
…A grids in focus mode. (nvaccess#20091)

Fixes nvaccess#17750.
Summary of the issue:

When moving to an ARIA grid cell in focus mode in web browsers, NVDA previously reported both the row and column headers even if only the row or only the column changed.
Description of user facing changes:

When moving to an ARIA grid cell in focus mode in web browsers, NVDA no longer reports both the row and column headers even if only the row or only the column changed.
Description of development approach:

Previously, there were two problems:

    After c4c3da6 (BrowseModeDocumentTextInfo.getControlFieldSpeech: Report the name of groupings (such as fieldsets) for quicknav and focus jumps, similar to how landmark labels are reported. nvaccess#7435), Browse mode was updating the speech properties cache before speaking the focused object, even in focus mode. That meant that the row and column coordinates for the newly focused cell were already cached before NVDA spoke it, which made NVDA behave as if the coordinates never changed. The fix is to update the cache from the TextInfo after speaking the focused object.
    Virtual buffers just used the IA2 unique id as the table id, but NVDAObjects use both the window handle and id, meaning that these didn't compare correctly in the speech cache. The fix is to make the vbuf normalize table ids to windowHandle and id.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

3 participants