16:53:13 <RRSAgent> RRSAgent has joined #aria
16:53:17 <RRSAgent> logging to https://www.w3.org/2023/10/26-aria-irc
16:53:17 <Zakim> RRSAgent, make logs Public
16:53:18 <Zakim> please title this meeting ("meeting: ..."), jamesn
16:53:19 <jamesn> agendabot, find agenda
16:53:19 <agendabot> jamesn, OK. This may take a minute...
16:53:20 <agendabot> agenda: https://www.w3.org/events/meetings/ecffaf8b-8aa7-4acc-b238-6088a86cf12f/20231026T130000/
16:53:20 <agendabot> clear agenda
16:53:20 <agendabot> agenda+ -> New Issue Triage https://tinyurl.com/wanbd6t5
16:53:20 <agendabot> agenda+ -> New PR Triage https://tinyurl.com/2p92nm86
16:53:22 <agendabot> agenda+ -> WPT Open PRs https://github.com/search?q=repo%3Aweb-platform-tests%2Fwpt+is%3Aopen+label%3Awai-aria%2Caccname&type=pullrequests
16:53:26 <agendabot> agenda+ -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates
16:53:28 <agendabot> agenda+ -> Requesting changes to new implementation-blocked merging process https://github.com/w3c/aria/issues/2055
16:53:31 <agendabot> agenda+ -> Update from PR #1018 for nameFrom: heading https://github.com/w3c/aria/pull/1860
16:53:34 <agendabot> agenda+ -> associationlist and related roles have tediously long names https://github.com/w3c/aria/issues/1662
16:53:37 <agendabot> agenda+ -> describe grouping (and naming of the group) for exclusive accordions <details name> https://github.com/w3c/html-aam/issues/509
16:53:41 <agendabot> agenda+ -> "Radio" role exemption from required context https://github.com/w3c/aria/issues/2058
16:53:43 <agendabot> agenda+ -> Title should not contribute to accName for generic elements https://github.com/w3c/html-aam/issues/506
16:53:47 <agendabot> agenda+ -> ARIAMixin has many integer attributes with string types and uses DOMString? incorrectly https://github.com/w3c/aria/issues/1110
16:53:50 <agendabot> agenda+ -> Hierarchy of treeitems per aria level only? https://github.com/w3c/aria/issues/2065
16:53:53 <agendabot> agenda+ -> Ambiguous cascade of role invalidation rules (including dependency label computation) complicates implementations https://github.com/w3c/aria/issues/2064
16:53:56 <agendabot> agenda+ -> Ambiguous but normative requirement about hidden nodes is hidden by default in AccName https://github.com/w3c/accname/issues/211
16:53:59 <agendabot> agenda+ -> Ambiguity in AccName LabelledBy section: "[if] current node is not already 'part of' [sic]…traversal" https://github.com/w3c/accname/issues/209
16:54:19 <jamesn> agenda?
16:58:42 <Francis_Storr> Francis_Storr has joined #aria
16:59:04 <spectranaut_> spectranaut_ has joined #aria
16:59:05 <StefanS> StefanS has joined #aria
16:59:49 <Adam_Page> Adam_Page has joined #aria
17:00:17 <spectranaut_> agenda?
17:00:29 <scotto> scotto has joined #aria
17:01:11 <spectranaut_> present+
17:01:33 <Francis_Storr> present+
17:01:34 <StefanS> present+
17:02:02 <pkra> pkra has joined #aria
17:02:09 <pkra> present+ pkra
17:02:11 <pkra> scribe: pkra
17:02:24 <pkra> Zakim: next item
17:02:28 <pkra> Zakim, next item
17:02:28 <Zakim> agendum 1 -- -> New Issue Triage https://tinyurl.com/wanbd6t5 -- taken up [from agendabot]
17:02:28 <Adam_Page> present+
17:02:48 <pkra> jnurthen: core-aam#206
17:02:55 <pkra> ... scotto already said "no"
17:02:58 <pkra> ... seems ok?
17:03:02 <pkra> ... anyone disagree?
17:03:21 <Rahim> present+
17:03:22 <pkra> ... please add to the issue otherwise
17:03:48 <pkra> jcraig: let's close. we can always re-open.
17:04:12 <pkra> jnurthen: aria#2068
17:04:16 <pkra> pkra: has PR
17:04:28 <pkra> jnurthen: aria#2067
17:04:32 <pkra> scotto: agenda+
17:04:36 <pkra> zakim, next item
17:04:36 <Zakim> agendum 2 -- -> New PR Triage https://tinyurl.com/2p92nm86 -- taken up [from agendabot]
17:04:40 <pkra> jnurthen: PRs
17:05:02 <pkra> ... aria#2069
17:05:02 <pkra> ... scotto has reviewed.
17:05:16 <pkra> ... let's merge it.
17:05:30 <pkra> ... next aria#2066 link to focusable.
17:05:37 <pkra> ... needs changes in terms
17:05:50 <pkra> ... I'll reach out
17:05:55 <pkra> zakim, next item
17:05:55 <Zakim> agendum 3 -- -> WPT Open PRs https://github.com/search?q=repo%3Aweb-platform-tests%2Fwpt+is%3Aopen+label%3Awai-aria%2Caccname&type=pullrequests -- taken up [from agendabot]
17:06:06 <pkra> jnurthen: WPT PRs
17:06:18 <pkra> ... any action necessary?
17:06:18 <pkra> jcraig: I don't think so
17:06:33 <pkra> ... review for mine would be nice.
17:06:46 <pkra> ... would close priority 1 PRs for this year.
17:07:02 <pkra> ... Rahim will take over Melanie's PR
17:07:16 <pkra> ... to incorporate feedback.,
17:07:22 <pkra> ... I'll then review
17:07:51 <pkra> scotto: I cc'ed you (jcraig?) to check if I did mine right.
17:08:02 <pkra> jcraig: CI should be the check. I also sometimes have local failures.
17:08:09 <pkra> zakim, next item
17:08:09 <Zakim> agendum 4 -- -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates -- taken up [from agendabot]
17:08:35 <pkra> jnurthen: let's not add anything this week. we have lots to do today.
17:08:46 <pkra> ... might need more meetings.
17:08:46 <pkra> zakim, close item
17:08:46 <Zakim> I don't understand 'close item', pkra
17:08:56 <pkra> zakim, close this item
17:08:56 <Zakim> agendum 4 closed
17:08:57 <Zakim> I see 11 items remaining on the agenda; the next one is
17:08:57 <Zakim> 5. -> Requesting changes to new implementation-blocked merging process https://github.com/w3c/aria/issues/2055 [from agendabot]
17:08:59 <pkra> zakim, next item
17:08:59 <Zakim> agendum 5 -- -> Requesting changes to new implementation-blocked merging process https://github.com/w3c/aria/issues/2055 -- taken up [from agendabot]
17:09:16 <pkra> jnurthen: merging process.
17:09:36 <giacomo-petri> giacomo-petri has joined #aria
17:09:44 <pkra> spectranaut_: we started this discussion at TPAC 2023
17:09:48 <pkra> ... deciding how things should land.
17:09:51 <giacomo-petri> present+
17:10:04 <pkra> ... jcraig had raised questions about process
17:10:18 <pkra> ... others felt uncomfortable with "implementation from PR"
17:10:24 <Matt_King> Matt_King has joined #aria
17:10:29 <pkra> ... it's what other specifications are doing.
17:10:32 <Matt_King> present+
17:10:33 <pkra> ... especially evergreen ones.
17:10:55 <pkra> ... so we have proposals for two processes
17:11:11 <Matt_King> q?
17:11:12 <pkra> ... 1) to land PRs before implementations and mark that
17:11:19 <Matt_King> q+
17:11:20 <pkra> ... 2) implement first, then land.
17:11:35 <pkra> ... the issue has a lot of details on the two proposals.
17:11:57 <pkra> ... e.g., consensus WG, open implementation issues, file issues in other specs
17:12:10 <jamesn> qv?
17:12:10 <pkra> ... still: either warning in spec or not land until specifications.
17:12:25 <pkra> ... in the first case, we'd still need follow-up PRs to remove warnings.
17:12:38 <pkra> ... it's unfortunately complicated. not sure how to resolve it.
17:12:48 <jamesn> q+ jcraig
17:13:10 <jamesn> ack Matt_King
17:13:14 <benb> benb has joined #aria
17:13:14 <pkra> ... one reason to wait with landing is that if or once we get to evergreen, we want the evergreen version to  reflect what's implemented
17:13:18 <scotto> present+
17:13:25 <benb> present+
17:13:33 <pkra> Matt_King: I hope we can make it work so we don't have to put warnings in the spec.
17:13:47 <pkra> ... I'm very concerned about the clarity about what's new.
17:14:00 <pkra> ... sometimes we make 1 change that's many small changes across the document
17:14:22 <jamesn> q+
17:14:23 <pkra> ... if we make 2 of these, with their own sets of warnings, I don't even know how to read the spec and track the issues.
17:14:33 <pkra> ... I suspect it becomes unreadable
17:14:52 <pkra> ... I prefer the PR approach because whether 1 or 50 places in a change, they are easy to find
17:14:56 <jamesn> ack jcraig
17:15:30 <pkra> jcraig: I disagree because for example it's often multiple PRs across specs.
17:15:52 <spectranaut_> q+
17:15:56 <pkra> ... so it was impossible to get an overview over what's changed and what needs changes
17:16:30 <pkra> ... Also, to be able to test what's possible, I don't see the warnings more like links to "can I use", linking to WPT tests, seeing what works and what doesn't.
17:17:00 <jamesn> q?
17:17:02 <pkra> ... maybe there could be an icon to indicate level for support. The change would really be editorial.
17:17:22 <pkra> ... to Matt's point I realize there are changes across spec but it's not typical for new features anymore I think.
17:17:37 <pkra> .... say a new role
17:18:00 <pkra> jnurthen: I'm not sure. A new role will influence other roles, e.g., around nesting
17:18:26 <pkra> jcraig: let's take the one example that triggered this - name from heading
17:18:40 <pkra> ... group decided this needed new structure.
17:18:53 <pkra> ... then downstream changes across AAMs
17:18:57 <pkra> ... accname
17:19:21 <pkra> ... and those changes are even more difficult to pull out if we decide not to do it.
17:20:21 <jamesn> ack me
17:20:25 <pkra> Matt_King: I see a high risk that changes will cause additional changes across the spec.
17:20:38 <pkra> ... the person reading the ED of the spec, can't know if the mention is a valid mention.
17:21:16 <pkra> ... disallowing such mentions, making a branch off that
17:21:29 <pkra> jnurthen: right but here that wouldn't really work
17:22:04 <pkra> Matt_King: so all of them need a warning because anyone reading the ED might not know.
17:22:18 <pkra> jnurthen: the only way to make this work would be a respec feature to do this manually.
17:22:40 <pkra> Matt_King: what's the difficulty around cross-references across specs
17:22:57 <pkra> ... we can write a PR that makes an assumption but the PR in ARIA would have to be merged at the same time.
17:23:04 <pkra> ... is that hard?
17:23:14 <jamesn> ack spectranaut_
17:23:34 <pkra> spectranaut_: I'd suggest to link up
17:23:51 <pkra> ... a feature in that way is a set of PRs that need to be implemented
17:24:03 <pkra> Matt_King: but the link would be broken
17:24:04 <pkra> q+
17:24:13 <pkra> ... I see the problem now.
17:24:20 <pkra> jnurthen: in different repositories.
17:24:50 <pkra> jcraig: we're trying to describe the complexity but perhaps we should just read the proposals again
17:25:02 <pkra> jnurthen: I'd prefer to have a separate discussion
17:25:19 <pkra> jcraig: is Aaron here? He should be there.
17:25:49 <pkra> pkra: next week is DST shenanigans week
17:26:27 <pkra> jnurthen: sounds like we can try it as deep dive next week
17:26:37 <pkra> q-
17:27:48 <pkra> zakim, next item
17:27:48 <Zakim> agendum 6 -- -> Update from PR #1018 for nameFrom: heading https://github.com/w3c/aria/pull/1860 -- taken up [from agendabot]
17:27:56 <pkra> zakim, close this item
17:27:56 <Zakim> agendum 6 closed
17:27:57 <Zakim> I see 9 items remaining on the agenda; the next one is
17:27:57 <Zakim> 7. -> associationlist and related roles have tediously long names https://github.com/w3c/aria/issues/1662 [from agendabot]
17:27:58 <pkra> zakim, next item
17:27:58 <Zakim> agendum 7 -- -> associationlist and related roles have tediously long names https://github.com/w3c/aria/issues/1662 -- taken up [from agendabot]
17:28:23 <pkra> jnurthen: I proposed 3 options on the issue.
17:28:30 <pkra> ... a) remove from 1.3
17:28:38 <pkra> ... so no parity with DL for now
17:28:45 <pkra> ... b) keep them as is
17:28:53 <pkra> ... c) change the name to make them less long
17:29:16 <scotto> q+
17:29:26 <pkra> Matt_King: can somebody state the pros and cons of not doing this in 1.3?
17:29:52 <pkra> jnurthen: as far as I'm aware, we are no longer seeking full parity.
17:30:23 <pkra> ... for elements without a role, we map them to a default for testing purposes
17:30:36 <pkra> jcraig: there's a proposal for that part.
17:30:51 <pkra> ... for association list, if we have a term, then the mappings can still work.
17:30:54 <pkra> ... dl is still a list.
17:31:00 <pkra> ... listitem is still a listitem
17:31:09 <pkra> ... and one new role for the DT
17:31:23 <pkra> ... that way, we still get the main results.
17:31:36 <pkra> ... role parity doesn't mean 1 to 1 but 1 to many
17:31:46 <pkra> Matt_King: so for AT it doesn't matter what kind of list that is?
17:31:59 <pkra> jcraig: if it does, it can still do this
17:32:07 <pkra> jnurthen: from the children.
17:32:20 <jamesn> q?
17:32:38 <pkra> Matt_King: so DL maps to list, DD to listitem, and DT to a new one.
17:32:45 <pkra> ... what is the pro or con?
17:33:05 <pkra> ... as opposed to 'dd-html' ,'dt-html' etc
17:33:57 <pkra> ... I don't know why it would be used in HTML
17:33:58 <jamesn> ack scotto
17:34:05 <pkra> ... maybe SVG?
17:34:21 <pkra> scotto: I like jcraig's suggestion. But some mappings would be good to get unification across AT
17:34:28 <pkra> ... just the fact that we can group them in HTML
17:34:42 <jamesn> q+ to ask should we work on that first before doing that?
17:34:43 <pkra> ... multiple DT per DD and vice versa
17:34:54 <pkra> ... but I agree that we can re-use list and listitem for DL and DD
17:35:00 <pkra> ... and do something for DT
17:35:10 <pkra> ... but let's do something
17:35:33 <pkra> Matt_King: if we can have multiple DTs for a single DD. Is there a parent child problem?
17:35:46 <pkra> jnurthen: let's maybe not get in the weeds right now.
17:35:52 <pkra> ... let's have a proposal.
17:35:56 <jamesn> ack me
17:35:56 <Zakim> jamesn, you wanted to ask should we work on that first before doing that?
17:36:11 <jamesn> q+ jcraig
17:36:12 <pkra> jnurthen: should we work to get the HTML mappings right?
17:36:24 <pkra> scotto: right now pointing to definition and term which is wrong.
17:36:28 <pkra> ... chicken & egg problem.
17:36:36 <jamesn> ack jcraig
17:36:45 <Matt_King> q?
17:36:49 <Matt_King> q+
17:37:01 <pkra> jcraig: my argument was on the implementor side. we don't need the additional complexity
17:37:20 <pkra> ... but also from the constituents side.
17:37:41 <pkra> ... 3 new roles affects users even more
17:38:07 <pkra> ... so I'd favor: pull it entirely or 1 for DT
17:38:23 <pkra> jnurthen: both of these would mean removing what's there right now.
17:38:40 <pkra> jnurthen: I really want 1.3 FWPD
17:38:51 <pkra> ... I don't want associationlist in there if we don't want to ship it
17:39:03 <pkra> jcraig: let's pull it and revisit then.
17:39:09 <pkra> Matt_King: let's have a proposal
17:39:14 <pkra> ... for the new thing
17:39:21 <pkra> +1
17:39:32 <pkra> jnurthen: anyone disagree?
17:39:42 <Matt_King> ack me
17:39:44 <jamesn> ack Matt_King
17:39:53 <pkra> ... I'll make a note
17:39:53 <pkra> zakim, next item.
17:39:53 <Zakim> agendum 8 -- -> describe grouping (and naming of the group) for exclusive accordions <details name> https://github.com/w3c/html-aam/issues/509 -- taken up [from agendabot]
17:39:54 <Rahim> q+
17:40:54 <pkra> rahim: is role parity a goal?
17:41:03 <pkra> jnurthen: was a task. for example for custom elements.
17:41:16 <pkra> ... but less so now -- too many questionable roles were added
17:41:21 <pkra> jcraig: also for testability
17:42:16 <pkra> jnurthen: scotto can you sum up the accordion issue?
17:42:30 <pkra> scotto: let's skip.
17:42:37 <pkra> zakim, next item
17:42:37 <Zakim> I see a speaker queue remaining and respectfully decline to close this agendum, pkra
17:42:51 <jamesn> ack Rahim
17:42:56 <pkra> zakim, next item
17:42:56 <Zakim> agendum 9 -- -> "Radio" role exemption from required context https://github.com/w3c/aria/issues/2058 -- taken up [from agendabot]
17:43:22 <pkra> rahim: came from working on contextual roles WPT test
17:43:36 <pkra> ... in the spec, radio role doesn't have required context.
17:43:42 <pkra> ... or accessibility parent role.
17:43:58 <pkra> ... I understand the rationale why this role doesn't necessarily have it
17:44:12 <pkra> ... on the native side we have grouping via name so I don't feel very strongly about this.
17:44:41 <pkra> Matt_King: in ARIA, is it currently that we don't require radio to be in a radio group?
17:44:54 <scotto> q+
17:45:01 <pkra> ... we don't have html name for this after all.
17:45:09 <jcraig> q+
17:45:22 <pkra> ... but in ARIA if we don't require it, there's no way to determine label, posinset etc.
17:45:27 <pkra> ... is that an oversight?
17:45:34 <pkra> jnurthen: we have SHOULD but not MUST statement
17:45:57 <pkra> ... if not DOM children, SHOULD be aria-owns
17:46:04 <pkra> Matt_King: I feel like we should change it.
17:46:15 <pkra> ... I see that for HTML mappings this might be a problem.
17:46:17 <Rahim> q+
17:46:20 <jamesn> qv?
17:46:26 <scotto> https://github.com/w3c/aria/issues/1721
17:46:33 <pkra> scotto: here's a related issue
17:46:48 <pkra> ... where we have no way to do things without a group container.
17:47:01 <pkra> ... yes, in html you don't have to group them explicitly. name does the trick
17:47:08 <jamesn> q+
17:47:16 <jcraig> q+ to state the aria-custom requirement could cause a validator warning in HTML native elements, and the primary benefit of the name attr is to provide the mutually exclusive functionality, which is handled by JS in ARIA controls
17:47:35 <pkra> ... depending on the use case, if there's no overall label that's bad but can be ok if the individual labels are clear you can get away with it.
17:47:59 <pkra> ... at least on the conformance checker side they come down on the "we can't require this" side.
17:48:16 <jamesn> qv?
17:48:21 <pkra> ... yes, from an ARIA point of view, it's missing. from an HTML one it isn't.
17:48:22 <jamesn> ack scotto
17:48:25 <jamesn> ack jcraig
17:48:25 <Zakim> jcraig, you wanted to state the aria-custom requirement could cause a validator warning in HTML native elements, and the primary benefit of the name attr is to provide the mutually
17:48:28 <Zakim> ... exclusive functionality, which is handled by JS in ARIA controls
17:48:52 <pkra> jcraig: if we require it, it might throw a warning on an HTML native element.
17:49:02 <pkra> ... that seems like a first.
17:49:42 <jamesn> q+ to ask how aria radiobuttons would know about their grouping (posinset etc.) if they aren't part of a group
17:50:15 <jamesn> q+ to reply that radio buttons in disparate parts of the page cause keyboard complications
17:50:25 <pkra> ... also, the name attribute isn't really required for grouping but for exclusivity. I'm not sure it's required.
17:50:38 <pkra> ... of course JS can handle the exclusivity in an ARIA situation.
17:50:44 <jamesn> qv?
17:50:54 <Matt_King> q?
17:50:54 <jamesn> ack me
17:50:55 <Zakim> jamesn, you wanted to ask how aria radiobuttons would know about their grouping (posinset etc.) if they aren't part of a group and to reply that radio buttons in disparate parts of
17:50:55 <Zakim> ... the page cause keyboard complications
17:50:59 <Matt_King> q+
17:51:29 <pkra> jamesn: how would a screenreader know? Would a developer have to provide that information?
17:52:15 <pkra> ... and: html in disparate parts. while supported, I don't think it's a good idea. E.g., arrowing around them can get very messy.
17:52:25 <jamesn> qv?
17:52:32 <pkra> ... so there's usage which is allowed but evidently not a good idea
17:52:38 <jamesn> q+ Cory
17:52:45 <jamesn> q- Rahim
17:52:50 <jamesn> ack Matt_King
17:53:32 <pkra> Matt_King: for posinset etc I was thinking about the ARIA case. That would be change if we did.
17:54:07 <pkra> ... for HTML parity, it seems we'd need an alternative to name attribute
17:54:29 <pkra> ... I think we already have cases where we differ from HTML, are more stringent than HTML.
17:55:32 <pkra> ... I do find it confusing if there are 3 payment options all over the page without grouping it is extremely hard to follow on a screenreader.
17:55:38 <jamesn> ack Cory
17:55:43 <pkra> ... it would be good to have a way to suggest this is not a good idea
17:56:19 <pkra> Cory: grouping was there because we needed to  force a better pattern into the design
17:56:25 <pkra> ... for me comes down to being a sufficent technique
17:56:48 <pkra> ... I think it follows good form design to require a heading
17:56:54 <jamesn> qv?
17:58:03 <pkra> jcraig: I think either we leave it as we should - gets some validator warnings. Maybe we could push it to a must but I suspect they're functional enough as is
17:58:16 <pkra> ... I suspect most AT users will figure out it's a group.
17:58:26 <pkra> jnurthen: what about "apple 1 of 1"
17:58:42 <pkra> Matt_King: I run into that all the time with things don't group reasonably
17:58:53 <Rahim> q+
17:58:57 <pkra> ... browsers not getting it right. 1, 3, 5 and 6 through 10.
17:59:21 <pkra> jnurthen: a developer should know the number of the set. If we don't require group, we should require that.
17:59:37 <pkra> scotto: I'll agenda my other issue
17:59:52 <pkra> Rahim: 1 of 1 - nothing wrong with that in HTML. that's why I was wondering about this.
18:00:47 <jamesn> zakim, end meeting
18:00:47 <Zakim> As of this point the attendees have been spectranaut_, Francis_Storr, StefanS, pkra, Adam_Page, Rahim, giacomo-petri, Matt_King, scotto, benb
18:00:50 <Zakim> RRSAgent, please draft minutes
18:00:51 <RRSAgent> I have made the request to generate https://www.w3.org/2023/10/26-aria-minutes.html Zakim
18:00:58 <Zakim> I am happy to have been of service, jamesn; please remember to excuse RRSAgent.  Goodbye
18:00:58 <Zakim> Zakim has left #aria
18:17:43 <\join_subline> \join_subline has joined #aria