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

Shorten more roles and states in braille #7188

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

Shorten more roles and states in braille #7188

leonardder opened this issue May 18, 2017 · 29 comments
Milestone

Comments

@leonardder
Copy link
Collaborator

@leonardder 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 Add more role and state abreviations for braille output Shorten more elements on a braille display (e.g. roles, states, position info) May 18, 2017
@leonardder
Copy link
Collaborator Author

@leonardder 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"

Loading

@dkager
Copy link
Collaborator

@dkager 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.

Loading

@derekriemer
Copy link
Collaborator

@derekriemer derekriemer commented May 18, 2017

Loading

@leonardder
Copy link
Collaborator Author

@leonardder leonardder commented May 18, 2017

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

Loading

@jcsteh
Copy link
Contributor

@jcsteh jcsteh commented May 18, 2017

Loading

@derekriemer
Copy link
Collaborator

@derekriemer derekriemer commented May 19, 2017

Loading

@dkager
Copy link
Collaborator

@dkager 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.

Loading

@leonardder
Copy link
Collaborator Author

@leonardder 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.

Loading

@dkager
Copy link
Collaborator

@dkager 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.

Loading

@leonardder
Copy link
Collaborator Author

@leonardder 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.

Loading

@dkager
Copy link
Collaborator

@dkager 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.

Loading

@leonardder
Copy link
Collaborator Author

@leonardder 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.

Loading

@dkager
Copy link
Collaborator

@dkager 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).

Loading

@leonardder
Copy link
Collaborator Author

@leonardder 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.

Loading

@dkager
Copy link
Collaborator

@dkager 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. :)

Loading

@feerrenrut
Copy link
Member

@feerrenrut feerrenrut commented Jun 3, 2017

Loading

@leonardder
Copy link
Collaborator Author

@leonardder leonardder commented Jun 3, 2017

Loading

@dkager
Copy link
Collaborator

@dkager 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.

Loading

@feerrenrut
Copy link
Member

@feerrenrut 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).

Loading

@dkager
Copy link
Collaborator

@dkager 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).

Loading

@leonardder
Copy link
Collaborator Author

@leonardder leonardder commented Jun 3, 2017

Loading

@feerrenrut
Copy link
Member

@feerrenrut 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.

Loading

@derekriemer
Copy link
Collaborator

@derekriemer derekriemer commented Jun 3, 2017

Loading

@leonardder
Copy link
Collaborator Author

@leonardder 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.

Loading

@jcsteh
Copy link
Contributor

@jcsteh jcsteh commented Jun 29, 2017

Loading

@leonardder
Copy link
Collaborator Author

@leonardder 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.

Loading

@jcsteh
Copy link
Contributor

@jcsteh jcsteh commented Jul 1, 2017

Loading

@leonardder leonardder marked this as a duplicate of #7450 Jul 28, 2017
@leonardder leonardder changed the title Shorten more elements on a braille display (e.g. roles, states, position info) Shorten more roles and states in braille Jul 28, 2017
@leonardder
Copy link
Collaborator Author

@leonardder 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)

Loading

@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
… Please see "Control Type, State and Landmark Abbreviations" under Braille in the User Guide for a complete list. (issue #7188, PR #7248)
@dkager
Copy link
Collaborator

@dkager 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.

Loading

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