<jamesn> scribe: CurtBellew

New Issue triage

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

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

jn: how should we triage this? It's not really what we scoped for 1.3

joanie: flag it as maybe a milestone called furture?

future = furture

jn: does everyone agree it's not a 1.2 or 1.3?

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

general agreement

jn: this one is on disallowing aria-disabled

mck: this definitely shouldn't be universal
... it's a bug. 1.3

jn: 1.3
... spec is unclear on grammar usage. i've put 1.3 on it. anyone disagree?

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

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

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

jn: already marked as 1.3
... done there so we can move on the the new PR triage. and there are none

PR Triage

TPAC

jn: reminder. tpac registration is open

<jamesn> https://www.w3.org/2019/09/TPAC/registration.html

jn: prices go up very soon. register before the 21st of June or you will pay more
... you have two weeks
... any comments on tpac?

tpac = TPAC

Quick status check of blocking role-parity issues:

<joanie> https://github.com/w3c/core-aam/issues/46

jn: joanie, what are our blocking role parity issues

joanie: waiting on answers to my questions from James Craig

jn: meter is on my plate and i will get too it

<joanie> https://github.com/w3c/html-aam/issues/141

<joanie> Scott_O: ^^

mck: question on label. is it ok if we do label later in authoring practices? i want to get release 4 out and then do label later
... what are our goals wrt that?
... is it ok if it's not in the next working draft:

joanie: yes. some of it are going to be tricky to implement

jn: so that one we don't to plan to get in to but the others I plan to create a PR

joanie: as a general rule, because this is role-parity we are taking the mappings that in HTML AAM

Scott_O: waiting to verify UIA then I can get the branch in

Quick status update - Tree Inclusion focus/activedescendant requirements need clarification…

<jamesn> https://github.com/w3c/aria/pull/950

jn: this one has been hanging around for a while and there are a bunch of things that need to happen based on comments
... wondering what we are going to do to progress it. Caroline is not here so it might not be worth discussing
... joanie, shall we just punt this to next week?

joanie: yes

[wip] Do not allow label on certain roles

<jamesn> https://github.com/w3c/aria/pull/985

jn: i made some modifications to my PR for this
... creates a new staets and properties section that appears on certain roles
... it removes the states and properties section
... defines a new accessible names calculation section it defines a new type
... added new text to global text and properties

<jamesn> <section id="prohibitedattributes">

<jamesn> <h3>Prohibited States and Properties</h3>

<jamesn> <p>List of properties that are prohibited on a <a>role</a>. Authors MUST NOT specify a prohibited state or property.</p>

<jamesn> <p class="note">A host language attribute with the appropriate <a href="#implicit_semantics">implicit WAI-ARIA semantic</a> would also prohibit a state or property in this section. </p>

<jamesn> </section>

jn: biggest question is do we want implicit wai aria semantics to prohibit states and properties as if they had a role on them
... or leave it to the base language

mck: if it's permitted by the aria spec to prohibit it then it seems inconsistent not to
... if we prohibit it in list item and yet you can do it on an li that doesn't make sense.

jn: if we did do this then i would be looking for the same thing in their spec
... even if we do this we want them to clarify the same context

mck: If it's legal for us to do this then definitely

jn: we do have similar notes elsewhere
... we do say that you don't have to have a role on an element to use states and properties

mck: this really has more to do with what the user agents have to with aria-label

jn: this doesn't impact what the user agents do with it

<jamesn> <p>If the author specfies a WAI-ARIA property on a role where that property is prohibited, the user agent SHOULD treat the property as if it were allowed. </p>

jn: I added in the "correcting author errors" section:

mck: if you don't have this text in there. If we're silent. We would keep things as they are today.

jn: user agents may read this differently

mck: seems like we might be building contradictions in. It's not allowed but user agents should treat it as if it is

jn: We do this elsewhere. "if they doing something that isn't allowed, what should user agents do?"

mck: I'm worried that they may assume that we don't care if they do or not

melanie: These would be considered a browser bug if they're marked as a SHOULD

