Meeting minutes
New PR Triage
jamesn: no issues to triage?
… anyone?
New Issue Triage
jamesn: starting with June 26th
… 3 new issues
… first is editorial
… allowed accessibility child roles on performance
… needs someone to look at it
… any volunteers?
jcraig: I’ll take it and add context
… it’s not that an author should avoid too many elements, the point is that if we allow infinite nesting then we’re forcing the web engine to do that computation all the time
… the note should just be for authors to be reasonable
jamesn: next is aria#2569
… should label override content
… briefly discussed in WG call
jcraig: I can also give context to this
… what if there were something deeper in, like image title attribute, etc. what happens if you put an aria-label at the top, does it cascade and cause children to become presentational?
… or could there be a smarter hybrid
aardrian: isn’t it limited to certain roles?
<Mario> w3c/
aardrian: my kneejerk is that this is about scoping model and other things correctly
jcraig: stevef’s article isn’t about model, that’s just my secondary consideration
… please read and comment on the issue
jamesn: this sounds like a great TPAC candidate
… F2F
jamesn: last one is aria#2567
… should toolbar role be widget instead of doc structure
Mario: recommend changing category
… toolbar is really a region, a shortcut for menu
… a toolbar has to manage the focus for its sub elements
… toolbar should be region
… when you put focus on a button in a toolbar, then NVDA switches to reading mode — not good
… I normally can’t use arrow keys to navigate to other parts of the toolbar
… manually have to change back to navigation mode
… maybe we should change the category in the spec
jamesn: I seem to remember the reason that toolbars don’t state that authors MUST manage focus is because Apple does this differently
… and that’s why this is categorized the way it is
jcraig: I don’t recall that
… but it’s very possible
<spectranaut_> found this old issue: w3c/
<spectranaut_> Why is toolbar as a document structure role? #713
jamesn: maybe we should do some digging to determine why it’s categorized this way
jcraig: toolbars in iOS did get some special handling
… oh toolbar, yes I remember — I was thinking scrollbar
… at the time Windows toolbars were very focused on keyboard navigation
… kind of an exclusionary set like radio buttons
… so managed focus was almost a requirement for this
… but we chose MAY because no toolbars in macOS were managed focus
… we have “segmented controls”, which are kind of like radio buttons
… there’s “pop up button”
… a few other things that would conflict with the idea of a toolbar always having managed focus
… so I think we need to keep this as is
jamesn: maybe we can investigate it more, since it definitely causes a problem with NVDA switching modes
… but NVDA could decide to change their behavior?
jcraig: here’s a strawman: could we give some explicit flag for managed focus true/false?
… I think we may have considered and dismissed that in the past
jamesn: yes, we have
… could be worthwhile to investigate
… there was an `aria-interactive` idea that might be related
… proposed as a more generic thing
… we should start out small, and expand later on
aardrian: my chaos approach would be let’s just call it a toolbar
… aligns with many expectations
… and aligns with Windows
… and since Apple has different UI, it just gets documented
… if enough implementations want it to be a toolbar, then we just document exceptions
jcraig: the problem there is that we’re depending on is it a Windows user expectation or a Mac user expectation
… the author MAY or may not manage focus
… the technology would’t do that by default
aardrian: I was surprised to see that it’s a `document`
… but yes, that’s a good point
Mario: could we do something more?
… some more discussion
jamesn: if someone comes up with a proposal, then we can discuss that
jcraig: I have a proposal
… consider moving this to authoring practices repo
… and documenting that it’s reasonable for an author to manage focus on a toolbar
… and VO on Mac can handle that if they do
… but it’s also reasonable to not manage focus, to simulate Mac-like experience
… then the question is what do we do for Windows screen readers?
… or Linux
… either way, reasonable to have a separate documented page about this platform difference in authoring practices
sarah: quick question about cross-platform difference
… I’ve done a lot of cross-platform user studies
… never seen VO users have an issue with managed focus
… it doesn’t matter since they’re using VO commands
… how big is the actual impact on Mac VO users
… how does it’s categorization matter?
… to me, `widget` does make sense
<spectranaut_> +1 to try to make the spec make authoring sense
sarah: does moving it to a `widget` role have any bearing on what authors should do?
jcraig: good point; no objection to the taxonomy change as long as it doesn’t change the authoring requirement
sarah: another example
… in Windows, you tab between menu items
… even in Fluent UI, we had this discussion
… do you tab between items
… role had no bearing
jcraig: we would have to change the def of widget, if we moved it there
… this would not be a discrete UI object
<scott> a row is a widget.
jamesn: `widget` doesn’t sound appropriate
… for this multiple use
jcraig: especially nested managed focus widgets
… managed focus toolbar that contains a managed focus radio buttobn
Mario: JAWS understands it as a managed focus widget
… and you can automatically use arrow keys
… but NVDA doesn’t
sarah: yes, I think both JAWS and Narrator agree on that
… and I think NVDA probably should too
… maybe should bring this up with them independently
<scott> magic. magic is in narrator
jamesn: plainly this is not a simple change
… if someone wants to come up with a proposal
… then we can review and discuss
… just remember platform differences
jcraig: Mario, the scenario you’re talking about, is it simple toolbar buttons?
… because we’re considering more complex patterns
… is the concern just for a one-level deep flat toolbar?
Mario: for example, in a horizontal toolbar, you need to be able to use arrow left and arrow right to go to every child
… or in a vertical, to use up and down
… it’s managed
<scott> agreed. even changing the spec would still mean nvda would need to change
<scott> just changing the spec wouldn't do anything
jcraig: I agree with sarah that the issue should be raised with NVDA
Mario: I’ll file an issue with NVDA
WPT Open PRs
jamesn: anything new?
jamesn: wpt#53676
Rahim: I had a question on this
… keithamus, you raised this
… are these crash tests reliable?
… questions around availability of a11y tree relative to DOM load event
keithamus: yeah, it was jteh who raised this initially
… and you’re right
… the crash tests just wait for the load event
… and if the page is still running, then it shuts down and assumes a pass
… but the way Gecko works
… we have an out-of-process a11y manager that handles all the a11y logic
… and communicates via RIC
… fully asynchronous
… so it’s problematic
… so crash tests aren‘t conclusive for Gecko
jcraig: right, is it crashing the main process, or the a11y process off the thread
… in the results, Firefox is passing even though there is presumably a crash
… is there harm in checking this in?
… I think no, it’s just not effective
keithamus: just the false sense of security
… the a11y process may well still be crashing
jcraig: should we raise a new issue on Firefox?
… if this out-of-process crash happens, it should crash the main thread?
keithamus: yes, there’s something more to pick at here
… around WPT crash tests
… there are others that do async operations
… it may well not correctly flag
… not just a11y code
… the fact that it’s waiting on DOM load; an eager event
… we need to address that in some capacity
… maybe script can tell when a test should complete
… or add a new mechanism for waiting
jcraig: I’m gonna add you as a reviewer
… would you reach out to other crash test writers?
… that did exercise these crashes
… in the a11y Slack
spectranaut_: do crash tests actually run with a11y turned on in the browser?
… and I would also have to talk to those same people
jcraig: presumably, that’s what caused the crash
spectranaut_: but on the server
jcraig: understood, I don’t know
keithamus: there’s a blurred line; it could touch code in the DOM
… or it could turn on the a11y engine
spectranaut_: with Acacia testing system, we *will* be able to write a crash test
… or at least some kind of failure
jcraig: it’s possible some of these are so old that they were written before a11y was decoupled from the main thread
jamesn: do folks know what they’re doing with this one?
spectranaut_: is there an issue for it?
… if so, assign me to that
Rahim: keithamus, is there a way we could run this crash test with a previous Firefox build?
… to see if it’s detected
keithamus: I don’t know
… I’ll dig up the bg
… we might have a separate test for that
… which might make this redundant
… if we’re targeting a crash that happened in Gecko, I imagine there’s a test in Gecko’s suite
jcraig: keithamus, would you take an action to reach out to Aaron, Tyler, and spectranaut_
… to see about improving reliability and validity of a11y crash tests?
keithamus: yes
spectranaut_: we still have to solve this problem in Acacia
jcraig: you can do it if you call computedRole or computedLabel
… in WPT if there were a way to show devtools, that could be an option too
keithamus: should look into webdriver as well
spectranaut_: webdriver is kind of in maintenance mode
… but wouldn’t be opposed to changes
… and this could be motivating
jamesn: do we have a direction?
keithamus: let’s say yes
… we’re heading in *a* direction ;-)
Rahim: the broader issue of writing WPT tests
… I’m still working on case sensitivity tests
sarah: also
… NVDA does switch modes for toolbars, so no need to file an issue
Deep Dive planning
jamesn: any plans? any one want to plan one?
aardrian: next week, no?
jamesn: yes!
… layout tables
… great
… if you want to plan another, please add it in GH and add the tracker
… or email the chairs
Registration open for TPAC 2024 in mid July
jamesn: registration opens in mid July
… in Kobe, Japan 🇯🇵
… tentatively scheduled meetings
… still open to change
… Thursday we have one cross-group meeting
… we’ve managed to not clash with CSS so far
aardrian: I may not be able to attend in person, how difficult would it be to run sessions remotely?
keithamus: people have done it
jcraig: we can schedule them for convenient times
Daniel: we have plenty of time to shift our agenda
jamesn: realistically, we’ll schedule session for remote attendees in the morning
jcraig: and logistically, rooms are set up pretty well now
spectranaut_: everyone, go use the last 10 minutes to go review issues!