<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?
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
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
<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
<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.)[End of scribe.perl diagnostic output]