nvaccess
NVDA is showing lowercase notation for single letters in the Input Gestures Dialog (possibly elsewhere) which introduces confusion for sighted assistants
Steps to reproduce:
This issue can be reproduced in many instances, as I have now been made aware that NVDA does a "force lowercase" on single letters when they occur in keyboard shortcuts (and, possibly, in documentation, but I am not certain of that and do not have time to research it). A topic now exists on the NVDA Add-On Developers Group where I brought this up: A suggestion: In documentation, when referring to the letter L (ell), use the capital form.
Based on conversation there, this practice extends to all keyboard shortcuts when presented by NVDA, and that presentation not only is confusing (particularly for the letter ell, which in lowercase in the font used by NVDA, is indistinguishable from an uppercase I) for any sighted user or assistant, but goes against the de facto standard in every piece of documentation from every major software maker I've read since the mid-1980s. Individual letters when used in keyboard shortcuts are always presented in their uppercase form. This is easy to confirm in looking at any Microsoft keyboard shortcut documentation, JAWS shortcut documentation, and many others.
The way I happened upon this was for the Speech Logger Add-On, when looking for the input gesture to toggle it off/on, which is NVDA + Alt + L. I could not tell whether it was an I versus an L, and this would have been immediately obvious had uppercase been used for the single letter in the shortcut.
Standard practice is using uppercase and NVDA should be following that practice.
CC NV Access folks, but first, please fill out the template to the fullest. Thanks.
Joseph,
No, I am not filling out the rest of the template because:
- It's not relevant.
- This is clearly something NVDA has been doing for ages.
I will not be a slave to convention where convention serves no purpose. If this issue is rejected based on "being incomplete" then so be it. ALL necessary information has been given to identify the problem, and propose a solution. That is enough.
Brian
On Mon, Apr 22, 2024 at 9:47 AM Joseph Lee @.***> wrote:
CC NV Access folks, but first, please fill out the template to the fullest. Thanks.
— Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/16438#issuecomment-2069501665, or unsubscribe https://github.com/notifications/unsubscribe-auth/AENFMHX6JYKRJSQUIUIAKULY6UIFRAVCNFSM6AAAAABGS2EWM6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRZGUYDCNRWGU . You are receiving this because you authored the thread.Message ID: @.***>
This definitely also affects the complete user guide and the quick command references. In the user guide standards there is following written:
- Key commands (e.g.
``NVDA+control+upArrow``):- should be written in lowerCamelCase
cc: @Qchristensen do you have any ideas why lower case has been prefered as standard over upercase?
Hi,
Issue template: I get that. But do remember that there are community members who will insist and ask us to show our work.
Documentation style: I guess this came from coding style as well where we use camel case. This works okay for Latin scripts but not for other languages (this is why I advised asking translators in the oiginal NVDA Add-ons list thread).
Thanks.
@britechguy next time please use the feature request template and not the bug template. In the feature request template you can describe the problems better.
@Adriani90
This, too, has been mentioned in the NVDA Developer's Group topic I linked to.
This is a "systemic issue" that I have no way to cleanly identify other than by identifying the issue and letting those who know where to look go there and fix it.
I don't get to make the call as to whether it's fixed, but it is a major violation of common convention, and I can say that with no worry of being contradicted.
@Adriani90
I asked about which template to use, and there was no consensus. I just wanted to get this on record. The report would have been no different regarding which format I had chosen. As I said, this is a systemic issue that the NVDA Development and documentation teams need to look at and address, or not address.
@josephsl
What work can you possibly show in this context?
As to the translators, as I said, they need to be involved. Now there is an issue that allows anyone who wants to needs to "hang their hats" on it. I've done my duty.
Hi,
For this project, coders tend to write documentation as well - we should definitely ask @Qchristensen about coordinating a change to documentation style/convention/wording.
@josephsl is camel case usually used in front end and GUI design at all? Or is camel case used rather for backend development or for things that are not shown on the screen? If camel case is not used in GUI in general, we should change the standard to upercase in my view.
Hi,
Stack Overflow discussions do reference PEP8 which advises using underscores, but do have a note about using whatever style a project has adopted. In case of NVDA, it uses camel case regardless of front-end/back-end, so it is easy to see how it is affecting documentation style. Recently, NVDA has been moving a bit closer to PEP 8 style recommendations (using underscores to separate words when defining labels for constants (all uppercase)). The coding style also extends to add-ons but the style used in add-on code depends on authors' style (I generally follow NV Access's coding style in my own add-ons).
In case of input gestures representation (separate issue but this is a big example used), gesture bindings are both presented and stored in camel case form except the NVDA modifier key which is all uppercase in input gestures dialog.
Thanks.
+1. I think this is likely also a concern for low-vision users.
You can safely "bet your bottom dollar" on that, and have a sure thing. It's confusing for me, and I can see everything. It's far worse for those whose visual discrimination is decreased, but who still have enough vision to rely on it, at least in part.
The lowercase, especially for single letter, is clearly not something common, and I have always found it strange in NVDA.
Thanks @britechguy for having opened the subject on the mailing list, and then this issue.
@britechguy two additional fields of the original template would still have been useful. So I'd complete as follow. Feel free to confirm or express a different opinion.
Actual result
NVDA uses lower camel case in its documentation as well as in input gesture dialog, except for NVDA kay which is always uppercase. E.g.: NVDA+alt+l, NVDA+control+upArrow
Expected behaviour
NVDA should rather use upper camel case in its documentation as well as in input gesture dialog, except for NVDA kay which is always uppercase. E.g.: NVDA+Alt+L, NVDA+Control+UpArrow
So I'd complete as follow. Feel free to confirm or express a different opinion.
Actual result
NVDA uses lower camel case in its documentation as well as in input gesture dialog, except for NVDA kay which is always uppercase. E.g.: NVDA+alt+l, NVDA+control+upArrow
Expected behaviour
NVDA should rather use upper camel case in its documentation as well as in input gesture dialog, except for NVDA kay which is always uppercase. E.g.: NVDA+Alt+L, NVDA+Control+UpArrow
Cyrille,
I fear the following will be taken personally, and I am urging you not to, and all here to read and consider what I have to say. I am someone who has a background in software development and using a system akin to GitHub, so I'm a more sophisticated reporter than many might be.
I have no idea what in the hell "lower camel case" even is. The very first time I've heard this terminology is here.
I also made clear that the issue I was reporting was likely in areas I had not even considered, because I did not and do not have the background to make those considerations.
Issue reports by end users need to be taken understanding that "on the receiving end" they may need to be broken into multiple pieces, expanded, etc., by those who are "in the know."
I am not "in the know" in this case. It is not my job, nor should it be, to be doing what is asked because it is beyond my skill set.
If someone offers a clear problem description, and a clear rationale for a request for change, in a situation like this, this needs to be accepted as more than enough. It is up to those at NVAccess to parse all this apart and get the necessary parties involved, not the reporter's.
@britechguy, to be more concrete without opening endless discussions, my only question is:
On the basis of the examples provided in the description that I have made, do you agree with these changes or not?
And if not, could you provide examples of what you suggest? e.g. NVDA+Alt+A and NVDA+ALT+A are two distinct solutions to the current issue.
PS: @britechguy, if you do not know what "lower camel case" is, it's not too late, fortunately! A Google request on these 3 terms point on the following page explaning it.
e.g.
NVDA+Alt+AandNVDA+ALT+Aare two distinct solutions to the current issue.
Either is entirely acceptable. Anyone reading NVDA documentation, or other documentation, should recognize that modifier keys are often in either all uppercase or mixed case. It was strictly the A at the end of those two examples that should consistently be presented in uppercase form.
Similarly, the command in Excel to change the Font Face in use would be presented as, ALT + H, F F or Alt + H, F F. Any letters, used as letters in a keyboard shortcut, are conventionally presented in uppercase. My personal preference is that modifier keys that correspond to actual keys on the keyboard are presented in mixed case, first letter capitalized, while modifier keys that are assigned by software, e.g. the NVDA Key, be presented in all uppercase.
This issue has been temporarily locked for being too heated - please remember the code of conduct when participating in the NVDA repository.
One alternative solution to this is changing the font in NVDA and documentation to a hyper-legible font that easily distinguishes these. Please update this issue or open a new issue using the feature request template. It would be helpful to format this issue so that it describes the problem, desired solution and alternative solutions in a structured manner.
it does seem we are not following Microsoft's convention here:
- https://writing.stackexchange.com/questions/19455/format-keyboard-keys-in-documents
- https://learn.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/term-collections/keys-keyboard-shortcuts
Note that when migrating, this is likely to be a slow and manual process. At the same time, having partially converted content will be even more misleading, as shift+I (upper case I) and shift+l (lower case L) will appear in the same document.
Updating to a hyper legible font will help minimize this problem until migration is complete, and ensure similar issues like confusing capital O and 0 don't result from this change.
One alternative solution to this is changing the font in NVDA and documentation to a hyper-legible font that easily distinguishes these.
Low vision users sometimes use custom fonts to improve readability, so they might be overriding that font. However, those fonts might have the same problem distinguishing between uppercase letter I and lowercase letter L. I know it is not very probable, but what I say is that you cannot guarantee that the user is seeing the text as you think they are doing.
Re the font specification, it does not cover the case where the text is copy/pasted elsewhere, although I acknowledge that it is a minor use case.
Could we take advantage of the next file format conversion (from .t2t to .md) to format all the shortcuts correctly? Or maybe it's already too late?
@CyrilleB79
Could we take advantage of the next file format conversion (from .t2t to .md) to format all the shortcuts correctly? Or maybe it's already too late?
I am willing to take on the task of doing this for the English docs, after the conversion to MD.
If possible, being able to automate it (at least partially), not only for English doc but also for translated ones would be a plus. Because mixing this conversion with other modifications in the documentation may be harder to follow for translators.
I expect to be able to use regular expression replacements to do most of it.
@michaelDCurran is this blocked by #17078? Or, what is the current opinion of NV Access, regarding using different key styling in the docs and the UI?
I consider the transition to upper case in parts of the key names (especially the single letter portions), to be an accessibility issue, not a cosmetic one, for low-vis users. See the conversation above. Thus I would like to take a stab at this issue, but it is of course dependent upon NV Access being willing to have different key styles in the UI and the docs, at least for a while.