a11y bug: number filter should insert a minus character for negative values (not dash)

[120psi]

I noticed that the AngularJS number formatter adds a dash for negative numbers (defined in ngLocale) but, for a11y, we should be using the minus sign (utf8 "−") (entity −) which is read out by screen readers as "minus" whereas a dash is often omitted.

[naomiblack]

@petebacondarwin assigning to you for triage... I'm not sure who should pick this one up.

[gkalpak]

Adding some context:

Angular uses the Google Closure I18N library, to generate its own I18N files. For negative numbers in particular, we rely on the negative patterns (if present) found in numberformatsymbols.js. If there is no negative pattern (the majority of cases), we indeed use - (a dash) - we also have a comment saying it is the same as \u2212 (the minus sign), which is obviously not very accurate.

I would be preferable (imo) to use the locale's MINUS_SIGN instead. That said, this would still not solve the issue by itself, since most locales use a dash as their MINUS_SIGN. There are also some that use \u2013 (an n-dash) as their MINUS_SIGN (example) and I assume there are some that use \u2212.

Ideally, we should be relying on Closure's MINUS_SIGN and the MINUS_SIGNs should be fixed in Closure, but I am not sure if there are legitimate reasons for the current values in Closure.

In any case, I don't think this is something that the number formatter should overwrite. It should stick to the negPre/negSuf values specified in each locale. Any solution should go through the locale files.

Alternatively, we could have ngAria overwrite the dash in the current locale's negPre/negSuf, although that is the kind of magic that turns out to be more confusing than helpful.

Finally, as a temporary workaround, it is also possible to overwrite the minus signs for number/currency formatting (demo):

run(function ($locale) {
  // `number` patterns
  replaceMinusSign($locale.NUMBER_FORMATS.PATTERNS[0]);

  // `currency` patterns
  replaceMinusSign($locale.NUMBER_FORMATS.PATTERNS[1]);

  function replaceMinusSign(patternsObj) {
    patternsObj.negPre = patternsObj.negPre.replace(/-/g, '\u2212');
    patternsObj.negSuf = patternsObj.negSuf.replace(/-/g, '\u2212');
  }
})

And with that, I hand it back to @petebacondarwin 😁

[IgorMinar]

Let's get this fixed in CLDR itself as the problem seems to originate there. Check out: http://www.unicode.org/cldr/charts/latest/summary/en.html which uses \u002d for the minus sign, rather than the accessible version: \u2212.

Once it is fixed there, we should ensure that the fix correctly propagates to Closure but also to angular/angular which pulls locale info directly from CLDR (fyi: @vicb, @pkozlowski-opensource, @ocombe).

[IgorMinar]

I've pinged the google i18n team to help us determine the next steps to get this fixed.

[120psi]

Original reporter here. This actually may be screen-reader dependent and there might not be a straightforward solution. I have access to both ChromeVox and VoiceOver.

Further investigation:

• VoiceOver reads '-13' aloud as "13"
• VoiceOver reads '−13' as "minus 13"
• ChromeVox reads '-13' aloud as "minus 13"
• ChromeVox reads '−13' as "minus sign 13"

I'd want to find out what JAWS and NVDA do before moving forward, since those are the most commonly used readers in the real world.

[petebacondarwin]

Waiting on further information from @120psi

[NilsAtGoogle]

(replying from corp github account)

Attached is a simple HTML page with both − and - used.
test.html.txt

As stated earlier in the thread, this appears to be an implementation issue with VoiceOver vs. a need to fix underlying libraries

[petebacondarwin]

So does that mean that we can close this issue @NilsAtGoogle ?