Add a significant amount of new braille role and state abreviations and change checked and pressed states to unicode (#7188) by LeonarddeR · Pull Request #7248 · nvaccess/nvda

LeonarddeR · 2017-06-03T09:58:54Z

Link to issue number:

Summary of the issue:

In current braille output, many object roles (e.g. window) and states (e.g. pressed) are unabbreviated. This means that roles and states often take a significant, redundant space on the braille display.

Description of how this pull request fixes the issue:

This pr adds the following:

It reorders the role and state labels as how the roles and states are defined in controlTypes. Without that, it was a headache to check what roles and states were covered and which ones were not.
A whole lot of new role and state abbreviations made up by @dkager and me, after some discussion, so our ideas match. Only additions, no changes, except the changes below
We changed tb for table to tbl, since tb is ambiguous (e.g. can be tab as well)
We changed the representations of the separator role and checked/not checked states to unicode braille patterns, in order for them to be identical across braille tables. Rationale in Shorten more roles and states in braille #7188 (comment) . States are now:
- Separator: ⠤⠤⠤⠤⠤
- checked/pressed: ⢎⣿⡱
- Half checked: ⢎⣭⡱
- Not checked/not pressed: ⢎⣉⡱

Testing performed:

For the unicode changes, we tested occurences of these new patterns. We haven't been able to test every new role and state though. May be @dkager can elaborate some more on this?

Anyhow, I'd suggest for this pr to be incubating in next somewhat longer than usual, since not everyone uses braille and I think that i'd be good if other's share their thoughts and ideas as well.

Known issues with pull request:

No user guide changes have been made yet. I think we'd first agree about the changes before we incorporate them into the user guide
As this adds a massive amount of abbreviations, UX for braille users might be siginificantly different from what they know and learnt in the past. I think we should also debate whether we want an option to make role/state abbreviations optional.

What's New Entries

In Changes:

- 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. (#7188)

…ls to be in the order of how they are defined in controlTypes. No functional change.

@dkager

* Change the checked and pressed states to unicode braille to be uniform across all braille tables Includes additions by @dkager

LeonarddeR · 2017-06-23T17:01:02Z

@josephsl and @derekriemer, I'd like your thoughts about the new states we added. Of course everyone else is welcome to review this and provide suggestions, alternatives or additions. I think I can speak for @dkager as well if I say that we'd like to have as much as possible consensus about this before we ask NV Access to look at this.

derekriemer · 2017-06-25T04:19:01Z

Let me clone this next week and play.

…

On Fri, Jun 23, 2017 at 11:01 AM, Leonard de Ruijter < ***@***.***> wrote: @josephsl <https://github.com/josephsl> and @derekriemer <https://github.com/derekriemer>, I'd like your thoughts about the new states we added. Of course everyone else is welcome to review this and provide suggestions, alternatives or additions. I think I can speak for @dkager <https://github.com/dkager> if I say that we'd like to have as much as possible consensus about this before we ask NV Access to look at this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7248 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFGivYZ7VACTICaVN0ilm67RLOEBqQDPks5sG-9RgaJpZM4NvCm_> .

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

jcsteh · 2017-07-10T06:34:15Z

@leonardder commented on 3 Jun 2017, 19:58 GMT+10:

No user guide changes have been made yet. I think we'd first agree about the changes before we incorporate them into the user guide

Fair enough, though I'd want the User Guide updated before this gets reviewed/incubated.

I think we should also debate whether we want an option to make role/state abbreviations optional.

While the experience is different, the goal (I hope) is that these abbreviations should be reasonably intuitive in context. So, my vote would be against such an option. We've never had it in the past, and though I understand this adds a lot more, I think it's better for users to learn the new abbreviations, rather than becoming less efficient than they were before by disabling all of them (even the we ones we had previously).

dkager · 2017-07-10T08:56:12Z

So except for user guide updates this is ready for review. @LeonarddeR are you doing the update?

jcsteh · 2017-07-10T08:59:59Z

There are also merge conflicts now that need to be resolved.

dkager · 2017-07-10T09:08:03Z

Fixed. @LeonarddeR please double-check.

jcsteh

Still merge conflicts. Maybe that just happened again today. :(

jcsteh · 2017-07-11T06:09:40Z

 	# tree view.
 	controlTypes.ROLE_TREEVIEW: _("tv"),
 	# Translators: Displayed in braille for an object which is a
+	# tree view item.


It's worth noting that this should rarely appear because we don't show the role for tree view items unless they provide no other info. Is it still worth including?

I believe it can occur in applications sprayed with ARIA.

jcsteh · 2017-07-11T06:14:26Z

+	controlTypes.ROLE_TOOLBAR: _("tlbar"),
 	# Translators: Displayed in braille for an object which is a
+	# drop down button.
+	controlTypes.ROLE_DROPDOWNBUTTON: _("ddbtn"),


I wonder if drbtn might be a bit more intuitive? I know dd stands for dropdown, but when all else fails, I try to sound it out. Drbtn seems to click more quickly in my head because of the "dr" sound, but I get that this is subjective.

Looking back at it now, I agree that drbtn is more intuitive. It would be nice to keep the buttons to 4 letters, e.g. rbtn, but I think dbtn is too vague.

jcsteh · 2017-07-11T06:15:09Z

+	controlTypes.ROLE_SECTION: _("sect"),
+	# Translators: Displayed in braille for an object which is a
+	# toggle button.
+	controlTypes.ROLE_TOGGLEBUTTON: _("tbtn"),


Would tgbtn be more intutive?

Similarly, I would now say that tbtn is too vague too, so agreed.

jcsteh · 2017-07-11T06:15:27Z

+	controlTypes.ROLE_TOGGLEBUTTON: _("tbtn"),
+	# Translators: Displayed in braille for an object which is a
+	# split button.
+	controlTypes.ROLE_SPLITBUTTON: _("sptbtn"),


Would splbtn be more intuitive?

Probably. I thought that's actually what we used, but we must have had an even brighter idea at some point. :)
Keeping in line with drbtn and tgbtn, would spbtn be an option? Probably not, because it could be confused with spin button. So splbtn then?

jcsteh · 2017-07-11T06:19:41Z

+	# Displayed in braille when an object (e.g. a toggle button) is pressed.
+	controlTypes.STATE_PRESSED: u"⢎⣿⡱",
+	# Displayed in braille when an object (e.g. a check box) is checked.
+	controlTypes.STATE_CHECKED: u"⢎⣿⡱",


Checked and pressed are the same I think? I guess this means more or less the same thing, but speech does differentiate. Should braille differentiate too?

See also the discussion with @feerrenrut in the issue (#7188).

jcsteh · 2017-07-11T06:24:05Z

+	# Displayed in braille when an object (e.g. a check box) is checked.
+	controlTypes.STATE_CHECKED: u"⢎⣿⡱",
+	# Displayed in braille when an object (e.g. a check box) is half checked.
+	controlTypes.STATE_HALFCHECKED: u"⢎⣭⡱",


I'm a little concerned this looks a bit like a Latin x, so users transitioning might be confused. Since we're doing ⢎⣿⡱ for checked, how about ⢎⡇⡱ or ⢎⢸⡱ for half?

I like this!

@jcsteh Would you be OK with ⣏⣸⣹ for half checked? I like the bottom line of the cell (dots 7 and 8) to be consistently filled to make clear that it is one shape. Same for unchecked.

jcsteh · 2017-07-11T06:26:52Z

 	# Translators: Displayed in braille when an object (e.g. an editable text field) is read-only.
 	controlTypes.STATE_READONLY: _("ro"),
+	# Displayed in braille when an object (e.g. a tree view item) is expanded.
+	controlTypes.STATE_EXPANDED: "-",


I see you made this untranslatable, but it's not Unicode. Is it possible that a dash might not work as expected in some language? What we're really wanting here is a minus sign, but most tables probably don't define the Unicode minus properly and I'm concerned about dash and minus somehow being interpreted very differently.

Very bold idea, but we could do Unicode shapes for those too, assuming 1 or 2 braille cells can sort of represent the visual symbols (what are the visual symbols?).
I believe UEB has rules regarding the hyphen and capitals, but only if no whitespace surrounds it.

jcsteh · 2017-07-11T06:27:27Z

+	controlTypes.STATE_COLLAPSED: "+",
+	# Translators: Displayed in braille when an object has a popup (usually a sub-menu).
+	controlTypes.STATE_HASPOPUP: _("submnu"),
+	# Displayed in braille when a protected control or a document is encountered.	


Trailing tab.

jcsteh · 2017-07-11T06:28:51Z

+	# Translators: Displayed in braille when an object is not selected.
+	controlTypes.STATE_SELECTED: _("nsel"),
+	# Displayed in braille when an object (e.g. a toggle button) is not pressed.
+	controlTypes.STATE_PRESSED: u"⢎⣉⡱",


See above re checked/pressed.

jcsteh · 2017-07-11T06:30:45Z

+	# Displayed in braille when an object (e.g. a toggle button) is not pressed.
+	controlTypes.STATE_PRESSED: u"⢎⣉⡱",
+	# Displayed in braille when an object (e.g. a check box) is not checked.
+	controlTypes.STATE_CHECKED: u"⢎⣉⡱",


As above, I'm concerned about this looking like an x. Any reason not to do ⢎ ⡱ (space in the middle)?

To me ⣉ looks distinctly taller than x.
SuperNova uses ⣏⣀⣹ to represent an empty checkbox. Maybe that makes it clearer that it is an empty box rather than an x? In the case of NVDA we could stick to the more 'rounded' box ⢎⣀⡱ which I think is a bit easier on the fingers.

dkager · 2017-07-11T09:47:35Z

@LeonarddeR Please review.

LeonarddeR · 2017-07-12T07:10:11Z

@dkager commented on 11 jul. 2017 11:47 CEST:

@LeonarddeR Please review.

This is ok. It seems you removed some whitespace issues from the BrailleDisplayDriver class, but he, why not?

Note that collapsed and expanded states are still left untranslatable.

dkager · 2017-07-12T09:22:36Z

It seems you removed some whitespace issues from the BrailleDisplayDriver class, but he, why not?

I did? Must be Git being smart.

Note that collapsed and expanded states are still left untranslatable.

I think *** is still translatable. Note that this is not Unicode braille.
@LeonarddeR Could you either make this untranslatable, or make + and - translatable again? As I said before, I wouldn't mind experimenting with Unicode shapes for plus and minus either. But I think most braille users prefer a real + over a braille pattern that looks a bit like a plus.

LeonarddeR · 2017-07-12T10:09:41Z

*** isn't translatable currently.

dkager · 2017-07-12T10:46:14Z

Suggestion for treeview state shapes:

Collapsed: ⢾⡷ (very blocky plus)
Expanded: ⠤⠤ (minus)

Pro: in Dutch, the plus and the exclamation point have the same braille pattern, though for the plus there are some extra whitespace rules. Readers could confuse the treeview collapsed plus for an exclamation point indicating an error. Unicode shapes are unambiguous.
Con: all those new shapes tend to overwhelm.

jcsteh · 2017-07-13T00:06:59Z

Personally, I'd vote for collapsed and expanded being punctuation, not braille patterns. However, they should be translatable because of the ambiguity of the "-" symbol.

…ate labels

dkager · 2017-07-13T08:55:35Z

That answers all feedback/questions I had.
Radio buttons are a bit of an edge case now because they are visually round but in braille they get boxy shapes. We can look at merging role and state for checkable items later. Apart from that I think we came up with the most intuitive abbreviations while keeping them truly short.

dkager · 2017-07-14T08:57:49Z

-	# graphic.
-	controlTypes.ROLE_GRAPHIC: _("gra"),
+	# block quote.
+	controlTypes.ROLE_BLOCKQUOTE: _("blq"),


One more detail: I would prefer blqt or bqt, because to me 'qt' is more intuitive than 'q'. Reading the two alternatives now I would settle for bqt.

dkager · 2017-07-14T10:14:14Z

OK, now I'm totally happy.

jcsteh · 2017-07-20T05:29:30Z

+| tvitem | tree view item |
 | lv N | a tree view item has a hierarchical level N|
+| wnd | window |
 | ``-----`` | separator |


Separator is defined in the code as ⠤⠤⠤⠤⠤, which makes sense to me... but this is inconsistent here in the User Guide.

jcsteh · 2017-07-20T05:31:45Z

+| ⣏⣿⣹ | displayed when an object (e.g. a checkbox) is checked |
+| ⣏⣸⣹ | displayed when an object (e.g. a checkbox) is half checked |
+| ⢎⣀⡱ | displayed when an object (e.g. a toggle button) is not pressed |
+| ⣏⣀⣹ | displayed when an object (e.g. a checkbox) is not checked |


While i understand why these are ordered like this in the code, I think it makes sense to keep checked, half checked and not checked together in the User Guide, rather than being interspersed with the pressed states.

…sue #7188).

jcsteh · 2017-08-01T23:52:24Z

Merging this one two days early, since it needs to go in now if we want it to get into 2017.3 and I can't see any reason to hold it back.

Leonard de Ruijter added 2 commits June 2, 2017 06:54

Changed the order of braille.roleLabels and braille.positiveStateLabe…

e436e1e

…ls to be in the order of how they are defined in controlTypes. No functional change.

* Add additional state and role labels for braille

5b61270

* Change the checked and pressed states to unicode braille to be uniform across all braille tables Includes additions by @dkager

Leonard de Ruijter added 2 commits June 29, 2017 19:51

Fixed two small mistakes and added some white space for consistency

4e95df1

Make unicode and punctuation based braille shapes untranslatable

0544066

dkager added 2 commits July 10, 2017 11:04

Merge branch 'master' into i7188

83eed5f

Merge branch 'i7188' of https://github.com/BabbageCom/nvda into i7188

cc334a0

Added new state and role abbreviations to the user guide.

83d21fc

jcsteh reviewed Jul 11, 2017

View reviewed changes

dkager added 2 commits July 11, 2017 11:15

Merge branch 'master' into i7188

834621e

Review actions.

126573e

User guide updates.

462460a

Restored the translatable states of some punctuation based braille st…

886d3fc

…ate labels

dkager suggested changes Jul 14, 2017

View reviewed changes

Leonard de Ruijter added 2 commits July 14, 2017 12:00

Changed blq to bqt

07fc04a

Also updated the user guide for bqt

2aee23b

dkager approved these changes Jul 14, 2017

View reviewed changes

jcsteh requested changes Jul 20, 2017

View reviewed changes

Review actions

e2e32f7

jcsteh approved these changes Jul 20, 2017

View reviewed changes

jcsteh added a commit that referenced this pull request Jul 20, 2017

New braille control type and state abbreviations. Incubates #7248 (is…

1071fd2

…sue #7188).

nvaccessAuto added the incubating label Jul 20, 2017

nvaccessAuto assigned jcsteh Jul 20, 2017

Merge branch 'master' into i7188, resolving conflicts.

c9d3ab1

jcsteh merged commit 2fdb94f into nvaccess:master Aug 1, 2017

nvaccessAuto removed the incubating label Aug 1, 2017

nvaccessAuto added this to the 2017.3 milestone Aug 1, 2017

LeonarddeR added the BabbageWork Pull requests filed on behalf of Babbage B.V. label Oct 11, 2019

Uh oh!

Conversation

LeonarddeR commented Jun 3, 2017 • edited by jcsteh Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Link to issue number:

Summary of the issue:

Description of how this pull request fixes the issue:

Testing performed:

Known issues with pull request:

What's New Entries

Uh oh!

LeonarddeR commented Jun 23, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

derekriemer commented Jun 25, 2017 via email

Uh oh!

jcsteh commented Jul 10, 2017

Uh oh!

dkager commented Jul 10, 2017

Uh oh!

jcsteh commented Jul 10, 2017 via email

Uh oh!

dkager commented Jul 10, 2017

Uh oh!

jcsteh left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dkager commented Jul 11, 2017

Uh oh!

LeonarddeR commented Jul 12, 2017

Uh oh!

dkager commented Jul 12, 2017

Uh oh!

LeonarddeR commented Jul 12, 2017 via email

Uh oh!

dkager commented Jul 12, 2017

Uh oh!

jcsteh commented Jul 13, 2017 via email

Uh oh!

dkager commented Jul 13, 2017

Uh oh!

Choose a reason for hiding this comment

LeonarddeR commented Jun 3, 2017 •

edited by jcsteh

Loading

LeonarddeR commented Jun 23, 2017 •

edited

Loading