Meeting minutes
New PR Triage
jamesn: it’s triage week, sharing window...
… aria#2657
… editorial, fix links and markup
… don’t need to talk about
Daniel: can discuss offline
jamesn: also don’t need to discuss aria#2655 and the next one
jcraig: aria#2650 is a F2F candidate
… talked about next week
… I addressed questions from Rahim and Matt
… keithamus expressed interest in looking into this
… chrishtr took an action to follow up
… one other suggestion I’ll add is the related WPT tests are both tentative
… but I’ll move them to non-tentative to encourage implementations
jamesn: is there anything we need to do in triage? Should we agenda it?
jcraig: that was full scope of what I wanted to share, so no need to agenda unless people want to follow up
jamesn: I’ll agenda it
chrishtr: I brought Lucas with me, he just joined the WG
Lucas: I’m helping with a11y stuff on Blink as well as on browser side
… my role isn’t fully clear yet, but for this quarter and next, I’ll be implementing some of this
… for name from, I just spoke with MS, and I understand we need one extra implementation
… so I will create the bug on our side
… the MS folks told me they might give it a stab, but if not, I can do it in Q1
spectranaut_: that will enable me to merge
<chrishtr> Full name: Lucas Radaelli
jamesn: let’s do intros...
Lucas: thanks, all — nice to meet you
zakim. next item
New Issue Triage
jamesn: aria#2656
… add `getComputedAria` to window
jcraig: it seems the commenter is unaware of the 2 parallel paths that we’re working on
… I’ll comment on the issue
… may be true for the second issue
jamesn: I’ll assign it to you
… I fear it’s something that won’t be easily available
jcraig: we had marked this out of scope for privacy
… so I’ll comment on that
jamesn: aria#2655
jcraig: this one is also out of scope
… I’ll add a comment to this too
jamesn: aria#2653
… should aria-live default be undefined instead of off
jcraig: I’d suggest we assign this to Rahim
… and I initially agree with Joannie on this
… but Rahim may know about complexities
WPT Open PRs
jcraig: wpt#55200 is just metadata changes
… no need to discuss
… wpt#53733
… spectranaut_, I added review comments
spectranaut_: thanks, I’ll review
jcraig: other reviewers, please block out time — it’s a biggie
… no other updates
TPAC planning
jamesn: we have a number of F2F candidates on the agenda
… spectranaut_ and I plan to make a first draft tomorrow
… so last call for candidates, y’all
… we can still fit in topics later, but by tomorrow would be great
jcraig: I have a suggestion
… we could have a `F2F miscellaneous` tag
… for bringing up older/smaller issues to talk through quickly in sequence
… direct touch, for example
… a bunch of old issues that fell by the wayside
jamesn: not a bad idea
… I’ll create another label for this
CSS: handing the a11y of anchor positioning
chrishtr: I took an action item for this issue
… I did follow up with Mason
… who led the effort to add the anchor positioning feature
… he said the suggestions in the issue from Scott and Sarah are worth pursuing
jcraig: Tyler on Webkit was looking into this
… considering `visibility: hidden`
… we may need to consider how things are hidden from the a11y tree
<jcraig> WebKit are considering this implementation detail wrt accessibility. We may need to tweak anywhere we're checking RenderStyle::usedVisibility to exclude cases where the thing is only visibility:hidden because of position-visibility.
keithamus: what’s the tl;dr for actually implementing accessible relations?
… is it a details relation?
jcraig: undecided, I think
chrishtr: it’s on the agenda because anchor positioning is about to be interoperable across browsers, so we need to make sure it’s accessible
… to answer keithamus’s question, it’s basically to follow what popover has already done
… maybe with specific ARIA attributes
keithamus: I think that’s fine, but are we to read the association from the defined anchor in CSS?
… it would be like a minimum/default details association?
… I assume that we’ll create the association when an explicit anchor reference has been created
… which seems fine
… but
… but because popover already does this, there’s nothing to do?
… would this conflict? Or would popover override?
… because you can have a different CSS-defined anchor competing with popover
chrishtr: yes, that’s a common pairing — so one would need to win
keithamus: this will also be an issue with interestfor
… because you’d have the combination of all of these
… that may be less obvious
… because I can imagine an explicit ARIA attribute should always win over implicit
… but popover and commandfor association would probably also win
… but they all set up the same details relation, I guess?
chrishtr: has the intersection between command and interestfor already been discussed
keithamus: no
… commandfor should always win over popover, I think — but now need to check Firefox codebase
… there’s a lot of work that needs to be done here to tease this apart
chrishtr: thanks for agenda’ing this pkra
keithamus: there is an explicit place in each of the browsers where there’s a known anchor
… and at that time, we just need to specify that it should be an aria-details relationship
… but one of the heuristics that we had for popover
… is that it is only aria-details when it *needs* to be
… to avoid redundant associations
… but with anchor positioning, that logic is not as evident
… because we’re talking about visual/spatial relationships
… but if everyone is going to pair anchor positioning with popover, then it won’t be so obvious
… is this even the right thing to do?
jcraig: neither of the HTML-AAM editors are here, and it’d be good for them to be involved
… this could be a good F2F candidate
jamesn: I agree
chrishtr: other reps will also be at TPAC, so I agree too
jcraig: if we schedule it for morning, we might be able to accommodate people not attending in person
jamesn: agree this should be F2F — who best to prep?
keithamus: I will
Lucas: before we move on
… I was implementing aria-details for interestfor
… there seems to be a timing window with when the details relationship is created
… and in my debugging, I’m not seeing screen readers convey that
jcraig: this is a perennial problem
… we’ll need to debug individually
… my suspicion is that SRs haven’t implemented yet
… some of these implementation chains go very slowly (web feature proposal, aam change, ua implementation, api change, downstream AT change), sometimes years
Lucas: for future reference, where’s a good forum for me to ask about this?
keithamus: the 1-second delay you mentioned...
… is that because it follows the interestfor delay timing?
Lucas: yes
keithamus: should it? Shouldn’t it be immediate?
jcraig: yes, we should do it immediately and let the AT decide when to present
Lucas: my understanding was that if you relate it immediately, the target may not actually exist in the DOM yet
jamesn: in core-aam, we have state and prop change events
… aria-details doesn’t currently have an event when it changes
… is that a problem for this?
… do we need to add a prop change event?
Lucas: I don‘t have an opinion yet, but I might next week
jamesn: it seems like this is just missing from the spec
… can we reuse EVENT_OBJECT_DESCRIPTIONCHANGE?
… rather than invent a new one?
chrishtr: that would be useful
jcraig: I’d want to discuss with other VoiceOver and WebKit engineers
jamesn: if we’re talking about using details, that is missing from the spec
… maybe people are working around this because they noticed it‘s missing
… we have to add that
chrishtr: someone should make an issue to describe this need
jamesn: yes, any volunteers?
Lucas: it was hard to pinpoint where the fault was
… after some time, if you have the element focused, it receives some ARIA details relationship
… the name isn’t changing
… none of the ATs read the name of the element again
… all AT would say “has details”
jamesn: yes, some props are meant to send a change event
jcraig: to help further your debugging, Lucas, with the xcode a11y inspector, you have to attach to the specific process
… since most browsers are multi-process tab, you have to attach to the tab
… and then you can sub-filter down
… at least you can confirm that the event is making it out of the browser to the platform
… and determine whether it’s being dropped by the AT
… in macOS
… but not sure about Windows/Linux
keithamus: I’m still hung up at relating this after a delay
… the node can be there in the DOM and a11y tree; it should skip the visibility checks
… I don’t know what the value would be to tell an AT user that there’s a relation *later than necessary*
jcraig: ATs often receive spurious notifications
Lucas: we can argue for the interestfor case to remove the delay
… but I think the problem exists regardless
… someone focused on an element could choose to create a details relationship and you wouldn’t be notified
keithamus: I agree with that
… it sounds like this came up because of the delay in visibility of the interestfor popover
… and that sounds like we could improve the UX just for the interestfor case
… but I certainly agree that we need to solve for the details event
Lucas: I wrote a doc for Mason and will continue working on this
chrishtr: thanks for the feedback, keithamus
jamesn: who will file this issue?
chrishtr: I will
… and I’ll tag Lucas
jamesn: anything else?
… I think we’ll just skip the last 2 things on the agenda
feat: aria-actions addition to the ARIA spec
Lucas: my understanding is that implementation was started last year on Chrome
… but there are still 4 points that need to be figured out
… I created a list of those 4 bugs
… that are actionable
… I wrote this doc because MS was interested in picking up the work
… so there’s been a bit of movement last week
… the document is internal
<chrishtr> filed w3c/
Lucas: we do have one public issue filed for discussion
… which I think will be coming up soon
… the other 3 are actionable and just internal implementation
… would expect the discussion to start again soon
jamesn: great news
… Jamie did a thorough review
… and the PR needs some care to proceed
Matt: I added some comments to the issue
… Brett @ Vispero and I had some concerns
… based on experience trying to get this to work with JAWS
… trying to get another listbox example added to the APG
… to help more clearly illustrate the concern
… it comes down to the requirement that the SR actually execute a click on the target of the actions
… create an actual click event
… what we’re discovering is that it causes focus
… and then if focus moves from the referencing el to the referenced el, then we’ve destroyed the utility of actions
… since the whole point is to keep a SR focused on the referencing el
… while you perform these actions
… so wondering how we can address that
… the click event had to do with protecting privacy
… but it’s getting in the way of the feature working in practice
jamesn: some of the use cases want focus to stay, but not all
… e.g.. moving focus to a dialog
… but I do appreciate there are many use cases where it would be a big issue
… even the destructive ones, then focus gets lost
Matt: how would we ever help people figure that out
… does the feature still have value with those limitations
jamesn: yes IMO, because there are use cases that can allow focus to move
jcraig: consider an example
… Gmail
… Gmail has these rows for messages, and if you hover it shows actions
… when you focus the row, these actions would become visible
… and could take a synthesized click
… in that case, the focus does not change
… these are secondary/alternative paths to do the same action
… similar to keyboard shortcut
… R for reply, etc.
… and so the goal of this is to give AT users the same shortcut
… and Gmail would be on the hook for making sure that focus doesn’t change
… there are all these examples where it would work as intended without a change to focus
… if you have actionable elements and they need to be focused because that’s the only way you would interact with them with a keyboard
… then they may not be appropriate use cases for this feature
Matt: your Gmail example is perfect
… because the SR has to click the star, for example, to important it
jcraig: I don‘t fully agree
Matt: the referencing element has to point to the target, according to the spec
jcraig: the details of the spec don’t require the SR to click
… what matters it that the click event is synthesized as far as the author is concerned