Meeting minutes
Zakim: next item
New Issue Triage
jnurthen: core-aam#206
… scotto already said "no"
… seems ok?
… anyone disagree?
… please add to the issue otherwise
jcraig: let's close. we can always re-open.
jnurthen: aria#2068
pkra: has PR
jnurthen: aria#2067
scotto: agenda+
New PR Triage
jnurthen: PRs
… aria#2069
… scotto has reviewed.
… let's merge it.
… next aria#2066 link to focusable.
… needs changes in terms
… I'll reach out
WPT Open PRs
jnurthen: WPT PRs
… any action necessary?
jcraig: I don't think so
… review for mine would be nice.
… would close priority 1 PRs for this year.
… Rahim will take over Melanie's PR
… to incorporate feedback.,
… I'll then review
scotto: I cc'ed you (jcraig?) to check if I did mine right.
jcraig: CI should be the check. I also sometimes have local failures.
Deep Dive planning
jnurthen: let's not add anything this week. we have lots to do today.
… might need more meetings.
Requesting changes to new implementation-blocked merging process
jnurthen: merging process.
spectranaut_: we started this discussion at TPAC 2023
… deciding how things should land.
… jcraig had raised questions about process
… others felt uncomfortable with "implementation from PR"
… it's what other specifications are doing.
… especially evergreen ones.
… so we have proposals for two processes
… 1) to land PRs before implementations and mark that
… 2) implement first, then land.
… the issue has a lot of details on the two proposals.
… e.g., consensus WG, open implementation issues, file issues in other specs
… still: either warning in spec or not land until specifications.
… in the first case, we'd still need follow-up PRs to remove warnings.
… it's unfortunately complicated. not sure how to resolve it.
… one reason to wait with landing is that if or once we get to evergreen, we want the evergreen version to reflect what's implemented
Matt_King: I hope we can make it work so we don't have to put warnings in the spec.
… I'm very concerned about the clarity about what's new.
… sometimes we make 1 change that's many small changes across the document
… if we make 2 of these, with their own sets of warnings, I don't even know how to read the spec and track the issues.
… I suspect it becomes unreadable
… I prefer the PR approach because whether 1 or 50 places in a change, they are easy to find
jcraig: I disagree because for example it's often multiple PRs across specs.
… so it was impossible to get an overview over what's changed and what needs changes
… Also, to be able to test what's possible, I don't see the warnings more like links to "can I use", linking to WPT tests, seeing what works and what doesn't.
… maybe there could be an icon to indicate level for support. The change would really be editorial.
… to Matt's point I realize there are changes across spec but it's not typical for new features anymore I think.
… say a new role
jnurthen: I'm not sure. A new role will influence other roles, e.g., around nesting
jcraig: let's take the one example that triggered this - name from heading
… group decided this needed new structure.
… then downstream changes across AAMs
… accname
… and those changes are even more difficult to pull out if we decide not to do it.
Matt_King: I see a high risk that changes will cause additional changes across the spec.
… the person reading the ED of the spec, can't know if the mention is a valid mention.
… disallowing such mentions, making a branch off that
jnurthen: right but here that wouldn't really work
Matt_King: so all of them need a warning because anyone reading the ED might not know.
jnurthen: the only way to make this work would be a respec feature to do this manually.
Matt_King: what's the difficulty around cross-references across specs
… we can write a PR that makes an assumption but the PR in ARIA would have to be merged at the same time.
… is that hard?
spectranaut_: I'd suggest to link up
… a feature in that way is a set of PRs that need to be implemented
Matt_King: but the link would be broken
… I see the problem now.
jnurthen: in different repositories.
jcraig: we're trying to describe the complexity but perhaps we should just read the proposals again
jnurthen: I'd prefer to have a separate discussion
jcraig: is Aaron here? He should be there.
pkra: next week is DST shenanigans week
jnurthen: sounds like we can try it as deep dive next week
Update from PR #1018 for nameFrom: heading
associationlist and related roles have tediously long names
jnurthen: I proposed 3 options on the issue.
… a) remove from 1.3
… so no parity with DL for now
… b) keep them as is
… c) change the name to make them less long
Matt_King: can somebody state the pros and cons of not doing this in 1.3?
jnurthen: as far as I'm aware, we are no longer seeking full parity.
… for elements without a role, we map them to a default for testing purposes
jcraig: there's a proposal for that part.
… for association list, if we have a term, then the mappings can still work.
… dl is still a list.
… listitem is still a listitem
… and one new role for the DT
… that way, we still get the main results.
… role parity doesn't mean 1 to 1 but 1 to many
Matt_King: so for AT it doesn't matter what kind of list that is?
jcraig: if it does, it can still do this
jnurthen: from the children.
Matt_King: so DL maps to list, DD to listitem, and DT to a new one.
… what is the pro or con?
… as opposed to 'dd-html' ,'dt-html' etc
… I don't know why it would be used in HTML
… maybe SVG?
scotto: I like jcraig's suggestion. But some mappings would be good to get unification across AT
… just the fact that we can group them in HTML
… multiple DT per DD and vice versa
… but I agree that we can re-use list and listitem for DL and DD
… and do something for DT
… but let's do something
Matt_King: if we can have multiple DTs for a single DD. Is there a parent child problem?
jnurthen: let's maybe not get in the weeds right now.
… let's have a proposal.
<Zakim> jamesn, you wanted to ask should we work on that first before doing that?
jnurthen: should we work to get the HTML mappings right?
scotto: right now pointing to definition and term which is wrong.
… chicken & egg problem.
jcraig: my argument was on the implementor side. we don't need the additional complexity
… but also from the constituents side.
… 3 new roles affects users even more
… so I'd favor: pull it entirely or 1 for DT
jnurthen: both of these would mean removing what's there right now.
jnurthen: I really want 1.3 FWPD
… I don't want associationlist in there if we don't want to ship it
jcraig: let's pull it and revisit then.
Matt_King: let's have a proposal
… for the new thing
+1
jnurthen: anyone disagree?
… I'll make a note
describe grouping (and naming of the group) for exclusive accordions <details name>
rahim: is role parity a goal?
jnurthen: was a task. for example for custom elements.
… but less so now -- too many questionable roles were added
jcraig: also for testability
jnurthen: scotto can you sum up the accordion issue?
scotto: let's skip.
"Radio" role exemption from required context
rahim: came from working on contextual roles WPT test
… in the spec, radio role doesn't have required context.
… or accessibility parent role.
… I understand the rationale why this role doesn't necessarily have it
… on the native side we have grouping via name so I don't feel very strongly about this.
Matt_King: in ARIA, is it currently that we don't require radio to be in a radio group?
… we don't have html name for this after all.
… but in ARIA if we don't require it, there's no way to determine label, posinset etc.
… is that an oversight?
jnurthen: we have SHOULD but not MUST statement
… if not DOM children, SHOULD be aria-owns
Matt_King: I feel like we should change it.
… I see that for HTML mappings this might be a problem.
<scotto> w3c/
scotto: here's a related issue
… where we have no way to do things without a group container.
… yes, in html you don't have to group them explicitly. name does the trick
… depending on the use case, if there's no overall label that's bad but can be ok if the individual labels are clear you can get away with it.
… at least on the conformance checker side they come down on the "we can't require this" side.
… yes, from an ARIA point of view, it's missing. from an HTML one it isn't.
<Zakim> jcraig, you wanted to state the aria-custom requirement could cause a validator warning in HTML native elements, and the primary benefit of the name attr is to provide the mutually exclusive functionality, which is handled by JS in ARIA controls
jcraig: if we require it, it might throw a warning on an HTML native element.
… that seems like a first.
… also, the name attribute isn't really required for grouping but for exclusivity. I'm not sure it's required.
… of course JS can handle the exclusivity in an ARIA situation.
<Zakim> jamesn, you wanted to ask how aria radiobuttons would know about their grouping (posinset etc.) if they aren't part of a group and to reply that radio buttons in disparate parts of the page cause keyboard complications
jamesn: how would a screenreader know? Would a developer have to provide that information?
… and: html in disparate parts. while supported, I don't think it's a good idea. E.g., arrowing around them can get very messy.
… so there's usage which is allowed but evidently not a good idea
Matt_King: for posinset etc I was thinking about the ARIA case. That would be change if we did.
… for HTML parity, it seems we'd need an alternative to name attribute
… I think we already have cases where we differ from HTML, are more stringent than HTML.
… I do find it confusing if there are 3 payment options all over the page without grouping it is extremely hard to follow on a screenreader.
… it would be good to have a way to suggest this is not a good idea
Cory: grouping was there because we needed to force a better pattern into the design
… for me comes down to being a sufficent technique
… I think it follows good form design to require a heading
jcraig: I think either we leave it as we should - gets some validator warnings. Maybe we could push it to a must but I suspect they're functional enough as is
… I suspect most AT users will figure out it's a group.
jnurthen: what about "apple 1 of 1"
Matt_King: I run into that all the time with things don't group reasonably
… browsers not getting it right. 1, 3, 5 and 6 through 10.
jnurthen: a developer should know the number of the set. If we don't require group, we should require that.
scotto: I'll agenda my other issue
Rahim: 1 of 1 - nothing wrong with that in HTML. that's why I was wondering about this.