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

Show control type state on the lefthand side or make it at least configurable #2955

Open
nvaccessAuto opened this issue Feb 1, 2013 · 13 comments

Comments

@nvaccessAuto
Copy link

Reported by halim on 2013-02-01 10:31
Currently, when braille is tethered to review (and to focus) the
control type state is shown on the right-hand side of its label.
For braille users, this makes it very hard to read because even on a 80
cells displays one eventually needs to scroll it till the user can get
the status of the control.
When the state (e.g. a checkbox which is checked) is shown in front of
the label the user can get its state immediately.
Its label can be read even by scrolling or by using speech. However,
users do not need to read the full string all the time and work more
effectively.

This seems to be the case in system dialogues (e.g. control panel ->
date and time) where checkboxes and radio buttons occur. Controls in
virtual buffers are represented as proposed.

@nvaccessAuto
Copy link
Author

Comment 1 by aliminator on 2013-03-20 08:04
Indeed, this makes working especially in review mode much easier because one does not have to read the whole braille string till one gets to the status.

@nvaccessAuto
Copy link
Author

Comment 2 by halim on 2013-06-05 05:46
The following patch changes brailleoutput as suggested in my initial description.
States are now displayed on left side of an object which has several advvantages for braille only users

  • you don't have to read complete string to get the status
  • you don't need to move arround your finger to find the state if labels of controls are of diferent size
    .....
    patch will follow shortly

@nvaccessAuto
Copy link
Author

nvaccessAuto commented Jun 5, 2013

Attachment patch added by halim on 2013-06-05 06:11
Description:
Update:
File added from Trac
patch.txt

@nvaccessAuto
Copy link
Author

Comment 3 by aliminator on 2013-06-20 08:29
Will this patch be integrated in the next release?

@nvaccessAuto
Copy link
Author

Comment 4 by jteh on 2013-06-20 09:17
I'd question why braille is different to speech here in terms of efficiency. Also, while this might be okay for some states, it might be confusing for others; e.g. protected and unavailable.

@nvaccessAuto
Copy link
Author

Comment 5 by aliminator on 2013-06-20 09:43
When using braille and speech concurrently both are outputing (more or less) the same.
Users, using this method can read the state of the element while the label is announced by speech. This makes it more efficient to work. No-speech users have always read the whole string (including the label) and finally get the state. Although the user gets an idea of the label it takes relativeley long time till they get to the state. Especially when those users use e.g. settings dialogues frequently and they know what they do.

@nvaccessAuto
Copy link
Author

Comment 6 by andreas on 2013-06-20 13:37
going through a form or settings box with the new patch installed, i can tip with the finger on the left side of my braille display, knowing with one touch which element (check box etc) the cursor is on. This is more fast than reading all the text of the element searching for the position of its status or type.
You are right that writing "not available" on the left-hand side is bit problematic. But the most form elements you go through are available. Perhaps you can offer a checkbox in the nvda settings, so the user can decide if he wants to see the state of this eleements on left or right-hand-side?

@nvaccessAuto
Copy link
Author

Comment 7 by halim (in reply to comment 4) on 2013-12-07 10:56
Replying to jteh:

I'd question why braille is different to speech here in terms of efficiency. Also, while this might be okay for some states, it might be confusing for others; e.g. protected and unavailable.

I am not sure if I got your question right.
The difference is that you have to move around and find the status every time at different positions while speech can output that information ver fast.
Using a 40 cell display the conntent has to be scrolled aditionaly. Another problem is that not every user wants to work with speech and braille at the same time. For braille only users the braille code needs more improovments but (OT).

Maybe the posted patch is not able to handle all controltypes correctly but it is a good start point for improoving braille output.
We can talk about other controltypes and howto display these.

@bhavyashah
Copy link

@jcsteh expressed his concerns about the proposed changes in #2955 (comment). Also, there were follow-ups by more than one user seemingly justifying the original request encompassed by this ticket. Could Braille experts provide their opinions on whether or not we should accept this issue?

@LeonarddeR
Copy link
Collaborator

There are some very similar other issues, e.g #1956, #6901. I opened #7232 a while ago as an umbrella for these, and that issue also covers speech. Not sure whether we should close this as duplicate, though.

@jcsteh jcsteh removed their assignment Sep 5, 2017
@Adriani90
Copy link
Collaborator

@halim did you try to use braille extender add-on?
@michaelDCurran, @LeonarddeR, are there any further thoughts regarding to this issue?
In my opinion, a check box in braille settings where the user can decide if state is displayed on the left or right would be suitable.

@Adriani90
Copy link
Collaborator

I suggest to let the referenced issues open and this one as well until the discussions move to one of them. All issues related to this topic have detailed discussions which might be helpful.

@MarioBatusic
Copy link

This improvment would be very important. We at Fabasoft company develop our products exclusively as Web Apps. And there is a planty of checkboxes and radios in our Property Dialogs. It were much easier for Braille users to see the state of a check box / radio in front of its name, such as by buttons and links.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants