Nvda: Add RGB values for colors to formatting reporting

[leonardder]

Steps to reproduce:

1. In MS Word, change the color of a line of text
2. Press NVDA+f twice to get formatting information

Actual behavior:

The color of the text is mentioned, however there is no information about the RGB value.

Expected behavior:

I think it makes sense to have the RGB value reported when viewing formatting information in browse mode. When pressing NVDA+F once, RGB information is overkill. Having the RGB value can assist blind people who do not have any idea of what colors look like in getting a conceptual idea of how a color is created (i.e. purple is a combination of red and blue). Alternatively, it can assist in reproducing the color when using color pickers such as the Windows default color picker dialog, that allows creating custom colors based on RGB values.

[leonardder]

CC @feerrenrut:

See also https://github.com/nvaccess/nvda/issues/6029

To give an additional rationale, NVDA treats both RGB(0, 0, 255) and RGB(50, 50, 255) as bright blue, whereas RGB(50, 50, 240) is treated as light pale blue. I can imagine that the difference between the first and second examples is way greater than the difference between examples 2 and 3.

[DrSooom]

@leonardder: Thanks for opening this issue because I also planned to do the same. So, here is my suggestion:

Expected behaviour:

Document Formatting NVDA Settings

Add the following options:

• [combobox] First color value
  
  
  
  • color name [default value]
  
  
  • RGB (decimal)
  
  
  • RGB (hexadecimal) [important for web developers]
  
  
  • HSB [would be nice too]
  
  
  • CMYK [important for to be printed documents]
  
  
• [combobox] Second color value
  
  
  
  • None [default value]
  
  
  • color name
  
  
  • RGB (decimal)
  
  
  • RGB (hexadecimal)
  
  
  • HSB
  
  
  • CMYK
  
  
  • Note that the value of the first color value combobox has to be make unselectedable in the combobox of the second color value.
  
  
• [checkbox] Use app-specific color names (if available)
  
  
  
  • Default value: enabled [actual behaviour in NVDA 2018.1]
  
  
• [checkbox] Report background color
  
  
  
  • Default value: enabled [actual behaviour in NVDA 2018.1]
  
  

Speech and Braille output:

• If "None": First color value [actual behaviour in NVDA 2018.1]
• If not "None": First color value (Second color value)
• RGB (decimal), HSB and CMYK: Values are comma separated in Speech and Braille output without any differences.
  
  
  
  • 170, 0, 0 | 0°, 100, 66.67 | 0%, 100%, 100%, 33.33%
  
  
• RGB (hexadecimal): Different separation in Speech and Braille output because of different speech pronunciations depending on the selected synthesizer.
  
  
  
  • Speech: a a, 00, 00
    
    Note: There must be always a space in front of the second letter, but never in front of the second digit.
  
  
  • Braille: #aa0000
    
    Note: Small letters in Braille are easier to read instead of capitals.
  
  
• Well, and the formatting information has to be the same on NVDA+F and NVDA+F double pressed, otherwise it is just confusing.

[leonardder]

@DrSooom: I like your suggestion, but I'll limit it to name and decimal rgb only. If you real need other values, you can perfectly use the decimal values to calculate hsb.

Update: actually, this still gets pretty verbose.

[leonardder]

I have a prototype branch that adds the RGB value to the browsable formatting information, retrieved when pressing NVDA+f twice.

@feerrenrut: I'd like your opinion on user experience here, taking the following considerations in mind:

1. The RGB value is very helpful for developers, while not at all interesting for the mainstream user.
2. The current way of getting the raw RGB value requires some knowledge about textInfos and the python console, and is therefore too complex for quick debugging.
3. In contrast, having a browseable message like this is pretty verbose:
   very dark aqua-blue grey (red=36/255, green=41/255, blue=46/255) on white (red=255/255, green=255/255, blue=255/255)
   We can also leave out the /255 part, but then, it is just stupid garbage for everyone who is not interested in the RGB value. Converting the values to percentages throws away accuracy.

[DrSooom]

