Meeting minutes
Setup and Review Agenda
<jugglinmike> Matt_King: Any requests for change to agenda?
<jugglinmike> Matt_King: hearing none, we'll stick with what's planned
<jugglinmike> Matt_King: Next meeting: October 22
<jugglinmike> Matt_King: I may be out of office on November 5 because it's election day in the US, but we can talk about that as it approaches
Publication planning
<jugglinmike> Matt_King: We talked about possibly pulling this forward sooner than the 29th
<jugglinmike> Matt_King: I'm not sure we'll be ready, though
Matt_King: I gave input from howard-e on his open pull request
howard-e: I incorporated that feedback, and it's ready for another look
Matt_King: Wow! That was fast!
Matt_King: That should be ready this week, then
<Jem> presenet+
howard-e: The redirects should continue working through the 29th. If they stop working, I think it will occur in the middle of November
Jem: Did GitHub fix the problem, or was it automatically fixed?
Matt_King: GitHub fixed it, but they are redirecting. We're making it so we don't rely on the redirects
howard-e: We interacted directly with GitHub support--the handle of the person was "dash"
Feedback sent to mailing list
Matt_King: We have received feedback on the public mailing list in the last month or so.
Matt_King: Although we encourage people to share feedback on that channel, we don't have a process for handling such e-mail. Let's fix this.
Jem: Why don't I volunteer for now to transfer those e-mails to GitHub issues?
Matt_King: And can you copy the replies back to the mail list threads?
Jem: Yes
Matt_King: And can you go back into the history over the past few months?
ask dmontalvo
dmontalvo: We should also immediately reply to the people when we open the issue so they know we are discussing there
Matt_King: So at least two e-mails to the reporter--one when we open the issue and another when we close it
Jem: Sounds good!
Lola: I was going to say the same thing
Lola: Where do people learn about that e-mail list?
Matt_King: It's on the bottom of every WAI page. It's a different address for different pages. Every APG page references our list
Lola: Is there some way to make things clearer for folks? Moving discussions between mailing lists and GitHub issues is fine, but maybe we can communicate GitHub to folks
Matt_King: The footer also includes a link to opening issues, and we express our preference for GitHub on the home page
Lola: Great!
Lola: Also, I'm available to help triage e-mails
Jem: I think we should automate it in the future
howard-e: Should the issue triage also be updated?
howard-e: It may be helpful if there's a section in the issue triage wiki describing what will happen
Matt_King: That wiki is for us (so most people who raise issues likely will not see it), but you're right that we should update it
Matt_King: I can take that as an action item because I was the one working on the wiki
Skipto Update
github: w3c/
Matt_King: Jon made some changes to skipto and submitted them as a pull request
Jon: I've been testing here at the University of Illinois. The feedback I received means that none of the changes will be perceptible to end users
Jon: I added a new "scrollTo" feature which is off by default. I could enable that feature if you would like, but consensus here at the University of Illinois was to disable it
Jon: besides that, there are changes under-the-hood related to web components
Matt_King: The motion is in direct response to pressing a key, so don't we always expect some kind of change in that case?
Matt_King: I always thought the motion thing was... Well, maybe the problem is the smooth-scrolling specifically
Jon: I can enable the "instant scroll" variant of the feature and people can take a look at that
Jon: I can also open a separate pull request with the "smooth scroll" variant of the feature. With two pull requests, people would be better-equipped to compare
Matt_King: I think we should evaluate it within this group. There's even the possibility that you could add something to feature--somehow making it easy for people to update their setting directly
Jon: Let's let people try the two kinds of scrolling and test to make sure that it gets disabled when people turn off the feature on their OS
Matt_King: Sounds good
Lola: Is there a place for the user to control scrolling in the place where the scrolling is?
Jon: there is not right now
Lola: I think there would need to be if it were on by default. I believe WCAG requires that users have the ability to adjust animation whenever it is used
Jon: scrolling only occurs when people use skipTo
Matt_King: I don't know if this counts as animation. This is exactly the same kind of scrolling that you get with tabs
Jon: think the next step is for people to try it
Jon: I'll make that second pull request
howard-e: It sounds to me like the scroll is controlled in the script itself. Or is it in an HTML attribute?
Jon: It can be controlled through a data- attribute, yes
Jon: there are three states: none, smooth, and instant
High Contrast guidance update
jon: I'm still working on updates
Jon: I hope to have something ready for next week
github: w3c/
Bug: First element in listbox should receive focus
github: w3c/
Matt_King: There's a discrepancy between the implementation and the guidance for the scrollable listbox example
Matt_King: The pattern says the first item should receive focus. I think that's probably correct guidance
Matt_King: The problem here is that there isn't an item in the list that says "choose your favorite element" or "choose value" or something like that
Matt_King: If we focus the first item, it would amount to choosing the first item for the user by default
Matt_King: This kind of has more to do with the design of the example. If you focus the first one by default, that means there's a default favorite
Matt_King: So I'm wondering if a better fix is to add an option to the beginning of the list--one labeled something like "Choose an element". That coul get selected by default.
howard-e: For me, it does feel right to support what the bug reporter said. A placeholder or "option zero" could be good here. Provided it was styled appropriately
howard-e: That is--a "disabled look"
arigilmore: The dropdown implementation in my company's UI framework may be relevant...
Adam_Page: In the original bug, the reporter quoted the keyboard interaction instructions, but only partially
<Matt_King_> Preview of proposed fix: https://
Adam_Page: They did not include the final statement in the text they referenced. That statement reads, "Optionally, the first option may be automatically selected."
Adam_Page: We could update this so that we don't automatically select it, we just require the press of the "space" key
Matt_King: My concern is that if there is nothing selected, then--JAWS and NVDA would normally announce the label of the list box without speaking a value because no value is selected
Matt_King: If there's an item focused that isn't selected, is it going to be somehow represented as the value of the list box?
Matt_King: I'm unable to test the current behavior using JAWS and Chrome at this moment; I don't understand why that is...
Matt_King: In NVDA, when I navigate to the listbox, it says, "List clickable neptunium". It doesn't tell you whether it's selected, which is interesting
Matt_King: If I select a value, tab out, and then return...
Matt_King: In NVDA, there's no way to read the ones that are not selected in a single-select list box, so there isn't a distinction between focus and selection
Matt_King: I know I've seen other implementations with a placeholder value which represents the empty value
Matt_King: That's why I was wondering if that could be the answer for our implementation, and I even kind of wonder if the pattern should say something about it
Matt_King: Is that common practice in your experience, Adam_Page?
Adam_Page: I think so. This particular use case is probably something I would discourage from a UX perspective because it presents options to the user, but it doesn't give them a user a mechanism for removing their selection
Adam_Page: To get out of that, the UX recommendation is usually to add an option which represents "no selection"
Adam_Page: It seems like a fix for this particular issue, but it kind of kicks down the road the question of whether this is a valid use case (where nothing is selected by default and there is no way to remove a value once one has been selected)
Adam_Page: We could either pattern change this pattern to be more realistic, or we could let this example continue to exist as it does and just update our documentation to explain how it should behave
Matt_King: How would we make it more realistic? Would it be enough to add a placeholder value?
Adam_Page: I think that is enough
Matt_King: It sounds like Adam_Page, arigilmore, and howard-e agree that a placeholder would make this a more realistic example
Matt_King: That could receive focus by default