18:02:52 RRSAgent has joined #aria-apg 18:02:56 logging to https://www.w3.org/2025/04/15-aria-apg-irc 18:03:00 rrsagent, make minutes 18:03:01 I have made the request to generate https://www.w3.org/2025/04/15-aria-apg-minutes.html Jem 18:03:48 rrsagent, make log public 18:03:52 scribe+ jugglinmike 18:04:00 https://github.com/w3c/aria-practices/wiki/April-15%2C-2025-Agenda 18:04:04 meeting: ARIA Authoring Practices Task Force Weekly Teleconference 18:05:43 topic: Setup and Review Agenda 18:05:54 present+ Matt_King 18:06:00 present+ lola 18:06:04 present+ jongund 18:06:08 present+ Adam_Page 18:06:12 present+ howard-e 18:06:19 present+ arigilmore 18:06:22 CurtBellew has joined #aria-apg 18:06:25 present+ CurtBellew 18:07:19 Matt_King: Any requests for change to agenda? 18:07:27 Matt_King: Hearing none, we'll stick with the agenda as planned 18:07:32 Matt_King: Next meeting: April 22 18:07:35 present+ 18:07:38 Topic: Publication planning 18:07:55 Matt_King: We may or may not be ready for a publication on April 29 18:08:08 Matt_King: We have nothing ready, yet, but there are two things that are awaiting review 18:08:24 Matt_King: One is a minor editorial change, and I think we had a reviewer assigned to it. It's issue 3252 18:08:33 https://github.com/w3c/aria-practices/pull/3252 18:08:49 Matt_King: We've requested a review from jongund and siri 18:09:04 Matt_King: This is a super-simple pull request, and I think even just one reviewer would be satisfactory 18:09:19 jongund: I'll look at it 18:09:21 Matt_King: Thank you 18:09:35 Matt_King: Then there's the massive one which jongund has been doing most of the work on. Issue 2191 18:09:47 s/2191/2991/ 18:09:49 https://github.com/w3c/aria-practices/pull/2991 18:10:05 Matt_King: I'm still unsure of how we make this actionable for people 18:10:13 Matt_King: I'll write down my thinking, though 18:10:20 Matt_King: And I'd appreciate input from others, as well 18:11:00 Matt_King: In this section where we're talking about contrast themes--I'm trying to figure out how to give readers explicit concrete things they can do in order to make it approachable 18:11:15 Matt_King: I want the consequences of the advice to be clear 18:11:27 jongund: I've broken it up into three sections 18:12:51 Matt_King: What about the effects of CSS (the "gotchas," etc), like we have in some of the other articles we've written? 18:13:00 jongund: I've placed that kind of information in the table 18:15:37 Matt_King: When I'm reading this, I have to get my head back into the space by reviewing the references. I want to make sure that the key points aren't lost in the sort of "giant forest" of information 18:16:00 Matt_King: I'm interested in what other people have emphasized on these topics--the people who are writing to a similar audience 18:17:04 Matt_King: This is an area where I am just as much a student as anything else. It's not part of my daily milieu 18:17:47 Matt_King: As a practical matter, in terms of getting this published, I really welcome feedback from other contributors--especially arigilmore and CurtBellew 18:17:59 Matt_King: In particular, any advice on making it more actionable would be great 18:18:13 Topic: Issue 3257 - Potential bug with vertical temperature slider 18:18:21 github: https://github.com/w3c/aria-practices/issues/3257 18:18:38 Matt_King: The text of the value is exposed in two different ways in this slider 18:19:19 Matt_King: Because one of those pieces of text is outside of the slider, and because it is a value, the user has to press multiple down "arrow keys" to get into the slider 18:20:10 Matt_King: The first SVG element which contains the value (and says "degrees c"), but the aria-value text says "degrees Celsius". They don't agree with each other, and that was one part of the feedback 18:20:39 Matt_King: The question is: do we need both of these representations of the value? 18:20:53 Matt_King: And would it be possible to only have the representation of the value inside of the slider? 18:21:07 Matt_King: It doesn't seem like a good practice, from an accessibility standpoint, to have this duplication 18:21:41 jongund: In the original design, we only had the text outside of the slider. We added the value by the thumb so that folks with low-vision could see the value while they move it 18:22:02 Matt_King: How much zooming would someone have to do before they could no longer see the value that is right next to the thumb? 18:22:07 jongund: That's the one they will see? 18:22:28 Matt_King: I mean how much zooming will they need to do before they cannot see the value which is outside 18:22:31 jongund: I'm not sure 18:22:56 Matt_King: I'm just not certain that the justification is relevant in practice (rather than being purely theoretical) 18:23:22 Adam_Page: Depending on the context (e.g. the vertical position), I think it could be easy for the temperature value which is adjacent to the label to no longer visible 18:23:53 Matt_King: It's kind of like we have temperature, followed by the current value, followed by a thermometer (which also shows its value) 18:23:57 Jem: That's right 18:24:48 jongund: The label at the top is more traditional 18:24:59 jongund: We could put aria-hidden on the text 18:25:12 Matt_King: I've been really reluctant to use aria-hidden in that way 18:25:27 Matt_King: I'd prefer the duplicate text over aria-hidden 18:25:57 Matt_King: One could argue that it's decorative... But it's not a graphic--it's text! 18:26:29 Adam_Page: I'd vote to just kill the value at the top altogether. I'm not sure I see the usefulness in it 18:26:54 Adam_Page: The value in the handle is persistent, it's always there and always perceptible--not only in the moment of interaction, but also after the value has been set 18:27:01 Matt_King: What is the rationale for the label at the top? 18:27:42 jongund: I don't remember why. It was a while ago. It was probably a feature on other vertical sliders that we reviewed in the real world. 18:28:27 Jem: As a visual user, the justification for me is that it is easier to see what the temperature value is. I can see it as rendered by the thumb, but the label at the top is easier to understand 18:28:48 Matt_King: How do you move the thumb without seeing the value next to the thumb? 18:29:16 Matt_King: You have to be able to look at the thumb to move it, right? 18:29:24 jugglinmike: Well, you can move it using the keyboard 18:30:41 jugglinmike: In the ARIA-AT community group, there was some concern that the value which moves with the thumb could be difficult for users who prefer less motion 18:31:23 jongund: The color slider example has a value which appears alongside the thumb and moves with it as it changes 18:31:53 jongund: It's probably more uncommon to have the value next to the thumb. Maybe the value next to the thumb should only be there when you are interacting 18:32:04 Matt_King: That wouldn't address the issue for screen readers 18:32:32 Matt_King: I'm hearing that there are justifiable reasons for all the alternatives--that there are valid trade-offs here 18:33:03 Matt_King: I'm hearing consensus that there isn't a compelling reason to change this, and there are some potentially-compelling reasons not to change it 18:33:36 Matt_King: For some users, the value next to the thumb is useful. And for others, the value at the top provides greater accessibility 18:34:50 Adam_Page: I think the issue is based on the fact that visually, it is "11.9 C" and the value text is "11.9 Celsius"? 18:35:11 Matt_King: I don't think that's a major issue here. It's part of the question, but I don't think it's important 18:35:44 Matt_King: We could change the value text to match the visual text, but I don't think that's a bad practice for the value text to be more explicit (because you don't know how a screen reader is going to read "degrees C") 18:35:51 Jem: That's what we had for the calendar, too 18:36:04 s/Adam_Page:/CurtBellew:/ 18:38:10 Matt_King: Screen readers can't de-dupe the value that is above because they don't know that it is a value 18:38:33 Matt_King: Theoretically, a screen reader could skip over the word "temperature" (although none of them do currently) because it knows the word "temperature" is part of the label 18:38:47 Matt_King: But the screen reader can't know that "25 degrees C" is part of the value 18:38:53 Matt_King: So it's kind of a semantically ambiguous element 18:39:01 Matt_King: But I don't think there's a reason for not having it 18:39:25 CurtBellew: When I try, VoiceOver represents them in the same way 18:39:29 Matt_King: Yeah, so does JAWS 18:39:52 Matt_King: It doesn't sound like we have compelling consensus for change, and there are more voices in this conversation saying "don't change it" 18:41:14 jugglinmike: But the color viewer slider only has a value that moves with the thumb. Shouldn't our decision apply to both patterns? 18:41:30 Adam_Page: And ditto for the multi-value slider I saw (which is also horizontal) 18:41:49 Adam_Page: Maybe we would justify this approach for a vertical slider specifically 18:42:21 CurtBellew: When I'm using the vertical slider on my phone, my thumb gets in the way. That's not the case with the horizontal slider 18:42:41 Adam_Page: I hear that. Although we could perhaps adjust the positioning of the vertical slider to account for that... 18:43:24 Matt_King: One approach I was imagining is that we don't have the value besides the thumb, and the value above is part of the slider itself (as a element hierarchy perspective) 18:44:35 Matt_King: The horizontal sliders have their value above the thumb--there's actual text above the thumb. It doesn't get duplicated when you read it, I'm assuming because it is a child of the slider element 18:45:45 Matt_King: Even if you wanted to show the value in two different places while the thumb was being moved on the vertical temperature slider, would it be possible to make the value that is above as a child of the slider? 18:46:10 jongund: That's pretty subtle. Would you tell people you did that intentionally for this purpose? 18:46:20 Matt_King: We do it for the horizontal slider for this reason 18:46:27 jongund: Yes, but we don't document that rationale 18:46:43 Matt_King: That's right. We could tell them 18:47:02 jongund: Or we could decide that we don't need to tell them. That's what we're doing now, after all 18:47:43 Matt_King: Coding-wise, would that be legit? To make the one that's above a child of the slider? Is there any reason that wouldn't work? 18:48:31 jongund: There's just an SVG "g" element, and only part of the slider components are in there (the focus ring, the thumb), I guess they all could be in there 18:48:40 Matt_King: The focus ring is tricky 18:49:26 jongund: the graphics for the rail are outside the SVG "g" element. I think from a coding practice, it would be cleaner for those to be inside 18:49:42 jongund: and it would be consistent--whether we tell people that's why we did it or not 18:49:54 Matt_King: I like that consistency, and I like that it could potentially solve this problem 18:50:03 Matt_King: Who wants to make an experimental pull request? 18:50:10 jongund: I can--unless somebody else wants to! 18:51:30 Matt_King: Hearing no other volunteers, then let's take jongund's offer 18:51:38 Jem: I'll assign jongund to the issue 18:51:51 Topic: PR 3249 - Add HTML search to landmark practice 18:51:57 github: https://github.com/w3c/aria-practices/pull/3249 18:52:31 Matt_King: I tried to push a commit to this, and my commit wasn't getting represented... 18:52:36 howard-e: We fixed that 18:52:43 Matt_King: Okay, then I think this is ready for review 18:53:53 Matt_King: There's a link to the "search landmark" example, and CurtBellew's pull request changes that by adding an "HTML technique" tab 18:53:59 Matt_King: And yes, I see my change here, now 18:54:21 Adam_Page: I'll be a reviewer 18:54:23 Matt_King: Thanks! 18:54:55 Adam_Page: We moved the conditions--why? 18:55:21 Matt_King: Because it was kind of backwards. If you have a footer that meets these conditions, that's when it maps to "content info". It's not the other way around. Footer has to be used in a certain way... 18:55:34 Adam_Page: Right, but I still associated the condition with the landmark role 18:55:38 Matt_King: Exactly 18:55:50 Adam_Page: So it makes more sense to me to attach the condition to the element rather than the role that it becomes 18:56:44 Matt_King: So, in that table, for "footer", it says it maps to content info but only if the footer is in the context of a body element 18:57:22 Matt_King: I guess we could change the wording. "content info if the footer is in," etc. And then we could say, "otherwise, it's not mapped" or "otherwise, it's generic" 18:57:33 https://www.w3.org/WAI/ARIA/apg/patterns/landmarks/examples/HTML5.html 18:57:44 Matt_King: It can be done either way, but the way it was worded didn't make sense to me. We could change the wording and do it the other way around, though 18:58:36 Adam_Page: We obviously have the same understanding of reality. I think this is just about the editorial trade-offs. Let me give this a more thorough review 18:59:44 Matt_King: We're assigning Adam_Page to review this, and I think that will be enough reviewers (this is mostly editorial) 19:00:11 Matt_King: I'm open to changing the conditions 19:00:55 Zakim, end the meeting 19:00:55 As of this point the attendees have been Adam_Page, jugglinmike, Jem, Matt_King, lola, jongund, howard-e, arigilmore, CurtBellew 19:00:57 RRSAgent, please draft minutes v2 19:00:58 I have made the request to generate https://www.w3.org/2025/04/15-aria-apg-minutes.html Zakim 19:01:04 I am happy to have been of service, jugglinmike; please remember to excuse RRSAgent. Goodbye 19:01:04 RRSAgent, leave 19:01:04 I see no action items 19:01:05 Zakim has left #aria-apg