Meeting minutes
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: this is a normative change so it should have the checklist on it.
jamesn: we (the editors) can do that for you.
New Issue Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
AriaNotify Permissions Policy -- needs resolution
Jacques: What concerns me is sites embeding content from other sites
… this is going to make adoption hard
Clay: I think there could be a list of allowed domains that we can reuse in the future
Jacques: Don't think this would be even exposed to ATs
JamesN: Is there anything we could ask browsers to do? For example, if something is allowed by defult or blocked by default that could ranslate to ARIANotify
Jacques: That's where I'm not sure. The equestion is it should be allowed or blocked by default
… Authors may not know that they need to opt-in
<giacomo-petri> +1 allow by default
JamesN: I lean towards allowing by default, you can block bad actors when they start to misbehave
… If you don't trust the site you'll block JavaScript anyways and that's not going to work
Jacques: Agree.
proposed resolution: we should allow arianotify to be allowed by default as written in the current version.
Jamesn: Objections?
Resolved: we should allow arianotify to be allowed by default as written in the current version.
RESOLUTION: we should allow arianotify to be allowed by default as written in the current version.
Clay: If we decide to change this, what would this look like?
Jacques: It'd require implementation changes. I think allowing by default and then changing to denying by default would be an option
JamesN: What we are resolving on today is not to give somebody something new that hey couldn't do with live-regions
Clay: Yes, this is not going to work worse than live regions
Consider adding an attribute for table-cell formulas
jamesn: we asked three implementors how this was going to work but haven't heard back.
aardrian: lets skip this one.
If time, next steps for aria-actions: aria-actions: handling focus when actions are synthetically triggered
sarah: I wanted to check - the tables added are script heavy and focused on aria-activedescendant
Matt: in the first use case, the APG example cannot do what is expected, but in the other use cases that are related to keyboard and mouse they do what is expected
Matt: I rewrote all of the tables on James Craig's feedback to be clear on focus vs active descendant.
sarah: this is good, but this isn't focused on what the browser does
sarah: this is fine for this example, but this is a very specific example.
sarah: this isn't talking about the difference of what the browser would do
Matt: we want to make sure this works in both the case where you do and don't use activedescendant. These are real world examples we expect to work.
sarah: Is the conclusion that the browser does not set focus when you use the actions rotor
Matt: that is correct
<Daniel> +1 to JamesN, we should really keep these arguments for when they ask for rationale
jamesn: we should prepare ourselves for feedback from wider review, make sure we have a good response for why this is OK. I suspect they will flag this.
jcraig: the js event model gives away more about users than anything this is doing.
jcraig: I would object to the browser doing anything different than it normally would. Say the browser is synthesizing a mouse click, if the element is focusable, by default the focus will move. Doing what browser does today will be the only way to not add an additional detection vector.
jcraig: we could say that AT should consider if an automatic focus change should bring AT focus along with it.
Matt: if the AT says activate action X and anything more than that happens, then that breaks.
Matt: js should continue to influence focus as it does today, but doing an action from the ATs shouldn't be seen as a regular click event.
jcraig: When you trigger an accessibility press, cascade of event, mouse down, mouse up, events, if the element is focusable then by default focus will move to the element. this is the normal browser behavior, so we shouldn't enshrine in spec language that actions from an AT prevent or preclude this cascade of expected events.
sarah: I don't see how preventing focus moving could cause issues with most controls. I do see how this could be used as an AT detection vector, but I don't think this is a new concern.
sarah: eventing and focus differences between AT and non AT are already present.
sarah: This is the same thing, but only happens with aria-actions, as opposed to what already exists.
sarah: one of the major use cases is composit widgets, if dom focus moves then that could already break in some instances.
sarah: if focus moves from a list to a button when an action is used, a user wouldn't expect focus to move, so when they hit down it wouldn't work as they would expect.
jcraig: we should get into more details on a spec PR so we can discuss deeper.
sarah: I can make a PR to my PR branch to discuss this on.
jcraig: Maybe make a new PR to replace the original, if the original is causing issues on Github.
sarah: I could put the proposed wording change on the issue.
jcraig: lets discuss the specific wording on the issue.
RESOLUTION: Sara will propose the specific text change in the issue
sarah: If screen reader focus hasn't moved but dom focus does, it could cause issues.
jcraig: If star is used in gmail, then there could be issues.
jcraig: If I hit star and focus was moved to star, then arrow keys might not do anything, but this would be for all users.
Matt: That might not be how the APG example works. If you click the move-up button, after clicking it focus moves to it.
Matt: that one can be complicated due to activedescendant
jcraig: All the places this is going to be used are reasonably complicated web applications, where subsequent actions are reasonably handled for mainstream users, and therefore may benefit these cases too.
sarah: We aren't expecting someone to click on a button with the mouse and then use arrow keys and expect it to work. This could break many things I've seen.