<jamesn> agendabot, find agenda

<agendabot> jamesn, OK. This may take a minute...

<agendabot> clear agenda

<jamesn> zakim drop item 3

<scribe> scribe: Irfan

<jamesn> https://github.com/search?l=&q=is%3Aopen+is%3Aissue+repo%3Aw3c%2Faria+created%3A%3E%3D2020-10-08+repo%3Aw3c%2Faria+repo%3Aw3c%2Faccname+repo%3Aw3c%2Fcore-aam&type=Issues

jamesn: this sounds like 1.3 or later.

https://github.com/w3c/aria/issues/1341

do we mark it as 1.4 milestone?

https://github.com/w3c/aria/issues/1336

jamesn: do you think we can do it it 1.3?

joanie: if AT wants to have a fully accessible meter element, we might need to do it in 1.3.
... I can take this.

<harris> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meter

https://github.com/w3c/aria/pull/1340

matt: this is drop PR.

Why does marquee require an accessible name?<https://github.com/w3c/aria/issues/1339>

<jamesn> https://publicwww.com/websites/%22role%3D%5C%22marquee%5C%22%22/

<Irfan_> http://html5marquee.com/

<Irfan_> jamesn: we have conclusion about marquee that we dont need accessible name.

<Irfan_> jamesn: does anyone wants to take this on?

<Irfan_> jamesn: there is no PR as of now

<msumner> https://html.spec.whatwg.org/multipage/obsolete.html#non-conforming-features

<Irfan_> melanie: marquee is obsolete element.

<Irfan_> i check for element and any role that might be implicit or explicit.

<harris> axe-core raises an issue for use of the marquee html tag as well

<Irfan_> mk: if this is obsolete then we should revisit.

<Zakim> jcraig, you wanted to ask if the recommendation for validity is a MUST or SHOULD?

<carmacleod_> Issue to consider deprecating marquee: https://github.com/w3c/aria/issues/1104

<Irfan_> jamesn: we can have another issue log in

<Irfan_> jcraig: people are still using the concept of marquees, therefore I dont think it should be deprecated.

<Irfan_> jamesn: we still need accessible name

<Irfan_> matt: if we also submit the PR for accessible name.

Add a conditional on when aria-controls is needed<https://github.com/w3c/aria/pull/1335>

Authors do not need to set aria-selected in single-selection containers…<https://github.com/w3c/aria/pull/1327>

1.3 triage<https://github.com/w3c/aria/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22ARIA+1.3%22+no%3Aproject+sort%3Acreated-asc>

<Irfan_> jamesn: https://github.com/w3c/aria/issues/898

<Irfan_> it provides the date time in machine readable format

<Irfan_> matt: how is it related to ARIA

<Irfan_> ?

<Irfan_> matt: it doesnt make any sense since it is not accessibility semantic.

<sarah_higley> this is a note on the time role: At the present time, there are no WAI-ARIA properties corresponding to the datetime attribute supported on <time> in [HTML]. The addition of this property will be considered for ARIA version 1.3.

<Irfan_> jamesn: we dont believe that it does anything with accessibility semantic.

<Jemma> html role is "timer", not time, right?

<Irfan_> jamesn: We dont believe that we need to do it.

<Jemma> https://www.w3.org/TR/html52/textlevel-semantics.html#element-attrdef-time-datetime

<Irfan_> may be we should just wait and change the note to future version of aria.

<Irfan_> sarah: agree with everything. looked into the mapping

<Irfan_> will post the link here

<Matt_King> Time is currently listed in APG structural roles section: https://w3c.github.io/aria-practices/#structural_roles

<sarah_higley> link to HTML AAM mappings for the datetime attribute on the time role: https://w3c.github.io/html-aam/#att-datetime-time

<Irfan_> jamesn: we also have deletion and insertion role here.

<Irfan_> question is, does any AT do anything with this?

<Irfan_> talking about date time attr

<Irfan_> Matt_King: I am not aware if there are any AT for windows doing anything like this

<Irfan_> jamesn: we should ping Aaron about it. I'd like to leave it for 1.3. it might be useful for annotations.

<Irfan_> jamesn: I will myself on it right now but will work with Aaron. it was useful discussion.

<harris> https://github.com/w3c/aria/issues/899

<Irfan_> https://github.com/w3c/aria/issues/899

<Irfan_> jcraig: would love to get it done in 1.3.

<Irfan_> Matt_King: part of the discussion that we had before, we would not provide authoring guidelines in some cases. would it effect accname calculation? should that be a part of accName? how far do you want to go with this?

<Irfan_> jcraig: Joanie does not agree with original proposal.

<Irfan_> it seems like we need some specific verbiage

<Irfan_> Matt_King: we have testing tool which calculate the name in one browser but not in another.

<Irfan_> jcraig: I'd rather have it to be something that happens consistently.

<Irfan_> if there is a heading that we should use first heading. its not perfect but reasonable approach.

<Irfan_> carmacleod_: question about section element. there are so many landmark might appear.

<Irfan_> there are browsers to handle landmark navigation. only way in HTML to give section an accessible is to use title name.

<Irfan_> jcraig: keep the language short in specs. content label would be more important than content.

<jcraig> https://github.com/w3c/aria/pull/1018

<Irfan_> jamesn: additional complexity is user agent accessible name calculation. we dont want to add additional complexity.

<Irfan_> jcraig: If that is the consensus, I am okay to push it out of 1.3

<Irfan_> joanie: if we do author correction, then we still might use some inter-operability.

<Irfan_> jamesn: if we specify something new for author correction, it allows browser to do the same thing.

<Irfan_> Matt_King: I'd rather not be correcting the author error thing.

<Irfan_> may be we can write authoring guide that can support it. I am concerned correcting author error kind of approach.

<Irfan_> jcraig: this is effectively lot of work of a11y engineers. acc name is good example. I'd say that we are 80% there with regards to acc name. extra 20% is still not compatible.

<Irfan_> I am not oppose to it. it is potentially achievable–with a significant amount of work– but I am little hesitant.

<Irfan_> Matt_King: if this was kind of change that we were not going to implement then I'd rather not see this kind of correction takes place in browsers. its is better for individual AT to do their own guessing. then it doesn't effect things like dev tools

This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/one/on/
Succeeded: s/james: /jamesn: /g
Succeeded: s/it might be useful./it might be useful for annotations./
Succeeded: s/with that I am okay to push it in 1.3/If that is the consensus, I am okay to push it out of 1.3/
Succeeded: s/achievable/potentially achievable–with a significant amount of work–/
Present: Irfan Jemma StefanSchnabel Joanmarie_Diggs harris MarkMccarthy msumner carmacleod_ sarah_higley
Regrets: CurtBellew PeterKrautzberger ScottOHara SinaBahram
Found Scribe: Irfan
Inferring ScribeNick: Irfan
Agenda: https://lists.w3.org/Archives/Public/public-aria/2020Oct/0025.html

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)