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

Shorten more roles and states in braille #7188

Closed
leonardder opened this Issue May 18, 2017 · 29 comments

Comments

Projects
None yet
6 participants
@leonardder
Collaborator

leonardder commented May 18, 2017

Originally suggested in #214 (comment)

Ok this very old ticket describes a realy annoying problem with nvda's braille display output.

  • in german nvda prints eg. (nicht verfübar) for not available. This output is important but should be replaced with some shorter text and it needs some tweak to be distinguished from the real text of the focuesed object.

Alternative str

  1. Go to windows 10 settings > privacy
  2. There are several toggle buttons here. On a braille display, "not pressed toggle button" is printed, wasting lots of space on a braille display

@leonardder leonardder changed the title from Add more role and state abreviations for braille output to Shorten more elements on a braille display (e.g. roles, states, position info) May 18, 2017

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder May 18, 2017

Collaborator

Here are some additional ideas. @bramd, @jcsteh, @josephsl, @derekr, @dkager, comments please?

Change some states to unicode braille

Several reasons for this:

  1. State indicators differ between braille tables
  2. Default state indicators will change unexpectedly and undesirably when #6952 is somehow implemented. E.g. checked will change from ⠷⠭⠾ to ⠐⠣⠭⠐⠜ which is ridiculous imo

I propose

  • Checked: ⠷⠭⠾
  • half checked: ⠷⠤⠾
  • not checked: ⠷ ⠾
  • separator: ⠤⠤⠤⠤⠤

Shorten position information:

  • change "%d of %d" to "%d/%d"

Strip white space from roles and states which are not explicitly set

e.g. toggle button would be togglebutton, not pressed would be notpressed. I eventually like something like nprs tbtn, but this is so you can get the idea

Create separate checked and unchecked braille patterns

E.g. for radio buttons and check boxes, so we can get rit of "(x) chk" and "(x) rbtn"

Collaborator

leonardder commented May 18, 2017

Here are some additional ideas. @bramd, @jcsteh, @josephsl, @derekr, @dkager, comments please?

Change some states to unicode braille

Several reasons for this:

  1. State indicators differ between braille tables
  2. Default state indicators will change unexpectedly and undesirably when #6952 is somehow implemented. E.g. checked will change from ⠷⠭⠾ to ⠐⠣⠭⠐⠜ which is ridiculous imo

I propose

  • Checked: ⠷⠭⠾
  • half checked: ⠷⠤⠾
  • not checked: ⠷ ⠾
  • separator: ⠤⠤⠤⠤⠤

Shorten position information:

  • change "%d of %d" to "%d/%d"

Strip white space from roles and states which are not explicitly set

e.g. toggle button would be togglebutton, not pressed would be notpressed. I eventually like something like nprs tbtn, but this is so you can get the idea

Create separate checked and unchecked braille patterns

E.g. for radio buttons and check boxes, so we can get rit of "(x) chk" and "(x) rbtn"

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager May 18, 2017

Collaborator

Strip white space from roles and states which are not explicitly set

Not a huge fan of this, though I like intuitive abbreviations. IMO tbtn is one of those.

Collaborator

dkager commented May 18, 2017

Strip white space from roles and states which are not explicitly set

Not a huge fan of this, though I like intuitive abbreviations. IMO tbtn is one of those.

@derekriemer

This comment has been minimized.

Show comment
Hide comment
@derekriemer

derekriemer May 18, 2017

Collaborator
Collaborator

derekriemer commented May 18, 2017

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder May 18, 2017

Collaborator

Could you explain this? I'm not familiar with BrailleNote?

Collaborator

leonardder commented May 18, 2017

Could you explain this? I'm not familiar with BrailleNote?

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh May 18, 2017

Contributor
Contributor

jcsteh commented May 18, 2017

@derekriemer

This comment has been minimized.

Show comment
Hide comment
@derekriemer

derekriemer May 19, 2017

Collaborator
Collaborator

derekriemer commented May 19, 2017

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager May 19, 2017

Collaborator

