16:57:59 <RRSAgent> RRSAgent has joined #aria
16:58:03 <RRSAgent> logging to https://www.w3.org/2026/08/20-aria-irc
16:58:03 <Zakim> RRSAgent, make logs Public
16:58:04 <Zakim> Meeting: ARIA WG
16:58:17 <jamesn> Agendabot, find agenda
16:58:17 <agendabot> jamesn, OK. This may take a minute...
16:58:18 <agendabot> agenda: https://www.w3.org/events/meetings/690d057f-db6d-4169-b13f-68d7f1336b59/20260820T130000/
16:58:18 <agendabot> clear agenda
16:58:18 <agendabot> agenda+ -> New PR Triage https://github.com/search?q=is%3Aopen+is%3Apr+created:%3E=2026-08-13+repo:w3c/aria&type=Issues
16:58:18 <agendabot> agenda+ -> WPT Open PRs https://tinyurl.com/wpt-a11y
16:58:21 <agendabot> agenda+ -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates
16:58:24 <agendabot> agenda+ -> Updated on: Add explicit language and direction metadata to AriaNotificationOptions https://github.com/w3c/aria/issues/2828
16:58:27 <agendabot> agenda+ -> With overflow:clip and line-clamp CSS properties, users of AT have a very different content experience than sighted users have https://github.com/w3c/css-aam/issues/29
16:58:30 <agendabot> agenda+ -> Unclear purpose of aria-valuemin and aria-valuemax when aria-valuetext is used https://github.com/w3c/aria/issues/1128
17:00:08 <filippo-zorzi> filippo-zorzi has joined #aria
17:00:16 <Jacques> Jacques has joined #aria
17:00:39 <Steven_Lambert> Steven_Lambert has joined #aria
17:00:45 <ZakK> ZakK has joined #aria
17:01:02 <front-endian-jane> front-endian-jane has joined #aria
17:01:21 <spectranaut_> spectranaut_ has joined #aria
17:01:23 <giacomo-petri9> giacomo-petri9 has joined #aria
17:01:32 <giacomo-petri> giacomo-petri has joined #aria
17:01:38 <giacomo-petri> present+
17:01:42 <front-endian-jane> present+
17:01:44 <front-endian-jane> scribe+
17:01:45 <filippo-zorzi> present+
17:01:53 <ZakK> present+
17:02:00 <aardrian> aardrian has joined #aria
17:02:13 <aardrian> present+
17:02:27 <dgrogan> dgrogan has joined #aria
17:02:38 <front-endian-jane> zakim, next item
17:02:38 <Zakim> agendum 1 -- -> New PR Triage https://github.com/search?q=is%3Aopen+is%3Apr+created:%3E=2026-08-13+repo:w3c/aria&type=Issues -- taken up [from agendabot]
17:02:38 <github-bot> I can't comment on that because it doesn't look like a github issue to me.
17:02:49 <Jacques> present+
17:03:20 <dgrogan> present+
17:03:58 <front-endian-jane> jamesn: 2869 needs another reviewer
17:04:02 <HaTheo> HaTheo has joined #ARIA
17:04:11 <front-endian-jane> Jacques: I can take it up
17:04:27 <HaTheo> Present+
17:05:05 <front-endian-jane> jamesn: 2868 is a pdf-aam one so our group may not need to look at it
17:05:31 <front-endian-jane> spectranaut_: Do we want to keep pdf-aam as things we look at on this call?
17:06:02 <front-endian-jane> ZakK: While we don't need it for this PR, I think future PRs may need review from y'all for how we want to map things.
17:06:55 <front-endian-jane> jamesn: Current mapping documents map the reality of how things are currently mapped with user agents. We don't ofter review what the Apple mappings are for HTML elements for example. I don't know if that will be similar here. We aren't experts in this.
17:07:31 <front-endian-jane> ZakK: We may need the groups help if there are things where the mappings aren't clear or there isn't a mapping. Y'all can help us map things.
17:07:35 <front-endian-jane> zakim, next item
17:07:35 <Zakim> agendum 2 -- -> WPT Open PRs https://tinyurl.com/wpt-a11y -- taken up [from agendabot]
17:07:35 <github-bot> I can't comment on that because it doesn't look like a github issue to me.
17:08:16 <HaTheo> q+
17:08:42 <front-endian-jane> jamesn: 61929 for WPT tests
17:10:00 <front-endian-jane> HaTheo: I did some testing on this and it is inconsistent across browsers. Agree that this PR is needed even though area tags aren't common. Chrome doesn't handle onclick the same as Firefox. Happy to review this and add comments since I was reviewing something similar from Lola.
17:10:01 <katez> katez has joined #aria
17:10:05 <katez> present+
17:10:51 <front-endian-jane> jamesn: 61892 is administrative so we don't need to worry about it
17:10:54 <front-endian-jane> zakim, next item
17:10:54 <Zakim> I see a speaker queue remaining and respectfully decline to close this agendum, front-endian-jane
17:11:01 <jamesn> Ack ha
17:11:03 <front-endian-jane> zakim, next item
17:11:03 <Zakim> agendum 3 -- -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates -- taken up [from agendabot]
17:11:03 <github-bot> I can't comment on that because it doesn't look like a github issue to me.
17:11:38 <front-endian-jane> jamesn: I don't think we have anything for deep dive planning today
17:12:06 <front-endian-jane> spectranaut_: On the 3rd during the deep dive session we'll do a new member orientation since we've had a lot of new members join
17:12:25 <front-endian-jane> jamesn: Since we are getting closer to TPAC I think we should replace this meeting item in future meetings with TPAC planning
17:12:27 <front-endian-jane> zakim, next item
17:12:27 <Zakim> agendum 4 -- -> Updated on: Add explicit language and direction metadata to AriaNotificationOptions https://github.com/w3c/aria/issues/2828 -- taken up [from agendabot]
17:12:28 <aardrian> +1
17:13:21 <Stefan> Stefan has joined #aria
17:13:25 <Stefan> present+
17:13:38 <Daniel> present+
17:13:40 <Daniel> q+
17:14:01 <front-endian-jane> spectranaut_: Last week we met with the i18n working group and they decided it was okay to not include the metadata in the aria notify options but they requested that we make the reasons why very clear. Daniel outlined this in the PR we discussed earlier in this meeting.
17:14:20 <front-endian-jane> jamesn: So that PR was covering security and i18n things?
17:15:13 <front-endian-jane> Daniel: Yes, it includes both. For now we have an example expanding on the existing spin button example which doesn't have much to do with several languages but jcraig has suggested we should add another example in the ARIA practices guide.
17:15:30 <front-endian-jane> Matt King: We also have a tabs example and one more.
17:15:57 <front-endian-jane> jamesn: I am not sure we want to rely on an example that also relies on Aria notify since that may not ship in this version of the spec.
17:15:58 <Jacques> Jacques has joined #aria
17:16:01 <Jacques> q+
17:16:16 <front-endian-jane> Matt King: What would be the requirements of the example for this to be good?
17:16:34 <jamesn> Ack d
17:16:41 <jamesn> Ack ja
17:16:53 <front-endian-jane> Jacques: Are the changes we are making the the ARIA notify spec going to be sufficient to address that concern? Maybe we don't need to update this?
17:17:58 <front-endian-jane> jamesn: That is my understanding of what Daniel said in his PR in the ARIA notify section. The example in there shows multiple languages. I think that is reasonable for now assuming the i18n folks agree. The ARIA practices issue can be filled for the future to add this.
17:18:10 <front-endian-jane> spectranaut_: There is already an issue filled for this.
17:18:33 <front-endian-jane> spectranaut_: I added a comment to the ARIA notify example one to add an i18n example.
17:18:53 <front-endian-jane> @jn PR 2869 needs another reviewer
17:19:03 <front-endian-jane> zakim, next item
17:19:03 <Zakim> agendum 5 -- -> With overflow:clip and line-clamp CSS properties, users of AT have a very different content experience than sighted users have
17:19:05 <Zakim> ... https://github.com/w3c/css-aam/issues/29 -- taken up [from agendabot]
17:19:21 <front-endian-jane> s/@jn PR 2869 needs another reviewer/ /
17:19:41 <front-endian-jane> jamesn: We briefly discussed this in triage last week
17:21:11 <giacomo-petri> q+
17:21:15 <HaTheo> q+
17:21:21 <jamesn> q+
17:21:31 <front-endian-jane> JohnJansen: I added 3 examples to the github issue. We want confirmation and tests written that the way we want this to behave is that truncation isn't read by assistive technologies, the full item is read even when a truncation is rendered to the screen.
17:21:34 <Matt_King> Matt_King has joined #aria
17:21:38 <jamesn> Ack giacomo-petri
17:21:59 <Matt_King> present+
17:22:15 <aardrian> Q+
17:22:38 <front-endian-jane> giacomo-petri: There is often a "more" button to see all the text, but for screen reader users that is useless because everything is already readable to them. Maybe there should be a CSS property to also hide the text to assistive technologies?
17:23:06 <front-endian-jane> JohnJansen: Interesting proposal, I can file an issue for it, but that is orthogonal to this particular issue.
17:23:11 <Matt_King> q+
17:24:43 <jamesn> Ack HaTheo
17:24:58 <front-endian-jane> JohnJansen: The current behavior of everything being read by ATs is how it works in every browser and has many reasons to work that way. I need an expert to confirm that it is supposed to work that way and we should write a test to enforce that.
17:25:57 <jamesn> Ack jamesn
17:26:07 <front-endian-jane> HaTheo: Yes, we very much want it to work this way. Some people use screen readers and zoom the text in at the same time. It's annoying to have to click a button to read the rest as a screen reader user. there are some corner cases that have to be thought of but I don't recommend changing this.
17:27:52 <front-endian-jane> jamesn: I don't think we could change because it's been this way for so long. Yes this is a good expected behavior. I also think it would be worth adding a way to hide truncated text as giacomo-petri recommended. You also get into weird situations when there are hover to show more interactions. We should think about how to make all that better.
17:28:06 <jamesn> Ack aardrian
17:29:26 <jamesn> q+ to loop back on the scrolling area thing
17:29:40 <front-endian-jane> aardrian: Largely I agree with what jamesn and HaTheo said, but issue mostly talks about screen reader experiences and concerns, but this impacts many other AT users. The issue should also note that some screen reader users are sighted. Should there be a separate conversation about making clipping keyboard accessible the same way scrollable regions are?
17:29:47 <jamesn> Ack Matt_King
17:30:22 <Daniel> s|issue filled for this|-> https://github.com/w3c/aria-practices/issues/3414 issue filled for this|
17:30:58 <front-endian-jane> Matt_King: I get that it has worked this way for a long time, but to me it feels like it causes a lot of problems for real screen reader users like me. I can't tell what parts are visible and what parts aren't. I can't tell that clipped content is being read to me in the examples given.
17:31:12 <front-endian-jane> JohnJansen: I can fix that in the examples.
17:32:16 <front-endian-jane> Matt_King: The clipped content can be anything, even interactive elements, right?
17:32:21 <front-endian-jane> JohnJansen: Correct.
17:32:57 <jamesn> Q-
17:32:58 <HaTheo> yes the clip might even be the name of a button.
17:34:07 <front-endian-jane> Matt_King: This is where I've run into problems, when the volume of content is large and the reasons it is clipped is it's in a collection of some kind. It makes it hard to skip to the content you want to get to that isn't clipped since you have to wade through all the clipped content. I canm
17:34:17 <jamesn> Q?
17:34:44 <Jacques> Jacques has joined #aria
17:34:50 <front-endian-jane> s/I canm/I can't tell when it is or isn't clipped so I don't always know when this is causing problems/
17:35:04 <HaTheo> +1  to giving authors a way of clipping that might be more friendly and better.
17:35:30 <front-endian-jane> q+
17:35:35 <jamesn> q+
17:35:55 <front-endian-jane> JohnJansen: I can take all this back to the group, and we need to think about having some way to hide the more button with a CSS property, We also may need a way to make it possible to hide clipped content to ATs for some cases.
17:36:07 <jamesn> Ack front-endian-jane
17:36:24 <Matt_King> q+
17:37:09 <jamesn> Q-
17:37:17 <jamesn> Ack Matt_King
17:37:27 <aardrian> pretend "keyboard user" includes voice users as well
17:37:50 <jamesn> Switch user too
17:37:57 <front-endian-jane> front-endian-jane: There could be a lot of issues for people who are sighted screen reader users if we give an option to hide things like a "more" button when content is clipped but read because they would lose AT access to the more button, but still see it and may still want to click it.
17:38:34 <giacomo-petri> +1 to Matt_King
17:38:49 <giacomo-petri> q+
17:38:50 <front-endian-jane> Matt_King: We definitely want a way to clip content for AT users too since often content is being clipped to reduce how busy the page is, reduce cognitive overload, etc.
17:38:58 <jamesn> Ack gia
17:39:03 <front-endian-jane> jamesn: There is definitely a problem to be solved that isn't solved today.
17:39:21 <front-endian-jane> Matt_King: We want to think of clipping as not just a visual thing.
17:40:03 <jamesn> agenda?
17:40:04 <front-endian-jane> giacomo-petri: Having an additional property may be essential for authors to make good show/hide UI's and to properly control their UX in the way they intend. A lot to think about on this.
17:40:13 <front-endian-jane> zakin, next item
17:40:19 <front-endian-jane> zakim, next item
17:40:19 <Zakim> agendum 6 -- -> Unclear purpose of aria-valuemin and aria-valuemax when aria-valuetext is used https://github.com/w3c/aria/issues/1128 -- taken up [from agendabot]
17:40:30 <front-endian-jane> s/zakin, next item/ /
17:42:40 <jamesn> q+
17:43:28 <front-endian-jane> Matt_King: For a while I've thought that we've had to make changes to ARIA around this. If aria-valuetext is specified, valuemin and valuemax should not be required. We may want to add aria-valuemintext (or aria-textvaluemin). AT don't really know what to do right now and they can generate some results when things are mixed that make no sense.
17:44:59 <Jacques> q+
17:45:06 <front-endian-jane> jamesn: I think I support most of what Matt_King is saying. Saw this causing weird behavior in an app the other day. My off the cuff proposal would be that value min/max/now are a group. If you specify all three the AT could give a percentage. If you specify valuetext and the min/max/now you want to read the text and the percentage. Just some off the cuff ideas to spark discussion.
17:45:07 <HaTheo> specifying only value text might not give an idea of the range and options, but need to think more.
17:45:09 <jamesn> ack me
17:46:06 <Jacques> https://github.com/w3c/aria/issues/2631
17:46:24 <front-endian-jane> Jacques: Not too much to add but I wanted to bring up this other issue that Sarah  brought up (2631).  2290 may be related too.
17:46:27 <jamesn> Q?
17:46:34 <jamesn> Ack ja
17:47:12 <front-endian-jane> Matt_King: It feels like we have agreement here so a PR could be brought forward for this. Shouldn't be a huge lift? I might be willing to work on this if it wouldn't be too late for 1.3
17:47:37 <front-endian-jane> jamesn: Yes, post 1.3 we are moving to evergreen so it could go in as a single feature.
17:48:00 <front-endian-jane> Matt_King: I can take up making a PR and driving it forward.
17:49:00 <front-endian-jane> zakim, end meeting
17:49:00 <Zakim> As of this point the attendees have been giacomo-petri, front-endian-jane, filippo-zorzi, ZakK, aardrian, Jacques, dgrogan, HaTheo, JohnJansen, katez, Stefan, Daniel, Matt_King
17:49:04 <Zakim> RRSAgent, please draft minutes v2
17:49:05 <RRSAgent> I have made the request to generate https://www.w3.org/2026/08/20-aria-minutes.html Zakim
17:49:08 <Zakim> I am happy to have been of service, front-endian-jane; please remember to excuse RRSAgent.  Goodbye
17:49:10 <Zakim> Zakim has left #aria