jn: i was trying to follow a convention on many of the others with this text
... we have a similar one in the paragraph after

thanks!

<jamesn> file:///Users/nurthen/aria/index.html#document-handling_author-errors_states-properties

<jamesn> https://pr-preview.s3.amazonaws.com/w3c/aria/pull/985.html#document-handling_author-errors_states-properties

jn: I'm ok changing it to a "may" but there are other "should"s in there
... which is it most similar to?

mck: sounds like there might be a site somewhere that did this when it wasn't strictly prohibited.

jn: BG has some examples of sites that have this issue but he still wants them to work
... the fact that there is no should in the spec in here shouldn't be an issue because accname will do what it does
... joanie, any comments on this as an implementer

joanie: authors shouldn't do this and we have to do work to calculate it
... "may" makes me happier

jn: if this was changed to a "may" would this be ok @bg

bg: I'd rather it was firmer.

bg = BG

bg: we have clients right now who are using techniques like this
... mobile web as well
... techniques like this currently work
... they will go through standards process, get an error, they will remove it and it will no longer be accessible

mck: @bg examples where they couldn't make it accessible if they couldn't label a generic? where there is no viable alternative?

bg: Part of a concept management system. like a shopping cart icon. it has all these dynamically update children
... they had to create the name something similar to what we're describing here
... if we change this then that particular component will break

mck: what element were they naming?

bg: I believe it was a <span?

<span? = <span>

mck: naming a span only works in certain limited conditions and only in some browsers right?

bg: it works on all the mainstreams ones that i checked

mck: didn't it have to be the child of an element that gets its child from content?

bg: yes

bg; I'm fine either way at this point

bg: we just need to be definite one way or another
... validaters and accname should say the same thing

Scott_O: did anyone look at my sample?

<Scott_O> https://scottaohara.github.io/testing/span/

mck: there are still those clients who could use another approach to make that span work
... off screen text would be on approach
... aria-label on a link doesn't work on IOS Voice Over. shocked to find that
... obviously a bug

bg: i've noticed differences in 11 and 12
... voice over

mck: if we went for the hard "no" approach it would drive more work wouldn't it?
... accname isn't necessarily tied to aria right, jn?

jn: no

mck: is it ok if aria 1.2 has that in it but accname hasn't caught?
... accname hasn't caught up at that time?

jn: the aim of getting this in now is to unblock the generic role
... prohibit authors but leave the rest of the code alone. even code that may be broken in some cases

mck: i'm ok with the fuzzyness for 1.2
... then raise an issue on accname for generic naming for a future version
... when accname resolves that issue then we change it in aria 1.3
... might be simpler if we dont' make the statement at all.

jn: I'm ok with that. I can make that change to remove it
... please review this in depth before next meeting.
... this change is something i want to get in before next working draft so it gets wide review

joanie: i would suggest we add an editorial note. tell user agents that they should or may change their behavior but that might change later
... for authors and for wide review
... I could try to draft it but it's not for user agents in my view
... i'll do it

jn: once we've got this done we can push generic
... text separation we can push off to get it more well rounded later

mck: does this effect "supported properties" section?

jn: yes

mck: same in the aria-label and aria-labelledby properties?

jn: this isn't from the script. manually generated
... I need to reread those definitions for aria-label and aria-labelledby
... there is a prohibited states and properties in aria-label and aria-labelledby
... I'll make those changes quickly.

joanie: I'll add my text as a comment

jn: please add review comments if you have any. let's get this in before next meeting.

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
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/if they're prohibited/if they're marked as a SHOULD/
Default Present: jamesn, Joanmarie_Diggs, Scott_O, harris, CurtBellew, Bryan_Garaventa, Matt_King
Present: jamesn Joanmarie_Diggs Scott_O harris CurtBellew Bryan_Garaventa Matt_King
Regrets: PeterKrautzberger CarolynMacLeod MarkMcCarthy
Found Scribe: CurtBellew
Inferring ScribeNick: CurtBellew
Found Date: 06 Jun 2019
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.)