Meeting minutes
[Intros]
New PR Triage
New Issue Triage
spectranaut_: Editorial from Peter
pkra: Noticed this because of a link in 7.1
… Should link to presentational conflict resolution probably
… It's a simple change
spectranaut_: If anyone wants a good first issue that'll be great if you could volunteer
Jacques: I could do this
spectranaut_: Editorial from me -- will discuss with other editors and Daniel
spectranaut_: #37 in mathml -- How should alt text be exposed
… We should agenda it
jamesn: and we should check to pick it up in our query
JamesC: Webkit has the most complete implementation of mathml
pkra: Spec is not maintained
cyns: Wonder if James T wants to resurrect this as well
JamesC: It seems it's got most of the mac data, which is fine
spectranaut_: @@@ group focus
Priti: I took a look at this
JamesC: You can add me as assignee
Priti: Proposal is interesting, when I tried with VO on iphone it does announce multiple links as one link
… If we use aria-focus this may help
JamesC: This may be a bug that we can fix without a new attribute
… I am guessing that's more than markup, there are also style changes affecting
… If that's the case that may result in some additional nodes being involved
… I want to review because I think it's a bug. If iOS VO is the only one having the issue, I'd treat it as bug
Priti: Could reproduce with Chrome andd JAWS and Android
JamesC: Would you add this to the issue comment?
WPT Open PRs
Add ariaNotify
<spectranaut_> github-bot, take up w3c/
Add ariaNotify
<github-bot> OK, I'll post this discussion to w3c/
spectranaut_: You put this on the agenda Jacque with some comments
Jacques: We were waiting for commitments from other browsers
… webkit had some movement
… What are next steps?
JamesC: Apple engineers are optimistic about it, can't give specific tiimelines, it's near to the top of the pile
spectranaut_: Is there an open issue?
JamesC: I'll look for it
keithamus: We're possitive, no immediate plans to implement though
spectranaut_: Do you have an issue?
keithamus: I'll dig it out
JamesC: I'd say best to wait until another implementation is at least started
Jacques: Sounds good
aria-actions: handling focus when actions are synthetically triggered
<spectranaut_> github-bot, take up w3c/
aria-actions: handling focus when actions are synthetically triggered
<github-bot> OK, I'll post this discussion to w3c/
sarah: The behavior we want is on the referencing element you wnat to be able to choose the secondary action, activate, and stay on the primary action
… But activation triggers focus to the secondary action, which is not desired user expectationisbehavior
… From the browser's perspective it's easy to just not call focus, but that may have privacy/security implications
… We could move focus back to primary just after it's moved to secondary, but that may create oddities in AT behavior
Matt_King: I commented on this issue with what I wanted to say
… If the action itself causes (or should cause) a focus change, the result may not be that you want focus to immediately go back
… However, if it opens a menu/dialog or similar that's when you do want focus back
… What if the primary element is destroyed
… For example, actions to increase the product quantity, which are expected to be performed repeatedly, you'd like to here the updated amount but still keep focus on the trigger
<Zakim> front-endian-jane, you wanted to comment about authoring concerns with option 2
Jane: Option 2 may cause author errors. Agree.
JamesC: I may change my mind later when I fully review the thread.
… Some clarifying questions
… In the gmail-like scenario -- I think gmail is doing a smart inteerception of the click event, it might be a known issue
… Second -- "less of a detection vector". How could this be a detection vector?
sarah: Because keyboard could also trigger focus change
JamesC: I'll think some more about that one
JamesC: From Matt_King's list
… We could add some advice to the implementation that the center point of the similar event doesn't have these capabilities
Matt_King: Are yo saying that if you use option 1 you can obscure it with the location to be randomized?
JamesC: Time in particular, timing should'nt be predictable. Triggering a click and triggering a focus after some seconds may be even more of a detection vector because it's multiple events that are synthesized
JamesN: A well-written application where the button itself can take care of moving the focus back where it was
… This is not a requirement. I don't think this should block us
… #1 has privacy issues, #2 is subjected to author errors
Matt_King: All the examples we've come up with, aria-actions doesn't end up adding any value at all if the focus change happens. There's literally no point in having aria-actions
sarah: I wouldn't go that far -- having aria-aactions still tels you that there are actions
… If you are using a screen reader virtual cursor your focus is moving randomly without pretty much any interaction, which in itself can be used for tracking
… If folks are oK with this then there might not be a problem
JamesC: I wouldn't implement something differently than mainstream would do
… If something moves focus "mainstream", it should move it too
… We should add an author requirement to manage the "focus back" afterwards
Matt_King: There's a challenge. IF you put an author requirements that means author can't support a combination of mouse/keyboar users
… If you say that author shouldn't allow focus to be moved via click that creates another accessibility problems
JamesC: Author should manage that, didn't say shouldnt move
Jane: If someone triggers and action in a menu, if it's a mouse user that clicked on it I want to close the menu
… How could I distinguish these?
JamesC: I don't think you should keep focus in the menu item regardless
Matt_King: We'd appreciated help from this group to solve our current proposed examples. One is a set of tabs with actions, another is a list box with possible actions for each element on the list
… In the list box, if the mouse click hovers and clikcs the button, we do want focus to be on that button, but if the screen reader is on the list item and clikcs the button via the action item, we don't want focus to go there
sarah: This is hard to resolve from an author's perspective
… Even if you try you'd still have the focus bouncing. If we can do that that'd e the best approach. I don't think that's achievable by authors at this point
<Zakim> jcraig, you wanted to acknowledge we're using two different definitions of "focus management"
JamesC: Different definitions of managing focus. Matt was talking about the ARIA definitions, I was talking more generically about author controlling focus
… For the tab container, if you trigger this you'd change to tab container and move focus
… In the menu, it'd trigger a click event in one of these aactionable elements and then whatever happens results in another UI event which will need focus handling anyways
sarah: An action on every column header to sort. You want to be able to trigger the action without the focus moving to the inside button every time
Matt_King: The APG examples are not at all as you're describing
JamesC: Please link them to this issue
Matt_King: I'll do
Bryan: Is there an event?
JamesC: It's possible, but we talked about intentional events triggering AT events and it didn't really work
Siri: Are we talking about actions that appear on hover or on focus? Or about menus and sub menus?
… Focus management would be done differently for each
… How are we trying to differentiate this?
<Zakim> jcraig, you wanted to answer Siri
JamesC: Actions is a concept from VoiceOver, we are trying to come up with a way to implement this on the web. It's primitive. It only triggers the action based on what the app originally does
… Some of the proposals here may allow for AT detection
sarah: Does VO move focus?
Matt_King: VO triggers the action and sends it to the app through the api, then the app does whatever they decide
sarah: Maybe click but not focus on the action is the way to go
… user events may not be a problem for AT detection cause they are everywhere
<giacomo-petri> +1 to activating but not moving and allow authors to manage it if they think differently
James: the iOS implementation doesn't trigger the "tap" event
… It should have the exact same behavior as a mouse click would have on the web
sarah: Theoretically yes
Jane: The user experience wouldn't be as good if author doesn't have the ability to maintain focus. But that'd be differentiating the screen reader experience
JamesC: As a web author you can intercept that click
Jane: But I cannot only do it for screen reader user and not for mouse user
JamesC: Why would a mouse user wnat that?
Matt_King: I talked earlier about these two different expectations
sarah: You also don't want the focus back
JamesC: VO has the ability to follow mouse events based on VO settins
JamesN: I am assuming the order of events is going to be the same, we could use the same for sccreen reader users
sarah: You don't want to prevent focus unless the event is triggered by the action
JamesN: Focus could be there already.
Janes: You click there with the physical mouse and then you go back to the keyboard, there might be a different behavior
JamesN: You just want focus to be there
sarah: To prevent focus going there you should call focus somewhere else