This post is co-authored by Michael Fairchild and Jeremy Katherman.
That little minus sign before a number is very important. It can mean the difference between having money in your bank account or paying overdraft fees. It can be the difference between a deposit or a withdrawal.
Negative numbers can be indicated in several ways, including:
- Red text: $100
- Parentheses used for the number: ($100)
- A minus sign in front of the number: -$100
These patterns can present various challenges for accessibility. To discuss those challenges and how to address them, let’s center the conversation around a couple of personas.
Each persona will contain an acceptance criteria that outlines the expectation and how to test it.
Summary
While color may visually emphasize that a number is negative, another method is required to signal that it is negative. Using parentheses or adding a minus sign are common solutions.
For a minus sign: the minus character (?) will provide the most robust support across most screen readers and formats.
The hyphen-minus character that is found on keyboards (-) also has pretty good support but has some gotchas. If you use the hyphen-minus character, do not put a space between the character and the value.
For parentheses: It’s best to make sure that users are informed that negative numbers will be marked in parentheses, especially if used in a non-accounting context where the parentheses may be unexpected.
Persona 1: a low-vision user who is colorblind.
Some people who have low vision or are color blind may incorrectly conclude that a number is positive if red text is the only indicator that it is negative. While color may visually emphasize that a number is negative, another method is required to signal that it is negative. Using parentheses or adding a minus sign are common solutions.
Acceptance criteria
Scenario: A low vision user who is color blind can determine when a number is negative
Given I am testing the low-vision / color blind experience
When the page contains a negative number
And I look at the page through a grayscale filter
Then I can tell that the number is negative
Examples
Bad example: $100
Good example: ($100)
Persona 2: a blind screen reader user.
How the negative number is coded is also very important. If it is coded incorrectly, some blind screen reader users might not be aware the number is negative. There are several techniques to accomplish this with varying levels of screen reader support.
Acceptance criteria
Scenario: A blind screen reader user is made aware that a number is negative.
Given I am testing the blind screen reader user experience
And the page contains a negative number
When I navigate to the negative number
Then I hear that the number is negative (usually announced as “minus”)
Using a minus sign
There are several characters that can be used to code a minus sign. Some examples:
- Unicode’s hyphen-minus character (
-). This is the character that is most often used because it’s the character found on most keyboards. Note: the hyphen-minus character is technically different from the hyphen character in unicode. The hyphen character is not found on most keyboards and is not commonly used. - The minus character (
−). This character is not found on most keyboards and must be coded. In HTML, a common way to code this character is by using the−HTML entity. - Other dash characters, such as em and en dashes. These have different styles and meanings than the hyphen-minus character and minus characters, but are sometimes used in designs for their appearance.
There are also several formats that can be used to indicate a negative dollar value. A few examples:
- -$100 (no space between the minus sign and the dollar sign).
- – $100 (a space between the minus sign and the dollar sign).
- $-100 (dollar sign before the minus sign).
Recommendation
The minus character (−) will provide the most robust support across most screen readers and formats. The hyphen-minus character (-) also has pretty good support but has some gotchas, especially with certain formats. If you use the hyphen-minus character, do not put a space between the character and the value.
Using parentheses
It is a common practice, especially in accounting, to indicate a negative number by wrapping the amount in parentheses: ($100). Testing shows that most screen readers ignore parentheses with default settings and typical navigation commands, which means that if the user isn’t explicitly looking for the parentheses, they might not realize that the number is negative.
Recommendation
It’s best to make sure that users are informed that negative numbers will be marked in parentheses, especially if used in a non-accounting context where the parentheses may be unexpected. This notice will prompt users to explicitly look for the parentheses while navigating the content. It may also be worth considering using a minus sign instead of parentheses.
Tests and results
The testing done for this blog post is pretty exhaustive, covering eight different screen reader and browser combinations. This level of testing can sometimes be helpful in revealing support gaps and gotchas, but takes a lot of time, effort, and expertise, and may not always be reasonable to perform. Nor will it always be possible to achieve 100% support.
The testing shows that:
- The minus character (
−) yields great support in most screen readers, and suffers less situational gotchas than the hyphen-minus character.- Narrator does not support this character. However, Windows users primarily use other screen readers, so this is not likely to cause a significant issue unless your users are restricted to just using Narrator (perhaps for example, because of corporate restrictions).
- The hyphen-minus character (
-) provides good support in all formats that were tested. This will likely be a good starting point, and is also probably the easiest to implement.- There are some gotchas with the hyphen-minus character that cause some screen readers to not announce the value when reading in browse mode (or similar). For example: Including a space between the hyphen-minus and the number value. Avoid a space between the character and the value whenever possible to steer clear of this problem.
The tests were executed using default settings in all screen readers and used the command to navigate to the next line (or equivalent) in browse mode to navigate to the number under test. For example, in JAWS, NVDA, and Narrator, the down arrow command was used. In VoiceOver for iOS and talkback for Android, the swipe-right gesture was used.
Screen reader settings and navigation commands can be used to announce the character even if it is not announced when navigating line-by-line or element-by-element. However, these may not be used by all screen reader users, especially if it is not obvious that the number they are reading might be negative.
Test suite with several examples of how negative numbers might be formatted and coded. This is not an exhaustive list of all the ways that a negative number could be represented.
| Scenario | NVDA/Chrome | NVDA/Firefox | JAWS/Chrome | JAWS/Firefox | Narrator/Edge | VO/MacOS/Safari | VO/iOS/Safari | Talkback/Chrome |
|---|---|---|---|---|---|---|---|---|
| 1 Hyphen-minus before dollar sign, no space | pass “minus 100 dollars” | pass “minus 100 dollars” | pass “minus dollar 100” | pass “minus dollar 100” | Pass “dash dollar 100” | Fail “100 dollars” | pass “minus 100 dollars” | pass “minus dollar 100” |
| 2 Hyphen-minus before dollar sign, with space | Fail “100 dollars” | Fail “100 dollars” | Fail “dollar 100” | Fail “dollar 100” | Fail “100 dollars” | Fail “100 dollars” | Fail “100 dollars” | Pass “minus 100 dollars” |
| 3 Hyphen-minus after dollar sign, no space | Pass “dollar minus 100” | Pass “dollar minus 100” | Pass “dollar minus 100” | Pass “dollar minus 100” | Pass “dollar dash 100” | Pass “dollar sign minus 100 | Pass “dollar sign minus 100” | Pass “dollar minus 100” |
| 4 Minus character before dollar sign, no space | Pass “minus 100 dollars” | Pass “minus 100 dollars” | Pass “minus dollar 100” | Pass “minus dollar 100” | Fail “dollar 100” | Pass “minus 100 dollars” | Pass “minus 100 dollars” | Pass “Minus dollar 100” |
| 5 Minus character before dollar sign, with space | Pass
“Minus 100 dollars” |
Pass
“Minus 100 dollars” |
Pass “minus dollar 100” | Pass “minus dollar 100” | Fail “100 dollars” | Pass “minus 100 dollars” | Pass “minus 100 dollars” | Pass “minus 100 dollars” |
| 6 Minus character after dollar sign, no space | Pass “dollar minus 100” | Pass “dollar minus 100” | Pass “dollar minus 100” | Pass “dollar minus 100” | Fail “dollar 100” | Pass “dollar sign minus 100” | Pass “dollar sign minus 100” | Pass “dollar minus 100” |
| 7 Parentheses | Fail “100 dollars” | Fail “100 dollars” | Pass “left paren dollar 100 right paren” | Pass “left paren dollar 100 right paren” | Fail “100 dollars” | Fail “100 dollars” | Fail “100 dollars” | Fail “dollar 100” |
| 8 Parentheses hack | Pass “minus 100 dollars” | Pass “minus [next element] 100 dollars” | Pass “minus dollar 100” | Pass “minus dollar 100” | Fail “(silence) [next element] 100 dollars” | pass “minus [next element] 100 dollars” | pass “minus [swipe right] 100 dollars” | Pass “minus [swipe right] 100 dollars” |
| 9 Text followed by hyphen-minus before dollar sign, no space | Pass “Balance minus 100 dollars” | Pass “Balance minus 100 dollars” | Pass ”Balance colon minus dollar 100” | Pass “Balance colon minus dollar 100” | Pass “balance dash dollar 100” | Pass “balance minus 100 dollars” | Pass “balance minus 100 dollars” | Pass “balance minus dollar 100” |
| 10 text followed by minus character before dollar sign, no space | Pass “Balance minus 100 dollars” | Pass “Balance minus 100 dollars” | Pass “Balance colon minus dollar 100” | Pass “Balance colon minus dollar 100” | Fail “balance dollar 100” | Pass “balance minus 100 dollars” | Pass “balance minus 100 dollars” | Pass “balance minus dollar 100” |
Versions
- NVDA 2023.1 with Chrome 116 on Windows 11 22H2
- NVDA 2023.1 with Firefox 117 on Windows 11 22H2
- JAWS 2023.2307.37 with Chrome 116 on Windows 11 22H2
- JAWS 2023.2307.37 with Firefox 117 on Windows 11 22H2
- VO on iOS 16.6
- VO with Safari 16.6 on MacOS 13.5
- Talkback 13.5 with Chrome 115 on Android 13
- Narrator with Edge 116 on Windows 11 22H2
Jeremy Katherman is a Senior Accessibility Consultant/Coach at Deque with over a decade of experience leading teams in accessibility in the banking and insurance industry and consulting with various companies worldwide to develop their accessibility programs. Throughout his career he has worked to inspire inclusion and a love of learning. He is a Certified Professional in Web Accessibility (CPWA) from the International Association of Accessibility Professionals (IAAP) and eager to help you take the next step in your accessibility journey.