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

Jump to bottom

Radio buttons in Java applications always announce position information as 1 of 1 regardless of the number of radio buttons #3754

Closed
nvaccessAuto opened this issue Jan 8, 2014 · 11 comments
Closed

Radio buttons in Java applications always announce position information as 1 of 1 regardless of the number of radio buttons #3754

nvaccessAuto opened this issue Jan 8, 2014 · 11 comments
Labels
bug z ITSWork (archived)
Milestone
2014.2

Comments

@nvaccessAuto
Copy link

Reported by mdcurran on 2014-01-08 03:59
Currently, NVDA assumes that all radio buttons are direct children of the same parent, and that the only children of the parent are in deed radio buttons. Therefore, NVDA uses the child index and the parent's child count as the 'ordinal' or position information for each radio button.
Clearly this is not at all useful if the radio buttons are within separate panels etc.
We could either 1. no longer expose position info for adio buttons (especially if its 1 of 1), or 2. Come up with a complex huristic that searches for and counts radio buttons around the current radio button, and calculates suitable position information. However, it is debatable as to how high up the parent structure the search should go. Surely there are examples where there are two groups of radio buttons within the same frame?

Therefore, for best performance and suitability for as many situations as possible, we should simply stop exposing this position information for Java radio buttons.
@nvaccessAuto
Copy link
Author

Comment 1 by Michael Curran <mick@... on 2014-01-08 08:44
In [b19de45]:

Java Access Bridge support: no longer expose position information for radio buttons as they are hardly ever placed siquentially in the same parent with no other controls at all. Stops NVDA announcing "1 of 1" all the time. Re #3754

@nvaccessAuto
Copy link
Author

Comment 2 by Michael Curran <mick@... on 2014-01-22 06:23
In [85fe598]:

Merge branch 'javaImprovements' into next. Incubates #3753, #3754, #3755, #3756, #3757, #3770

Changes:
Added labels: incubating

@nvaccessAuto
Copy link
Author

Comment 3 by Michael Curran <mick@... on 2014-02-07 05:31
In [5bd2574]:

Merge branch 'javaImprovements'. Fixes #3753, #3754, #3755, #3756, #3757, #3770

Changes:
Removed labels: incubating
State: closed

@nvaccessAuto
Copy link
Author

Comment 4 by mdcurran on 2014-02-07 05:36
Changes:
Milestone changed from next to 2014.1

@nvaccessAuto
Copy link
Author

Comment 5 by mdcurran on 2014-02-12 02:44
Looks like Java Swing provides the memberOf relation on radio buttons inside buttonGroup objects. Therefore we can support better radioButton position info.
Changes:
State: reopened

@nvaccessAuto
Copy link
Author

Comment 6 by Michael Curran <mick@... on 2014-02-12 02:47
In [d05e100]:

Java Access Bridge support: support position information (i.e. x of y) on where ever the 'memberOf' relation is exposed (e.g. radio buttons in button groups). Re #3754

Note: JAB NVDAObject's _getJABRelationFirstTarget has been renamed to _getJABRelationTargets and now always returns a list of targets.

@nvaccessAuto
Copy link
Author

Comment 7 by Michael Curran <mick@... on 2014-02-12 02:48
In [a55d3d1]:

Merge branch 't3754' into next. Incubates #3754

Changes:
Added labels: incubating

@nvaccessAuto
Copy link
Author

Comment 8 by mdcurran on 2014-02-12 02:54
Changes:
Changed title from "Radio buttons in Java applications always announce position information as 1 of 1 regardly of the number of radio buttons" to "Radio buttons in Java applications always announce position information as 1 of 1 regardless of the number of radio buttons"

@nvaccessAuto
Copy link
Author

Comment 9 by mdcurran on 2014-02-12 03:01
Changes:
Milestone changed from 2014.1 to next

@nvaccessAuto
Copy link
Author

Comment 10 by Michael Curran <mick@... on 2014-02-27 04:50
In [69e3e5a]:

Merge branch 't3754'. Fixes #3754

Changes:
Removed labels: incubating
State: closed

@nvaccessAuto
Copy link
Author

Comment 11 by mdcurran on 2014-02-27 04:57
Changes:
Milestone changed from next to 2014.2

@nvaccessAuto nvaccessAuto added this to the 2014.2 milestone Nov 10, 2015
This was referenced Nov 10, 2015
Closed
Closed
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug z ITSWork (archived)
Projects
None yet
Milestone
2014.2
Development

No branches or pull requests
1 participant
@nvaccessAuto