Meeting minutes
Setup and Review Agenda
https://
Matt_King: Any requests for change to agenda?
Matt_King: Hearing none, we'll stick with the agenda as planned
Matt_King: Next meeting: November 19
Matt_King: No meeting November 26
Matt_King: We'll be back on December 3
Publication planning
Matt_King: Our target date is Thursday, December 12
Matt_King: We'll have two meetings in December to prepare for that
dmontalvo: I let Shawn know about the off-cycle publication date--there should be no issues about that
Matt_King: We have one thing complete and three things in process
Matt_King: We'll probably do our final in-meeting review of the high-contrast work on December 3
Matt_King: I hope to get my editorial changes complete by next week, and then we can assign reviewers during that meeting
jongund: I think I'm done with my work for now
Matt_King: Okay. I'll continue with my minor editorial clean-up so that we're ready to assign reviewers next week
jongund: I might update some examples like the carousel example to actually use this
Matt_King: That would be a separate pull request, though
jongund: Agreed
jongund: This opened up a lot of questions for me. Our coverage report talks about contrast--I think that should be about forced colors to be more clear
Matt_King: I think that's okay as a follow-on, as well. It doesn't have to be done at the same time
Matt_King: I think we're pretty solid on the plan for that pull request
Matt_King: There's also scrollable listbox and multi-thumb slider. Those are both on the agenda for today's meeting
Matt_King: Is there anything else folks want to see included on this milestone?
Matt_King: Hearing none, we'll stick with what we've got
PR 3139 - Scrollable listbox fix
github: w3c/
Matt_King: jongund requested a change from the author, and it looks like they made that change
Matt_King: And all the tests pass
jongund: I have reviewed their work since they made the changes, so it looks good to me, now
jongund: I was doing code review and test review
Matt_King: I think this is now just waiting on me. I'll review it, and if it's looking good, then it'll get merged!
PR 3172 - Add rail click functionality to multi-thumb slider
github: w3c/
Matt_King: This adds the functionality to the multi-thumb slider which we discussed a few weeks ago. It allows people to click on the rail to move the sliders--it moves the closest one
Matt_King: This changed JavaScript and CSS
Matt_King: It seems there's a failing check... It says the JavaScript linter is failing, jongund
Matt_King: Does anybody think we need to change any of the documentation about the example? It's a change to mouse behavior--it doesn't change keyboard. It doesn't change roles, states or properties, either.
jongund: The CSS change allows pointer events to travel through a particular element
Matt_King: So this doesn't change the visual appearance?
jongund: No. However, it occurs to me that some folks might prefer the rail itself to be a few pixels taller now that it is click-able
Matt_King: There's no change to design, so we need somebody to test the functionality, and we need someone to perform a code review
jongund: Are we supposed to be applying the "use strict" directive to all JavaScript files?
howard-e: Yes, that seems to be the case
jongund: I also updated the JavaScript to replace all the "var" declarations with "let" declarations
Matt_King: Should this be tested both with a mouse and with touch events, jongund?
jongund: I only used "click" events, but probably we should test with both
lola: I can volunteer if someone doesn't mind walking me through the changes that I'm looking for
Matt_King: The kind of testing that we want to do is documented in a link in a comment at the top of the pull request
lola: Okay, then, I can just use that
Matt_King: The specific change that jongund made is described in the linked issue. What you're looking for in this functional review is the pointer behavior is as described in the issue across multiple browsers
lola: Got it
howard-e: I can perform the code review
howard-e: jongund, you should be able to correct the formatting issues by running the command "npm run fix"
lola: My GitHub handle is lolaodelola
PR 3147 - SkipTo Scroll feature
github: w3c/
Matt_King: jongund asked for this to be back on the agenda
Matt_King: This is the pull request for the "skipTo" feature that has smooth scrolling
Matt_King: In our prior discussions, it seemed like there really wasn't a consensus around whether we even wanted to add this feature (whether it be smooth scrolling or instant scrolling)
Matt_King: I thought the decision was to leave it the way it is for now, but jongund, it sounded like maybe you were having second thoughts and thought we should choose one of the scrolling options.
jongund: The more I thought about it--since it does support "reduced motion" media query, we allow folks to opt out depending on their system configuration
jongund: I thought it was something that some people in the group thought was valuable
jongund: I like that if someone discovers it and uses it (especially on a touch device or something like that), it actually shows you where you're going to go
jongund: Part of my view of skipTo is that it's like a curb-cut. Maybe it's there because it's required by law, but people find other uses for it
jongund: Right now, I think "skipTo" is included only because it is understood as a vague requirement. I see "skipTo" as being more than just meeting an accessibility requirement. It also raises awareness of concepts like headings and landmarks to people who may not have thought about them before. That's the bigger picture for me
Matt_King: I think that making a change right now to just add this one particular feature to "skipTo", we would need a decision about which to do--instant or smooth
Matt_King: I think people liked the smooth scrolling more, but thought it was a little too fast. You said that it may have been difficult to slow down.
Matt_King: Also, there are even fewer people available on the call today
Matt_King: Years ago, jongund mentioned the option of having the "skipTo" menu always visible. That's a template change. Back when we were working on the redesign, Shawn seemed amenable to that idea, but it got de-prioritized because we had so much on our plates
Matt_King: Currently, though, "skipTo" is different on APG as it is on the rest of WAI
Matt_King: On the rest of WAI, I see there is a "skip to content" link. It just goes to "main"
jongund: That's a traditional "skipTo" link. It worked for the past 24 years; it will probably work for another 24 years
Matt_King: Do you think that the WAI team would be interested in upgrading its skipTo functionality, dmontalvo?
dmontalvo: There's an issue that Kevin opened about the skipTo keyboard interaction. It was flagged by someone that you cannot use the "tab" key throughout the interaction. That infringed WCAG
Matt_King: It supports arrow key navigation exclusively because it's a menu. You are supposed to "tab" out of a menu, so it would be incorrect to interpret that key differently
dmontalvo: That's true from an ARIA perspective, but I think the user expectation may be different
Matt_King: I'm happy to discuss. I just don't know why we would want to break keyboard conventions. We certainly want to follow our own guidance
Matt_King: The primary thing here is making the button always visible (whether it's a link or a button)
Matt_King: I think we did have a design for a non-very-obtrusive (but still visible) element for "skip to"
Matt_King: I think Isaac originally worked on it, we could probably find it
jongund: The default behavior is for it to be constantly visible; we configured it otherwise via an HTML "data-" attribute
Matt_King: So it would be a matter of how we style and position it
<dmontalvo> w3c/
<dmontalvo> This issue was closed
dmontalvo: We can re-open the issue, but we'll definitely want to have a conversation
Matt_King: This is not a burning issue, clearly--not something we have to solve on a rapid time-table. But it seems like it could potentially be a win for a lot of groups (if we were to make it more visible, that is)
Issue 3144 - Feed keyboard interaction issue
github: w3c/
Matt_King: Feed is not something that exists in desktop, so everything that we did in feed is kind of tentative in a way
Matt_King: If we had "experimental" content back in the day, we would have marked it as such
Matt_King: The keyboard suggestions in it are not based on desktop conventions because there is no such thing as a feed on a desktop
Matt_King: Judging from the most recent comments on this issue, it seems like maybe there is a problem with focus visibility in Safari
Matt_King: But now, I'm not sure based on the most recent comment
Matt_King: It's not clear to me that there is a problem, actually
Matt_King: I will come back to this
Issue 3155 - Potential combobox bug
github: w3c/
Matt_King: This is a weird bug, but it sounds like a theoretical problem with the robustness of the code
Matt_King: I would like to have someone look at this issue, look at the code, and decide if this is a valid bug that we need to respond to
jongund: I can look at the code
Matt_King: I'm not going to label it a bug, yet. I'd prefer to hear your opinion, first, jongund. I'll only assign the issue to you and label it "feedback" for now
Issue 3159 - Tooltip placement
github: w3c/
Matt_King: This is another one of those things where I need the opinion of someone else to figure out what to do with the issue
Matt_King: I don't know if I'm following the description. Why is the large cursor going to be more below than above? Also, I'm not sure if we had any instructions related to tooltip placement
Matt_King: We might need some people who aren't present today...
howard-e: I'm also not too sure about what the report is referencing.
Matt_King: Would it help if they provided a screenshot?
howard-e: Yeah, that'd be very helpful to me
Matt_King: That seems like a reasonable next step. It would be nice if it were more clear, though I'm not sure if it's even in the scope of what we want to do with tooltip... Although I suppose that's what we need to decide as a group