Shorten more roles and states in braille

[LeonarddeR]

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]

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 Make Unified English Braille the default Braille code #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]

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]

Honestly, yeah, indicators should look the same across languages. Ideally, a checkbox should look like a box with either a mark or no mark, and maybe we do the thing braillenote does with expanding boxes for edit.

…

On Thu, May 18, 2017 at 8:36 AM, Leonard de Ruijter < ***@***.***> wrote: Here are some additional ideas. @bramd <https://github.com/bramd>, @jcsteh <https://github.com/jcsteh>, @josephsl <https://github.com/josephsl>, @derekr <https://github.com/derekr>, @dkager <https://github.com/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 <#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" — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFGivTQ--o7VG_xd99JYvoWq1g2qKyGCks5r7FdXgaJpZM4NfKxY> .

-- Derek Riemer: Improving the world one byte at a time! - University of Colorado Boulder Department of computer science, 4th year undergraduate student. - Accessibility enthusiast. - Proud user of the NVDA screen reader. - Open source enthusiast. - Skier. Personal website <http://derekriemer.com>

[LeonarddeR]

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

[jcsteh]

A concern I have with the idea of using Unicode braille for checked states is that the mappings you provided are very much biased to English computer braille (or at least Latin languages). A Latin braille "x" doesn't look like a check mark. ⠷⠾ don't look anything like a box and were only used because of the computer braille parentheses. If anything, I'd say the outer symbols it should be ⠣⠜; at least that kind of looks like a circle.

[derekriemer]

But if a paren is 123-7 in some braille code, it certainly won't look like a box or resemble that in this mythical language. I'm sure a language exists where the current states don't look correct.

…

On Thu, May 18, 2017 at 5:11 PM, James Teh ***@***.***> wrote: A concern I have with the idea of using Unicode braille for checked states is that the mappings you provided are very much biased to English computer braille (or at least Latin languages). A Latin braille "x" doesn't look like a check mark. ⠷⠾ don't look anything like a box and were only used because of the computer braille parentheses. If anything, I'd say the outer symbols it should be ⠣⠜; at least that kind of looks like a circle. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFGivW_uClKpLNx-klReeAq1muvln5RIks5r7NAngaJpZM4NfKxY> .

-- Derek Riemer: Improving the world one byte at a time! - University of Colorado Boulder Department of computer science, 4th year undergraduate student. - Accessibility enthusiast. - Proud user of the NVDA screen reader. - Open source enthusiast. - Skier. Personal website <http://derekriemer.com>

[dkager]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Personally I think the suggestion of ⢎⣉⡱ for off and ⢎⣿⡱ for on is the least ambiguous. Yes, it deviates from the slider / switch metaphor but I personally I think that metaphor has some issues, particularly when trying to represent it with braille. To be sure I'm talking about the same thing, I'm assuming we are looking for a braille replacement of https://www.w3schools.com/howto/howto_css_switch.asp These switches are "on" when on the right, to help give a hint about when they are on / off, the background is grey when they are off, and coloured blue (in this case) when on. I have seen this pattern around a fair bit. Personally I think its also clearer when the label for the slider also changes when the slider position changes, but that's off topic I guess. A question, do these need to be differentiated from checkboxes? Semantically, they seem the same to me. My guess is that they are used visually to fit in the "flat UI" trend, and to make the site appear new/fresh/interesting. That said, sometimes they also contain text which is can be useful visually. Example of this http://www.bootstraptoggle.com/

…

On Fri, Jun 2, 2017 at 4:18 PM, Davy Kager ***@***.***> wrote: 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. :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADVGEpJrLvFOUJWzZynrH3u3gN31Bh_Mks5r_8VXgaJpZM4NfKxY> .

-- Regards, Reef Turner

[LeonarddeR]

To be sure I'm talking about the same thing, I'm assuming we are looking for a braille replacement of https://www.w3schools.com/howto/howto_css_switch.asp These switches are "on" when on the right, to help give a hint about when they are on / off, the background is grey when they are off, and coloured blue (in this case) when on. I have seen this pattern around a fair bit. Hmm, not sure whether this is the same thing. We were actually talking about the type of toggle button you see in Windows 10 settings>Privacy, e.g. "Let Windows track app launches to improve Start and search results"

[dkager]

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]

@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]

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]

It might eventually be interesting to have separate shapes for radio buttons, which allows us to get rid of rbtn. We already discussed this above, but this has no high priority and is probably better to discuss in a separate ticket. The demand isn't very high though.

[feerrenrut]

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]

Button rectanble, checkbox circle?

…

On Fri, Jun 2, 2017 at 1:57 AM, Davy Kager ***@***.***> wrote: 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). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFGivYj4xwwpgBgbbSrsyzeR8p0gi8esks5r_8BfgaJpZM4NfKxY> .

-- Derek Riemer: Improving the world one byte at a time! - University of Colorado Boulder Department of computer science, 4th year undergraduate student. - Accessibility enthusiast. - Proud user of the NVDA screen reader. - Open source enthusiast. - Skier. Personal website <http://derekriemer.com>

[LeonarddeR]

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]

Agreed. Unicode shapes should not be translatable.

[LeonarddeR]

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]

I think using the actual Unicode characters is best here. Note that you'll need to add an encoding comment at the top of the file and ensure it's saved as UTF-8 with no BOM.

[LeonarddeR]

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)

[dkager]

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.