Each timestamp is read out twice on iOS voiceover

[ChrisBAshton]

Describe the bug
Using voiceover on IOS navigate to the timestamp hear it read out twice.

Could be related to https://github.com/bbc/simorgh/pull/1373/files#diff-0e47b297888cf8b4c4eaef5dace2cfd4R38 (and would therefore be fixed by #1446).

To Reproduce
Steps to reproduce the behavior:

1. On an iOS device, turn on VoiceOver
2. Visit https://www.bbc.com/news/articles/cxvxrj9yvppo (this article id is no longer in use; try https://www.bbc.co.uk/news/articles/c5ll353v7y9o or other articles)
3. Navigate to the timestamp
4. Observe that the timestamp is read out twice

Expected behavior
The timestamp should only be read out once.

Screenshots
N/A

Desktop (please complete the following information):
N/A

Smartphone (please complete the following information):
Any iOS device

Additional context
N/A

• Initially labelled with "bug"

[ghost]

@ChrisBAshton Could you update the link given above. Am getting a 404.

[andrew-nowak]

Unfortunately Chris no longer works with us.
If still present, I would expect this behaviour to be true of any article; you could try https://www.bbc.co.uk/news/articles/c5ll353v7y9o for example

[ghost]

@aacn500 Thats the behaviour

[andrew-nowak]

It seems that voiceover (both iOS and macos) reads out the content of the time tag and then reads out the datetime attribute without caring that the content and the datetime attribute are the same or not.

eg. <time datetime="2019-02-11">11 February 2019</time> is read out as 'the 11th of february 2019, the 11th of february 2019'
eg. <time datetime="2000-01-01">11 February 2019</time> is read out as 'the 11th of february 2019, the 1st of january 2000'

I will do some research but I'm not sure what possible solutions there are

[andrew-nowak]

Wrapping the <time> in a <span role="text"> stops the datetime attribute being read out by voiceover... would need to do more testing to see if that breaks any other AT

[tochwill]

I don't think we should try and modify the behaviour here, as this is the expected behaviour of VoiceOver interacting with a semantic time element.

In a time element, VoiceOver reads:

1. Visible text content as written.
2. The ‘datetime’ attribute value, in system language (have tested in English and French).
   • So relative timestamps say ‘2 minutes ago’ (for example), followed by the full date in the timestamp.
   • If system language is not the same as the page language, VoiceOver will read the visual date (or relative date) as written in the page's language, followed by the timestamp date in the OS language.

I think trying to hack anything in to stop this default behaviour increases the risk of more serious accessibility regressions.

[tochwill]

I've emailed [email protected] to see if not announcing duplicate content here is something they are considering.

[tochwill]

I'll also take a look at using role="text" - I avoided it as it was non standard on the aria spec, but I spoke to Catharine and it's in use to avoid text splitting currently. (This works when in a span around the time element, but not when added to the element itself (as mentioned above on 23 July 😄 ))

[mykeels]

It looks like role="text" fails an a11y lint rule, because text is not a valid ARIA role.

Is this something we're willing to overlook, or is there a valid ARIA role we can replace text with?

[greenc05]

@mykeels we are using role text when appropriate for now, though no decision has been made with regards to this issue. I've filed an Issue with axe to get an exception added for this to Lighthouse dequelabs/axe-core#1597

[greenc05]

@tochwill did you get a reply from Apple?

[tochwill]

@greenc05 I got an automated response saying it may be passed on to an appropriate team, but nothing since - I think if we're using role="text" in numerous places already, I'm not against using it here?

[greenc05]

I've re-tested this today...

iOS 13.3 - Tested on Canonical and AMP front pages - Pidgin, Scotland article

• When it’s a minutes/hours ago timestamp, it reads (not tested on article):
  7 minutes ago, the 15th of January 2020 - That’s fine
• When it’s a date timestamp, it reads:
  The 14th of January 2020, the 14th of January 2020 - Not so great due to the duplication

Mac OS - 10.14: Mojave - Pidgin front page and Scotland optimo article

• 1 hour ago, reads (not tested on article):
  1 hour ago, the 15th January 2020 - That’s fine
• Date time stamp reads:
  The 14th of January 2020, the 14th of January 2020 - Not so great due to the duplication

This is more of an issue for front pages as there is a timestamp for every promo on the page, though it’s only really an issue for older content e.g. timestamps with a date rather than minutes ago.

Closing this ticket, as it’s not worth the hack. Can re-look into this in the future if it becomes an issue for users.