search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
Other
2.08k stars 627 forks source link

Add RGB values for colors to formatting reporting #8674

Open LeonarddeR opened 6 years ago

LeonarddeR commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

LeonarddeR commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

JulienCochuyt commented 4 years ago

@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 commented 4 years ago

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

jage9 commented 3 years ago

I see this issue was closed without being resolved. While an add-on is available, it seems like an appropriate use of NVDA+F twice, especially with a shorthand for color values. I'm currently in a spot where I need to determine the hex colors of various website elements in order to copy them to other locations. Since the information is available, and NVDA+F twice by design is a command that would typically be executed when one is looking for detailed info, this seems like an an appropriate small mod.

JulienCochuyt commented 3 years ago

@jage9, I actually quite agree with @XLTechie's https://github.com/nvaccess/nvda/issues/8674#issuecomment-653281034 proposal of a setting in the Advanced section.

For a quick and dirty one-liner workaround, you may paste the following in the Python console:

import colors; colors.RGB.name = property(lambda self, super_=colors.RGB.name.fget: f"{super_(self)} (RGB: #{self.red:02x}{self.green:02x}{self.blue:02x})")

Make sure to run this only once per session, though, otherwise it'll mess things up until you restart NVDA.

feerrenrut commented 3 years ago

If someone is willing to do the work, this might be appropriate as a command (not assigned to a shortcut). The command could report the named color on first press and the RGB / HEX on second and third press.

JulienCochuyt commented 3 years ago

@feerrenrut wrote:

If someone is willing to do the work, this might be appropriate as a command (not assigned to a shortcut). The command could report the named color on first press and the RGB / HEX on second and third press.

Having an easy way to copy this info is also pretty useful, especially as there are up to three colors to consider (foreground, background and background2 in case of a gradient). The browsable message is just perfect for this. Thus, I'd like to kindly insist on providing a new unbound global command script showTechnicalFormattingAtReview, behaving just like showFormattingAtReview does, but including this additional technical information. It could then subsequently be augmented by other technical info regarding the formatting as need arises without further polluting non-technical users. Regarding RGB decimal vs RGB hex vs CMYK vs anything else, IMHO this is of no importance as technical users most likely can easily handle the needed conversion. I'd personally go for "RGB #XXXXXX" as used in HTML/CSS, but I really do not care much.

@feerrenrut, would you accept a PR implementing this proposal?

JulienCochuyt commented 3 years ago

@leonardder is your BabbageCom/nvda@ad41d9f6c still relevant / functional? Should it be included here?

lukaszgo1 commented 3 years ago

Having an easy way to copy this info is also pretty useful, especially as there are up to three colors to consider (foreground, background and background2 in case of a gradient). The browsable message is just perfect for this. Thus, I'd like to kindly insist on providing a new unbound global command script showTechnicalFormattingAtReview, behaving just like showFormattingAtReview does, but including this additional technical information.

+1 to this.

Regarding RGB decimal vs RGB hex vs CMYK vs anything else, IMHO this is of no importance as technical users most likely can easily handle the needed conversion. I'd personally go for "RGB #XXXXXX" as used in HTML/CSS, but I really do not care much.

I believe the most common presentation inn NVDA is RGB decimal - while certainly more verbose than RGB hex it seems to me the latter is known only to people familiar with HTML/CSS. For what its worth all other screen readers under Windows present color as RGB decimal.

JulienCochuyt commented 3 years ago

@lukaszgo1 wrote:

I believe the most common presentation inn NVDA is RGB decimal - while certainly more verbose than RGB hex it seems to me the latter is known only to people familiar with HTML/CSS. For what its worth all other screen readers under Windows present color as RGB decimal.

Thanks for the feedback. In order to preserve conciseness (especially when there are three colors involved) I would opt for not mentioning the names "red", "blue" and "green", but I'm wondering whether slashes or commas are most appropriate as separators. That is, either "(RGB: 255/255/255)" or "(RGB: 255, 255, 255)".

FWIIW, here is my draft implementation with the hex notation: accessolutions/nvda@473cab87d (I mentioned @leonardder here as co-author as this is partly based upon his earlier prototype)

My personal taste is to bind this to NVDA+alt+shift+f.

LeonarddeR commented 3 years ago

@leonardder is your BabbageCom/nvda@ad41d9f still relevant / functional? Should it be included here?

It is only relevant if you care about NVDA reporting an unknown background colour for display model text if the colour couldn't be determined appropriately.

LeonarddeR commented 3 years ago

I will reopen as there seems to be debate about whether this should yet be in core.

feerrenrut commented 3 years ago

I will reopen as there seems to be debate about whether this should yet be in core.

While I think this is most useful for developers (but not necessarily NVDA developers), it is quite a small addition and as long as it is a command doesn't add more config to create varied behavior for end users.

