search

wet-boew / GCWeb

Canada.ca theme - A reference implementation of the Canada.ca Content and Information Architecture Specification, the Canada.ca Content Style Guide and the Canada.ca Design System
https://wet-boew.github.io/GCWeb/
Other
94 stars 130 forks source link

add `timedate` to the Date modified #2081

Open shawnthompson opened 1 year ago

shawnthompson commented 1 year ago

Add the timedate attribute to the <time> element in the date modified. 

<dl id="wb-dtmd">
    <dt>Date modified:</dt>
    <dd><time timedate="2023-01-10" property="dateModified">2023-01-10</time></dd>
</dl>

This will improve the interoperability of the content by applying a more specific info & relationship.

EricDunsworth commented 1 year ago

I'd be against this since it's redundant and doesn't enhance semantics. It also doesn't tie into WCAG conformance.

Here's an excerpt on this topic from the WHATWG HTML spec's definition of the time element:

The datetime value of a time element is the value of the element's datetime content attribute, if it has one, otherwise the child text content of the time element.

Since the text content of date modified's time element is already written in a machine-readable format (<time>2023-01-10</time>), there's already enough information in place to programmatically-determine a date "as-is".

PS: The main idea behind the datetime attribute is to provide a machine-readable representation of the date/time when the time element's content isn't already written like that.

For example, if date modified had been written along the lines of <time>January 10, 2023</time>, it'd of failed HTML validation and there'd of been a valid use case for adding datetime="2023-01-10". But that's not the situation we're dealing with here.

shawnthompson commented 1 year ago

Thank you very much @EricDunsworth, always great details in your replies.

I agree with you on that, if the text in the time element ISO format is the same as the datetime there is no need to be repeating it.

If they decide to change the displayed date format then we would have to make sure the datetime is added.

Does repeating it cause any problems?

Could this be future proofing our code if the date format ever changed?

I'm ok to close this issue if there's a consensus that it's not needed.

Thanks again @EricDunsworth, you're awesome.

EricDunsworth commented 1 year ago

Thanks for the compliments @shawnthompson 😃! Btw I've added my follow-ups below.

Full disclosure: This is just my opinion and shouldn't be taken as an authoritative answer.

If they decide to change the displayed date format then we would have to make sure the datetime is added.

Yeah. If date modified's writing format were to change into a non-machine readable format in the future, HTML validation would start failing on it unless a datetime attribute got added.

Does repeating it cause any problems?

Having a redundant datetime attribute shouldn't cause any issues, but it'd represent extra code that serves no purpose at this time. So it'd represent a maintenance burden and be kinda bloat-y.

Could this be future proofing our code if the date format ever changed?

Yes. But IMO it's highly unlikely that date modified's format will change in the future.

The pre-existing ISO date format looks to have been in place for over 23+ years (going by this 1999 snapshot of a random Canada.ca page). There might also be some GC web standards out there that mandate it (I didn't check).

IMO an argument could be made that something like "January 10, 2023" is more readable than "2023-01-10" and therefore may benefit accessibility/usability. But on the other hand, the ISO date format is better-suited to i18n. Plus I'm not aware of anyone having ever complained about the ISO format before.

I'm ok to close this issue if there's a consensus that it's not needed.

I think it'd ultimately be up to @duboisp to decide.

FWIW I'm just a contributor and therefore can't officially make these kinds of calls.

shawnthompson commented 1 year ago

The more I work in the cognitive space and plain language I see the need to make our content even more accessible.

Having a date in the ISO standard on our page can create a barrier for someone out there although having it in text would help everyone and having the datetime attribute would help anything that needs it programatically.

I doubt they would ever change it though, because it doesn't fail conformance to WCAG.

In the W3C's Making Content Usable for People with Cognitive and Learning Disabilities, it states the following.

Dates that can be read and understood in any culture.

Consider how you write dates, because once again the text-to-speech will use the format associated with the language of the voice. A date such as 04/03/2019 will be read as “April 3rd 2019” by a US English voice and “4th of March 2019” by a British English voice. Writing out the month in words can avoid confusion.

Once again we focus on making content accessible to users of Assistive Technology (AT) but not those who need help understanding our content and don't use any AT devices due to many different reasons.

There is work being done in WCAG 3 that is trying to include as much of Making Content Usable as possible in the guidelines but that's many years away from becoming a standard in the GC.

EricDunsworth commented 1 year ago

@shawnthompson

The more I work in the cognitive space and plain language I see the need to make our content even more accessible.

I personally agree with this sentiment and usually go beyond WCAG 2.x when doing assessments or providing feedback.

Having a date in the ISO standard on our page can create a barrier for someone out there although having it in text would help everyone and having the datetime attribute would help anything that needs it programatically.

I'm neutral about the ISO date format vs full dates in writing, but can totally see your point of view.

Putting the month in writing is less ambiguous than a 2 digit number (particularly when the latter is adjacent to another 2 digit number).

Although unlike some other confusing date formats (e.g. DD-MM-YYYY vs MM-DD-YYYY), the ISO format (YYYY-MM-DD) is always written in a unique order that's well-understood internationally. And that's where I think your biggest challenge would be. Changing the date into plain text may help certain users with cognitive impairments, but at the same time it'd become more difficult for international audiences to understand EN/FR month names vs the ISO format's numbers. Might not be too big of a deal in the context of the web though given how many browsers have built-in translators.

There are also other formats out there that could arguably be more user-friendly than dates. For example, many sites these days use "X minutes/hours/days/etc ago" and can optionally show the exact date (usually via title attributes... 🤢). The default format those sites use might revert to full dates as a page becomes older.

As far as the datetime attribute goes - I'm totally for it as long as it serves a meaningful purpose and isn't just adding redundant bloat.

I doubt they would ever change it though, because it doesn't fail conformance to WCAG.

It might be an uphill battle to change it at this time. But if you still want to give it a shot, I'd recommend starting off by reaching out to @delisma and/or DTO.

You could probably get the ball rolling with a good argument (which you've already made) and links to sources/studies/usability testing/etc that support your stance.

Btw here's what I was able to dig up about date formats in GC standards: