Meeting minutes
New PR Triage
spectranaut_: aria 2698 from sideshowbarker
scott: I can take this one.
… it came from a lot of fixes in validator.
… the linked issue needed some conversation
… I added myself as reviewer.
spectranaut_: thanks.
pkra: I can review
spectranaut_: next aria 2697 also from sideshowbarker
… I'll add myself
WPT Open PRs
spectranaut_: doesn't look like we have anything new.
jcraig: I merged the PR from giacomo. Otherwise all good.
core aam roles known entries w3c/aria#2682 [from agendabot]
<jamesn> github: w3c/
giacomo-petri: related to the WPT, I had a question about UAs not following the suggestion on presentational children.
jcraig: the PR I merged was on SVG. So nothing happened on that.
spectranaut_: we'll agenda the other one for next year.
spectranaut_: David Tseng has been adding the core-aam mappings for Android.
… this included frontmatter and a bit of TBD entries
dtseng: over the past year there's been a renewed effort to enhance and extend the android AAPIs
… there is more work ahead. The initial round is coming to Android SDKs
… the PR adds the initial parts of this, in particular how Android tackles roles
… it's mostly mapped to existing Android widgets.
… we have mappings for some existing APIs which I'll try to add. Some more hopefully incoming.
<spectranaut_> https://
spectranaut_: thank you! FYI for everyone, the PR has a deploy link but the links need adjustments to reach the child specs
… the PR has some reviewers
mattking: maybe the correct links could be added to the top card?
Daniel: yes, I need to get to automate that.
<jarhar> the whatwg/html spec has this when you create a PR there, it automatically edits the PR description and adds links to the previews of the modified files
spectranaut_: are there more reviewers?
… is there a particular kind of feedback you're hoping for, david?
… My assumption is that you're the experts and this documents the status quo and should be merged.
dtseng: review would help, using the experience of the ARIA group.
… also on the API level.
… I think we can discover a lot from the review.
… I want to mention that some things are trickier. E.g. accessible name doesn't have an equivalent. We have content description, labelledby etc. We have discussed this internally but having insights from this group would be very useful.
… all the tricky things that this group has dealt with will help. E.g. overriding, concatenating or not
Add namefrom: heading. w3c/aria#2650
<jamesn> github: w3c/
spectranaut_: we didn't get to finalize this at TPAC
… in particular with Feedback from Jamie Teh.
jcraig: I think Jamie is right and we need to think about it some more.
scott: what was the issue?
jcraig: essentially dom mutations.
… for performance and author reasons this poses some difficulties.
scott: right. Jamie mentioned DOM vs accessibility tree as well.
jcraig: some of that leads to mutations as well.
feat: aria-actions addition to the ARIA spec w3c/aria#1805
spectranaut_: since Sarah is not here, we should skip.
Expose implicit ARIA semantics (browser-defaults and ElementInternals) w3c/aria#2663
<jamesn> github: w3c/
jamesn: wondering where are we lining up on this.
… I'm not sure we have good path forward.
… we had come to 2 approaches.
… this seems to be a fundamental blocker for testing tools.
<jamesn> w3c/
giacomo-petri: server side it's not so much a problem
jamesn: it's definitely a blocker for axe
spectranaut_: I'm not sure how to move this forward.
jane: do we need the relevant people on the call?
jamesn: I think the arguments are laid out on the issue, e.g. axe and everything that uses it
… I think there's always encapsulation problems
… which get in the way.
Jacques: solution 2 looks nicer to me
… to advocate on Ben's behalf
jamesn: I suspect in plain JS this will remain a problem. In an extension it's not problem but it remains.
jcraig: the way I understand this, it's not technically a web compat issue since it's never been solved via a public web API.
… there's webdriver etc but never a public DOM API
… ... so it feels to say it's breaking axe seems very strong.
jamesn: setsInternalElementRole is a relative new feature and it causes this problem, no?
jcraig: There are other existing scenarios where Axe-Core can't detect the real role... I just want to make sure we're stating the problem accurately. This is not "breaking" Axe-Core. This is a new web feature that can't be tested in client-side code, and client-side testing tool devs want to solve that *new* problem.
… but it's a new feature
… we've had other requests, e.g. opening up the accessibility tree. And there were concerns (performance, security etc).
… so the second part is just not feasible. We cannot let JS in general inspect everything
… but in a test environment, like webdriver or audits, this is possible. And I understand that e.g. axe would like something in plain JS
… I know there are arguments around elements internals that it's problematic in various ways
scott: I agree with both James and James. I think it would be useful to determine the role. But we know it's difficult for good reasons. The computed role changing is a problem
… we need to acknowledge this limitation
jane: I agree it's a new feature and thus not breaking anything technically but it seems it would create a lot of work if switching to custom elements cannot be tested properly. This is a problem worth fixing.
… but it's unclear how the options will help. I understand that breaking encapsulation is a problem but it seems theoretical with a real impact on accessibility of websites.
jarhar: chromium has had computedRole for over a decade. It's interesting that it's so old.
jcraig: is this a public API?
<jarhar> w3c/
jarhar: it's behind a flag.
jarhar: it seems heavy but it probably works.
Jacques: this requires a flag and restart?
jarhar: I think just the flag.
… the flag is "computedAccessibilityInfo"
… it might be very very slow right now, starting/stopping the accessibility engine.
cyns: CLI or runtime?
Jacques: it's a runtime flag
cyns: people who cannot use fancy flags (like locked down browsers) won't be able to use this, right?
jcraig: right. Would need an admin.
jane: even in those environments exceptions can sometimes be made for testing etc.
jcraig: and presumably you can deploy this in CI environments with a command line flag. Looks like perf would not be good, but determinable on a case-by-case basis. That's better than hanging every person's browser to solve a testing use case.
<Zakim> spectranaut_, you wanted to ask about proposal 2 specifically -- element.implicitAria
spectranaut_: I wanted to hear people's thoughts on the implicitAria proposal. It seems more lightweight.
… I wonder what testing people would think
… but there doesn't seem to be feedback on that.
scott: I think both approaches would have some benefits at least.
… this stems from the allowed-roles in aria-in-html. That's a really good basis. But sometimes setting a rule it breaks something down in the engines and it's really hard to tell where the problem lies.
<jarhar> more context on the code i found: https://
scott: knowing the implicit role really helps but even then it probably still only reaches "90% sure".
jamesn: any of this would give rules engine a way to write some rules instead of having no idea what role a component has going on.
giacomo-petri: I think the problem is like not knowing what the explicit role is. If you set role=button on a button, if you know the implicit one is region but the current one is button you can raises an issue but it's not relevant.
… so you can raise it but you don't know if it's accurate.
mattking: I think that's a good point. If you knew it's a button, you could raise an error on focus. But if it's a region, you wouldn't catch that.
siri: wouldn't the computedRole give the end result?
jcraig: assuming it works, yes.
mattking: we're talking about the implicit role though
jamesn: aren't we focused on custom elements which do not have implicit roles
giacomo-petri: yes but if you change the role, you still don't know.
jamesn: you're setting it though, right?
giacomo-petri: but if you change it later?
jamesn: you'd set it the same way and get it back the same way?
spectranaut_: @giacomo-petri, it would be great to have an example.
<jamesn> github-bot, end topic
spectranaut_: FYI 2 week break
see you on the 8th!
<Priti> quit