I think for radio buttons SuperNova uses something like ⢎⡱ (checked) and ⢆⡰ (unchecked). For checkboxes, ⣏⣿⣹ (checked), ⣏⣀⣹ (unchecked) and ⣏⣤⣹ (half checked). The real symbols are probably different, but it goes to show they try to draw pretty braille shapes. A checkmark is probably not going to work in a single braille cell. Also, I wonder if we should stick to 6-dot shapes.

Collaborator

dkager commented May 19, 2017

I think for radio buttons SuperNova uses something like ⢎⡱ (checked) and ⢆⡰ (unchecked). For checkboxes, ⣏⣿⣹ (checked), ⣏⣀⣹ (unchecked) and ⣏⣤⣹ (half checked). The real symbols are probably different, but it goes to show they try to draw pretty braille shapes. A checkmark is probably not going to work in a single braille cell. Also, I wonder if we should stick to 6-dot shapes.

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder May 19, 2017

Collaborator

Personally, I like those.

I also have been thinking about ⠪⠕ for radio buttons, so that would stay in the 6 dots range. Also, ⢾⡷ for checked check boxes, ⢎⡱ and ⢞⡳ for half checked check boxes.

Collaborator

leonardder commented May 19, 2017

Personally, I like those.

I also have been thinking about ⠪⠕ for radio buttons, so that would stay in the 6 dots range. Also, ⢾⡷ for checked check boxes, ⢎⡱ and ⢞⡳ for half checked check boxes.

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager May 19, 2017

Collaborator

On the topic of checkboxes, we also discussed marking the pressed/not pressed state of toggle buttons with (x) and ( ). Technically they aren't checkboxes, but this pattern is much shorter than "not pressed" and still quite intuitive. It may give users the wrong impression though, in which case "nprs" might be better.

Collaborator

dkager commented May 19, 2017

On the topic of checkboxes, we also discussed marking the pressed/not pressed state of toggle buttons with (x) and ( ). Technically they aren't checkboxes, but this pattern is much shorter than "not pressed" and still quite intuitive. It may give users the wrong impression though, in which case "nprs" might be better.

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder Jun 1, 2017

Collaborator

Toggle buttons look like ovals with a switch in it. I showed the alternative below to my sighted colleague and he said it looks like it visually.

  • Not pressed: ⢾⣏⡱
  • Pressed: ⢎⣹⡷

@feerrenrut, it might be handy to have some sighted assistance for this in order to come up with shapes that match the visual shapes as close as possible.

Collaborator

leonardder commented Jun 1, 2017

Toggle buttons look like ovals with a switch in it. I showed the alternative below to my sighted colleague and he said it looks like it visually.

  • Not pressed: ⢾⣏⡱
  • Pressed: ⢎⣹⡷

@feerrenrut, it might be handy to have some sighted assistance for this in order to come up with shapes that match the visual shapes as close as possible.

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Jun 1, 2017

Collaborator

What about ⢎⣏⡱ and ⢎⣹⡱, which are symmetrical and feel a bit easier under the finger?

Also, adding these shapes make the btn, rbtn and toggle button (tbtn?) to be redundant.

Collaborator

dkager commented Jun 1, 2017

What about ⢎⣏⡱ and ⢎⣹⡱, which are symmetrical and feel a bit easier under the finger?

Also, adding these shapes make the btn, rbtn and toggle button (tbtn?) to be redundant.

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder Jun 2, 2017

Collaborator

What about ⢎⣏⡱ and ⢎⣹⡱, which are symmetrical and feel a bit easier under the finger?

Yes, I like these even better

Update: Hmm, problem with these is that the differences between on and off are quite subtle. I wonder whether everyone would directly see whether the switch is in the left or in the right position.

Collaborator

leonardder commented Jun 2, 2017

What about ⢎⣏⡱ and ⢎⣹⡱, which are symmetrical and feel a bit easier under the finger?

Yes, I like these even better

Update: Hmm, problem with these is that the differences between on and off are quite subtle. I wonder whether everyone would directly see whether the switch is in the left or in the right position.

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Jun 2, 2017

Collaborator

What about ⢎⣏⡱ and ⢎⣹⡱, which are symmetrical and feel a bit easier under the finger?

Yes, I like these even better
Update: Hmm, problem with these is that the differences between on and off are quite subtle. I wonder whether everyone would directly see whether the switch is in the left or in the right position