An advanced or developer centric formatting command sounds like a good idea @JulienCochuyt

I think commas and a colon are most appropriate. It is the main convention I have seen. EG "RGB: 255, 255, 255".

How will this print other variations of color formatting RGB Hex? Perhaps "RGB: #FFFFFF" That leaves room for other color models, and number formats:

RGB: 255, 255, 255
RGB: #FFFFFF
HSB: 26.1, 51.6%, 43.7%
CMYK: 0, 0.385, 0.68, 0.337

To be clear, I don't expect all these color models to be in this first implementation. I'd suggest starting with both RGB decimal and RGB hex since they are easy and cover the most frequent use cases:

JulienCochuyt commented 3 years ago

@feerrenrut, thanks for the feedback. I'm not sure I'm getting your point regarding the different formats, though. The current prototype implementation supports a single format and requires no configuration at all. I understand we agree to default on decimal with commas (RGB: 255, 255, 255) Outputting in two formats, eg: (RGB: 255, 255, 255 / #ffffff) seems still quite reasonable, but adding more formats after each color names will pollute the output more than it helps IMHO. Thus, would you prefer (sorted according to my personal preference, but without much conviction) : 1- stick with just decimal (RGB: 255, 255, 255) 2- the dual formats solution (RGB: 255, 255, 255 / #ffffff) 3- the full-fledged but lengthy (RGB: 255, 255, 255 / #ffffff; HSB: 26.1, 51.6%, 43.7%; CMYK: 0, 0.385, 0.68, 0.337) 4- a setting in advanced to choose the preferred format

XLTechie commented 3 years ago

@JulienCochuyt Since you're doing this in a browseable message, why not put the different formats after each other, one per line, as the last element provided?

RGB: 255, 255, 255 Hex: #FFFFFF HSB: 26.1, 51.6%, 43.7% CMYK: 0, 0.385, 0.68, 0.337

if you're going to provide that much information. The user not caring about HSB or CMYK can just stop reading.

Alternatively, if just providing hex and RGB:

FFFFFF (255, 255, 255)

The latter seems most compact, but otherwise I vote for your option 2.

CC @ajborka

ajborka commented 3 years ago

My experience with this issue is the varying preferences each person might have with displaying color values. A typical user might want color names, where a developer might want the other color models. On the other hand, some developers such as myself, use more than one. I would recommend providing an option for the color model(s) to show with formatting information. In fact, it might be more of a benefit to not only let users choose the color models to display, but also allow them the choice on what formatting elements to watch for. Developer toolkit addon already provides these features as well as the ability to explore the accessibility tree of applications/websites. Maybe you could include Developer toolkit in NVDA core? This way, users get a choice on formatting elements and color display. They would also get the accessibility tree explorer. In either case, the standard color format is MODEL_NAME(parameter1, parameter2, parameter3…).

JulienCochuyt commented 3 years ago

@XLTechie wrote:

why not put the different formats after each other, one per line, as the last element provided?

Because in order to limit the workload and the burden of maintaining a feature that is not really needed by the "core target", I chose to follow @leonardder's prototype path of reusing the "showFormatting*" commands code, which in turn actually reuses the code used to report format changes in speech. The original statement, as output to speech when reporting of color changes is enabled, is something like "black on white" or "black on white to yellow" in case of a gradient (with potentially much more lengthy and precise describing color names. This way of doing it is of course open to discussion and appending a full detailed description of the up to three colors involved is naturally feasible. Still, IMHO, the advantage of this approach is the conciseness of the patch to review as NV Access has limited resources and must choose with care what it prioritizes.

feerrenrut commented 3 years ago

I'm not sure I'm getting your point regarding the different formats, though. The current prototype implementation supports a single format and requires no configuration at all. I understand we agree to default on decimal with commas (RGB: 255, 255, 255) Outputting in two formats, eg: (RGB: 255, 255, 255 / #ffffff) seems still quite reasonable, but adding more formats after each color names will pollute the output more than it helps IMHO. Thus, would you prefer (sorted according to my personal preference, but without much conviction) : 1- stick with just decimal (RGB: 255, 255, 255) 2- the dual formats solution (RGB: 255, 255, 255 / #ffffff) 3- the full-fledged but lengthy (RGB: 255, 255, 255 / #ffffff; HSB: 26.1, 51.6%, 43.7%; CMYK: 0, 0.385, 0.68, 0.337) 4- a setting in advanced to choose the preferred format

Let's do option two for now. I haven't looked at the PR yet, but I was imaging that each format would be on its own line and could be identified quickly by the first characters (EG "RGB:", vs "RGB: #"). This leaves room for future alternative formats (which is a separate question). I just wanted to make sure this design left room for the possibility, allowing new formats to be uniquely identified quickly.