WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: weirdness with NVDA reading multidecimal numbers

for

Number of posts in this thread: 6 (In chronological order)

From: glen walker
Date: Mon, May 10 2021 6:54PM
Subject: weirdness with NVDA reading multidecimal numbers
No previous message | Next message →

If you have a number with three parts, such as a success criteria, and the
third number is double digit, such as 1.4.10, NVDA seems to think the
number is a date, sort of. It thinks the first two numbers are a date and
the third number is just a number.

I tried this with html, with and without list structures, and tried it in a
word doc both with and without multilevel list formatting, and with a
simple text document.

Numbers like 1.2 or 1.2.3 read just fine. In fact, 1.2.X reads fine from
1.2.1 up to 1.2.9. But when the last number goes to double digit, 1.2.10,
1.2.11, all the way up to 1.2.99, NVDA says "January 2nd" and then the
third number. When I hit 1.2.100, NVDA is back to announcing all three
numbers.

(Note, depending on your locale settings, 1.2.10 might read as January 2nd
or it might read as Febuary 1st.)

I think it's a bug in NVDA. Nothing in the settings seems to prevent it.
It's somewhat related to this github issue, but not exactly.

https://github.com/nvaccess/nvda/issues/8103

Has anyone else noticed this? It's not a problem with JAWS.

From: Steve Green
Date: Mon, May 10 2021 8:09PM
Subject: Re: weirdness with NVDA reading multidecimal numbers
← Previous message | Next message →

I have not seen that particular instance, but it's a fairly common type of issue. Screen readers use heuristics to try to read numbers appropriately, based on their format, but it is the nature of heuristics that they are not always right. As long as they are mostly right, they are beneficial.

I suspect that NVDA decided that a number format such as 1.2.99 is going to be a date more often that it's going to be anything else. Since it can be other things, such as a paragraph number, then any decision will sometimes be wrong. Would it benefit anyone if they removed the heuristic entirely and just read the numbers and dots?

In order to improve the heuristic, they would need to take account of the context in which the number appears. If it's in the middle of a paragraph, it's almost certainly a date (but maybe not). If it's the very first thing in a paragraph, it could be a date, a paragraph number or something else. See how difficult this gets?

Steve Green
Managing Director
Test Partners Ltd


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: 11 May 2021 01:54
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] weirdness with NVDA reading multidecimal numbers

If you have a number with three parts, such as a success criteria, and the third number is double digit, such as 1.4.10, NVDA seems to think the number is a date, sort of. It thinks the first two numbers are a date and the third number is just a number.

I tried this with html, with and without list structures, and tried it in a word doc both with and without multilevel list formatting, and with a simple text document.

Numbers like 1.2 or 1.2.3 read just fine. In fact, 1.2.X reads fine from
1.2.1 up to 1.2.9. But when the last number goes to double digit, 1.2.10, 1.2.11, all the way up to 1.2.99, NVDA says "January 2nd" and then the third number. When I hit 1.2.100, NVDA is back to announcing all three numbers.

(Note, depending on your locale settings, 1.2.10 might read as January 2nd or it might read as Febuary 1st.)

I think it's a bug in NVDA. Nothing in the settings seems to prevent it.
It's somewhat related to this github issue, but not exactly.

https://github.com/nvaccess/nvda/issues/8103

Has anyone else noticed this? It's not a problem with JAWS.

From: Mallory
Date: Tue, May 11 2021 12:55AM
Subject: Re: weirdness with NVDA reading multidecimal numbers
← Previous message | Next message →

I would feel better if the text that's visible was the text read out, but that's me.
I don't want to be in an address with "CO" in it and some speech engine says "Company", or says "Doctor" for "Dr" when it has no way of knowing this is "1564 Foobar Dr, Boulder CO" or "Foobar Co, Attn Dr Foo, cat dentist extraordinaire".

Sighties see only the Attn, the Dr, the CO, and they use human brains to determine the context, which I think gives them a leg up on non-Braille screen-reader users who have to go manually spell shizzle every time they hear something which might sound weird.
But many SRs esp NVDA listen to their users, and it's possible they do this because more users liked it than hated it. This is certainly the case with some other SRs like Orca.

cheers,
_mallory

