Meeting minutes
<lwarlow> I agree its good to allow either way, and authors can decide when they want it.
Mason introduces the issue, background, a11y behavior, alternatives considered, etc.
See w3c/
??: Note the problem with context menus is largely for links, buttons don't have as complex interactions.
masonfreed: Some websites might want to have the ? icon on everything that has a hint, to indicate that there's somethign there.
matt: Not being focusable is correct, but probably should still be in a11y tree and able to be clicked.
sarah: I don't think it should be exposed in a11y tree. We need another mechanism to expose the tooltip.
sarah: The target has to be some sort of interactive element regardless of the pseudo-element. ANd the author might not always put psueod-element there.
sarah: So it's not the right way for accessing the info.
sarah: We need a reliable way to indicate interest on teh invoker. Pseudo is specifically for pointer users, to be able to indicate interest.
sarah: But either through aria-actions or some other specific assistive tech way to directly interact with the invoker
BGaraventa: Same. Touchscreen devices not scrolled by voicover etc.
<Siri> if element is not exposed to keyboard navigation how will they show up for them? If AT user hears clickable and hint appears on focus/touch but no action is done , it will confuse them. How will voice input users will interact with them?
BGaraventa: I would suggest tabindex=-1 to ensure it is focusable, can help with activation
luke: Touchscreen screenreader users will have some action to trigger the interest.
… : They con longpress or press the separate button.
… : if you are a screenreader user, you'll focus on a link and be able to activeate somehow
… : we need some way for AT to trigger that behavior. They may already have it, if ways to trigger context menu or select a link... I don't know how that works today.
… : but if I hide the interest button, feature still needs to be accessible, so relying on button being in AT is not solving the problem
jcraig: This is basically exposing a standard tooltip. If we expose using that mechanism, then exposing also the extra button would be a duplication.
… It's not not in the tree. It's there as a tooltip.
… My understanding is that there's only static content, no interactives?
masonfreed: There are two classes of tooltips. We'll call them tooltips and hovercards.
… hovercards can be interactive
… Both popovers. Can launch a popover that has buttons and links etc.
jcraig: That certainly complicates it.
jcraig: 2nd thing, anne couldn't attend, but ::interest-button makes the proposal more appealing
… but if this is primarily for solving the problem, why is it opt-in rather than opt-out?
masonfreed: We discussed a lot in OpenUI. Mostly default is to not show because majority of developers acted that way.
… but maybe if it's a standard API that's easy to use, easy to turn off, might be reasonabe to have on by default.
Siri: [asks her question above]
<dbaron> <Siri> if element is not exposed to keyboard navigation how will they show up for them? If AT user hears clickable and hint appears on focus/touch but no action is done , it will confuse them. How will voice input users will interact with them?
masonfreed: That's basic question of whether or not it shoudl show up in a11y tree. It feels like it shouldn't show up there because having 2 ways to do one thing...
emilio: A lot of the discussion assumes the pseudo-element is the way we want to go
… but I don't think that's a great approach.
… They are not very flexible. Limits on what content can be put in, etc.
… I feel that an attribute or command or JS API is a lot simpler and more flexible.
… It might not be so easy to do the right thing AT-wise, but as designed this is opt-in. So first thing you will look up an example.
… Allowing random element is that you can put a bunch of stuff in there that maybe doesn't belong, or do something silly like nesting interactive content
… but that's also a limitation of pseudo-element approach. It feels oddly specific to be a pseudo-element.
… Do we really want to go with this approach?
… but a lot of the behavior falls out of this choice
masonfreed: I'm also ok with an attribute on a span. It is weird because can't use on <input type=button>.
emilio: THat's a replaced element, can't have pseudos.
<lwarlow> interestfor doesn't work on input type button anyway does it?
<lwarlow> commandfor doesn't
<Zakim> fantasai, you wanted to ask sarah a question
fantasai: what do you do for sighted users with the keyboard, how do they invoke this?
… I like the idea of the attribute, pseudos have a bunch of limitations, not just content but also position in the tree
… I think this attribute should automatically do the right thing rather than suggesting aria attributes
… I also agree with masonfreed that we should not require JS for this
emilio: use a declarative mechanism like an attribute
masonfreed: re. the question focusing the originating element itself
masonfreed: focus interest target with keyboard, just as Edge shows title attribute, you would also show interest
<jcraig> Mason replied to the sighted keyboard user interaction question re: https://
sarah: You focus the actual invoker, and you can reach the interactives by pressing tab.
[agreement that author shouldn't have to figure out the right aria stuff for this]
sarah: Making pseudo interactive would introduce interactive element inside interactive element, which causes problems.
… This is an interactive control, already needs to support access directly, should not ever need to reach this interest-button in AT
masonfreed: Even if span with attribute, nested interactive, we could make it not interactive.
sarah: Replying to suggestion earlier that the pseudo-element or span would be exposed as a button
Matt: Possible that Sarah's statements addressed this, but want to double-check.
… If there is an accessibility tree providing a method or pathway for expressing interest, wondering if there's a conflict between needs of people using non-visual screenreaders vs say, switch control or voice control where you have the visual elements getting numbered
… Do we ever need the visual element that is the tap target, do we ever need that to be activatable with an assistive technology?
… What would be the visual way of using an assistive technology to get at the interest target?
sarah: Visually, voice control?
… We have talked about that, seems like the hardest to address.
… Would need to add something to Voice Control.
matt: Rely on aria actions?
sarah: yes, that would be my expectation
matt: So an AT would have to support, just like a screenreader would have to support, aria actions.
<Zakim> jcraig, you wanted to ask about focus and hover delays and AT focus into the interactive variant and to relate my prior q item to pre-objection discussion in w3c/
jcraig: Thanks for reminder about different types of invokers
jcraig: Question, linked some discussion about delays, there was some concern about ambiguity of delays.
… Tab had replied and made a vote for keywords rather than timing defaults, good logic for that
… But were there any more discussions or changes related to delays between hover and focus or times vs keywords? Because those interaction patterns are different, especially with different types of AT involved.
… Was there any more discussion since then about delays?
masonfreed: That discussion, started in the position that it was keywords to give more flexibility to UA
… but people pushed back and wanted to choose number of seconds
… They are the same delay for both keyboard and mouse.
… Though some discussion about having ability to set differently
… interest-delay
… There should be a provision that the UA can override those delays. So e.g. the user can ask for the delays to be doubled, or whatever
jcraig: Based on AT need and ability to change that delay, that timing delay I assume is author-observable at that point, right?
masonfreed: Hm. Yes. Would require some kind of user interaction.
… You could time it between mouse hover and the invokation.
jcraig: Concern wrt privacy and fingerprinting and assistinve technologies
… Trying to figure out how we could mask the differences?
masonfreed: Open to ideas! But issue makes sense.
jcraig: I only come with questions right now. :)
jamesn: Queue is empty. Seem to have exhausted the questions. What should be the next step?
masonfreed: Great discussion, thanks for setting up.
… I have some action items.
… Need to figure out how to hook into aria actions, would appreciate help with that.
masonfreed: Two approaches seem to have some traction. Pseudo-element and attribute.
jamesn: Both seem reasonable from a11y perspective.
<Zakim> jcraig, you wanted to respond to aria-actions integration
jcraig: aria-actions integration seems like easiest part of this issue.
jcraig: Lots of other hard questions!
sarah: Agreed. :) Harder part is convicing voice control authors to add functionality for this.
jcraig: Very subtle difference between voice control on iOS UI between items that have actions and items that don't. Little chevron or double chevron.
… So there's a visual hint that something has actions.
… Idk if something equivalent in Dragon or others.
luke: I think ::interest-button feels better markup-wise, vs making a span or adding an attribute.
… As for timing stuff, there's a lot that you'd have to fake to make this not observable. There's a lot of events that fire.
… You'd have to fake the events, fake selectors that match, a lot would be required there. Not super solveable.
jamesn: Are there other ways someone can observe that are easier than this?
jcraig: I hear that argument a lot with fingerprinting too, but we should do our best to avoid new methods that reduce detection entropy. Especially to not enshrine new detectability methods in new supported API.
sarah: In order to observe the difference here you'd have to time the delay?
… seems very labor intensive way to detect
masonfreed: Question for group -- pseudo-element vs span
… I think what I'm hearing is that this community is ambivalent between the two as long as a11y is correct?
<dbaron> Maybe clarify which "this community" you're asking?
keithamus: Span example, people will copy examples and that's the right thing to do, my worry is that this is not a pit of success.
… People will look at an example, see this weird span, not understand what it's for and delete it
… Pseudo-element can be more forceful, have to opt out
… If copying from example, might just wonder why span is there and not copy it.
I think the pseudo-element is opt-in as well keithamus
Siri: What are we solving for, pseudo-element vs attribute
… You have to take care of how it looks
… Two types of tooltips are hints. If tooltip has no interaction, it will calculate AT and show on focus
… even if programmatic focus
<keithamus> emilio: like a generated pseudo? I thought it was opt-out, like you have to `display:none` it?
Siri: How will user know the difference between actionable element and non-actionable element?
keithamus: that was discussed earlier but the initial proposal was opt-in, like ::before/::after, yes
Siri: Will screenreader see it as clickable? How will AT users differentiate?
… Problem with existing tooltips.
masonfreed: Sounded like group consensus is to not make the tap target focusable.
masonfreed: If author puts click handler on the new element, would need to tell authors to not do that.
masonfreed: If you focus the originating element (invoker) then it'll just show up. No need to interact with tap target.
jcraig: not ambivalent between the two. I would lean more towards pseudo-element unless I've missed something in Bryan or Matt's earlier points.
… Awkwardness I perceive is, in case of a focus user that's using tab navigation, the delay makes it unpredictable.
… If there is delay, could get in the way of a sighted user. iether want a really long delay, or show immediately. But if anythign in between
… Might want to tab past it, you enter unexpected interest invoker
<spectranaut_> We gotta go to the ARIA meeting :)
jcraig: But I see the interaction pattern of tab to something, always shows, and can escape key to get past it
… That's my usability concern
<dbaron> (I wonder if that implies that it might be useful for the default keyboard delay to be longer than the default mouse delay.)