Make Dates more readable

[StephDriver]

Dates are all over our pages - articles, news items, citations, data... etc.

Dates are not consistently interpreted by screen readers, there are variations between how a US and UK citizen might interpret them (day and month ordering) and they cause readability issues - unlike a character within a word, a digit within a number can't often be determined from context.

When dates are written as numbers separated by punctuation, e.g. 10-11-2024 or 2024-11-10 this is immediately visibly identifiable as a date, even if there might be US/UK confusion over whether it was the 10th of November or the 11th of October. When read aloud, his recognition that it is a date doesn't happen until one is part was through the number as the above examples are read as numbers e.g. "ten eleven two-thousand and twenty-four". Even with all punctuation being read "ten hyphen eleven hyphen two-thousand and twenty-four" the date is part read before any recognition is possible.

In short, dates rely upon typographical symbols to provide important context, making them effectively non-text content WCAG 1.1

Consider:
Either dates are written in full as suggested by the UK Gov approach (below) or there needs to be some markup at least for screenreaders. My preferred solution is to write them in full, because that makes them unambiguous across the board.

Additional info

• Accessibility Oz on date formatting
• UK Gov style for writing dates
• WCAG 1.1 techniques

[StephDriver]

from #4194

• Sample 2, item 67. consider using dates in a format where the month is written out, because that reduces ambiguity between US and UK orderings (and sounds nicer when read aloud!) see examples from UK Government stylesguide
• Sample 5.1, item 13. article publication date is not described - so the date is read out without any context.
• Sample 5.2, item 12. article date is not described as a date, so gets read out as as series of numbers, as the date icon is not described, these numbers have no context.
• Sample 5.3, item 7. date appended to news article not marked up as a date, so read as a series of numbers.
• Sample 5.3, item 21. date is not marked up as being a date
• Sample Other, item 24. dates written as "YYYY-MM-DD" are not very readable.

[joemull]

Thanks for singling this out--I just had a support ticket about it from a sighted user who found 2024-05-31 less readable than 31 May 2024 so I think this is due for some standardization across all templates.

In terms of possible solutions, we should likely use the {{ example|date }} template filter provided by Django, which uses the localization information to output a readable date in the user's language / locale.

[mauromsl]

Would it make sense to use a different label for text-to-speech?

I think it would be somewhat detrimental to lose the benefits that come from a standard such as ISO 8601, some of the benefits we'd lose would be

• Standardization regardless of locale (important when folks share data across regions)
• Ease of comparison between ranges.
• Easier data manipulation in inputs.
• Uniform and predictable string lengths.

Perhaps we can make the case of maintaining ISO 8601 for tabular data, whilst using an aria-label for screen readers?

[StephDriver]

Would it make sense to use a different label for text-to-speech?

The accessibility concern is about more than screen reader use - but if we do end up sticking to the current format, then we would need to label it up for screen readers at least.

Not all dates used on articles are in tabular form. Could we keep tabular data in ISO 8601 but have more human readable dates for those that appear in the wild, e.g.

[joemull]

For tabular data it may be worth considering the time HTML element and its datetime property which is intended to provide a machine-readable format that is behind a user-friendly display value.

[StephDriver]

This issue is about what the human sees on the front end where there is a date in isolation (not in a data table) - not about date storage or machine readable meta data.

[joemull]

Discussed in a11y meeting: we will make a templatefilter that populates the time element and then use this everywhere that's appropriate in public-facing pages.

Back-office templates are not in scope for this issue, so dates in tables and metadata outputs need to be discussed separately.

[StephDriver]

When working on this I came across an localisation issue.

There is a built in date filter that will by default produce the human readable date, and will localise it so that US and UK end up with the different order within the date as expected. Currently this is being overridden in the templates to produce YMD format. So the key change here is to go from {{ some_date_field |date:"Y-m-d" }} to {{ some_date_field |date}} across all the Front of House templates.

But when testing this approach, I found that instead of the expected 5 June 2024 I got June 5, 2024 - further investigation showed my browser was set up for UK English, but that the django template was working with English (en). It was localising correctly for the locale it was working in, but that locale was not the same as my browser. I further tested this by setting my browser to default to Spanish, but again, the django tempate considered the language as English.

I think the localisation needs to be fixed before changes are made to the dates.

[StephDriver]

When working on Icons in order to make the calendar icon that accompanies a date decorative rather than semantic, I have been updating those dates to the <time> tag. This should work even better when we add in a time template filter - for now it just includes the semantic information in the HTML rather than the icon.