On Tue, May 11, 2021, at 4:09 AM, Steve Green wrote:
> I have not seen that particular instance, but it's a fairly common type
> of issue. Screen readers use heuristics to try to read numbers
> appropriately, based on their format, but it is the nature of
> heuristics that they are not always right. As long as they are mostly
> right, they are beneficial.
>
> I suspect that NVDA decided that a number format such as 1.2.99 is
> going to be a date more often that it's going to be anything else.
> Since it can be other things, such as a paragraph number, then any
> decision will sometimes be wrong. Would it benefit anyone if they
> removed the heuristic entirely and just read the numbers and dots?
>
> In order to improve the heuristic, they would need to take account of
> the context in which the number appears. If it's in the middle of a
> paragraph, it's almost certainly a date (but maybe not). If it's the
> very first thing in a paragraph, it could be a date, a paragraph number
> or something else. See how difficult this gets?
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> glen walker
> Sent: 11 May 2021 01:54
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: [WebAIM] weirdness with NVDA reading multidecimal numbers
>
> If you have a number with three parts, such as a success criteria, and
> the third number is double digit, such as 1.4.10, NVDA seems to think
> the number is a date, sort of. It thinks the first two numbers are a
> date and the third number is just a number.
>
> I tried this with html, with and without list structures, and tried it
> in a word doc both with and without multilevel list formatting, and
> with a simple text document.
>
> Numbers like 1.2 or 1.2.3 read just fine. In fact, 1.2.X reads fine
> from
> 1.2.1 up to 1.2.9. But when the last number goes to double digit,
> 1.2.10, 1.2.11, all the way up to 1.2.99, NVDA says "January 2nd" and
> then the third number. When I hit 1.2.100, NVDA is back to announcing
> all three numbers.
>
> (Note, depending on your locale settings, 1.2.10 might read as January
> 2nd or it might read as Febuary 1st.)
>
> I think it's a bug in NVDA. Nothing in the settings seems to prevent it.
> It's somewhat related to this github issue, but not exactly.
>
> https://github.com/nvaccess/nvda/issues/8103
>
> Has anyone else noticed this? It's not a problem with JAWS.
> > > archives at http://webaim.org/discussion/archives
> > > > > >

From: glen walker
Date: Tue, May 11 2021 10:29AM
Subject: Re: weirdness with NVDA reading multidecimal numbers
← Previous message | Next message →

> Would it benefit anyone if they removed the heuristic entirely and just
read the numbers and dots?

I think it would be beneficial to have an option to turn off the
heuristic. Some people might want to hear the "raw" data and they'll use
the context around it to determine how to interpret the number.

The info was sent on 1.4.10 (meaning January 4th, 2010, if using US date
format. Does NVDA say "April 1st" if your locale is Europe?).
Did you see the info in 1.4.10 (meaning section 1, subsection 4,
subsubsection 10).
Two scrollbars will fail 1.4.10

I'd like the option to always hear "one dot four dot ten" and then I'll
figure out what that means from the context.

From: James Nurthen
Date: Tue, May 11 2021 1:07PM
Subject: Re: weirdness with NVDA reading multidecimal numbers
← Previous message | Next message →

I think this is often the TTS engines not the screen readers
Try pasting "Did you see the info in 1.4.10 (meaning section 1, subsection
4,
subsubsection 10).
Two scrollbars will fail 1.4.10" into Text-to-Speech (TTS) Engine in 119
Voices | Nuance | Nuance
<https://www.nuance.com/omni-channel-customer-engagement/voice-and-ivr/text-to-speech.html#!>

On Tue, May 11, 2021 at 9:29 AM glen walker < = EMAIL ADDRESS REMOVED = > wrote:

> > Would it benefit anyone if they removed the heuristic entirely and just
> read the numbers and dots?
>
> I think it would be beneficial to have an option to turn off the
> heuristic. Some people might want to hear the "raw" data and they'll use
> the context around it to determine how to interpret the number.
>
> The info was sent on 1.4.10 (meaning January 4th, 2010, if using US date
> format. Does NVDA say "April 1st" if your locale is Europe?).
> Did you see the info in 1.4.10 (meaning section 1, subsection 4,
> subsubsection 10).
> Two scrollbars will fail 1.4.10
>
> I'd like the option to always hear "one dot four dot ten" and then I'll
> figure out what that means from the context.
> > > > >

From: glen walker
Date: Tue, May 11 2021 1:46PM
Subject: Re: weirdness with NVDA reading multidecimal numbers
← Previous message | No next message

Good point, James. I was using the Nuance voice but when I change to
eSpeak NG, it does not try to interpret the number and always announces it
as one dot four dot ten.


On Tue, May 11, 2021 at 1:07 PM James Nurthen < = EMAIL ADDRESS REMOVED = > wrote:

> I think this is often the TTS engines not the screen readers
> Try pasting "Did you see the info in 1.4.10 (meaning section 1, subsection
> 4,
> subsubsection 10).
> Two scrollbars will fail 1.4.10" into Text-to-Speech (TTS) Engine in 119
> Voices | Nuance | Nuance
> <
> https://www.nuance.com/omni-channel-customer-engagement/voice-and-ivr/text-to-speech.html#
> !>
>
>
>