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/
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://
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://
<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://
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/
<melsumner> p+
<giacomo-petri> w3c/
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