How to handle version numbers for screen readers?
Asked Answered
S

2

0

I'm using Windows Narrator and a version number like 2.3.96 is being reader as a date "2nd March, 1996". How do I handle version numbers for screen readers? I see some answers suggested using a label and spell out the dots, like: aria-label="2 dot 3 dot 96". Is there a better way to do this?

Soto answered 9/4, 2020 at 9:40 Comment(1)
Do you want to add your HTML to the question. My guess is it is the way you have formatted that causes this behaviour (i.e. is the version number on its own within a <span>, if it is paired with words in a paragraph it will work as expected. e.g. <p>Version 2.3.96</p> will read correctly, <p>Version <span>2.3.96</span></p> probably will not.Susannahsusanne
S
1

Short Answer

Use <p aria-label="Version 2 point 3 point 96">Version 2.3.96</p>, this will get parsed correctly in most popular screen readers. Make sure there are no <spans> splitting the version number from the text, use an aria-label as overkill / a backup.

Long Answer

Normally I would advise to never interfere with the way a screen reader pronounces things, as @QuentinC has suggested.

However in this circumstance I would say that you do want to try and fix this problem, as hearing a date read where there should be a version number could be very confusing (was it the date the software was written, is it the date the company was formed? Who knows!).

This is a parsing problem in the screen reader, very different from problems most people have where they don't like the way something is read, please only follow the advice below for this one example only.

Fix one, change your markup.

You didn't add your markup but the below explanation is based on my testing.

This problem will actually fix itself (at least in JAWs, NVDA and VoiceOver from my testing) by simply adding 'Version' before the version number.

My guess is you have the version number in a format similar to the following:

<p>Version <span>2.3.96</span></p> or <p>2.3.96</p> without the word 'version'.

By removing the <span> in the first example JAWS, NVDA and VoiceOver read the following correctly in my testing:

<p>Version 2.3.96</p>

Once the <span> is added around the version number the context of the numbers is lost (text within <span> elements is evaluated on it's own) so a screen reader will try and parse it on it's own, without any context, and decide it is a date.

Surely using aria-label will fix it though?

Also aria-label will probably not work on static elements (<div>, <span> etc.) that do not have a role that indicates they are an active element, so odds are it will not work anyway for you.

For that reason I would not recommend trying to fix this problem with aria-label alone, however adding it for the screen readers that do take it into consideration is a step that would not hurt.

This is the only time I have ever recommended interfering with how a screen reader talks, please do not take this as a step to solve other pronunciation problems as this is a parsing problem not a pronunciation problem.

Taking that into account I would recommend you use the following:

<span aria-label="Version 2 point 4 point 99">Version 2.4.99</span>

With either a <span>, <p> or other content block surrounding it.

Susannahsusanne answered 10/4, 2020 at 19:16 Comment(5)
Yes, leave well alone. The w3c pronunciation taskforce (w3.org/WAI/APA/task-forces/pronunciation) is on this, and working out a solution which will offer author-level guidance such as "pronounce as spelled". It's work in progress at time of this comment, but until then, assume that any ameliorations will create new problems for other users.Thickhead
You have not understood the problem, this is not a pronunciation issue, it is a parsing issue. The screen reader is identifying the version number as a date. At this point the confusion caused by a date being read is greater than the confusion introduced for non English speakers hearing English words. To work around that problem you could code in an i18n library to swap 'version' and 'point' out. This will never get fixed by the pronunciation task force, the only way it could be fixed is if they introduce a WAI-ARIA label that says 'this is not a date, do not parse it as such', very unlikely!Susannahsusanne
It is both. How can you be sure it is the screen reader and not the speech synthesiser that is screwing up? The taskforce is tackling exactly this kind of issue by providing guidance for an arbitrary string to be parsed for pronunciation. Also, the fix you suggest would most likely not be harmless for braille-based AT users - they will certainly prefer to have the actual characters.Thickhead
You are indeed correct, braille users will suffer. However when you come to an impossible situation like this (it is why I love accessibility, it has some great debates!), in my eyes you have to go for the majority. Neither of us is right or wrong in this and there will always be a compromise. We ran into a similar issue with the parsing of an important reference ID and the votes from users were to override the pronunciation, the one braille user said it was understandable. With that being said it was a 'closed' system so people could learn the idiosyncrasies so maybe not the best reference.Susannahsusanne
oh if anyone reads these comments I would like to reiterate, do not do this for things like numbers, credit cards, etc. It is only when something is misinterpreted in such a way that leaving it makes it worse (my rule is if the way a screen reader interprets the text could be misleading then you should fix it, so far it has only been strings with the format of a date and an unusual scenario and one where some text was determined to be read as dutch, even with the proper lang attribute. These cases are rare), these scenarios are few and far between.Susannahsusanne
P
2

There are already several similar questions on stackoverflow and elsewhere about numbers and other things that aren't pronounced as the page writer expects. The same answer applies to version numbers interpreted as dates: you'd better do nothing and write it without anything special.

The problem is that the pronunciation of numbers depends on many layers:

  • The browser and its way to expose accessibility tree.
  • The OS, the screen reader and its settings. For example, Jaws offers many options that can change how numbers and dates are interpreted and spoken out.
  • The voice used. The same screen reader, on the same OS, with the same browser, but with different voices can indeed read the same text very differently.

You may try several things, like separating it in a different <span>, adding or removing spaces, writing "dot" via aria-label, etc.

However, by doing so, you are very likely to improve the pronunciation for some users, while degrading it for most others. The combinations of OS, browsers, screen readers, and voices are too huge to be able to test everything.

So the best is to keep pragmatic and don't do anything special. Keep your version number written as it is usually done everywhere. Screen reader users are generally used to such pronunciation quirks and can, if necessary, adjust options and set up dictionaries.

Pindling answered 10/4, 2020 at 18:7 Comment(1)
Just want to add that 'second-guessing' screenreader pronunciation will usually have adverse effects on other ATs such as Braille 'displays'. Yes, there really is a problem with pronunciation of certain character sequences, and it's usually down to the speech synthesiser the screen reader is hooked up to, rather than the screen reader itself. You'll find that different synth voices (even from the same vendor) will announce the same string in different ways, which does not make it easier to predict what the end user will experience. Browser language also plays a role. So... leave it as is.Thickhead
S
1

Short Answer

Use <p aria-label="Version 2 point 3 point 96">Version 2.3.96</p>, this will get parsed correctly in most popular screen readers. Make sure there are no <spans> splitting the version number from the text, use an aria-label as overkill / a backup.

Long Answer

Normally I would advise to never interfere with the way a screen reader pronounces things, as @QuentinC has suggested.

However in this circumstance I would say that you do want to try and fix this problem, as hearing a date read where there should be a version number could be very confusing (was it the date the software was written, is it the date the company was formed? Who knows!).

This is a parsing problem in the screen reader, very different from problems most people have where they don't like the way something is read, please only follow the advice below for this one example only.

Fix one, change your markup.

You didn't add your markup but the below explanation is based on my testing.

This problem will actually fix itself (at least in JAWs, NVDA and VoiceOver from my testing) by simply adding 'Version' before the version number.

My guess is you have the version number in a format similar to the following:

<p>Version <span>2.3.96</span></p> or <p>2.3.96</p> without the word 'version'.

By removing the <span> in the first example JAWS, NVDA and VoiceOver read the following correctly in my testing:

<p>Version 2.3.96</p>

Once the <span> is added around the version number the context of the numbers is lost (text within <span> elements is evaluated on it's own) so a screen reader will try and parse it on it's own, without any context, and decide it is a date.

Surely using aria-label will fix it though?

Also aria-label will probably not work on static elements (<div>, <span> etc.) that do not have a role that indicates they are an active element, so odds are it will not work anyway for you.

For that reason I would not recommend trying to fix this problem with aria-label alone, however adding it for the screen readers that do take it into consideration is a step that would not hurt.

This is the only time I have ever recommended interfering with how a screen reader talks, please do not take this as a step to solve other pronunciation problems as this is a parsing problem not a pronunciation problem.

Taking that into account I would recommend you use the following:

<span aria-label="Version 2 point 4 point 99">Version 2.4.99</span>

With either a <span>, <p> or other content block surrounding it.

Susannahsusanne answered 10/4, 2020 at 19:16 Comment(5)
Yes, leave well alone. The w3c pronunciation taskforce (w3.org/WAI/APA/task-forces/pronunciation) is on this, and working out a solution which will offer author-level guidance such as "pronounce as spelled". It's work in progress at time of this comment, but until then, assume that any ameliorations will create new problems for other users.Thickhead
You have not understood the problem, this is not a pronunciation issue, it is a parsing issue. The screen reader is identifying the version number as a date. At this point the confusion caused by a date being read is greater than the confusion introduced for non English speakers hearing English words. To work around that problem you could code in an i18n library to swap 'version' and 'point' out. This will never get fixed by the pronunciation task force, the only way it could be fixed is if they introduce a WAI-ARIA label that says 'this is not a date, do not parse it as such', very unlikely!Susannahsusanne
It is both. How can you be sure it is the screen reader and not the speech synthesiser that is screwing up? The taskforce is tackling exactly this kind of issue by providing guidance for an arbitrary string to be parsed for pronunciation. Also, the fix you suggest would most likely not be harmless for braille-based AT users - they will certainly prefer to have the actual characters.Thickhead
You are indeed correct, braille users will suffer. However when you come to an impossible situation like this (it is why I love accessibility, it has some great debates!), in my eyes you have to go for the majority. Neither of us is right or wrong in this and there will always be a compromise. We ran into a similar issue with the parsing of an important reference ID and the votes from users were to override the pronunciation, the one braille user said it was understandable. With that being said it was a 'closed' system so people could learn the idiosyncrasies so maybe not the best reference.Susannahsusanne
oh if anyone reads these comments I would like to reiterate, do not do this for things like numbers, credit cards, etc. It is only when something is misinterpreted in such a way that leaving it makes it worse (my rule is if the way a screen reader interprets the text could be misleading then you should fix it, so far it has only been strings with the format of a date and an unusual scenario and one where some text was determined to be read as dutch, even with the proper lang attribute. These cases are rare), these scenarios are few and far between.Susannahsusanne

© 2022 - 2024 — McMap. All rights reserved.