W3C

– DRAFT –
ARIA WG

22 August 2024

Attendees

Present
aardrian, Adam_Page, BGaraventa, Daniel, filippo-zorzi, giacomo-petri, jamesn, jcraig, katez, keithamus, sarah, scott, siri, smockle, StefanS
Regrets
-
Chair
valerie_young
Scribe
katez, Adam_Page

Meeting minutes

New Issue Triage

scott: this is a follow up on what clay is doing in the atk spec, and follow up from html aam

scott: for html aam, I would just like to clean up how they're referenced in the table

spectranaut_: this is a good first issue, if anyone would like to volunteer

smockle, I will volunteer

New PR Triage

WPT Open PRs

jcraig: going through asking if there are anything to discuss

jcraig: re: WPT Interop 2024 many of the files are being tracked as part of the Accessibility Focus Area, and there

would be happy to help

TPAC planning

spectranaut_: reminder to add topics for TPAC, right now there are 2 topics in this discussion board, and a few issues with face to face candidate

spectranaut_: now's the time!

@mattking: I will add some today

<spectranaut_> w3c/aria#2162

giacomo-petri: I've reviewed the item that was assigned to me, I'm not sure if there's anything else I need to contribute at this point, so the group needs to decide if they want to move forward

spectranaut_: I will make a note in the PR

PR Naming and Labelling conventions

<jcraig> was an updated subtest with an invalid expectation, which changed the failure rate for a browser, so we rolled it back so that it wouldn't adjust the scores. If you're working on WPT and have questions, I/

spectranaut_: just wanted to say that there was some inconsistencies in the PR name, since we went to the monorepo, we talked about it in the editor's meeting, as it is right now, people were using square brackets to say which were affected by the PR, but that was when we were moving individual items to the monorepo, but that was temporary, you

should now use labels per specification

spectranaut_: I added this to the process document so you can look at it there as well

<spectranaut_> https://github.com/w3c/aria/blob/main/documentation/process.md

jcraig: only those of us on the github team can add labels

spectranaut_: we can add the labels during triage

<melsumner> +1 to adding the label during triage

jamesn: we can see if a label isn't there pretty easily and one of us can add it

dmontalvo: we can double check

smockle: we can create automation and look at the changed files or pulling it from the title

smockle: from the github side it is possible

spectranaut_: it's related to which spec you're editing. if it's an editorial PR, starting with "editorial:" is very important because we're pulling info from the commits

spectranaut_: the changelog in aria

spectranaut_: the changelog filters out editorial changes

aardrian: is this documented somewhere?

spectranaut_: it's linked in the IRC, there is a process document

<spectranaut_> another link to the process document: https://github.com/w3c/aria/blob/main/documentation/process.md

<aardrian> Now you're making fun of me. Which is warranted.

jcraig: is this also updated in the PR template?

jamesn: if you forget it's not the end of the world, if we fix it before it's merged, it'll be okay

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

Non-aria way to declare an svg as presentational

spectranaut_: is there something further to discuss svg as presentational?

spectranaut_: this was not discussed last week

scott: I wanted to add something to the HTML select, it was called out that HTML doesn't like document conformance not related to HTML, there's no official way to do it in SVG, you have to use ARIA to do it, I wanted to raise this to see if there's anything anyone could use as an existing feature to indicate that an SVG is decorative

scott: can't use an empty title; curious what other people think or if there's something else we can do

jamesn: I contacted the chair of the SVG working group if anyone can help take a look; they said they don't have anyone working on it right now

scott: I raised it here because I knew the SVG group wouldn't take it up

jamesn: apparently they're going to have their first meeting at the end of the month, maybe this is a good item for them to work on

spectranaut_: any other comments from this group, or what are our other options?

scott: I was initially thinking about empty title, and then make the SVG treat it as role="none", that would assume that the graphic has nothing inside of it but the text could still be treated as text

jamesn: I would love to see the number of SVGs with empty title attributes, I suspect there are people that add it, but that's just my guess

aardrian: you mean empty title element

<aardrian> Oh sure, now I look like the pedant.

Spec for menu/menuitem does not provide enough author guidance for structure w3c/aria#2300

Spec for menu/menuitem does not provide enough author guidance for structure w3c/aria#2300

aaronlev: describes the issue, basically a SR would have to work backwards from a submenu to get to the parent menu

jcraig: are you talking about the accessibility sibling of the parent menu, which could get around generic div in-betweeners?

aaronlev: I put that as a criticism in the authoring text because it said sibling but not what type of sibling, but i thought the text they already had was pretty good

aaronlev: it's pretty obvious that if you have a menuitem, but you want to get the parent menu, but it would be good to have some clarification for Talkback

mattking: we have aria-controls, which is specified in the parent

aaronlev: does it say to use aria controls from the parent menu?

aaronlev: apg has some text about the sibling structure

aaronlev: the algorithm should be to use aria-controls, but if it's not there then the fall back would be to use the parent and then the sibling