I came to the same conclusion when reading them again this morning.
Another problem with both of our suggestions is that you have to know and remember which shape represents on and which represents off. Is there a visual aid for this, e.g. on/off labels?
If we use checkbox shapes for toggle buttons instead, then we lose some visual equivalence but it becomes more obvious when the button is pressed.
Or, we can stick with abbreviations like prs or prsd (pressed) and nprs or nprsd (not pressed).

Collaborator

dkager commented Jun 2, 2017

What about ⢎⣏⡱ and ⢎⣹⡱, which are symmetrical and feel a bit easier under the finger?

Yes, I like these even better
Update: Hmm, problem with these is that the differences between on and off are quite subtle. I wonder whether everyone would directly see whether the switch is in the left or in the right position

I came to the same conclusion when reading them again this morning.
Another problem with both of our suggestions is that you have to know and remember which shape represents on and which represents off. Is there a visual aid for this, e.g. on/off labels?
If we use checkbox shapes for toggle buttons instead, then we lose some visual equivalence but it becomes more obvious when the button is pressed.
Or, we can stick with abbreviations like prs or prsd (pressed) and nprs or nprsd (not pressed).

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder Jun 2, 2017

Collaborator

Is there a visual aid for this, e.g. on/off labels?

I belief that, apart from the position, there is a colour change. However, I think it is quite common style that left is off and right is on for switches.

To be sure, we could consider ⢎⣉⡱ for off and ⢎⣿⡱ for on, but that will make it an oval check box and doesn't match the visual presentation.

Collaborator

leonardder commented Jun 2, 2017

Is there a visual aid for this, e.g. on/off labels?

I belief that, apart from the position, there is a colour change. However, I think it is quite common style that left is off and right is on for switches.

To be sure, we could consider ⢎⣉⡱ for off and ⢎⣿⡱ for on, but that will make it an oval check box and doesn't match the visual presentation.

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Jun 2, 2017

Collaborator

However, I think it is quite common style that left is off and right is on for switches.

Maybe not in RTL languages or other cultures. Yes, playing devil's advocate here a bit. :)

Collaborator

dkager commented Jun 2, 2017

However, I think it is quite common style that left is off and right is on for switches.

Maybe not in RTL languages or other cultures. Yes, playing devil's advocate here a bit. :)

@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut Jun 3, 2017

Contributor
Contributor

feerrenrut commented Jun 3, 2017

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder Jun 3, 2017

Collaborator
Collaborator

leonardder commented Jun 3, 2017

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Jun 3, 2017

Collaborator

A question, do these need to be differentiated from checkboxes?

I believe checkboxes are more box-shaped instead of oval-shaped. This could be done in braille with ⣏⣉⣹ and ⣏⣿⣹.
That shape may not be so accurate for radio buttons, which @leonardder told me are circles. But NVDA and the underlying APIs only have one checked/unchecked state, so without merging the state with the role (check box or radio button) this looks like the best we can do.

Collaborator

dkager commented Jun 3, 2017

A question, do these need to be differentiated from checkboxes?

I believe checkboxes are more box-shaped instead of oval-shaped. This could be done in braille with ⣏⣉⣹ and ⣏⣿⣹.
That shape may not be so accurate for radio buttons, which @leonardder told me are circles. But NVDA and the underlying APIs only have one checked/unchecked state, so without merging the state with the role (check box or radio button) this looks like the best we can do.

@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut Jun 3, 2017

Contributor

@leonardder the toggle buttons in the Windows 10 privacy settings are basically the same as the ones in that w3 schools link. The windows ones do not have colours to signify on vs off, but they do have the text next to them. Semantically, I am unable to differentiate these from checkboxes.

@dkager some sliders are box shaped, some are oval shaped. In terms of visual difference from checkboxes, the checkboxes are square, and normally have a tick in them when checked. But in terms of what they represent, I don't really understand the need to be able to differentiate (togglebuttons from checkboxes). But I might be missing something?

I think its important to be able to differentiate radio buttons (only one is allowed in on/true state) from checkboxes (any number may be in on/true state, or none).

Contributor

feerrenrut commented Jun 3, 2017

@leonardder the toggle buttons in the Windows 10 privacy settings are basically the same as the ones in that w3 schools link. The windows ones do not have colours to signify on vs off, but they do have the text next to them. Semantically, I am unable to differentiate these from checkboxes.

