need role for time element

[jnurthen]

per plans for role parity need a role for equivalent to <time> in HTML

[melanierichards]

On the 7 Feb, 2019 call I mentioned I'd add examples of HTML expectations for the time element so we can work out the open questions on the PR. They are:

a) Author provides a machine-readable datetime content attribute on the <time> element, and is then free to provide human-readable (for example) child phrasing contents of the element:

<time datetime="2011-02-07">
  <span>Today's conference call</span>
</time>

b) Author does not use the datetime content attribute, and the <time> element must not have element descendants, as the text contents themselves are meant to be used for the human-readable format:

<time>2011-02-07</time>

[melanierichards]

Questions we discussed for PR #895:

• Added an author should to match the content expectations of HTML. Should this really be a SHOULD, since that'll generate implications for compliance checkers, or should we change to a gentler suggestion? I don't believe we got formal resolution on this but we can review the next call this comes up.
• Didn't mark this as "children presentational" but perhaps it should be, given HTML expectations: "A time element that does not have a datetime content attribute must not have any element descendants." Now I don't think we need to do this, given that we are adding the aria-datetime attribute and in my opinion it would be potentially unnecessarily complex to have different presentational rules with or without the attribute.
• For the role parity exercise, do we need something like aria-datetime? We determined that we do; Need an aria-datetime attribute for parity with HTML datetime attr #898

[melanierichards]

@jnurthen is there a preferred way to notify the group/chairs that PR changes are in and ready to review at an upcoming call? (This is also me notifying that #895 has been updated!)

Changes made, for call reference:

• Added note about potential future aria-datetime property
• Added valid date- and time- strings inline and removed normative reference to the HTML spec for this purpose; I added one example per category. The HTML spec is much more exhaustive, open to adding all of them if requested, but hopefully this a good set to get the point across
• Documented the HTML expectations for <time> element authoring, in a comment earlier in this issue thread. This is for reference as to whether children should be presentational or not.
• Also removed name from contents

[pkra]

@melanierichards I think adding the label "agenda" to the issue is enough.

[jnurthen]

Adding Agenda can work but an email is also good.... We review everything with Agenda on it during out planning meeting on Tuesdays so if it has Agenda before then it will be considered. Apologies for not putting this on earlier though.

[melanierichards]

@jnurthen you didn't miss it, it just took me forever to cycle back and make the changes 😅 Email to chairs or to the group?

[jnurthen]

@melanierichards up to you... We will see it either way. Also when the agenda goes out if something isn't on it which you think should be please let me know.

[css-meeting-bot]

The ARIA Working Group just discussed placeholder.

The full IRC log of that discussion

<jamesn> topic: placeholder
<jamesn> https://github.com/w3c/accname/issues/17
<irfan_ali> stefan: not clear which calculation is taking to consideration. we should be more clear here
<irfan_ali> jn: dont understand
<irfan_ali> stefan:aria-placeholder- what are your intentions to do here?
<bgaraventa1979> +q
<Stefan> q-
<irfan_ali> stefan: best practice on web. if you put an accessible description as a fallback, its a good idea?
<jamesn> ack bg
<irfan_ali> bg: as a fall back, if we are doing with title, if nothing before that would appear then adding a placeholder a good idea. otherwise placeholder technically would be in added in description
<irfan_ali> bg: title is hire up in the tree
<irfan_ali> jn:our plan was would be we would be make an accessible name and description calculation as placeholder
<irfan_ali> jn: is that correct?
<irfan_ali> jn: if people have no objection doing that, then we shoud agree that we are going to do that. we will take the issue again after pull request. is that okay part of action.
<irfan_ali> jg: i have reservation making placeholder as accessible description
<irfan_ali> jn: place-holder is already in accessible name
<melanierichards> q+
<irfan_ali> jg: I will file a bug
<irfan_ali> mr: there are some case where placeholder is an idea of providing an accessible name
<MarkMcCarthy> ack mel
<jamesn> q+
<irfan_ali> mk: for authors who wish to create a good experience, these techniques dont protect.
<irfan_ali> jg: i am worried about validators
<irfan_ali> jg: thats the way lot of developers work.
<jamesn> q?
<irfan_ali> mk: what we have done in acs names back, that certain steps in algorithm are fall back steps.
<jamesn> ack me
<jamesn> q+
<irfan_ali> mk: its not just an ac name issue but HTML aam issue. these are fall back vs intentional label
<irfan_ali> mk: code is parsable and readable and valid but its not necessary good code.
<irfan_ali> jn: we are not going to change validation.
<irfan_ali> jn: sounds like aria practicing issue
<irfan_ali> mk: this will absolutely covered in APG. it should not effect the html validator
<irfan_ali> jn: lets not worry about that
<mck> +1 for accname to align with html-aam
<Stefan> +1
<joanie> +1 to aligned
<irfan_ali> jn: do we have agreement, acc name calculation is similar to native code? do we want to do it.
<MarkMcCarthy> +1 to align
<irfan_ali> mk: its better to specs to align
<irfan_ali> mk: valid code is not always godo code
<irfan_ali> jn: BG, can you get that into acc name? issue is open.
<irfan_ali> mk: if you have a valid name and not description that idea is placeholder goes into the description
<irfan_ali> stefan: example would help
<irfan_ali> jn: we want parity and not diversion.
<MarkMcCarthy> s/godo/good
<irfan_ali> jn: I dont think we can come up with any conclusion on this.
<irfan_ali> zakim, next item
<Zakim> I see a speaker queue remaining and respectfully decline to close this agendum, irfan_ali
<jamesn> q?
<MarkMcCarthy> ack james
<irfan_ali> zakim, next item
<Zakim> agendum 6. "need role for time element" taken up [from jamesn]
<jamesn> https://github.com//issues/878
<melanierichards> https://github.com//pull/895
<jamesn> GitHub: https://github.com//issues/878
<irfan_ali> mr: we reviewed the need role for time element.
<irfan_ali> mr: there is an added not about some potential aria day time property
<melanierichards> https://github.com//issues/878
<irfan_ali> mr: Added an author should to match the content expectations of HTML. Should this really be a SHOULD, since that'll generate implications for compliance checkers, or should we change to a gentler suggestion? I don't believe we got formal resolution on this but we can review the next call this comes up.
<irfan_ali> mr: also removed name from content.
<irfan_ali> jn: any comment on pull request? are we ready to merge?
<irfan_ali> mk: having hard time with editor drafts. all the headings are gone.
<irfan_ali> mk: in the definition, shouldn't it be an element that represents specific point of time. we dont always refer to the super class.
<irfan_ali> mk: adding a super class something like phrase. I'd rather call it an element
<irfan_ali> jn: we have definition of an element.
<irfan_ali> jn: please take a look into the draft and make your comments
<irfan_ali> rrsagent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2019/03/07-aria-minutes.html irfan_ali