[Bug] Problem when reading dates in dd.mm.yyyy format

[arungupta540]

Steps to reproduce:

<div>21.05.2024</div>
<div>06.05.2024</div> 

Actual behavior:

First date is read as: two one point zero five point two zero two four Second date is read as: June fifth twenty twenty four

Expected behavior:

First date should be read as: May 21st twenty twenty four Second date is read as: May 6th twenty twenty four

System configuration

NVDA installed/portable/running from source:

installed

NVDA version:

2024.02 (2024.2.0.32555)

Windows version:

windows 11

Name and version of other software in use when reproducing the issue:

Microsoft Edge for Business Version 126.0.2592.113 (Official build) (64-bit)

Google Chrome Version 126.0.6478.183 (Official Build) (64-bit)

Does the issue still occur after restarting your computer?

yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

no

If NVDA add-ons are disabled, is your problem still occurring?

yes

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

no

[hwf1324]

The issue should be related to the synthesizer, and different synthesizers read it differently. Certainly I don't seem to have found a synthesizer that handles that date format correctly at the moment.

[XLTechie]

Which synth is reading these incorrectly?

21.05.2024

It is hard to see why this is read incorrectly. There is little else it could be than May 21, 2024.

06.05.2024

This, however, is ambiguous. Ten or more countries still use the mm.dd.yyyy date format, although rarely with the period as separator. Since the first division could be either month or day, and the second division could be either day or month, there is no way for the synth to be sure which it is reading.

Best, would probably be for it not to try to interpret this into a date at all, as in your first example.

This will never be settled, until either the world adopts an unambiguous date format that all countries agree to; or until AI gets good enough at context to know which date format is being used, and screen readers include AI in core screen review functions such that it can influence the way things are spoken.

Reference: https://en.wikipedia.org/wiki/List_of_date_formats_by_country

[CyrilleB79]

Very likely a matter of synthesizer used.

For example with OneCore voices:

• American English voices read date in MM.DD.YYYY format
• British English voices read date in DD.MM.YYYY format (same for French, Italian, etc.)

If the numbers do not fall in the expected range, e.g. MM=21, the whole expression seems to be read with individual digits as is, i.e. without any further processing.

Closing as it is not an NVDA issue.

If you still feel it is an NVDA issue, indicate why and the synth being used.

[arungupta540]

@XLTechie @CyrilleB79 @hwf1324 is there a way to handle it in html? We support multiple date formats. We'd like the screen reader to read the date in correct format. Or the other option could be just read the date as it is. Don't interpret month name etc just say the digits.

[CyrilleB79]

Usually screen reader users are used to configure their options and choose their synthesizer according to their needs. If the user uses a synthesizer supporting automatic language switching and if the HTML is correctly tagged with lang attributes, the synth follows the language of the content; thus you may use American date format in US English text and European date format in British English text.

I'll let people that are more expert with HTML and multi-lingual/cultural web development comment further though.