18:03:43 <RRSAgent> RRSAgent has joined #aria
18:03:47 <RRSAgent> logging to https://www.w3.org/2023/12/07-aria-irc
18:03:47 <Zakim> RRSAgent, make logs Public
18:04:18 <Zakim> Meeting: ARIA WG
18:04:18 <spectranaut_> meeting: ARIA WG
18:04:18 <spectranaut_> chair: ValerieYoung
18:04:18 <Adam_Page> Adam_Page has joined #aria
18:04:18 <spectranaut_> agendabot, find agenda
18:04:18 <agendabot> spectranaut_, OK. This may take a minute...
18:04:18 <agendabot> agenda: https://www.w3.org/events/meetings/ecffaf8b-8aa7-4acc-b238-6088a86cf12f/20231207T130000/
18:04:18 <agendabot> clear agenda
18:04:18 <agendabot> agenda+ -> New Issue Triage https://bit.ly/47UTwJm
18:04:18 <agendabot> agenda+ -> New PR Triage https://bit.ly/3RsFsRD
18:04:18 <agendabot> agenda+ -> WPT Open PRs https://github.com/search?q=repo%3Aweb-platform-tests%2Fwpt+is%3Aopen+label%3Awai-aria%2Caccname&type=pullrequests
18:04:18 <agendabot> agenda+ -> describe grouping (and naming of the group) for exclusive accordions <details name> https://github.com/w3c/html-aam/issues/509
18:04:18 <agendabot> agenda+ -> Consider a mechanism to associate controls without an explicit grouping https://github.com/w3c/aria/issues/1721
18:04:18 <agendabot> agenda+ -> handling multi-selection / selection confirmation of action for menus https://github.com/w3c/aria/issues/2067
18:04:18 <agendabot> agenda+ -> aria-controls spec update https://github.com/w3c/aria/pull/1996
18:05:46 <giacomo-petri_> giacomo-petri_ has joined #aria
18:05:48 <pkra> scribe: pkra
18:05:50 <Adam_Page> present+
18:05:52 <pkra> zakim, next item
18:05:53 <Zakim> agendum 1 -- -> New Issue Triage https://bit.ly/47UTwJm -- taken up [from agendabot]
18:05:55 <giacomo-petri_> present+
18:06:26 <scotto> present+
18:06:30 <pkra> spectranaut_: aria 2086 nested headings
18:06:43 <Marcelo_Paiva> Marcelo_Paiva has joined #aria
18:07:03 <jamesn> jamesn has joined #aria
18:07:08 <Rahim> present+
18:07:14 <Marcelo_Paiva> present+
18:07:23 <pkra> jamesc: from a live website. they have different levels, one native, one aria heading. We just didn't know what to do.
18:07:29 <keithamus> present+
18:07:36 <pkra> spectranaut_: sounds like we should agenda it
18:07:44 <pkra> jamesc: I wasn't even sure it's an author error.
18:07:53 <pkra> jamesn: it should be.
18:08:06 <pkra> scotto: html won't flag it because it won't take aria roles into account.
18:08:50 <pkra> spectranaut_: milestone for 2024?
18:09:11 <pkra> jamesc: more than editorial. jawsTest mentioned that nested elements are not allowed so we could match that.
18:09:45 <pkra> scotto: I think both authoring guidance and if ARIA more overtly stated what it means now, then aria-in-html could drop the less normative section around this kind of thing
18:09:53 <pkra> jamesn: can we salvage some of that then?
18:09:56 <pkra> scotto: yeah. 2024.
18:10:11 <Rahim> q+
18:10:16 <pkra> spectranaut_: let's agenda it. any takers?
18:10:22 <pkra> scotto: will take a look.
18:10:41 <pkra> spectranaut_: aria 2085.
18:10:54 <pkra> ... customize announcement of state
18:11:02 <pkra> scotto: in openUI has been a proposal for a switch element.
18:11:10 <pkra> ... competing proposal to HTML
18:11:15 <CoryJoseph> CoryJoseph has joined #aria
18:11:26 <Rahim> q-
18:11:51 <pkra> ... what they keep on trying to do: a switch with states on both sides (day / night or dark/light).
18:12:16 <CurtBellew> present+
18:12:21 <pkra> ... so I go to the designers and say "you'll need a label where it's clear what on/off does"
18:12:22 <jamesn> q+
18:12:41 <pkra> ... push back from designers that that's not natural for, e.g., a.m./p.m.
18:13:00 <pkra> ... I'm not actually sure we should do it.
18:13:43 <pkra> jamesn: we have opened the path towards a switch. This sounds like a radio button.
18:13:56 <jamesn> ack me
18:13:56 <pkra> scotto: yeah, but that leads to similar discussions
18:13:58 <giacomo-petri_> q+
18:14:29 <pkra> jamesc: not clear if the proposal is about customizable state or a string that represents the current state of the control.
18:14:37 <pkra> ... I can see jamesn's point for just a label.
18:14:57 <Marcelo_Paiva> comment: switch with two states = a checkbox, but what if the switch has 3 states (on | unselected | off)?
18:15:04 <pkra> ... iOS and Mac have an API that would fit.
18:15:41 <pkra> spectranaut_: if it's just about explaining why we don't do this, then 2024 milestone sounds good.
18:15:43 <pkra> zakim, next item.
18:15:43 <Zakim> I see a speaker queue remaining and respectfully decline to close this agendum, pkra
18:15:52 <jamesn> qv?
18:16:34 <pkra> giacomo: just on jamesn radios. This might be due to the inconsistencies around operation.
18:16:37 <jamesn> ack giacomo-petri_
18:16:39 <pkra> zakim, next ietm.
18:16:39 <Zakim> I don't understand 'next ietm', pkra
18:16:42 <pkra> zakim, next item.
18:16:42 <Zakim> agendum 2 -- -> New PR Triage https://bit.ly/3RsFsRD -- taken up [from agendabot]
18:17:02 <pkra> spectranaut_: 2 PRs on html-aam.
18:17:08 <pkra> ... on text edit
18:17:18 <pkra> ... seems like those have reviewers
18:17:59 <pkra> ... this is all around the discussion about fieldset maxlength
18:18:10 <pkra> ... then there's 2 PRs on DPUB ARIA.
18:18:26 <pkra> ... around deprecated roles.
18:18:41 <pkra> ... seems they are in a good place
18:18:55 <pkra> jamesc: I'll get to the other one as well. Seems almost editorial.
18:18:59 <pkra> zakim, next item
18:19:00 <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]
18:19:49 <spectranaut_> https://github.com/web-platform-tests/wpt/pull/42769
18:19:50 <pkra> spectranaut_: 42769 seems in a good place.
18:20:05 <pkra> jamesc: yes, waiting for changes
18:20:06 <pkra> zakim, next item
18:20:06 <Zakim> agendum 4 -- -> describe grouping (and naming of the group) for exclusive accordions <details name> https://github.com/w3c/html-aam/issues/509 -- taken up [from agendabot]
18:21:19 <pkra> scotto: this is due to the HTML update to allow details elements to accept name attribute
18:21:41 <pkra> ... which adds functionality where only one details element will be displayed at a time.
18:22:10 <pkra> ... nothing has been done to make this new functionality clear as far as accessibility APIs are concerned.
18:22:26 <pkra> ... some suggestions were to imply a grouping and give that a name
18:22:38 <pkra> ... but in aria it's not possible without an explicit grouping
18:22:47 <pkra> ... I'm not sure naming is always necessary or even helpful.
18:23:14 <pkra> ... Steve F has also taken a look and suggested it might be good if the browsers could update the mappings for summary to enumerate them.
18:23:44 <pkra> ... that would avoid adding a new groupings attribute. Instead of additional groupings (section, fieldset etc).
18:23:57 <pkra> ... people seem to agree they want an "x of y" announcement.
18:24:08 <pkra> ... implying that if you interact with one, something will happen to the others.
18:24:23 <pkra> ... and of course this just adds to the existing problems around summary/details.
18:24:38 <Rahim> q+
18:24:54 <spectranaut_> ack Rahim
18:25:30 <pkra> Rahim: this issue impacts [zoom connection problem at scribe]
18:26:22 <pkra> scotto: there can always be groups of related controls that don't fall into clear groups. E.g., related buttons like a toolbar. There's no way to provide an "x of y" announcement (unless you use a list and have a platform that yields such output)
18:26:30 <Rahim> the issue impacts multiple user demographics, but conveying position within set as Scott recommended makes sense
18:27:01 <CoryJoseph> q+
18:27:02 <giacomo-petri_> q+
18:27:04 <pkra> ... maybe that opens up the can of worms where buttons and controls could be given position-in-set aria semantics so that they could be allowed to expose thos values.
18:27:13 <spectranaut_> ack CoryJoseph
18:27:16 <pkra> (thank you, Rahim.)
18:27:38 <pkra> CoryJoseph: how would naming the grouping be different from encapsulating a section and naming that section?
18:27:55 <pkra> scotto: I think it comes down to what you want the container be exposed as.
18:27:59 <pkra> ... they want a named group.
18:28:05 <pkra> ... in HTML that would be fieldset.
18:28:30 <pkra> ... the only way in HTML. (except the voldemort attribute)
18:29:07 <StefanS> StefanS has joined #aria
18:29:08 <pkra> ... there's a note "needs to be grouped for accessibility". Then section would have to be named but then that's a landmark and that seems questionable.
18:29:12 <StefanS> present+
18:29:19 <pkra> CoryJoseph: and you'd lose the "x of y" aspect.
18:30:00 <pkra> scotto: right. there was discussion around this. It ends up being a redundancy that you don't really need
18:30:04 <pkra> CoryJoseph: groups all the way down.
18:30:26 <pkra> scotto: some consensus that it wasn't always necessary.
18:30:30 <spectranaut_> ack giacomo-petri_
18:31:06 <pkra> giacomo: the idea of having this list of elements does not resolve the key point that something unexpected for the users, i.e., something unrelated collapsing.
18:31:47 <jongund_> jongund_ has joined #aria
18:31:52 <pkra> ... two different implementations leads to the same announcements. Say, a list of buttons. But one of them would do something unexpected.
18:32:11 <pkra> scotto: I think they wouldn't announce the same way.
18:32:47 <pkra> ... i.e., button in list item would be announced differently from summary in list item
18:33:17 <pkra> ... but I want to acknowledge that this doesn't solve the whole problem. Maybe there's more that we can do and I'm happy if we want to do that here, but it's a problem that exists everywhere.
18:33:25 <pkra> ... for any collapsing items, e.g., tabpanel.
18:33:46 <Rahim> q+
18:33:49 <pkra> ... there's an implicit assumption that switching closes the panel but that's not explicit anywhere.
18:34:01 <spectranaut_> ack Rahim
18:34:20 <pkra> Rahim: what would be the best user experience for this?
18:34:41 <pkra> giacomo: I think I'd like to hear something that tells me the other elements will be collapsed.
18:34:51 <Marcelo_Paiva> q+
18:35:02 <pkra> ... the relationship is important but collapse too
18:35:12 <pkra> Rahim: when entering the group or activating the item?
18:35:14 <spectranaut_> ack Marcelo_Paiva
18:35:22 <pkra> giacomo: when entering the group
18:35:40 <Marcelo_Paiva> https://designsystem.digital.gov/components/accordion/
18:35:56 <pkra> Marcelo_Paiva: US design system has an accordeon compent. This has an option for keeping them open or closing them on activation of another
18:36:03 <pkra> ... we have good success with that.
18:36:50 <pkra> spectranaut_: there seems to be some interest in making "x of y" counting work.
18:37:28 <pkra> scotto: if an aria-controls relationship was made between all elements, then perhaps AT could do something with that.
18:37:31 <Marcelo_Paiva> q+
18:37:32 <pkra> jamesn: but what would it do useful?
18:38:12 <pkra> scotto: but as Giacomo said, we don't have any parity. Getting beyond "x of y" would be much more than what I had wanted. hard if no platform decided to do that.
18:38:23 <spectranaut_> q+ spectranaut_
18:39:22 <pkra> Marcelo_Paiva: seconding Scott. Some use cases from my end: helps users with cognitive disability to collapse all, avoiding walls of text. We then also have "open/collapse all" functionality to help further
18:39:30 <pkra> spectranaut_: is this an HTML-only change?
18:39:49 <pkra> scotto: I was hoping for implementer interest to see if this has a chance of getting done.
18:40:04 <pkra> spectranaut_: we'd have to describe what to expose though
18:40:18 <pkra> scotto: I'd start with calculating setsize and position.
18:40:29 <pkra> ... we have that but it's scoped to certain elements.
18:40:38 <pkra> ... I assume we could update the platforms to expose it.
18:41:06 <spectranaut_> s/HTML-only/HTML-AAM only/
18:41:31 <Rahim> Will defer to James C. who is calling the shots, I'm just here for moral support :)
18:42:32 <pkra> jamesc: I was somewhat surprised by some of the reactions. I don't have a preference how we expose this. Was there a specific proposal to consider?
18:43:22 <pkra> scotto: I was looking for confirmation that there's interest. If html-aam exposes the name, then browsers would have to calculate setsize and pos-in-set. Can this property be exposed on an element that wasn't originally spec'ed to expose that.
18:43:42 <pkra> jamesc: that seems possible for WebKit and I'd assume other engines are similar here.
18:43:55 <pkra> ... AT should also be able to deal with that.
18:44:28 <pkra> ... I wonder if non-sequential elements will be weird, producing effects across the document.
18:44:44 <pkra> scotto: it wasn't discussed much. More thought of an 80/20 rule.
18:45:16 <pkra> ... so treating it as not a validation problem even if it's not used well.
18:45:48 <pkra> jamesc: I'd phrase it as HTML flexibility.
18:46:07 <pkra> scotto: there was also discussion around keyboard control for this but that would fall outside html-aam.
18:46:30 <pkra> jamesc: we already have some similar controls.
18:47:00 <pkra> scotto: yeah, how to move between them
18:47:27 <pkra> jamesc: right. that sounds outside the initial implementations.
18:47:45 <pkra> ... but I can see how something styled like an accordion would make users expect arrow keys.
18:48:04 <pkra> ... if it's more a traditional summary/details, then I wouldn't expect arrow keys
18:48:08 <pkra> scotto: agree
18:48:35 <pkra> ... I'll start with a change for html-aam, indicate potential places needed to change
18:48:41 <pkra> zakim, next item
18:48:41 <Zakim> I see a speaker queue remaining and respectfully decline to close this agendum, pkra
18:48:53 <spectranaut_> q?
18:48:54 <pkra> q?
18:48:59 <spectranaut_> ack Marcelo_Paiva
18:49:01 <spectranaut_> ack spectranaut_
18:49:04 <pkra> zakim, next item
18:49:04 <Zakim> agendum 5 -- -> Consider a mechanism to associate controls without an explicit grouping https://github.com/w3c/aria/issues/1721 -- taken up [from agendabot]
18:49:15 <pkra> spectranaut_: ties into previous item
18:49:43 <pkra> scotto: gets more into the part we discussed around radio buttons earlier
18:50:10 <pkra> ... in HTML you push things inside radio groups. ARIA is a bit less clear there
18:51:06 <pkra> ... I do see a use case to be able to have, e.g., controls in a toolbar, can be grouped even though they're not explicitly done.
18:51:27 <pkra> spectranaut_: are there cases where the browser can do the work already?
18:52:00 <pkra> scotto: e.g., the radio button example I think would require guess work from browser to know they're related.
18:52:14 <pkra> ... for the toolbar, arguably anything in the toolbar would be given "x of y"
18:52:32 <pkra> ... but do we always want that or do authors decide?
18:53:20 <pkra> CoryJoseph: is there really a situation where we don't think authors would want that?
18:53:41 <pkra> scotto: fair point. I don't know. Anecdotally, some like it and some don't.
18:53:52 <pkra> CoryJoseph: but that shoulds like something left for AT
18:54:05 <pkra> jamesc: don't think there's anything that prevents AT from calling out the numbering.
18:54:16 <pkra> ... doesn't feel like a browser specific change
18:54:30 <pkra> jamesn: but we don't expose this right now in the APIs so they don't calculate that.
18:54:59 <pkra> jamesc: maybe misunderstanding. If there are five items in the toolbar, they could do that.
18:55:24 <pkra> jamesn: but do they do the extra work?
18:56:10 <pkra> ... for, say, menus. AAM says that browser should calculate pos-in-set etc and expose that. Should we want AT to expose more than what's exposed? Should they really look through the tree and calculate that?
18:56:44 <pkra> jamesc: where the default positioning is efficient, it shouldn't need anything extra.
18:56:51 <spectranaut_> menuitem: https://w3c.github.io/core-aam/#role-map-menuitem
18:57:01 <pkra> jamesc: but isn't the browser exposing those properties instead of letting AT infer it from tree?
18:57:14 <pkra> jamesc: I don't think so.
18:57:24 <pkra> s/jamesc: but/jamesn: but
18:57:26 <pkra> s/jamesc: but/jamesn: but/
18:57:48 <pkra> spectranaut_: I don't think we expose it.
18:58:02 <jamesn> https://www.w3.org/TR/core-aam-1.2/#mapping_additional_position
18:58:18 <pkra> scotto: from internal discussions, people felt like they'd need to update how the API works.
18:58:33 <pkra> jamens: [recites spec from link]
18:58:44 <pkra> s/jamens/jamesn/
18:59:35 <pkra> jamesc: we can hopefully make that testable in WPT eventually. I don't think it's a real problem for AT.
18:59:57 <pkra> jamesn: I just don't know how they all work to say
19:00:19 <pkra> scotto: thinking specifically about toolbar. it's less clear than say menu or list.
19:00:31 <pkra> jamesn: and then you might have radio buttons in a toolbar.
19:01:30 <pkra> jamesc: way back when, there was discussions around toolbar. major UI difference between  windows, mac, linux.
19:01:37 <pkra> spectranaut_: at the hour. let's continue
19:02:04 <pkra> zakim, end meeting
19:02:04 <Zakim> As of this point the attendees have been Adam_Page, giacomo-petri_, scotto, Rahim, Marcelo_Paiva, keithamus, CurtBellew, StefanS
19:02:06 <Zakim> RRSAgent, please draft minutes v2
19:02:07 <RRSAgent> I have made the request to generate https://www.w3.org/2023/12/07-aria-minutes.html Zakim
19:02:15 <Zakim> I am happy to have been of service, pkra; please remember to excuse RRSAgent.  Goodbye
19:02:15 <Zakim> Zakim has left #aria
19:02:45 <Adam_Page> Adam_Page has joined #aria
19:04:28 <bkardell_> bkardell_ has joined #aria
19:04:34 <jongund_> jongund_ has joined #aria
19:48:25 <jongund_> jongund_ has joined #aria
20:05:52 <jongund_> jongund_ has joined #aria
20:08:08 <jongund__> jongund__ has joined #aria
21:07:40 <jongund_> jongund_ has joined #aria
21:51:24 <jongund_> jongund_ has joined #aria
21:58:38 <jongund_> jongund_ has joined #aria
22:09:24 <jongund__> jongund__ has joined #aria
22:51:37 <jongund_> jongund_ has joined #aria
23:16:47 <jongund__> jongund__ has joined #aria