16:54:16 <RRSAgent> RRSAgent has joined #aria-dive
16:54:20 <RRSAgent> logging to https://www.w3.org/2024/02/15-aria-dive-irc
16:54:20 <Zakim> RRSAgent, make logs Public
16:54:21 <Zakim> please title this meeting ("meeting: ..."), jamesn
16:54:47 <jamesn> meeting: ARIA Deep Dive - Invoketarget & Interesttarget proposals from OpenUI
16:59:39 <Adam_Page> Adam_Page has joined #aria-dive
17:01:37 <spectranaut_> spectranaut_ has joined #aria-dive
17:05:24 <spectranaut_> presnet+
17:05:36 <spectranaut_> s/presnet+/present+
17:05:50 <keithamus> keithamus has joined #aria-dive
17:05:55 <spectranaut_> s/presnet+/present+/
17:05:58 <keithamus> present+
17:06:09 <melsumner> melsumner has joined #aria-dive
17:06:34 <Adam_Page> present+
17:07:11 <jamesn> scribe: jamesn
17:07:16 <scotto_> scotto_ has joined #aria-dive
17:08:02 <jamesn> keithamus: Dialog, select boxes, popover, popover target etc. happening in openui. Would have an invoketarget on the button which would point to an interactive element.
17:08:58 <jamesn> https://open-ui.org/components/invokers.explainer/
17:09:47 <jamesn> open questions - what should the button say it does if pointing to an idref that does/does not exist
17:09:59 <scotto_> q+
17:10:07 <jamesn> ack scotto_
17:10:11 <melsumner> q+
17:11:10 <jamesn> scotto_: popover target - can only invoke popovers. Idea is that this button serves one purpose - to open, close or toggle the associated popover. Was straightforward, putting an aria-expanded on the button by default.
17:14:20 <jamesn> scotto_: Is it true that invoker can be used on an element for something that doesn't exist in the DOM
17:14:33 <BGaraventa> BGaraventa has joined #aria-dive
17:15:26 <jamesn> BGaraventa: How would the focus manaement work?
17:16:50 <jamesn> keithamus: I don't really know the answer to that. The button itself is a regular button. When the button is invoked it is down to the determinate element to manage the focus. Popover / Dialog will run their own focusing steps
17:16:56 <jamesn> ack melsumner
17:17:02 <scotto_> q+ to add a bit more about focusing
17:18:12 <jamesn> melsumner: A line in the explainer - if the button is a form element then invoke target should be ignored. "If a <button> is a form participant, or has type=submit, then invoketarget must be ignored."
17:18:33 <Adam_Page> q+ about managing display / a11y tree exposure of invoketarget
17:18:46 <Adam_Page> q+
17:19:24 <jamesn> keithamus: was a decision not based on any technical limitations but fallthrough logic. Was an implicit decision in popover target
17:19:27 <jamesn> q?
17:19:31 <jamesn> ack scotto_
17:19:31 <Zakim> scotto_, you wanted to add a bit more about focusing
17:20:21 <siri> siri has joined #aria-dive
17:21:06 <jamesn> scotto_: popover has manual and auto - auto focus moves, manual it does not. Even with auto focus is not always expected to move. This is where the autofocus element was extended. Autofocus would be the signal as to where to move focus. Any element could be popped up or invoked then there are different focus expectations
17:22:24 <jamesn> scotto_: autofocus would need to be used in some cases. Even with an aria role on some elements - we have the rule that changing the role doesn't have the default benaviour. to focus wouldn't move to an aria dialog.
17:22:38 <jamesn> scotto_: if someone did invoke a whatever. The next tab keypress would move focus into it as they are injected into the page
17:23:29 <BGaraventa> +q
17:23:41 <jamesn> scotto_: on the submit bit - buttons are submit buttons by default, in a form if type button isn't decalred then they submit by default. Something would have to break so was decided that submitting a form was more important
17:23:44 <jamesn> ack Adam_Page
17:24:06 <jamesn> Adam_Page: not finding anything explicit about the hiding/showing of invoketarget
17:24:06 <siri> +q
17:24:29 <jamesn> Adam_Page: is it assumed that we only ever use this to hide/show things
17:24:42 <MarioBatusic> MarioBatusic has joined #aria-dive
17:25:25 <jamesn> keithamus: the intent yes. Some of the things propoised had pushback around security concerns.
17:26:05 <jamesn> keithamus: invoketarget is a way to say that you are performing some control on the target element. it is coincidental that the initial 2 are popover and dialog.
17:26:37 <jamesn> keithamus: custom behaviours are part of the initial ship, The custom element could do whatever. Find the idea attractive
17:26:57 <jamesn> Adam_Page: Find the idea attractive.
17:27:00 <jamesn> q?
17:27:05 <jamesn> ack BGaraventa
17:27:26 <melsumner> q+ to say there are some HTML elements in the accessibility section, but are you open to some elements with certain roles also receiving the implicit aria-expanded states?
17:27:34 <MarioBatusic__> MarioBatusic__ has joined #aria-dive
17:27:42 <jamesn> BGaraventa: like the idea - once question - is the popover an encapsulated component?
17:28:21 <MarioBatusic__> present+
17:28:40 <jamesn> keithamus: because popover is an attribute it could be applied to a table. If the element has the popover attribute and you haven't applied a specific behaviour then will do the default.
17:29:13 <jamesn> keithamus: if the table is popover then the default behaviour is to emit the invoke behaviour. could hook up a custom behaviour.
17:29:30 <aardrian> aardrian has joined #aria-dive
17:30:11 <jamesn> BGaraventa: when focus isn't managed in a popover it will appear after the button in the a11y tree. If that button were in a table cell then presumably the popover content would be inserted in to the tree
17:30:27 <jamesn> scotto_: didn't say that - said it would be in the tab order not into the a11y tree
17:31:15 <jamesn> BGaraventa: see as being a problem - if arrow down doesn't work then would be an isse for disoverability
17:31:25 <jamesn> scotto_: need aria-details
17:31:26 <jamesn> q?
17:31:30 <jamesn> ack siri
17:32:35 <jamesn> siri: what is the difference adding this new invoker. What are we trying to achieve by adding this?
17:32:42 <jamesn> siri: nothing is changing
17:33:46 <jamesn> keithamus: idea is to make popovertarget applicable to more things. Allow to work with dialogs without needing scripting and ARIA. Take popover target and make it applicable to everything.
17:33:57 <jamesn> q?
17:34:05 <jamesn> q+
17:34:08 <jamesn> ack melsumner
17:34:08 <Zakim> melsumner, you wanted to say there are some HTML elements in the accessibility section, but are you open to some elements with certain roles also receiving the implicit
17:34:11 <Zakim> ... aria-expanded states?
17:35:06 <jamesn> keithamus: I think that would get some level of pushback. Roles shouldn't change the behaviour. Could only determine based on the element.
17:35:20 <jamesn> scotto_: can't change the functionality based on aria
17:35:25 <jamesn> ack me
17:35:42 <jamesn> jamesn: what do you need us to do?
17:37:02 <jamesn> jamesn: make the accessibility section complete.
17:37:59 <jamesn> keithamus: accessibility work in the browser implementation has not been done.
17:38:39 <jamesn> keithamus: have some rudimentary patches for aria-details. Guidance on the AT side is welcome
17:39:13 <keithamus> https://www.keithcirkel.co.uk/working-on/#ship-invokers-proposal-to-all-major-browsers
17:40:17 <keithamus> https://github.com/keithamus/invokers-polyfill
17:41:39 <jamesn> scotto_: one of the reasons aria-details was used as the popover target. Webkit didn't support aria-owns in the same way that aria-owns is supported elsewhere. Also when talked about with implementors they didn't want to implement using aria-owns.
17:42:05 <jamesn> scotto_: might be something to reconsider. aria-details was not the perfect solution we wanted.
17:42:09 <jamesn> q+
17:42:39 <jamesn> BGaraventa: would be worried about aria-owns on the button itself
17:42:57 <jamesn> scotto_: would have to create a fake container
17:44:02 <jamesn> jamesn: aria-details seems like a good idea
17:44:11 <siri> why not aria-describedby attribute instead of aria-details?
17:45:04 <jamesn> adrian: if the implementation is not rock solid and there is room for squishiness then AT could decide to not implement by default
17:45:19 <scotto_> because aria-details allows for someone to navigate to the related content
17:45:39 <scotto_> aria-describedby only provides a flattened text string of the associated content.  we wouldn't want that
17:46:07 <melsumner> is it realistic for AT to take that kind of stance though? I mean shouldn't we be able to do more iterative development so we can make progress in an incremental way?
17:46:37 <jamesn> keithamus: similar to invoke - idea is interest. When mouse/keyboard lands on a button then interest would enable custom tooltips. Could enable hovercards
17:46:45 <jamesn> keithamus: preview of profile
17:47:20 <keithamus> https://open-ui.org/components/interest-invokers.explainer/
17:47:43 <jamesn> keithamus: this one has nothing in the accessibility section
17:48:13 <scotto_> @melsumner - unfortunately it is realistic as it has happened.  if an AT does the work to implement functionality for a feature that makes it into the spec, and people don't like the feature - they're not likely to want to spend more time on that feature if the spec changes
17:48:53 <jamesn> keithamus: no implementations of this as of yet
17:48:57 <jamesn> keithamus: could have both on a button
17:52:35 <BGaraventa> BGaraventa has left #aria-dive
17:52:50 <scotto_> 'interested in interest'
17:53:27 <melsumner> I am very interested in helping with this
17:53:34 <dmontalvo> q+
17:53:50 <jamesn> q-
17:53:58 <jamesn> ack dmontalvo
17:55:10 <jamesn> dmontalvo: will see if APA can take a look at it
17:56:05 <jamesn> zakim, end meeting
17:56:05 <Zakim> As of this point the attendees have been keithamus, Adam_Page, MarioBatusic__
17:56:07 <Zakim> RRSAgent, please draft minutes
17:56:08 <RRSAgent> I have made the request to generate https://www.w3.org/2024/02/15-aria-dive-minutes.html Zakim
17:56:16 <Zakim> I am happy to have been of service, jamesn; please remember to excuse RRSAgent.  Goodbye
17:56:16 <Zakim> Zakim has left #aria-dive