Comments (5)
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.
from gcweb.
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:
- Modern standards:
- Mandating the ISO format:
- Recommending full dates:
- Older standards:
- Mandating the ISO format:
- Ambiguous stance:
from gcweb.
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'sdatetime
content attribute, if it has one, otherwise the child text content of thetime
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.
from gcweb.
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.
from gcweb.
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.
from gcweb.
Related Issues (20)
- Page details file refers to a file that don't exist HOT 1
- Crown copyright statement changes
- GCWeb top menu - Initial adjustment - Conformity with WCAG 2.1/2.2 Level AA
- Request - [`DataTable`]: [`Server side processing`]
- GCWeb: Splash page - Canada.ca assets down HOT 3
- Bug - Fieldflow table filter not firing when the filter sequence includes the first column
- [BUG] a11y: header section - Menu label is verbose - Short description of the bug HOT 1
- Liquid Warning: Liquid syntax error: [:comparison, ">"] is not a valid expression
- Bogue - Le contrast de couleur ne fonctionne pas
- Requête - When is the Mega Menu going to go away? and How? / Comment supprimer le Mega Menu sans causer une cascade d'exceptions javascript ?
- Bug - ʻOkina character does not display properly
- Featured link stabilization
- Featured link background stabilization
- [BUG] Canada.ca Menu - aria-label exceeds 250 characters HOT 1
- Bug - missing background on web alerts
- Fieldflow
- Broken example link on GCWeb index page
- Checkboxes are not user friendly for Dragon Naturally Speaking users HOT 1
- Bogue - Message contextuel tronqué sur le bouton de fermeture (wb-overlay)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gcweb.