Meeting minutes
scribenick aardrian
Provided introductions all around.
zakim next item
New Issue Triage
jamesn: 2306 May be a duplicate. I propose closing it as there is considerable discussion in previous issue.
jamesn: Anyone disagree?
scotto: I can respond to direct OP to participate in original issue.
jamesn: 2304 is a request from Mario.
mario: this is implemented in different ways across applications.
<jcraig> There's a similar issue for "token" or "token list" the more general term IMO
mario: There was a similar issue 6 years ago.
mario: The APG has an example but it may not make sense for screen reader users.
jamesn: My opinion is we should take this to OpenUI for a potential component.
jamesn: Then the ARIAWG can help that implementation along.
jamesn: The various implementations cited have enough nuance that they cannot be addressed here in a satisfactory way.
jcraig: There was a similar list for token lists (689) closed for a similar reason.
<jcraig> w3c/
sarah: I agree with the prior comments, but am curious if the interactive list role might get us closer.
scotto: This would need to be done in more than just ARIA.
<jcraig> Closed for same reason... OpenUI would be a better landing spot.
scotto: I agree it should be on OpenUI. Please go there and bring the discussions from here to that group. There aren't enough people in that group focused on accessibility. I can't be the only one over there.
scotto: Come join the club.
jamesn: Talk to Scott if you want to get involved.
<scotto> https://
<scotto> openui/
Matt_King: At one point there were quarterly conversations.
aardrian: Agree with Scott. OpenUI has a shortage of accessibility pros and the impact can be larger than just ARIA's remit.
mario: I thought the best place to start would be with ARIA roles.
jamesn: From past history, starting something here without more buy-in has proven to be challenging. We can specify, but then we need to get implementors on board and authors as well.
jamesn: The experience hasn't been successful.
Matt_King: I understand Mario's point.
Matt_King: I think Sarah's idea with interactive list role can be an example of that discussion.
jamesn: Keep in mind if there are things from that discussion that can be folded into it.
Matt_King: ARIA actions is a related example.
jamesn: Let me think about this and comment.
jamesn: 558, tabindex=0 on UA scrollable containers.
scotto: Follow-on to minimum role proposal. A tabindex would cause something to have a minimum role of `group`, but we left it out due to uncertainty. Aaron is running into issues so wanted to bring it up again.
scotto: I know what needs to be done and who to talk to, so assign it to me.
jamesn: 557, shadow DOM sub-issue from a closed issue.
Rahim: This and the next issue is the work Scott and I are doing to triage open AAM issues. DOn't need to discuss. Just needs grunt work.
scotto: If anyone is interested (also 556), comment.
jamesn: Last item is already on the agenda.
New PR Triage
jamesn: 5 new PRs. ATK URL (2309) looks editorial. If an HTML-AAM editor can weigh in, that would be great.
jamesn: Labeling "editorial", assigning Scott.
jamesn: Add `class` and `id` mappings to HTML-AAM (2308). Can I have reviewers from each of the platforms?
valerie: I'll review.
Rahim: I'll review.
scotto: Add me for general arguing.
jamesn: The next is editorial, no need to look. Same with the next.
jamesn: Fix broken links in AAPI mappings (447).
scotto: On my backlog.
Pkra: There is a new one as well.
Rahim: Is there an updated PR?
scotto: Not done yet.
WPT Open PRs
jamesn: Anything to talk about here? These seem old.
jcraig: I've updated a few.
valerie: I can respond to 45916.
jcraig: Can I just go ahead an auto-merge?
valerie: Yes.
jcraig: Not this one yet, but commit and I can merge.
TPAC planning
jamesn: We have some comments from Aaron. Please everyone add something.
jamesn: The event is coming soon.
aardrian: Is my comment Aaron's enough to +1 one of those items.
jamesn: Aaron doesn't think we need a bunch of time on this, so if it's important to you then comment.
aardrian: I don't know the process nor the other WGs.
jamesn: Make sure you have a goal.
aardrian: So an output objective with supporting material.
jamesn: Time-boxed as well. There may be 50-60 people in a room with maybe 15 minutes for a discussion.
Matt_King: Make sure we have the appropriate level of discussion in this group so we are speaking with one voice.
jamesn: Yes. With a WAI group maybe less formal, but definitely be on point with CSSWG.
jcraig: On the topic of good will and speaking with one voice, Daniel if you or other W3C contacts are working with that or other WG, then please coordinate in advance.
dmontalvo: Yes.
9.3 Presentational Roles Conflict Resolution does not consider custom element use cases
scott: Some context here is that Aaron has noticed a lot of custom elements are created by putting ARIA elements on the container and then propagating down to the shadow DOM.
scott: So it's being reflected down. The authors' intent or assumption is that other elements work this way so ARIA attributes should work this way.
scott: They are following prior art and doing the right thing, so validation errors are surprising.
scott: I see this all the time, so I see where he's coming from.
scott: So undoing this role specific to valid custom elements, or a new rule, to reflect actual use by authors for custom elements. The alternative is to tell all authors they are wrong and have to refactor.
scott: This seems like a use case to make the rule more nuanced.
jamesn: I see this all the time, that authors then have to rename the `aria-label` that gets mapped down to the element, camel case it or whatever. It seems like something it would be nice to support but how can we know if the custom element is doing anything useful with that `aria-label`?
jamesn: I don't know how we would implement this? How would we prevent the custom element naming the element and its child?
scott: Good question. Aaron said he has done some test implementations for cases he has seen.
scott: I am being Aaron's mouthpiece here, not expressing my opinions, so I have no response.
scott: But if someone did that, then it's hard to know what authors were expecting.
jamesn: We should talk to the web components folks before progressing any further.
<Zakim> melsumner, you wanted to ask if we can see some sample code? This sounds like author error as described.
scott: Makes sense.
melsumner: I spend a lot of time writing and correcting, so I'd like to see some code and use cases.
melsumner: I'd like to advocate for adding a custom component role rather than changing how the current approach works.
jamesn: Please add that to the issue.
pkra: Do people remove the wrong ARIA attribute or just leave it?
scott: They leave it.
"paving the cowpath"
jamesn: If we can find enough web components folks at TPAC, it sounds like a good potential discussion.
jcraig: Verbal +1 for TPAC.
Spec for menu/menuitem does not provide enough author guidance for structure
<jamesn> UAs/ATs need a way to determine the parent menuitem that caused a menu to be opened. This is important for Talback on Android, which provides the name of the menu along with the choices.
jamesn: notes `scribe+` works for multiple scribes
jamesn: Are you prepared to discuss this Scott? I don't know what to do with this one.
scott: are you prepared to discuss this one at TPAC?
scott: Haven't read it yet.
Accessibilty review of CSS proposal: reading-flow interacts with focusable display: contents elements agendabot]
jamesn: Could use an accessibility review.
valerie: We discussed at a previous meeting. I feel like Aaron was on it.
jamesn: We didn't take agenda off it. Oops. Removing that.
jcraig: It's great they are reaching out. It's the purview of APA, so did they ask and not get a response or asked to move it along.
valerie: Not really sure. I'll follow up to make sure CSSWG knows they should go through APA.
jcraig: Was this is a side request to you personally or the ARIAWG.
valerie: He asked the ARIAWG to review.
valerie: The problem is APA reviews occur late in the game, so an early review would be nice.
jamesn: APA provides the reviews and feedback and files issue, which must be resolved before going to CR. If it's a feature they want to ensure meets that requirement, they are being proactive.
<jcraig> should this be cross referenced https://
jcraig: Should this be cross-referenced to the TPAC discussion.
aardrian: Yes, it's the same or related issue.
jamesn: Maybe we can arrange a topic for TPAC.
jcraig: If we schedule at the time the CSSWG meeting is not happening, we might get participants from CSSWG. Then they can join if they want.
jamesn: We can have a less-targeted discussion if we host and they attend as interested members.
<aardrian> +1
Clarify "undefined" assignment for a state/property as the value (not the string)
jamesn: Still around but new comments from James Craig. Do you want to talk through these?
jcraig: Rahim and I can summarize.
jcraig: reflected nullable `DOMString?` is unlikely to change for webcompat reasons, as it's aligned and has shipped in all engines.
jcraig: If we want to update some to operate like enumerated attribute, we can do it in a reasonably backward-compat manner.
<jcraig> flase
jcraig: There are some concerns from an author confusion since "true", "false", "undefined" aren't really boolean.
jcraig: If we wanted a new validation type, we could equate to true or false or undefined [aardrian: line noise garbled my understanding while scribing]
jcraig: Similar to CSS added the class list to avoid name trampling.
jcraig: One complication was all number types having a default value, and an undefined versus missing type (zero) created challenges. There were some decisions done in the past as a result, but could not find documentation.
jcraig: Perhaps we could put notes about those in the spec, or a wiki (which tends to get forgotten).
jcraig: Should we write new WPT tests? Should the spec include additional notes?
jcraig: A suggestion to not add any new DOMstring accessors, but that seems confusing to authors as well for a different reason. Would need to discuss in detail.
jamesn: It seems there's not as much to do as we feared. Good summary?
jcraig: Sure? If we had a time machine, there was more to do before we shipped these things 6 years ago.
jamesn: Documenting why these decisions were made would be valuable.
jcraig: Mark that as "File as new issue".
Rahim: I have an open issue on proposed IDL updates. This could maybe go in that issue.
jamesn: I'm fine with the new issue.
<jcraig> More of that IDL meeting summary listed here. w3c/