Meeting minutes
New PR Triage
WPT Open PRs
jcraig: no new ones since last week. Just one possible blocked wpt. It's blocked by the ARIA PR.
spectranaut_: giacomo could you follow up once the comments are addressed.
spectranaut_: I'm waiting for reviews on the WPT extension for AAM testing.
… any help getting reviews in would be appreciated
jcraig: keithamus could you review the third PR?
keithamus: will do.
TPAC planning
<jcraig> web-platform-tests/
spectranaut_: reminder to open issues, flag issues for TPAC discusison
… chairs will start on the agenda soon.
Custom Elements with Button Activation Behaviors
<Jacques> Custom Elements with Button Activation Behaviors - w3c/
Jacques: this is a Microsoft proposal to bring to WHATWG. We are looking for ARIA WG input on this.
taylore: the basic question is: can we ship something so that a custom element can have commandFor abilities?
… i.e. without focusability, default aria etc.
… would this be ok from an ARIA perpective?
… we heard from design systems that they are interested in the ability to add submit button type or commandFor easily onto custom elements.
… we thought it might help improve customized built-ins but then realized that noone was really asking for ability for custom element to have all button elements. More about button type etc.
… most of the time these power-users only need limited features.
… so our feedback had also popover/commandFor.
… two package: A and B.
… A is the first code example in the issue
… static to opt into button behavior
… B is the second one. Focusing on individual abilities, e.g., commandFor.
… then authors still have to set aria attributes and focus management.
… main question: are there strong feelings about proposal B?
<melsumner> I feel like WCAG is pretty clear about the requirements for interactive elements, so I'm kind of confused by this issue
chrishtr: seems like option A is a safer default, providing things that are likely useful to users.
… what are the drawbacks for power users?
taylore: main cons are form association and default aria. If authors added button behavior but didn't want button, they would have to additionally override.
… form association. feedback was that people didn't like how native behavior behaves.
chrishtr: was it mainly power users not wanting form association?
<spectranaut_> ack +
dandclark: with whatwg, we got concerned that we were bundling too much with this proposal.
… so it seemed ease of use is less of a concern with element internals. More the focus of finding the most minimal set of features to get commandFor to work.
… that's why we're hoping for feedback here. If button behavior without full behavior is problematic, we'd like to hear it.
scott: I think if it's not exposed as a button, we've failed. E.g. expanded won't be exposed if role is not button.
<melsumner> +1 Scott
scott: I don't think screenreaders would allow activation if it isn't focusable.
… I know I brought this up elsewhere but to repeat here: option A is doing the right thing. Why make authors do the same extra work for a button if we want to make it easier for them.
… but I don't feel the same with form association.
<Zakim> jcraig, you wanted to discuss the lack of homogeneity in "a11y folks" viewpoints with regards to premissiveness and to discuss the misconception that AT projects are static and that asking them to update is not a dealbreaker
<scott> yes sorry. meant to also say +1 to what chris was saying
jcraig: I like the idea of making it more accessible by default. The argument that a framework developer will more likely modify it to their needs is a strong one.
… on the idea that "the accessibility folks tell us not to do this". I don't think it's as homogeneous as that. If I try to channel Mike, he'd probably second Scott. I'm more on the flexible side. iOS is a good example of how flexibility can help, e.g., mixins instead of hierarchy.
… to some degree other platforms have similar flexibility.
… I think there's also a misconception that ATs not supporting something now means we cannot move forward. Maybe some OSs are more difficult (different APIs and teams). To bring it back, webkit supports commandFor proposal. It improves authoring. There's a downside that especially new authors may not yet know that they need to do more. The closer
we get to primitives, the easier it is to repair such mistakes.
… it's easier to make something focusable rather than remove focusability.
sarah: a different point of view. Just in one week I see even experienced developers not knowing enough about these things, maybe doing low-level stuff but using them the wrong way.
… people so often think about behavior only when they can perceive it.
<melsumner> +1 Sarah
<front-endian-jane> Yes, please jump ahead of me jcraig
sarah: so if they use commandFor they are confused that other behavior does not come with it.
… I don't think it removes flexibility to option A. Authors can still adjust.
<Zakim> jcraig, you wanted to respond to sarah, can I just the q Jane?
jcraig: clarifying question: my intention with defaults + override comment was that our feedback from engineers is that the more the requirements are the harder it is to go back, avoid breakage, increase testing , ultimately creating larger changes than otherwise.
sarah: yes and no. We saw some of it when we added a lot of accessibility stuff. Yes, when it forces authors to make a lot of changes on their end. No, when our changes are purely internal. Nobody cares then. Authors can still set the role when we have a default.
front-endian-jane: I've also seen more interest in fine-grained control. But most people I talk to don't know enough about accessibility. They just grab a div and make things. If we give them something like commandFor they will not know to do the rest
<jcraig> but it will be easier to retrofit without side effects, right?
<melsumner> Need more specifics about what can't be built, IMO
front-endian-jane: while option A does seem very full, we can still go for more fine-grained control.
<jcraig> (I do acknowledge the points are valid though)
scott: to clarify my earlier comment. I do appreciate the idea of primitives. I'm primarily arguing for a good default. Without any other changes, e.g. to AT.
… I think this should be a default role of button, then it just means more work for developers.
… maybe it can be expanded to other roles but that's good in the future
… I probably say, form association is not necessary by default.
<jcraig> scott, how to "unset" the button role if you apply it to an html-native role?
<melsumner> type="button" ??
scott: I do think it should be focusable by default. Then developers can still adjust tabindex and change roles.
… and if there are problems, we can move forward there.
BGaraventa: I think AT have a long history. Trying to make a role do multiple things, it can be very confusing for users.
… I would say a default button role is good.
<Zakim> jcraig, you wanted to discuss macOS "keyboard navigation" vs "the new version of FKA" and to ask scott how to "unset" the button role if you apply it to an html-native role (abbr popover to add on from the FKA contet)?
BGaraventa: and then extend from there.
jcraig: I wonder how you would unset the defaults, e.g. focusability. We have the concept full keyboard access. Just because something has a certain primitive, doesn't have to mean it loses the usefulness in some other way. That's what I'm thinking of when I spoke about AT being able to change behavior in the future.
… so ATs might learn "this has a popover". It might say "this is clickable" even if it's not a button or link. We can still guide developers. And avoid authoring mistakes from preventing users to use it.
scott: can we focus on the custom element case for commandFor?
jcraig: right, let's do that.
scott: I'd use the pareto rule. At minimum a minimum role.
<keithamus> WICG/
keithamus: I agree that there should be a minimum set of constraints. I think the attribute must come with some basics, role, focusability. I also agree that we should look for more fine grained primitives.
… focusability is a repeating topic (see links)
… in other context.
… I like that we're heading towards more composable behaviors.
… perhaps something like custom attributes are more suitable; there used to be some proposals that might be worth revisiting.
… I think the accessibility constraints are one part of the problem, but that doesn't there isn't some middle ground. E.g., maybe not forms, not type but maybe still choose.
<scott> +1 keith
spectranaut_: do we have agreement on role and focusability?
<sarah> +1
<chrishtr> I propose we resolve for option A
<front-endian-jane> +1
jcraig: I want to be devil's advocate for focusability.
… a custom minimum role is reasonable to dismiss since it's a custom element.
… for focusability. sometimes custom elements duplicate functionality. buttons inside a listview can be problematic to present through AT.
<Zakim> jcraig, you wanted to ask how you "unset" focusability... tabindex="-1" does NOT do it, for example.
jcraig: But from the discussion, I wanted to point out that focusability is not really possible to undo. tabindex -1 only takes it out of the tab order.
<scott> tabindex=nope please
<keithamus> tabindex=-2
sarah: right, as I said earlier tabindex is tricky. If we're talking about additional asks, I would always say that undoing focusability would be a good thing.
<scott> the horrors i've seen where tabindex = negative numbers beyond -1....
sarah: once it's set, we cannot undo it. If anyone wants to pursue that, I would support this.
… so I would be closer to jcraig if one could apply commandFor to any element. I think in this instance it doesn't remove flexibility.
… on the topic of adding platform features, I think even that can be counter-productive. If we add features to compensate for authors, it can make it much more difficult down the line.
<chrishtr> q!
sarah: while the user is more important than developer workload, I would not want to make things worse.
jcraig: just to point out that jamesn has a lot of prior knowledge worth diving into.
<Zakim> jcraig, you wanted to suggest requesting further info from jamesn b/c of his oracle framework behavior
spectranaut_: did proposers get what they wanted?
chrishtr: could we get a show of support for one of the two proposals?
spectranaut_: we don't usually do that. Does anybody object to role and focusability?
jcraig: with caution
taylore: I think everyone seems to agree on focusability and maybe roles but form control might not be.
chrishtr: and not one-by-one
jcraig: I would caution to look out where it reduces flexibility for authors.
spectranaut_: and maybe look into a tabindex override.