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: PR triage
… first up aria 2821, editorial clarify def and term
theo: you can add me
jamesn: next an aria.js one
… then a css-aam, still in draft.
Update ARIA in HTML Recommendation with proposed amendments based on AC questionnaire results
jamesn: we had one suggested change from review.
… minor changes from google.
Daniel: one issue is still open, one has a PR. My suggestion would be to merge the PR and send it out.
siri: I can organize review.
scotto: the PR addresses both issues. I didn't merge because there was no response so far.
jamesn: we should do best effort to incorporate them but they're suggestions and the reviewers have stated support.
Daniel: we can send it as is or with changes from review (in terms of process)
jamesn: if they're easier to merge, we can. If not, let's move on.
Daniel: yeah, the process is the same for living standards.
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: what needs attention here?
tyler: one is mine but there's not much to talk about it yet.
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: any updates/
tyler: I had messaged James Craig from previous discussion
jamesn: I'll get in touch with others
Request for aria-describefor and aria-labelfor as ways to set accessible description and label in the inverse direction
jamesn: I like the idea but I'm worried about browser performance here - though I'd defer to experts there.
Rahim: is this trying to get around problems of lack of control of third party code?
… e.g. libraries or other authors.
<jamesn> "There are sometimes scenarios where you don't have control over the base HTML of a component (for example, with 3rd party code) but you control the HTML around it. It'd be nice to be able to provide names and descriptions for components that you don't have direct control over.”
Rahim: if you control the code, then the existing methods are enough, right?
clay: if you didn't have access, how would you have a stable ID to point to?
<HaTheo> is this to stop double reading?
aardrian: I think the experience is that often enough there is stable third party code. Otherwise agreed you can't.
sarah: often you can pass props into components and ID is more common than aria attributes.
… so if it doesn't impact performance, it seems nice.
jamesn: I'm hoping the APIs should be able to reuse the current connections, in reverse.
Matt_King: thinking about how to spec this. Since we have label and labelledby etc. might make it complicated. Do they take precedence over the others? Or never? Or combine them? In which order? Seems complicated.
Jacques: adding to matt. It doesn't raise red flags in terms of performance for me but complexity is added which is ok if it's useful.
scotto: seconding the above. I understand the need. But since it hasn't been there from the start, I'm concerned how to shoehorn it in.
… I like it and yet concerned.
Rahim: is this just scoped to naming?
jamesn: yes/
Rahim: ok I think this will take more thought.
giacomo-petri: the specific attribute name might cause typos.
jamesn: right. there was another comment on a similar issue.
scotto: I wonder if we should reconsider the naming by encapsulation we let go.
… encapsulation, you could use aria-owns to move things around.
… encapsulation would then do the same.
jamesn: to recap, if this doesn't have performance problems then there seems some general agreement that this might be a good idea but there is concern that integrating it into existing naming mechanisms might be tricky.
Accessibility mapping of <a> element
jamesn: we triaged it last week.
… it seems a elements do more in mathml. my view is: do what you like, map it accordingly.
… are there any other thoughts?
tyler: I looked briefly. It seems that sometimes it's a link and sometimes a table row.
… I might be wrong but VoiceOver will treat links as atomic links.
… I'm not convinced that by just calling it a link it can't contain complex layout.
jamesn: can you try to find out?
aria-actions: handling focus when actions are synthetically triggered
jamesn: we had a question from previous comments.
… from james craig to sarah.
… do we need more right now?
sarah: I meant "we" as in the people in the discussion.
Jacques: agreed.
… we also have the notes from the call with jamie.
jamesn: ok. So we can move forward?
Jacques: yeah I think there's nothing new right now.
sarah: I will have to follow up.
Jacques: did we have TAG review?
Daniel: that usually happens during review for the next editors' draft.
jamesn: right, that's weird since we no longer add things to the draft unless we have support for 2 and 1 active implementation.
Daniel: right. We should update the process.
Matt_King: we should try to do this before implementers get too far. Right now we're trying to find out what's feasible.
… In particular to move forward our consensus.
sarah: agreed. Could we have TAG review anyway?
Daniel: I think we can do that.
jamesn: could TAG review a PR?
Daniel: not sure but other review groups might
Jacques: I hesitate to say we're just experimenting. Firefox has shipped, we're trying to get it done for Chromium.
… I think we have consensus on what's author-facing. The last piece is user facing.
… Do others agree with that statement?
… then we can focus review on that.
Matt_King: I agree. But I'm not sure how well specified it. We have author requirements but the spec doesn't say "here's what we expect for users".
… that makes it difficult to say what success looks like.
Jacques: my thinking is that with the API as is right now, authors can associate actions. The contract is that screenreaders should take this into account like primary actions such as context menus.
… how specifically doesn't concern the authors as much?
… arguably a bit handwavy
Matt_King: as author you need to know what the feature will do and what it will enable.
… people are basing it on iOS behaviors that people know. If the results end up differently, then it might confuse authors.
sarah: I somewhat disagree as well. The discussion has moved to "screenreaders should do it". Even if it moves to user agents, then it'll be weak enough for browsers do what they want.
… I don't see it changing for authors.
… I think regardless what happens to focus you still want to do it. If users know there's an action they will likely have a method to query those actions.
… I don't see how the particular outcome of our discussion influences authoring.
Matt_King: I think it still might.
sarah: it will still be more accessible with aria-actions, no?
Matt_King: if you can't achieve a usable interface with actions, then you'll have to change the design.
sarah: right. right now we have semi-hidden keyboard behavior that's not surfaced easily.
… and that's not great.
Matt_King: if the outcomes are too different across platforms, it might prevent predictable results for users.
Jacques: could you give an example for this divergence?
… aria actions will provide users with information on those. Authors won't care how users interact with those features. They'll get there somehow.
Matt_King: divergence will make it more difficult though. Divergence is already a problem across platform. So is unpredictability .
sarah: could we come up with an example?
Matt_King: if activating the action in Apple environment it allows you to activate without moving but on windows you're moved to the element and have to move back as user, then that's a divergence. If the result of performing the action is unpredictable then we have a problem.
sarah: right. that doesn't seem like an author concern. Obviously for users it is a difference. But my opinion on the quality as author is somewhat irrelevant.
… it seems more about making good UX for screenreader users.
Daniel: an example we've mentioned is a product cart. You want to add multiples of the same item.
… it seems down to an AT decision how they want to handle that.
… but I'd hope we have enough in the spec to clarify such interfaces. In iOS, you have to tap it again but with windows screenreaders it's more painful.
… but I'm not sure who needs to remediate this kind of problem.
… but clear guidance to do it predictably is important I think.
Matt_King: doesn't it matter to authors where the focus is moved after the action is triggered?
sarah: the focus will fire, right? It will be the same whether AT or user or UA moves it back.
… even if screenreaders do it differently, as author you get the event and you know where focus is and you respond.
Matt_King: from a product team perspective who want to deliver a high quality experience, having different behaviors, procedures and outcomes are a problem.
… like any other web platform feature, if it behaves differently it's not interoperable.
<smockle> w3c/
Matt_King: when we're adding new features we should aim to allow users to get the same fundamental behaviors. Of course AT should customize the presentation but the basics should be the same.
Jacques: Just to repeat Jamie's point.
… about racing conditions.
… this seems like the most concrete concern around that.
… e.g. if a user removal fails, then focus might move to error banner. If it's done via actions, then it's unclear if users end up on such an error banner.
sarah: I think that's why we want to see if the AT solution is possible.
… on platform differences. If we do it in browsers, then that must be standardized. But if we do it at the AT level, then it's not an interop concern. The way screenreader triggers focus already changes not just by platform but users and their settings. That's always been an AT concern.
… not just screenreaders. The web platform needs to handle that so that authors can observer where focus moves. But beyond that it's hugely diverse.
… even just moving the virtual cursor can move focus or not. And that impacts authors a lot.
jamesn: since we're coming to the end, it seems we still have fundamental disagreements.
Matt_King: I'd say we primarily need more documentation as to what should happen.
jamesn: how do we make that happen?
sarah: I do think the question is do UAs or AT handle focus?
… for UAs it's more normative. For AT it would be a note?
… if the race condition shows up in practice, then we need to decide.
… and screenreaders can still ignore it.
tyler: I think the race condition is a realistic scenario. I think we can avoid what Jamie's point 4 has.
… maybe both UA and AT can
sarah: I think so, ATs get the focus event.
tyler: true.
jamesn: do folks need to get together outside the regular meetings?
sarah: we need to figure out whether the race condition is a real problem.
… I'm working to make some examples.