<jamesn> agenda order is 1,2,7,3,4,5,6

<scribe> scribe: melanierichards

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

jamesn: thinking 1.3 since it doesn't fit into what we're currently doing?
... this is about very little support for aria-controls, can we fix that or is it past fixing?
... about 2 disparate bits of the page, which I believe was the intent of aria-controls. Doesn't seem to be supported very well, perhaps partially because authors overuse it. Can we have guidance that makes it better? [paraphrasing a bit]

Scott_O: in JAWS, it's set to ignore by default

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

jamesn: proposing 1.3 for 995 but if someone wants to work on it sooner, it can land when it lands

<Jemma> https://github.com/w3c/aria/issues/993

<BGaraventa> having trouble with phone access, will dial in if possible

jamesn: 993, why would we have accessible name required for cell and grid cell in case where the cell is empty?

<Jemma> https://raw.githack.com/w3c/aria-practices/zcorpan/labelling-describing/aria-practices.html#naming_role_guidance

joanie: can name required, from the implementer's standpoint, if author provided an accessible name, use it, otherwise the implementer is required to do the work of calculating from the contents

jamesn: [unsure]
... validators will take accessible name required, and if not set, they will throw an error

joanie: I'm in favor of 1.2, if the implication is authors will slap a name on an empty cell, that seems bad
... rows would also end up with terrible names

harris: 90% sure you're right that validators would throw an error but let me dig into the code

jamesn: can you add a comment to the issue?

harris: yes

jamesn: no new PRs to look at

TPAC registration reminder

jamesn: reg fees go up next Friday

Jemma: any code from group discount on the hotel?
... so the link to book a room is the discount code?

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

jamesn: it should be just when you click through the link from the TPAC page

<Jemma> https://www3.hilton.com/en/hotels/japan/hilton-fukuoka-sea-hawk-FUKHIHI/index.html

jamesn: I had to do a separate booking because I was staying extra time (with a higher rate)

<jamesn> https://www.hilton.com/en/hi/groups/personalized/F/FUKHIHI-GW3CA-20190913/index.jhtml

jamesn: the link from the TPAC page

Global states and properties discussion

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

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

jamesn: we previously talked about disallowing aria-label and aria-labelledby on certain roles
... I put together 985 for that. Other issues logged. Such as not having aria-disabled as a global property and not allowing it on certain things
... so do we make these global and just disallowed on certain roles? And move other properties from global? So basically 2 different strategies. Or do we want to go back on our decision and make these all not global? Or do we want to make everything global and disallowed?

<jamesn> https://www.w3.org/2019/04/30-aria-minutes.html#item01

joanie: if memory serves, we did the disallowed thing because James C. raised an issue where some new thing (not necessarily an ARIA role) and now it can't have a name? On the one hand, that's a concern. On the other hand, not sure it's ARIA's job to solve it. Could put something in HTML-AAM that's a host language override: hey this could have a name
... then later create a new role for it in ARIA which supports name

Scott: I think that makes sense

Scott_O: making them non-global

+1

<Jemma> I also second not making "global"

Scott_O: ARIA in HTML or HTML-AAM could document what can be used on it or not
... looking through global states and properties, it does seem like there still would be states and props that would be categorized that way

<Jemma> that is the better option for the author too since they thought they can use but it turned out that it is "disallowed"

jamesn: yes, we wouldn't propose getting rid of all the globals

<Jemma> less information processing for authors

jamesn: of course, there are consequences of removing from global. Validation things, maybe changing anything with role="presentation" that had a previously-global attribute and now that's not valid

joanie: maybe we should use presentation role as part of this discussion. If you have aria-label and aria-disabled on it, now it's no longer presentational and it's in the acc tree and it has a state that makes no sense

jamesn: am I hearing we don't want to go prohibited states and props route? (985)

joanie: maybe can check with James Craig about override in HTML-AAM

carmacleod: could always start with prohibited and eventually get to "wellll it's not global anymore"
... you did start down this path and there were quite a lot of roles that suddenly didn't need a label

jamesn: not a comprehensive pass, just exploratory first pass

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

jamesn: if that's our direction, I can stop working on this again.

<BGaraventa> +q

joanie: you create a new abstract role that doesn't allow naming, which paragraph etc would inherit from
... this abstract role would become the superclass of the new generic role

<Jemma> I appreciate that group is trying to improve usability and do the better thing althought it adds extra work.

joanie: if in the end we decide we want to prohibit naming, I think we want to limit the prohibition to names and not extend that to aria-disabled

jamesn: so if we change label from a global prop, I think we SHOULD still call out acc name as prohibited on the role

carmacleod: agreed

+1

<joanie> +1

<Scott_O_> also +1

<Jemma> +1

<harris> +1

jamesn: I'll maintain that part of the PR. I'm going to work on both PRs and sync them up in such a way, not saying that we're going to go one direction or another, but knowing that the group is leaning towards not going with global states and props

BGaraventa: this is inflating what I usually have to do for acc name. I'm going to have to build out a matrix of roles and when these apply and don't. these will make things more complicated