@leonardder: Wouldn't it better to give the user the opportunity to set which value are spoken/displayed on pressing NVDA+F once (via a list of checkboxes in the Document Settings; see NVDA modifier key selection in NVDA 2018.3)? After NVDA+F is pressed twice, all values can be shown there, which makes even more sense, because every single value can be read by itself. This will reduce the amount of values to a minimum on the first announcement of the formatting info. Shall we open a new issue for this feature request?

[DrSooom]

And if only RGB is available, we can reduce "very dark aqua-blue grey (red=36/255, green=41/255, blue=46/255)" to "very dark aqua-blue grey (36, 41, 46)", because the order of the RGB values is always firm.

[JulienCochuyt]

@leonardder wrote:

I have a prototype branch that adds the RGB value to the browsable formatting information, retrieved when pressing NVDA+f twice.

IMHO including this only on the second press as you propose is both useful and fairly enough.

very dark aqua-blue grey (red=36/255, green=41/255, blue=46/255) on white (red=255/255, green=255/255, blue=255/255)

What about: very dark aqua-blue grey (RGB: #24292e) on white (RGB: #ffffff)

That is, simply present as a 24 bits hex value as commonly used with HTML/CSS, which significantly reduces footprint.
I guess most people interested in this value in the first place might be able to handle any needed conversion.

[CyrilleB79]

Did any non-developer complain about missing information regarding color? If not, having an add-on doing the job would be more appropriate; I do not know however if it is easily doable.

In any case, I also imagine that having much information at first press would be counterproductive and confusing for a majority of people who do not have a technical background.
An other option regarding the browseable message would be to separate technical info from standard information, e.g. putting technical color information (and maybe other) at the bottom of the browseable Message. This allow to dev or tech guys to get more info without confusing the other users.

[feerrenrut]

I tend to agree that this would likely be better as an addon. That said, if our current color descriptions are inaccurate or not handling edge cases well then please open issues for those specifically.

[leonardder]

I tend to agree that this would likely be better as an addon. That said, if our current color descriptions are inaccurate or not handling edge cases well then please open issues for those specifically.

There is at least #9183.

I think having this in an add-on is a valid solution here. Closing.

[Adriani90]

At least for web content, there is already this addon in place
https://github.com/ajborka/nvda_developer_toolkit
Amongst many features, you can press f to hear the formatting and the color of an element and with ctrl+c you can change the format of color reporting to rgb, hex, etc.

[lukaszgo1]

There is one use case for which having RGB values would be helpful which has not been considered i.e fetching the RBG value of the color used for selection in DisplayModel based controls. While interesting only for developers we have certain features only for them i.e Python Console, WX Inspection Tool etc and they are not _distributed_ as an add-ons. It would also be difficult to have this functionality in an add-on in a pretty form - we can either create second command only for fetching of the RGB values or replace the default script for fetching formatting entirely. I don't thing RGB values for foreground and background color present at the end of the browseable message would be problematic for people not interested in them, and they might be of great value during development of certain plugins for NVDA.

[XLTechie]

Or use a checkbox in advanced, or better yet a combo: off, hex, or RGB.

[JulienCochuyt]

@lukaszgo1 wrote:

There is one use case for which having RGB values would be helpful which has not been considered i.e fetching the RBG value of the color used for selection in DisplayModel based controls.

I agree. I already stumbled upon this one when developing an AppModule for a customer, and digging for the right values from the format fields of the TextInfo was pretty tedious.
I was even happier when a later update slightly updated the color theme...

[feerrenrut]

NVDA treats both RGB(0, 0, 255) and RGB(50, 50, 255) as bright blue, whereas RGB(50, 50, 240) is treated as light pale blue. I can imagine that the difference between the first and second examples is way greater than the difference between examples 2 and 3.

I was curious about this, they are quite similar colors to my eye. I do tend to agree that the first and second are further apart than the second and third. Though it's a mistake to compare them this way, the colours are given names based on them fitting into a segment of the colour space, they may not be at the center of the space. Two colours close to a boundary will have a small relative difference, but will be given different names. In the end colour names are a fairly arbitrary construct. Survey N people and you'll get N+1 answers for what the colour should be called 😛

For an interesting discussion on colour comparisons see: https://stackoverflow.com/questions/5392061/algorithm-to-check-similarity-of-colors