Meeting minutes
<Jem> https://
Setup and Review Agenda
Matt_King: Any requests for change to agenda?
Matt_King: Hearing none, we'll stick with the agenda as planned
Matt_King: Next meeting: April 22
Publication planning
Matt_King: We may or may not be ready for a publication on April 29
Matt_King: We have nothing ready, yet, but there are two things that are awaiting review
Matt_King: One is a minor editorial change, and I think we had a reviewer assigned to it. It's issue 3252
Matt_King: We've requested a review from jongund and siri
Matt_King: This is a super-simple pull request, and I think even just one reviewer would be satisfactory
jongund: I'll look at it
Matt_King: Thank you
Matt_King: Then there's the massive one which jongund has been doing most of the work on. Issue 2991
Matt_King: I'm still unsure of how we make this actionable for people
Matt_King: I'll write down my thinking, though
Matt_King: And I'd appreciate input from others, as well
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
Matt_King: I want the consequences of the advice to be clear
jongund: I've broken it up into three sections
Matt_King: What about the effects of CSS (the "gotchas," etc), like we have in some of the other articles we've written?
jongund: I've placed that kind of information in the table
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
Matt_King: I'm interested in what other people have emphasized on these topics--the people who are writing to a similar audience
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
Matt_King: As a practical matter, in terms of getting this published, I really welcome feedback from other contributors--especially arigilmore and CurtBellew
Matt_King: In particular, any advice on making it more actionable would be great
Issue 3257 - Potential bug with vertical temperature slider
github: w3c/
Matt_King: The text of the value is exposed in two different ways in this slider
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
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
Matt_King: The question is: do we need both of these representations of the value?
Matt_King: And would it be possible to only have the representation of the value inside of the slider?
Matt_King: It doesn't seem like a good practice, from an accessibility standpoint, to have this duplication
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
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?
jongund: That's the one they will see?
Matt_King: I mean how much zooming will they need to do before they cannot see the value which is outside
jongund: I'm not sure
Matt_King: I'm just not certain that the justification is relevant in practice (rather than being purely theoretical)
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
Matt_King: It's kind of like we have temperature, followed by the current value, followed by a thermometer (which also shows its value)
Jem: That's right
jongund: The label at the top is more traditional
jongund: We could put aria-hidden on the text
Matt_King: I've been really reluctant to use aria-hidden in that way
Matt_King: I'd prefer the duplicate text over aria-hidden
Matt_King: One could argue that it's decorative... But it's not a graphic--it's text!
Adam_Page: I'd vote to just kill the value at the top altogether. I'm not sure I see the usefulness in it
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
Matt_King: What is the rationale for the label at the top?
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.
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
Matt_King: How do you move the thumb without seeing the value next to the thumb?
Matt_King: You have to be able to look at the thumb to move it, right?
jugglinmike: Well, you can move it using the keyboard
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
jongund: The color slider example has a value which appears alongside the thumb and moves with it as it changes
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
Matt_King: That wouldn't address the issue for screen readers
Matt_King: I'm hearing that there are justifiable reasons for all the alternatives--that there are valid trade-offs here
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
Matt_King: For some users, the value next to the thumb is useful. And for others, the value at the top provides greater accessibility
CurtBellew: I think the issue is based on the fact that visually, it is "11.9 C" and the value text is "11.9 Celsius"?
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
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")
Jem: That's what we had for the calendar, too
Matt_King: Screen readers can't de-dupe the value that is above because they don't know that it is a value
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
Matt_King: But the screen reader can't know that "25 degrees C" is part of the value
Matt_King: So it's kind of a semantically ambiguous element
Matt_King: But I don't think there's a reason for not having it
CurtBellew: When I try, VoiceOver represents them in the same way
Matt_King: Yeah, so does JAWS
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"
jugglinmike: But the color viewer slider only has a value that moves with the thumb. Shouldn't our decision apply to both patterns?
Adam_Page: And ditto for the multi-value slider I saw (which is also horizontal)
Adam_Page: Maybe we would justify this approach for a vertical slider specifically
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
Adam_Page: I hear that. Although we could perhaps adjust the positioning of the vertical slider to account for that...
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)
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
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?
jongund: That's pretty subtle. Would you tell people you did that intentionally for this purpose?
Matt_King: We do it for the horizontal slider for this reason
jongund: Yes, but we don't document that rationale
Matt_King: That's right. We could tell them
jongund: Or we could decide that we don't need to tell them. That's what we're doing now, after all
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?
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
Matt_King: The focus ring is tricky
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
jongund: and it would be consistent--whether we tell people that's why we did it or not
Matt_King: I like that consistency, and I like that it could potentially solve this problem
Matt_King: Who wants to make an experimental pull request?
jongund: I can--unless somebody else wants to!
Matt_King: Hearing no other volunteers, then let's take jongund's offer
Jem: I'll assign jongund to the issue
PR 3249 - Add HTML search to landmark practice
github: w3c/
Matt_King: I tried to push a commit to this, and my commit wasn't getting represented...
howard-e: We fixed that
Matt_King: Okay, then I think this is ready for review
Matt_King: There's a link to the "search landmark" example, and CurtBellew's pull request changes that by adding an "HTML technique" tab
Matt_King: And yes, I see my change here, now
Adam_Page: I'll be a reviewer
Matt_King: Thanks!
Adam_Page: We moved the conditions--why?
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...
Adam_Page: Right, but I still associated the condition with the landmark role
Matt_King: Exactly
Adam_Page: So it makes more sense to me to attach the condition to the element rather than the role that it becomes
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
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"
<Adam_Page> https://
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
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
Matt_King: We're assigning Adam_Page to review this, and I think that will be enough reviewers (this is mostly editorial)
Matt_King: I'm open to changing the conditions