15:58:54 RRSAgent has joined #aria 15:58:58 logging to https://www.w3.org/2024/05/02-aria-irc 15:58:58 RRSAgent, make logs Public 15:58:59 Meeting: ARIA WG 15:59:10 agendabot, find agenda 15:59:11 jamesn, OK. This may take a minute... 15:59:37 Sorry, I did not find an agenda. 16:02:16 agenda+ [New Issue Triage](https://tinyurl.com/2j7n7te8) 16:02:16 agenda+ [New PR Triage](https://tinyurl.com/3v3y8x5v) 16:02:16 agenda+ [WPT Open PRs](https://bit.ly/wpt_a11y) 16:02:16 agenda+ [Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates) 16:02:16 agenda+ [Remove aria-expanded from listbox](https://github.com/w3c/aria/pull/1862) 16:02:17 agenda+ [Complex dashboards and standalone cards](https://github.com/w3c/aria/issues/2162) 16:02:17 agenda+ [ARIA should clarify distinction between “contents exposed as descendant text nodes” vs “name from contents” (Was: `listitem` should include `name from Contents` or `name prohibited`)](https://github.com/w3c/aria/issues/2160) and [td, th naming doesn't align with ARIA ](https://github.com/w3c/html-aam/issues/543) 16:02:18 agenda+ [Question: time can have a name from author?](https://github.com/w3c/aria/issues/2075) 16:02:18 agenda+ [Trim whitespace from computed accessible name/description](https://github.com/w3c/accname/issues/95) 16:05:57 StefanS has joined #aria 16:06:07 present+ 16:09:07 q+ 16:09:14 q+ 16:33:06 q? 16:33:21 q+ 16:40:13 StefanS has left #aria 16:40:13 ack StefanS 16:40:15 ack jongund 16:40:21 q? 16:58:01 Francis_Storr has joined #aria 17:01:12 katez has joined #aria 17:01:42 giacomo-petri has joined #aria 17:01:48 CurtBellew has joined #aria 17:01:55 present+ 17:02:38 aardrian has joined #aria 17:02:42 present+ 17:03:10 jongund has joined #aria 17:03:28 Mario_B has joined #aria 17:03:57 present+ 17:04:01 present+ 17:04:04 present+ 17:04:18 scribe: Rahim 17:04:39 scribe+ 17:04:46 ray-schwartz has joined #ARIA 17:04:59 siri has joined #aria 17:05:12 Doug has joined #aria 17:05:12 zakim, next item 17:05:13 agendum 1 -- [New Issue Triage](https://tinyurl.com/2j7n7te8) -- taken up [from jamesn] 17:05:14 Summer has joined #aria 17:05:53 spectranaut_: For aria #2173, this person is seeing a difference between Chrome/Firefox for these
  • elements 17:06:10 present+ 17:06:27 Matt_King has joined #aria 17:06:35 present+ 17:07:09 keithamus: the concern sounds like the DOM tree would have the custom elements and
  • s (which are slotted); the a11y tree reflects Shadow DOM but it's not working as expected 17:07:29 q+ 17:07:30 scotto has joined #aria 17:07:30 spectranaut_: may need more of a discussion, or point to incorrect/wrong use of Shadow DOM 17:07:34 q+ 17:07:52 keithamus: worth taking to the HTML tracker? 17:08:04 q? 17:08:07 q- 17:08:08 jamesn: Where's the ARIA impact of this issue? 17:08:08 sarah has joined #aria 17:08:13 present+ 17:08:25 Mario_B has joined #aria 17:08:46 present+ 17:08:50 scotto: Could be an implementation issue from Firefox; may not be directly Shadow DOM related. Likely a bug against Firefox 17:08:54 Summer has joined #aria 17:08:57 q? 17:09:00 ack sarah 17:09:03 ack scotto 17:09:09 +1 not ARIA issue 17:10:09 spectranaut_: for ARIA #2168, should we agenda+? 17:11:11 zakim, next item 17:11:11 agendum 2 -- [New PR Triage](https://tinyurl.com/3v3y8x5v) -- taken up [from jamesn] 17:11:28 present+ 17:12:00 spectranaut_: accname #236 looks like a simple change; does anyone want to weigh in (review)? 17:13:05 HaTheo has joined #ARIA 17:13:18 present+ 17:13:25 aardrian: add me as a reviewer (along with spectranaut_ ) 17:13:43 sarah: add me too 17:14:04 Present+ 17:14:18 spectranaut_: aria #2171: we need reviewers for this as well 17:14:26 jamesn: I can review it 17:14:34 Theo: I can review as well 17:15:02 spectranaut_: Reviews are a nice way to learn the spec 17:16:37 spectranaut_: aria #2170: already reviewed by Peter/Sarah; does anyone else want to take a look? 17:16:52 Theo: I can take a look 17:19:05 sarah: core-aam #229, will be closed 17:19:13 q? 17:19:21 q+ 17:19:22 q+ 17:20:12 I 17:21:20 is "undefined" allowed as a value (string) for an ARIA property or state? 17:21:32 Rahim: is "undefined" allowed as a value (string) for an ARIA property or state? 17:21:46 q+ 17:22:35 scotto: Specifying undefined on aria-expanded has been valuable if you had a button that allows a control to expand/collapse in certain context; by putting undefined on there, some browsers will prompt a11y tree to wait for a value and it just works (as opposed to putting true or false and changing as a result of user activation, it would not be exposed). in rare cases, I've found it to be useful 17:22:57 Matt_King: it almost sounds like you're relying on an implementation quirk to specify the behavior 17:23:43 ...I thought it meant the same thing as aria-expanded not being present? 17:23:49 ack sarah 17:24:20 fzorzi has joined #aria 17:24:40 sarah: I'm reading true/false/undefined, e.g., false is different than undefined in some contexts 17:25:09 q- 17:25:16 ack scotto 17:25:24 Rahim: the original issue lists out what each state/property means for "undefined" 17:25:44 scotto: just wanted to call out that "undefined" as a written value was intended to be useful; need to clarify if it shouldn't be a valuable 17:26:08 zakim, next item 17:26:08 agendum 3 -- [WPT Open PRs](https://bit.ly/wpt_a11y) -- taken up [from jamesn] 17:26:11 Rahim do you mind adding that issue to IRC. I would love to look at this. 17:26:53 Rahim: wpt #45916, I can review this one 17:26:59 zakim, next item 17:26:59 agendum 3 was just opened, Rahim 17:27:44 zakim, close this item 17:27:44 agendum 3 closed 17:27:45 I see 6 items remaining on the agenda; the next one is 17:27:45 4. [Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates) [from jamesn] 17:27:58 zakim, close this item 17:27:58 I do not know what agendum had been taken up, Rahim 17:28:07 zakim, next item 17:28:07 agendum 4 -- [Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates) -- taken up [from jamesn] 17:28:14 zakim, close this item 17:28:14 agendum 4 closed 17:28:15 I see 5 items remaining on the agenda; the next one is 17:28:15 5. [Remove aria-expanded from listbox](https://github.com/w3c/aria/pull/1862) [from jamesn] 17:28:17 zakim, next item 17:28:17 agendum 5 -- [Remove aria-expanded from listbox](https://github.com/w3c/aria/pull/1862) -- taken up [from jamesn] 17:29:24 spectranaut_: I've opened issues against browsers (and opened a Validators issue) but there appears to be pushback from Wilco 17:30:09 q+ 17:30:18 ...there has been lots of discussion on deprecation vs. removal in the past. I'd like to hear consensus from the WG more clearly that we'd want to do this against the wishes of Deque's axe 17:30:26 q++ matt 17:31:08 ack matt 17:31:13 ack + 17:31:37 Matt_King: I thought that if we put this in the "deprecated" that it would not invalidate current usage; it would be flagged but it means we could remove it in the future or perhaps make it throw a warning. Not understanding why it would be a problem (i.e., a problem for us to mark it as deprecated in the same way we did changing the global properties to non-global) 17:31:42 ack scotto 17:31:52 scotto: just to clarify, this PR is for removal and not deprecation 17:32:14 Matt_King: I would support deprecation if that's the only consensus path forward 17:33:11 scotto: I put this in the issue as well but we've deprecated other stuff so we can do it for this one too; raises the question of when will it be OK to actually remove stuff from the spec? Does path to removal need to be one point removal and then subsequently removed? Reason for deprecation is because we don't want people to use it anymore 17:33:43 scotto: I don't think the spec should be held up because a validator is using it 17:33:59 spectranaut_: we talked about a deprecation section in a previous F2F meeting. Perhaps this is the time to make this happen 17:34:16 spectranaut_: making a deprecation section is a bigger project 17:34:30 jamesn: wasn't Wilco going to give us a list of deprecation items? 17:35:38 spectranaut_: we should chase this, I can look into after this meeting. I can find where it's referenced/discussed in the past. It sounds like we do want a deprecation section which sounds like a separation issue. Do we want to put this aria-expanded in the deprecation section immediately, or mark it as deprecated in the tables? 17:35:54 spectranaut_: eventually we do want to remove it from the spec 17:36:54 Theo: I had a question; the purpose of this deprecation section is to serve as a final warning before user agents remove it. What's the idea here? Is the criteria to put it in this deprecation section, i.e., that it doesn't have significant usage. Is there a measurable criteria for how we do things differently between the two 17:37:50 spectranaut_: my understanding is that deprecation section is stuff that we want to remove from spec due to no/poor support so we don't want users to think if it's supported. E.g., what happened to this attribute that used to be allowed and why it is no longer (in the spec); Validators can point back to the spec on why something is no longer supported 17:38:15 Theo: the practice today is to put something in the table (characteristics table?); how should people read that differently 17:38:50 scotto: the idea of the deprecation section was to avoid having "deprecated" sprinkled throughout the spec. Instead, could have a dedicated section whether it be roles/attributes. Now, you don't know if it's deprecated, have to look for it/find it in spec 17:39:53 spectranaut_: now, given that we have a deprecation section, do we put in the deprecation table? Rather than leave it in the tables under "listbox". Any objections? 17:40:00 Theo: makes sense to me 17:40:05 zakim, next item 17:40:05 agendum 6 -- [Complex dashboards and standalone cards](https://github.com/w3c/aria/issues/2162) -- taken up [from jamesn] 17:41:36 Q+ 17:41:48 giacomo-petri: about 2 weeks ago, we discussed a similar issue raised by Mario B. I realized this issue may be 2 separate topics. I'm not advocating for a new role but trying to indicate situations where you have an iframe embedded within a page, i.e., treat a region of content separate from the underlying content. Need this for users and currently no way to do so currently 17:42:20 ...I think it would be beneficial authors to enable users to understand this kind of context, i.e., once something is updated, it's changing/updating some specific area of the page and not the whole page 17:42:26 ack aardrian 17:42:45 aardrian: I understand that you've compared this to an iframe...is this comparison a visual comparison? 17:43:02 ...would it fair to say a better analog may be a "group" or "region" role? 17:44:03 q+ 17:44:08 (for minutes on previous topic about deprecation - this is where this was discussed at TPAC - https://www.w3.org/2023/09/14-wcag-act-minutes#t03 ) 17:44:15 giacomo-petri: the problem is that if you have a link inside a region, it will update the entire page and not the content of the region. Thinking of this in the context where we have cards in a complex dashboard, when you start interacting with a card, only the content in that card will be updated...you could move the focus around but it's not exactly the same as an iframe. If you navigate an iFrame with an AT like VO, it announces "frame" and 17:44:15 dwell into/out of the frame so you can consciously interact with just that island of content 17:44:17 https://codepen.io/Giacomo-Petri/full/JjVejaP 17:44:50 spectranaut_: what is the role when you navigate to an iframe? (group says that it is "document") 17:45:10 q+ 17:45:26 sarah: iframe is a document; but an iframe nested inside a document doesn't necessarily get exposed (but does confine virtual cursor) 17:45:28 ack sarah 17:47:03 Q+ 17:47:10 jongund has joined #aria 17:47:21 q- 17:47:37 sarah: we've been discussing this at Microsoft in the context of chat messages; having conversations if SR behaviors should confine cursor (can also restrict AT shortcuts e.g., heading navigation). I think we should approach any attempt to create semantic (role-based) approach for confining with caution as it could have wide-ranging side effects. Not sure it's possible to confine virtual cursor to a region without side effects, should be 17:47:37 approached by authors with lots of caution. I'm not sure how much we want that outside of role="application" 17:47:39 ack CoryJoseph 17:48:37 CoryJoseph: just to add onto what Sarah said; it sounds like a modal type of experience without being a modal...the ideal scenario sounds like a help or tutorial panel that sits right/left of a page in a desktop; you'd be consuming and interacting with the help panel. To Sarah's point, you'd be totally confined in the panel or that region and not able to navigate back/forth what you're consuming and the content of the page as needed 17:48:55 +1 to the comparison with modal, that's a good one 17:50:07 q? 17:50:13 q+ 17:50:17 giacomo-petri: I'm not sure what is expected from the author; how can the author convey these types of behaviors to AT users besides focus management? Is the author only responsible to move the focus around and is this enough to communicate what is happening on the page to users? can't use a modal interaction because it would trap the user inside. E.g., you could be working on card 1 and at some point, move to card 3; the actions are 17:50:17 independent and what you do in card 1 doesn't impact other cards. This is just an example but it could be a panel or dashboard 17:50:42 CoryJoseph: it sounds like a region or section to me; something that announces or makes it clear that you're in a distinct area 17:51:12 giacomo-petri: is it fine to update the content of a single region without communicating to a user. If I activate a link for such a region, would they expect entire page to reload (or just a change to that region)? 17:51:54 Dropping thoughts here owing to time: I think there is merit to exploring this, but I think the expectations need to be more clearly defined. 17:52:01 q+ 17:52:05 ack spectranaut_ 17:52:06 spectranaut_: it sounds like there's a few concrete things that need solving; e.g., interacting with a card only updates that region of content. Perhaps it would be better to have the individual user interactions that are difficult, that you want resolved by this issue, describe how they can be resolved in different ways 17:53:03 ack Mario_B 17:53:06 giacomo-petri: I don't think trapping a user inside a card provides the same experience to all users. The intent is to provide a semantic role that allows users to predict what will happen as a consequence of interacting with particular content. To me, simple landmark doesn't convey the purpose of the changing functionality of the card short of providing a description for the card at the beginning (e.g., "activating one of the card's controls 17:53:06 will...") 17:54:23 Mario_B: I think this is very similar to tiles/cards in the dashboard proposal made by me because it's not important how the tile is visualized (looks?)...it's an area where you work within and has contents that you can choose/change and all other cards in this dashboard stay unchanged. Why couldn't we have a tile or card role for this instance? 17:54:54 giacomo-petri: I don't like the idea of card styles because it is restricted to the visual experience. I'm curious if there is something we can add regardless of the visual appearance of the element, e.g., a landmark region that only updates the content inside 17:55:07 q- 17:55:37 q+ 17:56:04 ...also regarding Sarah's feedback, the idea of an iframe is to convey something that updates without changing the other areas of the page; rather, it was the idea of content that updates regardless of the rest of the page. I'm not saying that when you're inside this card, you only convey the contents of this particular region 17:56:11 ack sarah 17:56:33 +q 17:56:43 jongund has joined #aria 17:57:31 ack HaTheo 17:57:46 sarah: my question is, when you say "convey", are you looking for a new role with localized role name? I can't think of one that would convey this idea as it's pretty abstract so what does it mean to "convey" that? Also, curious about how a nested role="document" without an intervening role="application" element would behave 17:58:12 Theo: I'm curious what the sighted user would see; is it more about indicating that the content is updated after a link is pressed? 17:59:09 giacomo-petri: if you interact with a single card/item, you immediately realize that only one card is updated. For SR users, you don't know what happening even if focus is being managed because you don't have overall context of the page. I.e., that interacting with a particular card only updates that card and not others 17:59:28 spectranaut_: it sounds like there is more to discuss here. What are next steps? 17:59:39 ...can put the deepdive label on it and get more detail on the issue 18:00:19 present+ 18:02:13 bkardell_ has joined #aria 18:03:06 rrsagent, make minutes 18:03:07 I have made the request to generate https://www.w3.org/2024/05/02-aria-minutes.html Rahim 19:37:26 jongund has joined #aria 20:42:29 jongund has joined #aria 20:59:48 jongund has joined #aria 23:29:15 jongund has joined #aria