Meeting minutes
<spectranaut_> s/presnet+/present+/
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.
https://
open questions - what should the button say it does if pointing to an idref that does/does not exist
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.
scotto_: Is it true that invoker can be used on an element for something that doesn't exist in the DOM
BGaraventa: How would the focus manaement work?
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
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."
keithamus: was a decision not based on any technical limitations but fallthrough logic. Was an implicit decision in popover target
<Zakim> scotto_, you wanted to add a bit more about focusing
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
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.
scotto_: if someone did invoke a whatever. The next tab keypress would move focus into it as they are injected into the page
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
Adam_Page: not finding anything explicit about the hiding/showing of invoketarget
Adam_Page: is it assumed that we only ever use this to hide/show things
keithamus: the intent yes. Some of the things propoised had pushback around security concerns.
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.
keithamus: custom behaviours are part of the initial ship, The custom element could do whatever. Find the idea attractive
Adam_Page: Find the idea attractive.
BGaraventa: like the idea - once question - is the popover an encapsulated component?
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.
keithamus: if the table is popover then the default behaviour is to emit the invoke behaviour. could hook up a custom behaviour.
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
scotto_: didn't say that - said it would be in the tab order not into the a11y tree
BGaraventa: see as being a problem - if arrow down doesn't work then would be an isse for disoverability
scotto_: need aria-details
siri: what is the difference adding this new invoker. What are we trying to achieve by adding this?
siri: nothing is changing
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.
<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 aria-expanded states?
keithamus: I think that would get some level of pushback. Roles shouldn't change the behaviour. Could only determine based on the element.
scotto_: can't change the functionality based on aria
jamesn: what do you need us to do?
jamesn: make the accessibility section complete.
keithamus: accessibility work in the browser implementation has not been done.
keithamus: have some rudimentary patches for aria-details. Guidance on the AT side is welcome
<keithamus> https://
<keithamus> keithamus/
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.
scotto_: might be something to reconsider. aria-details was not the perfect solution we wanted.
BGaraventa: would be worried about aria-owns on the button itself
scotto_: would have to create a fake container
jamesn: aria-details seems like a good idea
<siri> why not aria-describedby attribute instead of aria-details?
adrian: if the implementation is not rock solid and there is room for squishiness then AT could decide to not implement by default
<scotto_> because aria-details allows for someone to navigate to the related content
<scotto_> aria-describedby only provides a flattened text string of the associated content. we wouldn't want that
<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?
keithamus: similar to invoke - idea is interest. When mouse/keyboard lands on a button then interest would enable custom tooltips. Could enable hovercards
keithamus: preview of profile
<keithamus> https://
keithamus: this one has nothing in the accessibility section
<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
keithamus: no implementations of this as of yet
keithamus: could have both on a button
<scotto_> 'interested in interest'
<melsumner> I am very interested in helping with this
dmontalvo: will see if APA can take a look at it