W3C

– DRAFT –
ARIA WG

29 August 2024

Attendees

Present
aardrian, Daniel, filippo-zorzi, giacomo-petri, Matt_King, melsumner, pkra, Rahim, sarah, smockle, spectranaut_
Regrets
-
Chair
JamesNurthen
Scribe
aardrian, spectranaut_

Meeting minutes

zakim next item

New Issue Triage

<pkra> jcraig can you try the calendar?

jamesn: Issue 2324, missing table attributes

james: I feel there is a grid project, let's put it in there.

jamesn: I don't want to start a table / grid conversation without collecting them all in one place.

jamesn: I also want to work out what is well supported in native HTML as well.

jamesn: Not sure if we want to just replicate without testing existing support.

aardrian: There are open table issues, is there a tag?

jamesn: There is a project for it already.

aardrian: Perhaps tag them for easier grouping for non-project users.

jamesn: 2322, it seems ARIA actions might cover this.

bryang: I'm not sure it would since the ARIA actions makes no reference to any exceptions.

sarah: I didn't follow that case that wouldn't be covered.

bryang: There were examples, they reference supporting action buttons that are sibling to the role tab. They are referenced by ARIA actions on the buttons.

sarah: So is the issue that the ARIA actions is on the tab and not the tablist?

bryang: No, that there is no exception.

sarah: It creates an explicit exception for elements referenced by ARIA actions.

matt_King: There is a child reference?

jamesn: If there is no explicit exception, we should add it.

bryang: Do you see any reason why buttons in tablists should stop working?

jamesn: I'm not sure we can guarantee anything the breaks ARIA standards can be supported.

bryang: There are things supported by AT for 8 years.

matt_king: Are you asking if coding to the future spec is a problem?

bryang: Yes.

matt_King: As we discussed on Tuesday, I don't see any issue but there is no support today.

jamesn: So are we closing this issue?

bryang: Ask browsers to stop supporting buttons in tablists?

jamesn: I don't think we can put that in an ARIA issue. You can reach out to AT vendors if you want.

matt_King: This is one of the topics I proposed for TPAC -- working out AT support for ARIA actions.

jamesn: 2320, aria-label on<time>.

aardrian: This request seems out of scope for ARIA and should be kicked back to HTML.

jamesn: I might agree with you, but Scott had some notes.

matt_King: If it's a generic role and we don't allow aria-label, then we wouldn't allow it.

scott: Remember we made the time role for reasons.

jamesn: For parity?

matt_King: I thought we said it was generic?

jamesn: Yes.

scott: I can see where the issue is coming from, but it's making sweeping assumptions about how SR users understand abbreviations.

jamesn: If "1h" isn't clear for everybody, then they should use different text versus SR-only text.

scott: I don't disagree with the proposal because I can understand the position, but HTML already allows this with a title attribute, to Adrian's point.

jamesn: I would love an SR user to write a response and close the issue, if you agree.

matt_king: I do. The notion of giving SR users a different experience is beyond the scope of what you should do as an author. I can leave a comment.

jamesn: 2318, automate PR labeling.

dmontalvo: That's an internal issue.

New PR Triage

jamesn: I don't believe we need to talk about any of these 3 PRs. They all appear to be editorial.

WPT Open PRs

jcraig: The only one I have a question on is... no question because I responded to all of these.

Spec for menu/menuitem does not provide enough author guidance for structure

jamesn: Picking up again from last week with new comments.

jamesn: Bryan had examples, Aaron proposed an algorithm.

jamesn: Want to talk through it or should we just read it?

jamesn: I'll paste it here.

jamesn: Why did you choose "up to 3 ancestors up"?

<jamesn> Starting from menuitem:

<jamesn> * Navigate to ancestor menu (up to 3 ancestors up). If none found, return the empty string.

aleventhal: Because too many would be a bummer for performance.

spectranaut_: Can we do the first non-generic ancestor?

aleventhal: The first menu parent is non-generic.

<melsumner> if we specify non-generic ancestor then we don't have to say how far up specifically to go, yes? This would resolve the wrapping div problem.

aleventhal: Going up three levels is supposed to account for generics.

jamesn: If you have a page of generics that might not help it.

aleventhal: Do you expect to have that many generics wrapping it?

jcraig: Yes. The perf cost is infinite downward. I agree with Valerie that the first menu parent.

alevental: Get rid of the three.

sarah: I have a question about using index items since you have to find the closest parent menu anyway. Is this fundamentally different or can it be used?

aleventhal: The indexing would use first parent in the tree and use that for indexing child items. It is potentially -- we ignore generics and groups.

sarah: I thought indexing was different with groups for different AT.

aleventhal: We can't reuse the same code since it's in a different process.

<jamesn> * If another element controls this menu, navigate to that. If a menuitem, skip to step 4, else return the empty string.

aleventhal: If the element that controls is also a menu item, then step 4. I could explain that better.

bryang: Could that be a button?

matt_king: What happens in that case?

aleventhal: Sounds reasonable; I think we no ARIA menu button in MSAA...

sarah: How we usually build menus, the pop-up is rendered at the end of the DOM with its own z-index and positioning. For every submenu. I don't think we're unique.

sarah: I think we wrangling for more than is useful when looking at the DOM.

matt_King: We had at one time recommend aria-controls, but people said there was no use so we removed it.

matt_king: I could not find the issue for why we removed it. Do we want to revisit? Did you find the use case, Aaron?

aleventhal: No. To answer Sarah, the aria-controls can give it an accName.

aleventhal: We can have a fallback in the worst case scenario.

matt_king: Should we bring aria-controls back into the menu pattern so it provides a name to the menu?