@dkager some sliders are box shaped, some are oval shaped. In terms of visual difference from checkboxes, the checkboxes are square, and normally have a tick in them when checked. But in terms of what they represent, I don't really understand the need to be able to differentiate (togglebuttons from checkboxes). But I might be missing something?

I think its important to be able to differentiate radio buttons (only one is allowed in on/true state) from checkboxes (any number may be in on/true state, or none).

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Jun 3, 2017

Collaborator

But in terms of what they represent, I don't really understand the need to be able to differentiate (togglebuttons from checkboxes).

The only need we saw is to make the shapes as visually equivalent as possible. It's similar to what SuperNova does (they have different shapes for check boxes and radio buttons, I think they never got around to toggle buttons). Another differences is that check boxes can be half checked. But we could just as easily represent that in the oval shape.
Makes me wonder why people chose to have two visual representations that fulfill exactly the same UX...

I think its important to be able to differentiate radio buttons (only one is allowed in on/true state) from checkboxes (any number may be in on/true state, or none).

Yep, this is accomplished by the role indicator chk (check box) or rbtn (radio button).

Collaborator

dkager commented Jun 3, 2017

But in terms of what they represent, I don't really understand the need to be able to differentiate (togglebuttons from checkboxes).

The only need we saw is to make the shapes as visually equivalent as possible. It's similar to what SuperNova does (they have different shapes for check boxes and radio buttons, I think they never got around to toggle buttons). Another differences is that check boxes can be half checked. But we could just as easily represent that in the oval shape.
Makes me wonder why people chose to have two visual representations that fulfill exactly the same UX...

I think its important to be able to differentiate radio buttons (only one is allowed in on/true state) from checkboxes (any number may be in on/true state, or none).

Yep, this is accomplished by the role indicator chk (check box) or rbtn (radio button).

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder Jun 3, 2017

Collaborator
Collaborator

leonardder commented Jun 3, 2017

@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut Jun 3, 2017

Contributor

I think its useful to be able to differentiate radio and checkbox controls. Since its important to be aware that selecting one item deselects all others in the group (in the case of radio buttons) or not (in the case of checkboxes). I would say differentiating between radio and checkbox is more important than being able to identify toggle buttons. Which as mentioned, will be possible via the role indicator: chk / rbtn

As pointed out, toggle buttons normally can not be in a halfway state, where a checkbox can be. However, since a 2 state toggle button can be modelled with a 3 state checkbox, and all other semantics are the same that would be my suggestion.

Makes me wonder why people chose to have two visual representations that fulfill exactly the same UX...

It depends, if you are talking about checkbox vs radio button, then I think it's basically to make it clear that radio buttons only allow a single option to be selected. These mimic a type of physical button used on some electronics devices. A common example may have been a tape player, where the play button would pop up automatically when you pressed the stop button. You can not have both. I have seen some generic electronic switches that look just like a group of radio buttons, with the same behaviour. However if you are asking about togglebutton vs checkbox, then my best guess is just about the trends of UX. I think in some cases the toggle button provides better skeuomorphism, where the control would be more analogous to a physical "switch" or "sliding switch" than a tick in a box which is more likely to be found in a checklist.

Contributor

feerrenrut commented Jun 3, 2017

I think its useful to be able to differentiate radio and checkbox controls. Since its important to be aware that selecting one item deselects all others in the group (in the case of radio buttons) or not (in the case of checkboxes). I would say differentiating between radio and checkbox is more important than being able to identify toggle buttons. Which as mentioned, will be possible via the role indicator: chk / rbtn

As pointed out, toggle buttons normally can not be in a halfway state, where a checkbox can be. However, since a 2 state toggle button can be modelled with a 3 state checkbox, and all other semantics are the same that would be my suggestion.

Makes me wonder why people chose to have two visual representations that fulfill exactly the same UX...

It depends, if you are talking about checkbox vs radio button, then I think it's basically to make it clear that radio buttons only allow a single option to be selected. These mimic a type of physical button used on some electronics devices. A common example may have been a tape player, where the play button would pop up automatically when you pressed the stop button. You can not have both. I have seen some generic electronic switches that look just like a group of radio buttons, with the same behaviour. However if you are asking about togglebutton vs checkbox, then my best guess is just about the trends of UX. I think in some cases the toggle button provides better skeuomorphism, where the control would be more analogous to a physical "switch" or "sliding switch" than a tick in a box which is more likely to be found in a checklist.

