Re: determining the color of a text in Excel with NVDA
Thanks again Rick. This is another great post!toggle quoted messageShow quoted text
I agree with you that NVDA should not change how it renders what it encounters in terms of color. I also agree that Microsoft Accessibility ought to address the issue as you described.
You've shared the main reasons for this very well.
On Mon, 10/22/18, Rick <softwarethatworks@...> wrote:
Perhaps your difference for negative number choices is a localization variance based upon your operating system language. I am using US format for numbers and currency, so I get my third choice as number surrounded by parenthesis and fourth as red surrounded by parenthesis. Perhaps it is different for different countries.
Personally, I find no reason for NVDA to change. It is reading what is in the cell. JAWS and Narrator behave the same way. For NVDA to properly interpret the cells meaning, it would need to first ascertain that the cell is formatted as a number or currency before attempting to provide alternate speech for numbers that are bright red in color. If the cell is formatted as text, it may not even represent a negative number. Furthermore, since currencies differ from country to country, NVDA might have to further drill down based upon localization and currency choices. All this processing at each cell could slow down reading and I am not in favor. The real solution is for Microsoft to remove this antiquated choice (or replace it with a choice that is bright red with a negative sign) and to flag it as an accessibility error in their accessibility checker.
If the options with parenthesis are chosen and the NVDA symbol verbosity level is not set to high or all, the same situation occurs. NVDA will not speak the parenthesis and the user will not be provided with the necessary information. Should this be a warning in the accessibility checker, since a wrong choice for symbol verbosity will result in misinterpretation? I forget, but what is the default symbol verbosity level in NVDA?
To make things even more confusing, the use of red seems to come from accounting, yet there are no choices when setting the format to accounting to choose how negative numbers are displayed. Accounting format only displays negative numbers in parenthesis with no color variations. The difference in US currency is that accounting displays the dollar sign outside of the parenthesis while currency displays the dollar sign within the parenthesis. This means that when NVDA speaks the numbers with symbol verbosity to none or low, the user can differentiate between positive and negative accounting numbers. Positive numbers are spoken as 1 dollar, 2 dollars, etc. while negative numbers are spoken as dollar 1 dot zero zero and dollar 2 dot zero zero. Since currency formatting puts the dollar sign inside the parenthesis, positive and negative numbers are spoken identically when symbol verbosity is set to none or low.
I also did a little digging on the history of using red to signify negative numbers. Below is the best excerpt that I found.
What does it mean to be “in the black” or “in the red?”
September 30, 2015/
If you’re even slightly familiar with the world of accounting and finance, you’ve probably heard the phrases “in the red” and “in the black” before. Even if you are not in finance, you may have heard the terms anyway—they have become a part of our everyday speech and they are often used in common conversation.
For those of you not familiar with the phrases, I’ll briefly explain. The phrase “in the black” refers to being financially solvent or profitable, or sometimes more generally, just not in debt. A business that is “in the black” is usually making a profit or, at the very least, making enough to get by without having to worry about going bankrupt. Conversely, the phrase, “in the red” means to be in debt, running a deficit, or generally just not making money—being cash negative. Although cash flow cycles for businesses and people change from year to year, a business that is “in the red” for several years in a row without a plan to get out of debt often fail. Of course, the phrases aren’t always used consistently, and there are always exceptions to the rule, but in general, being “in the black” is a positive thing, and being “in the red” is usually considered to be a negative thing.
So, now that you know what both of these phrases mean, you may be wondering where the terms came from or what their origins are? After all, there aren’t really any other fields in which these colors (black and red) are used to indicate positive and negative. So if you are guessing that these color indicators are somewhat unique to the world of finance, you would be correct.
To understand where these phrases come from, we have to go back to the days before accounting was done on computers. Before computers, accountants did everything by hand and with pen and paper. In order to help them differentiate between deposits and debits, they started using different color ink for each. Because black and red ink were two readily available colors, they were chosen for the purpose. Though it’s only speculation, some say that red was chosen to denote debits/losses/debts because red is considered a harsh color and can catch one’s attention. It also subtly reinforces the idea of negativity or something “bad.” They wanted to make debts stand out and catch people’s attention. It’s the same reason that teachers often correct homework and quizzes and tests with red pens—it grabs a student’s attention and lets them focus on what they did wrong so, hopefully, they can learn from their mistake and correct the mistake on the next test or quiz or homework assignment.
And now that everything is done on computers, the history of the phrases has still stuck around. In many cases, they really are meaningless. Most software now uses parentheses to indicate a negative number or a debit. Sometimes, they also simply put a minus sign before a number or even have a separate column in a spreadsheet for debits. It is, however, interesting to note that some computer programs still do use red type for debts and debits—a nod to the history of accounting. Again, there is really no practical purpose for this, but it fits with the history of accounting.
From: email@example.com <firstname.lastname@example.org> On Behalf Of Quentin Christensen
Sent: Monday, October 22, 2018 6:11 PM
Subject: Re: [nvda] determining the color of a text in Excel with NVDA
Good points everyone - I should add, I wasn't intending to be argumentative, I was both indicating why NVDA reads what it does (firstly because it just reads the same text that a sighted user gets visually, and secondly because I don't think anyone had raised this particular scenario previously), and also starting to consider if we do change the information that is provided by the spreadsheet creator (a sighted user may automatically translate a number written in red to mean it's negative, but the information Excel gives them is still a regular number, written in red), are there any other situations to consider, either which should also be changed, or where this could lead to undesirable confusion.
Interestingly, the four options I have for number formatting in Excel (latest Office 365) are black with negative symbol, red without negative symbol, black with negative symbol and red with negative symbol. I'm not sure why the third option for me seems to repeat the first - I was wondering where people were getting the negative number in parentheses from - must be a bug in my Excel maybe?
I have created an issue on our tracker for this, but do feel free to add any other info to it that I haven't thought of: https://github.com/nvaccess/nvda/issues/8875
On Tue, Oct 23, 2018 at 8:13 AM Laurie Mehta via Groups.Io <email@example.com> wrote:
Excellent post-- thank you Rick!
And, for whatever it's worth, I hope that NVDA maintains the way it reads such things currently since we could end up with some unwanted/unforeseen consequences if simply reading the color displayed is replaced with something else. Thanks,
On Mon, 10/22/18, Rick <softwarethatworks@...> wrote:
Hello Mary and Quentin:
After following this thread since its beginning, I took some time to open Excel and play with number formatting. Excel essentially provides 4 standard ways to format negative numbers and currency:
• With a leading negative sign
• Bright red without a negative sign
• With parenthesis
• Bright red with parenthesis
The case Mary seems to describe is the second, where negative numbers are simply bright red without a negative sign. As Quentin pointed out, you could set NVDA to alert for color changes to signal negative numbers.
This case clearly violates WCAG guideline 1.4.1, do not use color alone to convey meaning. While I understand that it may be a common practice to format negative numbers in red, one would hope this practice would be deprecated as we move towards a more accessible world. This is not only bad for screen reader users but also a problem with printing on black and white printers and for people with some forms of color blindness.
Mary, are you able to contact the spreadsheet creator and explain the accessibility issue with the chosen display format? Otherwise, are you able to edit the spreadsheet to change the formatting option? If you select the range of cells, press the application key and select format cells. Tab a few times to get to how negative numbers are formatted and choose a more accessible format for yourself. The first tab should get you to the category, which is probably currency. The next tab is for number of digits after the decimal point. Next is the currency symbol. One more tab gets you to the negative number format. Now, use the up and down arrow to select your desired format (the top one is the conventional negative number sign). Remember, if you choose a format which uses parenthesis that your NVDA symbol level is set to most or all or you will not hear left parenthesis spoken when the number is spoken.
I formatted some negative numbers to display in the inaccessible format and ran the built-in accessibility checker. Sadly, it reported no errors. I reported this issue to Microsoft so hopefully it will be corrected in future versions.