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: two new PRs. aria PR 2815 html-aam.
… implementation of what's been discussed.
… can we have reviewers?
aardrian: add me.
jamesn: core-aam fixes, aria pr 2808
spectranaut_: just a few fixes.
jamesn: one looks significant.
spectranaut_: it's actually a typo
jamesn: do we have more reviewers?
New Issue Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: first up aria #2817.
… distinguishing accessibility trees.
spectranaut_: fall out from web driver work.
jamesn: this sounds like a PR is needed to discuss?
spectranaut_: we need to discuss it more in interop.
… you can assign it to me.
… we can skip the next one.
… discussing them with jamie and joanie.
jamesn: the next ones are with daniel.
daniel: you can skip those.
jamesn: aria #2809. Removing the note on comboxes.
daniel: we should get to that before 1.3.
jamesn: right. The third note might need some adjustments afterwards.
… next aria #2807. describeFor, labelFor
aardrian: came out of a discussion on a11y slack.
jamesn: I'd have some concerns in terms of performance etc.
spectranaut_: might be.
jamesn: let's agenda.
… next mathml-aam #39
spectranaut_: I think people are working it out.
jamesn: I want to point out that chrome treats a with clickHandler as links.
… can we agenda?
spectranaut_: makes sense.
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
spectranaut_: there are a couple we should talk abuot.
… new PR for UIA testing. Very exciting. Thanks to Theo.
HaTheo: first one is a draft and I keep adding to it. Full support for properties, but also patterns and events hopefully soon.
cyns: I can review
HaTheo: this one (60533) is the foundation. After that it'll be more atomic.
jamesn: next PR 60504.
spectranaut_: I reviewed that.
… seems straight forward
jamesn: 60503 is next
HaTheo: this allows for flat trees to be created.
… it specifies when authors specify setsize etc. What's difficult is to create a hierarchical tree in the browser accessibility tree.
… I gave an example. Is this one expected to create a hierarchy.
… I posted it to the aria PR 2091
sarah: I'll double check.
HaTheo: it seems they come out flat.
jamesn: can we add this discussion to the issue for the record?
sarah: will do.
HaTheo: the two points: is it valid and is it hierarchical
sarah: I'll retest my assumptions and comment.
jamesn: next 60502. We can skip
… next 60490.
spectranaut_: I've reviewed.
jamesn: next 60477.
spectranaut_: we can skip that.
jamesn: next is 60410
cyns: I'm working on a gap analysis.
spectranaut_: these were converted from joanie's manual tests.
cyns: I'm working on the html-aam tests so there'll be overlap.
jamesn: next is 60401
giacomo-petri: it's filling the gap we discussed last time.
spectranaut_: I'll review.
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: any topics?
… we have one scheduled?
Matt_King: we have one to be scheduled.
… posinset etc for menus.
jamesn: let's try and schedule this.
Matt_King: this needs to work for Jamie.
Tyler: would we need an apple screenreader user?
Matt_King: that would be good.
Tyler: I'll check internally.
aria-actions: handling focus when actions are synthetically triggered
jamesn: where are we?
Jacques: we discussed it yesterday. I think jcraig's input is needed.
Matt_King: as an update: we're looking at the necessity and feasibility of various options.
… we've ruled out the browsers-don't-do-anything option
… we discussed a couple of options for browsers and AT to approach this.
… with more experimentation we can hopefully gain more insight.
sarah: I could confirm that UIA cannot differentiate activations. So that would require UA heuristics.
… but we all have things to look into, I think.
jamesn: do you have a timeline? Will it slip out of 1.3?
sarah: do we need to solve this before the rest of actions goes in?
… esp. since it falls outside what's been spec'ed so far.
Matt_King: what are the acceptance criteria?
sarah: I think we need to solve if before the first AT implementation ships.
Jacques: I think voiceover and safari already support it?
Matt_King: I don't think it works in practice yet.
Jacques: I meant chromium.
sarah: safari has it behind a flag.
Matt_King: also on ios?
sarah: I don't think so. No way to set flag on ios
tyler: I don't think there's tech previews on ios.
sarah: can the non-specific-to-focus events go into 1.3?
jamesn: I think we specified in our working method that we will ensure AT implements new features.
… so that we no longer create orphaned ARIA features without screenreader implementations
Matt_King: my concern is that if it's in the spec but you cannot use it in practice without solving this problem then it creates the same kind of confusion.
<spectranaut_> we don't have any reference to AT implementions in our process document
<spectranaut_> https://
Matt_King: to me it's a big important feature. esp. on mobile. So I'd strongly like to suggest we get it to work the way we want it to work.
jamesn: it's not in the process?
spectranaut_: yeah, just UAs.
Daniel: how much would an author implementation change after these additional changes enter the spec?
… that would be a concern from the process pov.
Jacques: I'd expect the UA or AT behavior to change, but not authors.
Matt_King: I think that's right. No author must/should would change.
… just a matter of whether or not an author would be able to observe whether or not their code is doing what's intended.
… so they wouldn't have a way to test.
Jacques: but it wouldn't change in these scenarios?
Matt_King: correct.
jamesn: what are the next steps?
sarah: The answers to all of these questions are behaviors that are traditionally not in the ARIA spec.
jamesn: we've talked about notes for AT implementors in the spec.
… if we have something for that, that would be the right way, I think.
<siri> +1 what is use of having aria attributes if they are supported by SR. aria is for SR users
Matt_King: we shouldn't create more technical "spec debt" that impact a new AT or UA, making it harder for them.
… feels like there should be some UA musts or shoulds related to this.
… two solutions we're discussing are that way
… and we're not sure about the other one for screenreader-focused option.
jamesn: if you all working on it are comfortable, that's good. Do we need more meeting time or do you need separate meeting time?
Jacques: we can drive this forward separately but we need jcraig to get buy-in.
Tyler: I think jcraig is the right person.
sarah: I'll ping him.
… while we work this out, the group could think about where to put this information.
jamesn: we have spoken about having notes on expected screenreader behavior.
siri: can we leave a warning note?
sarah: not needed, we have implementations. It's about this specifci behavior.
update UIA mapping for maxlength
HaTheo: there is confusion how this is mapped to UIA. The maxlength is part of a range.
… it's used in a unconventional way.
… I just wanted to confirm that it's an approved way to ensure it works.
… I reached out to scotto. There was push back from firefox.
sarah: it's been a while. The properties refer to the value and no the text length.
… as I recall, the range value pattern was the specific workaround we talked about.
… I'll double check my discussions with Doug.
… I think this was all intentional.
HaTheo: maybe we can update the UIA documentation to allow other browsers to have an easier time to understand.
jamesn: would be a link to issue or PR discussions?
Matt_King: I think there's precedence for that.
jamesn: maybe not as much in html-aaam
sarah: i can also try to update the docs site.
jamesn: that'd be great!
Review roles with name from author and clarify expectations
jamesn: let's try some more from this old issue.
… recall that we just discussed heading specifically.
… the underlying problem of name from authors with content causes issues, e.g. with screenreaders.
Matt_King: in the past, we've prohibited naming on certain elements, e.g paragraphs.
jamesn: channeling my inner jcraig, are we overlooking some edge cases
Matt_King: do we want to approach this one element at a time?
jamesn: I thought we don't want to approach them one-by-one.
… but if there's a good reason, sure.
Matt_King: the harder they are, the more important to go one by one
spectranaut_: I think people wanted to treat this cohesively. We established last time that this starts with research on what happens when you put names on roles we want to reconsider.
… so I think research is the next step and I was wondering if someone is interested in that task.
aardrian: just to add: I have people getting questionable guidance to add aria on everything. So in an adversarial situation, pleasing other tools.
Matt_King: to get research, I think one element at a time seems best.
… headings seems particularly difficult.
… I wish for a firm solution - to not label but label conten
scotto: I've done some research. I've filed bugs, reported issues in AT etc.
… I feel this is the problem with the permissiviness approach. Then we end up with things like this where things are broken.
… then we try to compensate with more warnings and notes, making things more difficult.
… I can take up the research again but I agree with Matt that we should take this on.
… e.g. voiceover handling this on MacOS but not iOS.
… we need to be more explicit with the expectations.
jamesn: so we need more volunteers?
scott: I will redo my old research and post updates.
<aardrian> I can help scott with research too
jamesn: thank you so much.