@derekriemer

This comment has been minimized.

Show comment
Hide comment
@derekriemer

derekriemer Jun 3, 2017

Collaborator
Collaborator

derekriemer commented Jun 3, 2017

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder Jun 29, 2017

Collaborator

I'm leaning towards making the unicode shapes untraslatable. @jcsteh: What do you think about this? Unicode shapes in a po file might confuse people a lot.

Collaborator

leonardder commented Jun 29, 2017

I'm leaning towards making the unicode shapes untraslatable. @jcsteh: What do you think about this? Unicode shapes in a po file might confuse people a lot.

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Jun 29, 2017

Contributor
Contributor

jcsteh commented Jun 29, 2017

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder Jul 1, 2017

Collaborator

One thing I'm not sure about until I do a commit for this.

Unicode is now defined as follows:

controlTypes.STATE_CHECKED: u"⢎⣿⡱",

it could also be done like

controlTypes.STATE_CHECKED: u"\u288e\u28ff\u2871",

What is preferred here? Personally, I prefer the first approach, as you can either instantly see the pattern on screen or on a braille display. With the second approach, you probably want to have the braille pattern in the comment anyway.

Collaborator

leonardder commented Jul 1, 2017

One thing I'm not sure about until I do a commit for this.

Unicode is now defined as follows:

controlTypes.STATE_CHECKED: u"⢎⣿⡱",

it could also be done like

controlTypes.STATE_CHECKED: u"\u288e\u28ff\u2871",

What is preferred here? Personally, I prefer the first approach, as you can either instantly see the pattern on screen or on a braille display. With the second approach, you probably want to have the braille pattern in the comment anyway.

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Jul 1, 2017

Contributor
Contributor

jcsteh commented Jul 1, 2017

@leonardder leonardder marked this as a duplicate of #7450 Jul 28, 2017

@leonardder leonardder changed the title from Shorten more elements on a braille display (e.g. roles, states, position info) to Shorten more roles and states in braille Jul 28, 2017

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder Jul 28, 2017

Collaborator

I changed the title of this issue, since the associated pr doesn't cover shortening position info.

@gregjozk: If you are opening a separate issue for stripping spaces between column and row position (which is actually position info), I'm happy for you to also cover position info for lists as I mentioned in #7188 (comment)

Collaborator

leonardder commented Jul 28, 2017

I changed the title of this issue, since the associated pr doesn't cover shortening position info.

@gregjozk: If you are opening a separate issue for stripping spaces between column and row position (which is actually position info), I'm happy for you to also cover position info for lists as I mentioned in #7188 (comment)

@jcsteh jcsteh closed this in #7248 Aug 1, 2017

@nvaccessAuto nvaccessAuto added this to the 2017.3 milestone Aug 1, 2017

jcsteh added a commit that referenced this issue Aug 1, 2017

Many more control types and states have been abbreviated for braille.…
… Please see "Control Type, State and Landmark Abbreviations" under Braille in the User Guide for a complete list. (issue #7188, PR #7248)
@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Aug 7, 2017

Collaborator

While it doesn't bother me personally, a few weeks of using this code makes me wonder if *** (protected) is such a good idea. I have similar concerns about ..., though less so.

The problem I see is that for protected fiels, you can now have 3 groups of asterisks:

  1. An asterisk to indicate that the field is required.
  2. 3 asterisks to indicate the protected state.
  3. A number of asterisks that hide the actual input.

On the other hand I think *** and ... are really nice.

Collaborator

dkager commented Aug 7, 2017

While it doesn't bother me personally, a few weeks of using this code makes me wonder if *** (protected) is such a good idea. I have similar concerns about ..., though less so.

The problem I see is that for protected fiels, you can now have 3 groups of asterisks:

  1. An asterisk to indicate that the field is required.
  2. 3 asterisks to indicate the protected state.
  3. A number of asterisks that hide the actual input.

On the other hand I think *** and ... are really nice.

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