Telephone Numbers and Screen Readers

How to handle version numbers for screen readers?

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.

How to avoid NVDA announcing link in the middle of a phone number?

I just tried your simple example with NVDA in both firefox and chrome and I didn't hear the second "link". Your code sample might be pared down from your original code which has the problem. Perhaps post a bigger sample from your original code.

As a side note, I understand the aria-label with the spaces between the numbers to force the screen reader to announce the phone as separate digits but that causes a problem for braille users. They will read a bunch of spaces in the phone number and it will be more difficult to read. It's best to let the screen reader decide how to pronounce a phone number and then the user can adjust their settings to have it read in the style they want it.

When I try this with NVDA in both chrome and firefox, it reads the phone number like you'd expect.

<a aria-label="Call 1-800-555-1212 for further questions" href="Tel:18005551212">1-800-555-1212</a>

In fact, it reads it better than your example because there are slight pauses between "eight hundred" and "five five five" and "one two one two" because of the dashes. In your example, I hear the string of digits as one long string with no brief pauses.

How to avoid input type =num being spoken like currency amount in millions in web accessibility

I found out that this is related to operating system .Like in ios and android behavior screen reading is supposed to do so. I checked facebook and instagram as a reference.

Voice over doesn't read phone number properly

Let's break down what is happening. VoiceOver doesn't know that the text you are presenting is a phone number and treats it like a sentence of text. In that text it tries to find distinct components and read them appropriately. For example, the text "buy 60 cantaloupes" has 3 components, "buy", "60", and "cantaloupes". The first is text and is read as text, the second is purely numerical and is best read out as "sixty", and the third is read as text.

Applying the same logic to your phone number.

(I'm not talking about actual implementation, just reasoning.)

If you read 1-1xx-2xx-9565 from the left to the right then the first distinct component is "1" which in it self is numerical and is read as "1". If the phone number would have started with "12-1xx" then the first component would have been read as "twelve" because its purely numerical.

The next component is "1xx" or "-1xx" depending on how you look at it. In either case it is a combination of numbers and letters, e.g. it is not purely numerical and is thus read out as text. If you include the "-" in that component is interpreted as a hyphen which isn't read out. That is why the the "-" is never read out for that component. The next component ("-2xx") is treated in the same way.

The final component is "-9565" which turns out to be a valid number. As seen in the cantaloupe sentence, VoiceOver reads this as a number in which case the "-" is no longer interpreted as a hyphen but as a "minus sign".

Getting VoiceOver to read your own text

On any label, view or other element in your application that is used with Voice Over, you can supply your own "accessibility label" when you know more about how you want the text to be read. This is done by simply assigning your own string to the accessibilityLabel property.

Now, you can create a suitable string in many different ways, a very simple one in your case would be to just add spaces everywhere so that each number is read individually. However, it seems a bit fragile to me, so I went ahead and used a number formatter to translate the individual numbers to their textual representations.

NSString *phoneNumber = @"1-1xx-2xx-9565";

// we want to know if a character is a number or not
NSCharacterSet *numberCharacters = [NSCharacterSet characterSetWithCharactersInString:@"0123456789"];

// we use this formatter to spell out individual numbers
NSNumberFormatter *spellOutSingleNumber = [NSNumberFormatter new];
spellOutSingleNumber.numberStyle = NSNumberFormatterSpellOutStyle;

NSMutableArray *spelledOutComonents = [NSMutableArray array];
// loop over the phone number add add the accessible variants to the array
[phoneNumber enumerateSubstringsInRange:NSMakeRange(0, phoneNumber.length)
options:NSStringEnumerationByComposedCharacterSequences
usingBlock:^(NSString *substring, NSRange substringRange, NSRange enclosingRange, BOOL *stop) {
// check if it's a number
if ([substring rangeOfCharacterFromSet:numberCharacters].location != NSNotFound) {
// is a number
NSNumber *number = @([substring integerValue]);
[spelledOutComonents addObject:[spellOutSingleNumber stringFromNumber:number]];
} else {
// is not a number
[spelledOutComonents addObject:substring];
}
}];
// finally separate the components with spaces (so that the string doesn't become "ninefivesixfive".
NSString *yourAccessiblePhoneNumber = [spelledOutComonents componentsJoinedByString:@" "];

The result when I ran this was

one - one x x - two x x - nine five six five

If you need to do other modifications to your phone numbers to get them to read appropriately then you can do that. I suspect that you will use this is more than one place in your app so creating a custom NSFormatter might be a good idea.



Edit

On iOS 7 you can also use the UIAccessibilitySpeechAttributePunctuation attribute on an attributes string to change how it is pronounced.

Speech Attributes for Attributed Strings

Attributes that you can apply to text in an attributed string to modify how that text is pronounced.

UIAccessibilitySpeechAttributePunctuation

The value of this key is an NSNumber object that you should interpret as a Boolean value. When the value is YES, all punctuation in the text is spoken. You might use this for code or other text where the punctuation is relevant.

Available in iOS 7.0 and later.

Declared in UIAccessibilityConstants.h.



Related Topics



Leave a reply



Submit