16:56:05 RRSAgent has joined #aria 16:56:09 logging to https://www.w3.org/2024/08/15-aria-irc 16:56:09 RRSAgent, make logs Public 16:56:10 Meeting: ARIA WG 16:56:37 agendabot, find agenda 16:56:37 spectranaut_, OK. This may take a minute... 16:56:58 Sorry, I did not find an agenda. 16:57:45 jamesn has joined #aria 16:57:48 agendabot, find agenda 16:57:48 spectranaut_, OK. This may take a minute... 16:57:48 Sorry, I did not find an agenda. 16:58:27 i'll add it 16:58:37 agenda: https://lists.w3.org/Archives/Public/public-aria/2024Aug/0009.html 16:58:37 jamesn, sorry, could not get https://lists.w3.org/Archives/Public/public-aria/2024Aug/0009.html (code 429). 17:00:09 agenda+ [New Issue Triage](https://tinyurl.com/bdwucdu3) 17:00:09 agenda+ [New PR Triage](https://tinyurl.com/fpamwzap) 17:00:09 agenda+ [WPT Open PRs](https://bit.ly/wpt_a11y) 17:00:09 agenda+ [TPAC](https://bit.ly/aria-meaty-topic-candidates) 17:00:09 agenda+ [9.3 Presentational Roles Conflict Resolution does not consider custom element use cases](https://github.com/w3c/aria/issues/2303) 17:00:10 agenda+ [Spec for menu/menuitem does not provide enough author guidance for structure](https://github.com/w3c/aria/issues/2300) 17:00:48 Adam_Page has joined #aria 17:01:02 StefanS has joined #aria 17:02:04 katez has joined #aria 17:02:29 present+ 17:02:51 present+ 17:03:26 present+ 17:03:35 present+ 17:03:50 present+ 17:03:54 regrets+ PeterKrautzberger 17:03:58 scott has joined #aria 17:04:28 scribe: Rahim 17:04:33 present+ 17:04:35 zakim, next item 17:04:35 agendum 1 -- [New Issue Triage](https://tinyurl.com/bdwucdu3) -- taken up [from jamesn] 17:04:49 CurtBellew has joined #aria 17:06:37 aaronlev has joined #aria 17:09:00 present+ 17:09:42 present+ 17:09:45 OliverH has joined #aria 17:09:59 aardrian has joined #aria 17:10:09 present+ 17:10:14 Matt_King has joined #aria 17:10:18 spectranaut_: for aria #2313, can you introduce this Scott? 17:10:21 present+ 17:11:00 scott: working on HTML-related stuff; idea of having to specify that aria-hidden is used to make an SVG decorative is a "prickly" subject. Made me realize there's no good way to do this with SVGs (e.g., alt for ). No need to talk now, can agenda+ 17:11:07 present+ 17:11:15 present+ 17:11:35 spectranaut_: after moving to monorepo, no good way to tag PRs so please weigh in if you have an opinion 17:11:37 Brett-Lewis has joined #aria 17:12:09 spectranaut_: aria #2310 was already discussed, James to tackle 17:12:12 zakim, next item 17:12:12 agendum 2 -- [New PR Triage](https://tinyurl.com/fpamwzap) -- taken up [from jamesn] 17:12:32 siri has joined #aria 17:12:37 zakim, close this item 17:12:37 agendum 2 closed 17:12:38 I see 4 items remaining on the agenda; the next one is 17:12:38 3. [WPT Open PRs](https://bit.ly/wpt_a11y) [from jamesn] 17:12:59 Present+ 17:13:23 Nina has joined #aria 17:13:50 jcraig: for wpt #47608, associationlist is included in test even though it's been moved from editor's draft. Aaron saw a problem with how name prohibited is enforced; pretty straightforward but a bit bigger due to ancillary issues I discovered as part of fixing WPT issue 17:13:58 spectranaut_: Aaron can you take a look? 17:14:26 jcraig: Chris or Simon can add you to the (a11y) interop team so you can review it as reviewer 17:15:27 ...one reviewer is all that's needed for WPT but since this is related to 2 or 3 ARIA issues, good to have a few people from ARIA WG review it. If I recall correctly, it shows accname reviewers (and Val/James). Feel free to remove anyone that doesn't want it but nice to have other reviewers 17:15:36 Was there a message about it? 17:15:47 spectranaut_: I can take a look 17:16:02 ...(and Melanie) 17:16:26 zakim, next item 17:16:26 agendum 3 -- [WPT Open PRs](https://bit.ly/wpt_a11y) -- taken up [from jamesn] 17:16:50 zakim, close this item 17:16:50 agendum 3 closed 17:16:51 I see 3 items remaining on the agenda; the next one is 17:16:51 4. [TPAC](https://bit.ly/aria-meaty-topic-candidates) [from jamesn] 17:16:54 zakim, next item 17:16:54 agendum 4 -- [TPAC](https://bit.ly/aria-meaty-topic-candidates) -- taken up [from jamesn] 17:17:10 present+ 17:18:03 spectranaut_: previously we had issue for accname #95 as a potential F2F candidate but Melanie will not be at TPAC; there was a suggestion to move to deep dive unless Bryan prefers it at TPAC? Can also keep it at TPAC 17:18:13 ...will keep this as a deep dive otpic 17:18:26 q+ 17:18:49 ack q 17:18:50 ...anything else on TPAC topics? Just a reminder that TPAC is happening in a month and next week, James and I will start to make a draft agenda and share with the group. If you have topics, add the "F2FCandidate" tag and write something in the discussion board 17:18:56 ack smockle 17:19:10 Clay: we've talked about aria-notify breakout session; is there docs for how to put together an effective one for review? 17:19:15 CurtBellew has joined #aria 17:19:35 spectranaut_: no, sessions are up to whoever is running it. Only guidance is there should be clear goals/guidance that should come out of the discussion but can talk more offline if you want more guidance than that 17:21:00 aaronlev: if you have complicated stuff, might be good to socialize with smaller group to gather feelings/thoughts so it's smoother when brought to larger group. It's been somewhat successful before to start with something that won't be hard to agree on, then have a list of 5/6 things you want to go through towards resolution. Hopefully won't need to start from the beginning and explain everything 17:21:11 jamesn: having something written beforehand is also very handy 17:21:16 zakim, next item 17:21:16 agendum 5 -- [9.3 Presentational Roles Conflict Resolution does not consider custom element use cases](https://github.com/w3c/aria/issues/2303) -- taken up [from jamesn] 17:21:48 spectranaut_: this is Aaron's issue that we briefly discussed but Aaron wasn't present. Seems like there's more to discuss 17:22:31 aaronlev: what I learned from last week is that there are more people that are seeing this in multiple places; i.e., not that people put role="none" on it. Most folks don't understand engine internals for a11y 17:23:16 q+ 17:23:18 ...could recommend something in the long run (e.g., shadow DOM delegate). Role="none" always means take something out of the tree, then later it was raised (as philosophical issue), what happens if someone puts role="none" and there's an important property there 17:24:06 ...people didn't see harm there, and browsers would ignore it. Now, when people implement custom elements, there's no quick and easy way to fix that. It came up for me when working on rules that prevent Chrome's UI which has HTML in it (and broke things like elements that have name prohibited) 17:24:27 ...by allowing role="none" on custom elements, don't think we're breaking anything, and doesn't preclude more elegant solutions but I think it's a small change that would help me right now 17:24:30 ack jamesn 17:24:59 jamesn: are you saying that the custom elements that you want this to work from are handling aria-label and doing something with it, or are moving all other attributes to the target element? 17:25:14 aaronlev: sometimes it could be aria-label, aria-description 17:25:27 jamesn: are they specifically targeting those? (Aaron says no) 17:25:52 ...danger of doing this is that there are lots of authors using custom elements who end up adding aria-label to a custom element and shouldn't be doing it, and the aria-label isn't getting passed anywhere else 17:26:18 spectranaut_: I think Aaron said they are targeting aria-label and aria-description, rather thank blanket copying 17:26:20 aaronlev: not saying custom elements get a default role of none; I'm saying that the custom element knows to copy the appropriate attributes 17:26:30 s/thank/than/ 17:26:53 jamesn: if a custom element does this, and the author unintentionally is setting ARIA on it, now that aria-label is not getting reflected properly 17:27:15 ...(correction***: ARIA generally, not just aria-label) 17:28:00 ...we don't generally allow people to put ARIA on custom elements because of this problem; you don't allow someone to do that if you're going to copy those properties somewhere else. Shouldn't this problem surface as part of testing? 17:28:29 aaronlev: we have testing, but doesn't test every environment and feature (that should be thorough). You're saying that people at Adobe should be able to set aria-label/role="none" on custom element? 17:28:41 q? 17:29:13 jamesn: when someone has set aria-label on this thing (custom element), I'm concerned this will be a breaking change and things are not ignoring that aria-label so it ends up creating a group; then, the author is getting this behavior (although not intended) and now it's broken 17:29:41 aaronlev: could I convince you that we're giving people a tool to get more things to work; your case is theoretical and my case seems more real 17:30:10 jamesn: I would like to talk more people who have experience creating custom elements; this discussion should go to those people rather than us (ARIA WG) making a decision 17:30:11 q+ 17:30:17 ack scott 17:31:15 q+ 17:31:16 scott: I did reach out to some of the people at Microsoft who build custom elements/components; one of the things they struggle with is what Aaron has brought up; i.e., authors are used to putting attributes on custom element wrapper and then have it passed down to element's internals. ARIA has been the exception (and there's been pushback) and we've had people change their code but not for all the frameworks' custom elements 17:31:30 ...one of the developers I reached out to commented on the issue 17:31:49 ack aardrian 17:31:55 aaronlev: not just changing implementation of custom element, would have to change everything that uses it (easier to change in one place rather than many) 17:32:16 q+ 17:32:24 ack jamesn 17:32:25 aardrian: do we raw data of what's being used in the wild? Scott gave some from Microsoft, and Aaron from Google; more data could help make more informed decision 17:32:49 jamesn: rather than using role=none as the internal, should there be something else you specify as an alternative approach? (e.g., a new role?) 17:32:59 q+ to say +1 to the idea of having something else to specify instead of `role="none"` 17:33:07 ack me 17:33:07 melsumner, you wanted to say +1 to the idea of having something else to specify instead of `role="none"` 17:33:19 aaronlev: we should go with Adrian's suggestion of getting more data; don't need more roles 17:33:24 absolutely do not want this to be a role 17:34:06 Matt_King: instead of a new role; instead of declaring none, but also declaring a secondary role that represents the custom element? e.g., role="none tree" or "none button" as a way of distinguishing it 17:34:16 q+ 17:34:21 q+ 17:34:29 aaronlev: let's not make it harder and just follow the markup of what someone put 17:34:50 ack scott 17:36:11 scott: adding context to opposition to addition of new role: custom elements are being used as Aaron mentioned; and using them as funnily-named divs. If they have a generic role by default and if we made a role, valid argument for why this isn't the default role for custom elements. If the whole point is to pass attribute to element internals, it would break custom elements that already use the global ARIA attributes (e.g., passing aria-live 17:36:11 down to element internal) 17:36:34 keithamus: is this solved by the referencetarget proposal, and work around these issues? is it easier to have the conversation when that proposal ships 17:37:07 q+ 17:37:13 ack keithamus 17:37:49 ack spectranaut_ 17:37:52 aaronlev: no; e.g., referencetarget lets you use a relation so you can point to something going inside the custom element, e.g.., set aria-controls and point it to something inside. In this case, it's not necessarily a relation 17:38:15 q+ 17:38:54 spectranaut_: I want to see the pros/cons of making this change, some speculative. I've heard multiple cons but difficult to process from just this discussion. From the perspective of making ARIA easier to learn, does it help that role=none works one way on one element and another? 17:39:16 ack jamesn 17:39:17 jamesn: author doesn't set role=none here, it's the component (but author could set it?) 17:40:27 ...this could also encourage authors to start setting aria-label on custom elements (in a willy nilly way); this is the reason we encourage people to not use the ARIA attributes on the custom element itself 17:40:30 ack me 17:40:42 aaronlev: any alternate solutions? 17:41:11 keithamus: how many people try to do this? When I've done this, I've removed the attribute on the custom element 17:41:26 aaronlev: problem is that custom element has onattributechange event handlers 17:41:48 spectranaut_: not hearing hard "no" either, what are next steps? 17:42:25 It seems like we need a way to gather user feedback since there's an uptick in anecdotal evidence, yeah? 17:42:26 jamesn: want to talk to our internal folks to learn more 17:43:07 aaronlev: the reason I'm pushing on this is because I'm trying to implement an experiment anyone can play with and play with name prohibited elements (and move that content to description) 17:43:24 q+ to ask if we have considered "Stages" like they do with TC39 so we have ways to experiment? 17:43:51 ...right now, what I'd have to do is have an exception for my experiment (but in order to make it work, need to change behavior of custom elements). This proposal gives me a way to fix it in a single place 17:44:11 ...for the content I'm specifically worrying about, it's the stuff that's part of Chrome's UI which is written in HTML 17:44:43 ...I basically have to carve out an exception for the name prohibited, allowing names on custom elements or provide some way for people to work around it 17:44:49 q+ 17:45:05 spectranaut_: otherwise the role would none? (Aaron says it should be generic so name is prohibited) 17:45:08 q? 17:45:19 ack melsumner 17:45:19 melsumner, you wanted to ask if we have considered "Stages" like they do with TC39 so we have ways to experiment? 17:45:27 s/the role would none/the role would be none/ 17:46:21 melsumner: experimentation would be really useful; we are getting stuck because the "horse is out the barn's door", but implementators are stuck as well 17:46:29 spectranaut_: maybe you can make an issue and agenda+ it 17:46:49 q? 17:46:58 ack jcraig 17:47:19 * 17:48:12 jcraig: I don't have a strong an opinion on this issue; one of the things I want to call out is that Aaron is moving away from what other browsers are currently doing. E.g., for
,
, Gecko/WebKit still pass the label through despite it being an author error. You're (to Aaron) enforcing an author error as use behavior may be problematic in terms of priority of constituencies. This is part of the reason we don't have a user agent 17:48:12 requirement 17:48:37 scott has joined #aria 17:49:24 aaronlev: I'm putting this behind a flag so people can play with it (and moves the content behind description). We've been working with AT vendors to support description on anything (e.g., virtual buffer mode, tabbing though a form), helps authors supply a plain text representation and have it rendered/announed. When I looked at aria-label on generic elements, sometimes it's being used as duplicate text, and sometimes something additional to 17:49:24 have spoken 17:49:30 jcraig: how does it apply to generics? 17:49:42 aaronlev: if there's an interesting ARIA property on a generic, it gets exposed in the a11y tree 17:49:57 jcraig: are you using aria-label for example to description as well for role=generic? 17:50:02 q+ 17:50:27 aaronlev: that's what the experiment does; not all screen readers can handle having text in a container (get confused when you have text from a name and inner text) 17:51:45 ack Matt_King 17:51:47 (i.e., inner text = descendant objects/elements that have their own accessible name) 17:53:25 Matt_King: this discussion is getting concerning around forcing users of screen readers to hear stuff that should be by design to be ignored (i.e., the extra information). The reason we have name prohibited on certain things is partly because of this noise factor where you have authors doing this and labelling things where it creates more problems than it solves. It feels like there's an inconsistency that we don't stuff named, but it can be 17:53:25 named; don't care what it's called, it's still a problem 17:53:44 aaronlev: none of the browsers remove the information from the tree so you get different experiences across ATs/browsers 17:54:10 Matt_King: wondering if we're not doing the job we need to do to prevent authors from doing things that are detrimental to users (which is why we have name prohibited) 17:54:25 aaronlev: extra verbosity might be better than to remove something 17:55:33 Matt_King: if something is vital information, and if the tooling isn't doing what it needs to do (you just put vital information and expressed it in a bad way), authors should realize this vital information isn't getting rendered properly 17:56:54 Brett-Lewis: we do have problem with verbosity; I like moving this information to description and reading description afterwards (and giving user easy way to ignore them). I like what Aaron is talking about which is rendering all available information about an element 17:57:35 Matt_King: example we've trying to tell authors is that aria-label overrides content inside link. But if we expose both the link text and aria-label and expose both? 17:58:18 Brett-Lewis: I get the difficulty and challenge here and I agree with Aaron's sentiment that we should say too much rather than remove stuff 17:58:28 aaronlev: which is why I created this experiment so you can try it 17:58:43 spectranaut_: next steps are James N. will talk to others, any other next steps? 17:59:01 aaronlev: we need to reach out to Westbrook and ask their opinion on ARIA on custom elements that get duplicated? 17:59:05 keithamus: I can do that 18:00:09 s/But if we expose both the link text and aria-label and expose both/But if we expose both the link text and aria-label?/ 18:02:00 rrsagent, make minutes 18:02:02 I have made the request to generate https://www.w3.org/2024/08/15-aria-minutes.html Rahim