jamesn: good point. previous discussion was going to leave acc name not changing. If the author created an error where they added a label where not expected, implementers would not change anything, it would just be a validation error

joanie: I don't think this changes the plan where validators throw an error and UAs do whatever they want

jesse: is the idea that you don't want the UA to announce a link as disabled? do they want them to do something or just want validator to flag the error?

jamesn: talking more about the name but it's a valid question

joanie: in the ARIA spec, we have author error handling section. Bryan saying we're going to have contradiction where a spec is saying something different. But I'm not sure that's the case

jamesn: what does error handling say when author uses a state/prop not allowed on the role? What does it say now, what should it say, should the implementer change anything?

joanie: realistically, UAs should ignore aria-disabled, say, on a paragraph (can't make it a must). Perf concerns with checking for this, up to ATs to filter it out

BGaraventa: if the acc name spec says that the hierarchy of the structure, and aria-label is supported on a node, but then the aria spec itself says that there are certain roles where that does not apply, then you're saying one thing in one spec and one thing in another
... so some implementers may choose to not return that aria-label, others may choose to return it, and we're never going to achieve interop

joanie: understood, what I thought I heard us say before was "if we do it this one way, it's ok, if we go this other route, it's not ok"
... are you saying that depending on how we prohibit it we do or don't have specs that contradict each other?

<Jemma> aria-disabled is "state"

joanie: could we add a line to the acc name spec that says "if the element doesn't support naming, return the empty string"?

BGaraventa: yeah, I think we could do something like that
... I just need to make sure these are in sync

jamesn: the Acc Name spec is how UAs should calculate based on what's supplied to them. If you could have something prohibited for an AUTHOR, it could still be passed through, and the Acc Name spec could still support doing it

mck: missed the beginning of the convo, are we talking about what to tell UAs to do with prohibited attrs?

jamesn: we were talking about making these non-global instead of prohibiting route from F2F

mck: I think the reason for making naming global but prohibited in certain cases is valid in certain cases, but for things like aria-disabled they just don't make sense to be global. Disabling something non-interactive is....I don't know why that was made global. Changing those is completely independent topic of this PR
... there is a good reason for aria-label, labelledby, describedby potentially global but prohibited in some cases

joanie: can you remind of what James C said?

mck: was saying if you bring in roles like the dpub roles or other extensions of ARIA, and you want them to be name-able things, and the props aren't global, then those properties wouldn't be usable in those modules at all. Maybe it was new elements also

joanie: could we create a new abstract role that prohibited naming etc, and another abstract role that does allow it, and all the dpub roles inherit from that second abstract role, would that solve it?
... new abstract role foo which prohibits naming. Paragraph etc would inherit from foo. DPub roles would inherit from section, which allows naming.

mck: that sounds messy to me

jamesn: why don't I create a PR with this and see how it goes?

<Jemma> at least, what Joanie is suggesting is clear to me.

BGaraventa: [gave an example where prohibiting name on say a div breaks naming for a button]

joanie: could say disallow on the root element only

jamesn: I can see a possibility of working this out, why don't I share a PR, maybe by the EOD. and we can see how that shakes out

mck: as long as aria-label and aria-labelledby remains global
... if you make them not-global, but if they are inherited into presentation and none

jamesn: they're not going to be inherited into presentation and noen

mck: I guess I don't have clear picture, you're right, PR would make it clear

jamesn: let's discuss in PR

<joanie> https://github.com/w3c/aria/pull/994

Table Properties

<joanie> https://raw.githack.com/w3c/aria/issue-667/index.html#aria-colindextext

<Jemma> https://raw.githack.com/w3c/aria/issue-667/index.html#aria-rowindextext

joanie: if you think about a spreadsheet, you've got numeric rows and letters for the columns. Google Sheets already exposes this, they have aria-rowtext and aria-coltext. I've got a proposal with aria-colindextext and aria-rowindextext

<joanie> Defines a human readable text alternative of aria-colindex. See related aria-rowindextext.

<joanie> Authors SHOULD only use aria-colindextext when the provided or calculated value of aria-colindex is not meaningful or does not reflect the displayed index, as is the case with spreadsheets and chess boards.

<joanie> Authors SHOULD NOT use aria-colindextext as a replacement for aria-colindex because some assistive technologies rely upon the numeric column index for the purpose of keeping track of the user's position or providing alternative table navigation.

<harris> I've got to drop off. Cheers everybody!

<joanie> Unlike aria-colindex, aria-colindextext is not a supported property of row because user agents have no way to reliably calculate aria-colindextext for the purpose of exposing its value on the cell or gridcell.

<pkra> have to go. by everone.

jamesn: please review this, comments in the PR. If we don't have substantive comments in the PR next week, we'll presume we can merge it

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/aria-disable/aria-disabled/
Present: Joanmarie_Diggs scott_ohara jamesn melanierichards pkra carmacleod \ Jemma harris Bryan_Garaventa Stefan Matt_King jesse
Regrets: MarkMcCarthy IrfanAli JaninaSajka JonGunderson CurtBellew
Found Scribe: melanierichards
Inferring ScribeNick: melanierichards
Found Date: 13 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.)