smockle: it's pretty common to have an unordered list, then another unordered list as a child

aaronlev: non-generic accessible tree

<Zakim> jcraig, you wanted to clarify aria-owns could handle all the scenarios with non DOM sibling, accessibility siblings and to clarify I'm not lost in the controlled-by relationship

jcraig: wanted to clarify that aria-owns handles all the relationships for menu parent where it's the non-dom parent, any non-dom relationship can be handled by aria-owns

aaronlev: by the time AT gets to it, it doesn't know the relationship

aaronlev: are you talking about the natural dom or the flat dom?

jcraig: you would have a controlledby relationship by the parent menuitem not the parent menu, I haven't seen that.

aaronlev: parent menu item has aria controls on it and that points to the menu that is open

jcraig: it would be good surveying from the primary components from popular js libraries, but I don't know of any spidering tools on the web that would handle it

BGaraventa: discussing elements that could have something in between them

<spectranaut_> I don't see aria-controls on this page: https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/ or https://www.w3.org/WAI/ARIA/apg/patterns/menubar/

aardrian: aria controls is not mentioned in the apg page. it should only be used as an override to a structure

<Zakim> scott, you wanted to ask if clarifying this would resolve the issues i linked in Aaron's issue

scott: wanted to reference an old issue I made, menuitem doesn't have children presentation, people would be nesting menus inside of menuitems. Wanted clarification about how we should be nesting

jcraig: I recommended aria controls, and then then parent, then the parent menu item, then back down to the aria-selected one. There's a complicated algorithm

scott: when I hear parent menu item, the submenu is nested in the menu

BGaraventa: when you have the menu item on the parent node, people will put active elements inside of that, and usually those are rendered by links, inside that you'd have the focusable link, then you'd have the sibling menu, historically it's always been very problematic, and causes issues for SRs. Over the years we've had many discussions in APG

where menuitem role should always be on the active element interacted with the AT

mattking: we took out aria controls based on feedback, people didn't want it to be a required thing

mattking: we still recommend the structure where the parent menu item where the submenu is contained within the parentmenu and that's how you get the relationship. one thing about the spec is that aaron, were you asking where in the spec language where the child, controlled menu is an accessible child, of the accessible parent menu item?

aaronlev: I'm just asking that the menu structure is understood by AT like tree structure, AT needs to know the menu structures and be able to navigate it, in this case, like labelling the menu with the parent menu's name

mattking: I'm pretty sure it currently states that tree item contains other tree items, this would be the same concept

BGaraventa: I've seen that in trees where levels aren't calculated correctly

mattking: and that hasn't been the case for menus, but I think aaron is saying that it would be better that the spec required...but people might not like that it's required

mattking: not sure what to do from a spec point of view, or that it would be an improvement for mobile devices.

<Zakim> giacomo-petri, you wanted to talk about tree and treeitems based on last Matt feedback

giacomo-petri: we found inconsistencies and conflicts in terms of accessibility parent roles and children for tree role, and there's already a ticket pending reviews until december and it should be addressed because of the conflict

<jcraig> giacomo-petri: do you have the link to the issue?

spectranaut_: if there are old items, please add agenda to the issue

<sarah> w3c/aria#1120

<melsumner> p+

<giacomo-petri> w3c/aria#2315 and w3c/aria#2094

spectranaut_: it seems like figuring out the algorithm is still on the table and open to feedback

jcraig: if we figure out all the edge-cases, it feels like there should be a tree and/or menu algorithm defined somewhere

sarah: my PR has a bunch of role updates and allows x referenced, but if we add menuitem and tree, let me know if I need to make a bigger issue, we might need a more formal way of defining children and children presentational

aaronlev: we're getting closer to an answer to this issue

aaronlev: we don't want to have another accname

I rejoined today's meeting

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

Diagnostics

Succeeded 1 times: s/@jamescraig: /jcraig: /g

Succeeded: s/it's worth noting for the group that one of the reason we had a pr that james reviewed is that we're currently checking these files right now, but there was one with an exception, and it changed the failure rate for the browser so we rolled it back very quickly so that it wouldn't adjust the scores, if you're working on anything and I/re: WPT Interop 2024 many of the files are being tracked as part of the Accessibility Focus Area, and there

Succeeded: s/accessibility sibling?/accessibility sibling of the parent menu, which could get around generic div in-betweeners?/

Succeeded: s/the meeting/today's meeting/

Succeeded: s/@mattking/mattking/

Succeeded: s/@jamescraig/jcraig/

Maybe present: @mattking, aaronlev, dmontalvo, mattking, spectranaut_

All speakers: @mattking, aardrian, aaronlev, BGaraventa, dmontalvo, giacomo-petri, jamesn, jcraig, mattking, sarah, scott, smockle, spectranaut_

Active on IRC: aardrian, Adam_Page, BGaraventa, dmontalvo, filippo-zorzi, giacomo-petri, jamesn, jcraig, katez, keithamus, melsumner, sarah, scott, siri, smockle, spectranaut_, StefanS