matt_king: We might use aria-labelledby on the menu pointing to the...

aleventhal: Yeah, if #2 says another element controls this then there is a relation. So we need a half step where we use the name on the menu, if none, then the name of the thing controlling the menu.

alventhal: That second step means it doesn't matter if its a menu item because we can use its name.

sarah: Are we taking out DOM walking, previous sibling as a fallback?

jamesn: Can we? Isn't it part of the algo?

sarah: The obscure DOM non-relationship scares me. We don't usually name fly-outs, but now trying to debug how it got its name from a random element seems tricky.

jamesn: This is fallback naming. Ideally authors would name them, so this is when authors fail to do so.

matt_king: The concern Sarah has is the fallback could make a worse name than just "menu" as Aaron suggests.

matt_king: So this can be a worse outcome.

sarah: Yes. A lot of things don't have names, such as file menus. We don't use aria-controls now, so the fallback would come into play and we would get some weird names based on the DOM structure.

matt_king: When using touch, it seems like it could be a problem if a touch view presents an odd reading order.

sarah: We use differen things for leveled flyouts.

bryang: There's no association in iOS.

sarah: It does, but you should test it. Shout out to James Craig.

matt_king: If aria-owns is used, how would that affect the DOM?

aleventhal: This is talking about siblings or parents and looking at aria-owns because it restructures the tree.

matt_king: Does that bring the structure back into use, Sarah?

sarah: I think it's brittle. It's common to not have hierarchical structures, to not name menus, to now use aria-owns.

jamesn: Can you come up with examples in the wild?

sarah: Sure.

aleventhal: We're trying to close some gaps, so any feedback is good.

aleventhal: Thinking about a Share menu and if that will make redundant announcements.

matt_king: Working on that with ARIA-AT. When moving from one menu item to another it would say nothing about the container unless you request information about a specific item.

matt_king: Neither TalkBack or VO/iOS have a way to explore that info, but on desktop you can get that info.

aleventhal: WHat about when it opens?

matt_king: Yes.

aleventhal: When I down arrow I'll get it.

matt_king: If down arrow opens it, then you already heard it.

aleventhal: I just arrow right and it opens a menu.

matt_king: arrowing shouldn't just open a menu so it should have no effect.

bryang: You would need a live region.

matt_king: It's about when you put focus into it. Normally I didn't think submenus would expand automatically on focus. On desktop I might hear "Share, menu collapsed."

<pkra> I have to leave early today. Bye everyone.

jamesn: We have more agenda items. Go read the proposal, comment there. Note Sarah's comments where things might get worse.

Sarah: So far all those would be wrong, so I'll add comments.

Remove group as allowed child of tree

TPAC

jamesn: This is our topics we have been asked to put on the agenda for TPAC.

jamesn: We have a number of issues.

<jamesn> ARIA (now) yearly process review+feedback

<jamesn> 2025 prioritization

<jamesn> Relationship between ARIA and AT

jamesn: And how to improve that.

<jamesn> Prohibited name repair (prototype available in Chromium)

spectranaut_: There are questions about agenda setters. Now's a good time for someone to set it.

spectranaut_: We might not schedule it if no agenda.

jamesn: Aaron can you take the prohibited name one?

<jamesn> New HTML features - updates

Conversation about attendance happens.

jamesn: Aaron and Scott for that one.

<jamesn> New CSS features - updates

jamesn: Also for Aaron.

matt_kind: I thought interactive lists and list view were the same thing.

spectranaut_: You and Sarah submitted them.

conclusion: same topic, sarah and matt will work offline

jamesn: Matt and Sarah will work on that.

jamesn: Doug will not be at TPAC for ARIA notify.

Smockle: ALlison and Keith will be there.

alison: Happy to help.

jamesn: Can you run this Adrian?

aardrian: Yup, will ask for help setting it.

<jamesn> User agent and authoring requirements for aria-actions

jamesn: Three of Matt's at the end. You good to run that?

matt_king: Yup.

<jamesn> Update on ARIA-AT

matt_king: Hopefully with APG examples.

<jamesn> AT expectations for aria-actions

jamesn: we can maybe align that with authoring requirements.

jamesn: So we need to keep them in the order listed.

jamesn: If the order for your session matters, say so.

jamesn: We have room in the agenda and meetings with other WGs.

jamesn: The immersive web one is unclear to me. Who called for it and what are we talking about?

spectranaut_: We should check in.

dmontalvo: I didn't request anything with them.

dmontalvo: I'll see if I can find out, but they may be placeholders.

jamesn: So we have room on the schedule, but propose sooner rather than later.

jamesn: I imagine we can fill two days with this. Aaron could fill both.

matt_king: Good not to overload TPAC.

rahim: I'd like to propose an ARIA IDL topic. I've been researching and would like to discuss stuff with the group.

jamesn: Make an issue and tag it with f2fcandidate, we can agenda it.

jcraig: Rahim has been working hard on this, so I want him to field the questions, not me.

Minutes manually created (not a transcript), formatted by scribe.perl version 229 (Thu Jul 25 08:38:54 2024 UTC).

Diagnostics

Maybe present: alevental, aleventhal, alison, alventhal, bryang, conclusion, dmontalvo, james, jamesn, jcraig, matt_kind, scott

All speakers: aardrian, alevental, aleventhal, alison, alventhal, bryang, conclusion, dmontalvo, james, jamesn, jcraig, matt_kind, matt_King, rahim, sarah, scott, Smockle, spectranaut_

Active on IRC: aardrian, dmontalvo, filippo-zorzi, giacomo-petri, jamesn, Matt_King, melsumner, pkra, Rahim, sarah, smockle, spectranaut_