Meeting minutes
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: July 8
Publication planning
Matt_King: We currently have three pull requests merged and fully ready to go
Matt_King: I think there are two more that may be ready after today's discussion
Matt_King: But even if it is to only be the three, then I would like to publish
Daniel: That will work. I will be off next week, so I would like to receive a pull request by tomorrow
Matt_King: I can try to get it submitted today
Daniel: That would be even better
Matt_King: Cool. I can commit to that
PR 3448: Fix for the link checker
github: w3c/
Matt_King: We were getting 403 errors, and it wasn't clear why
Daniel: My systems colleague figured this out
Daniel: I suggest we change our approach: instead of trying to mimic a user-agent string, we just use the default
Matt_King: Part of me wonders if we get a 403 error, whether we might actually try to use the alternate strategy as well
Matt_King: Currently, it seems that all the 403 errors are genuine. I thought we had the University of Illinois one fixed
Daniel: Now, it doesn't show 403 errors. It has the link-checker passing
Daniel: I last reviewed last week, and it was passing then
Daniel: Most of the previous 403 errors were from the W3C, and we got confirmation that old Chrome versions were rejected by the firewall rules
Matt_King: Based on the feedback from howard-e, this looks pretty straightforward
Matt_King: I think I will merge this today. That doesn't impact the publication plan
PR 3430: Editor Menu Bar Example: Implement optional spacebar behavior for radios and checkboxes
github: w3c/
Matt_King: We have had three people look at this
Matt_King: It doesn't change anything about visual appearance or design. It's just the keyboard support
Matt_King: We had the regression tests changed accordingly, and jongund reviewed that
Matt_King: I reviewed functionality in Windows
Daniel: And I tested functionality on macOS
Matt_King: I think I can merge this today
Matt_King: there's one bit of feedback from jongund. It's about a comment in the test file
Matt_King: The author didn't respond to that, but it's a one-word change in a comment in a test file, so I will make the change myself
Matt_King: It will be included in the upcoming publication. Does anyone have any concerns with that?
Adam: Nope
PR 3372: Add Experimental Example of Scrollable Listbox with Actions on Options
github: w3c/
Matt_King: We've had a lot of reviews and a lot of flux here
Matt_King: I'm a little un-concerned with this not being 100% polished because it is and experimental example and clearly labeled as such
Matt_King: There's some outstanding feedback that are kind of just polish
Matt_King: The text is written as if selection follows focus, but it doesn't.
Matt_King: The functionality is correct; it's the documentation that needs updating
Matt_King: Those are pretty trivial editorial changes, so I'm proposing that I make those editorial changes about the automatic selection in the keyboard table. There might also be one small change to the "attributes" table
Matt_King: ...and that I raise issues for the other aspects of the review that haven't been addressed yet
Matt_King: And that I merge this pull request so that it can inform active discussions in ARIA
Matt_King: Are there any concerns about expediting this in that way?
Daniel: We may get some comments around this. I can't remember if we have other experimental examples already published
Matt_King: We do. The only way you can find them is to go to the index and go to the bottom of the page to a section labeled for experimental examples
Matt_King: They are not reference from other examples
Matt_King: The "experimental" warning is automatically expanded instead of automatically collapsed
Matt_King: We have one other experimental example right now
Daniel: Just in case, since Remi may not be familiar. But I don't see any issue--this is just a warning that comments may come up
Matt_King: I know Shawn was involved in the design to ensure that experimental examples could never be confused with stable examples
Adam: I'm playing with it now. I'm seeing it resolved an issue that we chatted about. It was where some buttons would be unfocusable.
Matt_King: Yes, that is fixed
Adam: ...but now, it's making me interrogate the behavior of where we place focus when the thing we would normally place focus on has disappeared
Adam: If I move to the "down" button, and I press it, then focus remains on that button, and I can continue pressing it to move things down
Adam: When I return to the conditions that we chatted about before, where I'm on the second item from the top, I expected focus to land on the "down" button rather than the item
Matt_King: When Curt asked that question, my intuition was to place focus on the item. I thought that would be the most appropriate thing as a screen reader user. I can see the argument for "up" and "down" to go to the opposite item.
Matt_King: Delete should always go to the item; not the "delete" button for the next item
Matt_King: But if you wanted to keep deleting a bunch of items...
Matt_King: This is an important question. I don't know if the input I gave to Curt is really the best, but that is why he did it the way he did
Adam: Understood. Honestly, it's quite subjective
Adam: As a user, for reordering, I am in a mode of reordering, so I would like focus to remain on something within that task
Adam: As for deletion, I agree with your rational that it's too destructive to the next delete button. It could cause users to delete things unintentionally
Matt_King: What if we merge it and raise issues for these things and address them in separate pull requests?
Adam: That sounds great. I didn't mean to nitpick on minor subjective issues
Adam: Also, there's a small bug: when you delete an item, focus lands on the list. It doesn't land on the nearest item.
Adam: Probably the next item is the best way of expressing it as a rule. If you're in the middle of the list, then I think people expect that people expect things to sort of "shift up"
Matt_King: You're right. The edge case is deleting the final item
Adam: This example is so cool, though!
Matt_King: Yeah, and it's complete enough to allow us to review and refine the final edge-cases
Matt_King: Okay, so I'll merge this, make the editorial changes we talked about, and file follow-up issues for the outstanding comments
PR 3449: Three Combobox Examples: Expand on click and improve filter behavior
github: w3c/
Matt_King: In the previous meeting, we agreed on a set of changes, and the author has already created a pull request for those
Matt_King: I haven't reviewed it yet, but it does a lot, so there's quite a bit to review here
Matt_King: This is a ways away from being ready for publication
Matt_King: There is one open question in the related issue that is not directly related to the pull request that we might want to actually have it captured in the issue--if we decide to discuss it, now
Matt_King: But before we go there, is there anyone else that can help me share initial feedback? Not necessarily a formal review, but just early feedback, particularly on their code
CurtBellew: I might be able to give light-weight feedback on this
Issue 3442 question
github: w3c/
Matt_King: colm, the contributor, asked the question: is it too aggressive to expand the listbox on first click if you click in the "edit" field of the combobox?
Matt_King: This is what we discussed in a prior meeting
Matt_King: If you click in the combobox and the list is collapsed; that seems like an intent to change the value
Matt_King: They agree, they are asking if you should need to click the chevron if you want to see the list
Matt_King: This is a pretty subtle UX issue and maybe a matter of there being a lot of different users with a lot of different needs and intents. You try to serve the greatest number in cases like this. And in the most accessible way
Matt_King: Our current direction that the pull request takes is that if you click in the input box, we put the focus in the edit box and expand the list
Matt_King: The question on the table is: should it do both of those things? Or just put the focus in the "edit" box?
Matt_King: I can think of a couple accessibility "pros" for expanding the listbox on click
Matt_King: But I don't want to dilute peoples' thinking
CurtBellew: To me, I'm sympathetic to the idea that when you click in the field, it doesn't open the dropdown. You're effectively filtering in that case
CurtBellew: The only problem is--I like to stick with HTML as much as possible. When you click on a select box in HTML, it opens no matter where you click
CurtBellew: I like to follow HTML when possible because that's less surprising to users
Matt_King: This pull request changes things. If you have a complete value in the input field, and you trigger any event that causes the drop down to appear, if the value of the combobox is a full value, then you would show the full value of the list
Matt_King: The only time it would filter is if you have an incomplete value or no value at all
Matt_King: If you type "aj", then you would have an empty list. If you type just "a", then you'd get all the states that start with "a". If you typed "Alaska", you would get all states
Matt_King: The way the pull request is currently coded: if the value "alaska" is in the field, an it's not focused, if you click the field, then that will cause the focus to go to the "edit" box and the list will expand
CurtBellew: I can't think of a reason why that would subvert users' expectations
Matt_King: The contributor expressed surprise about the expansion
CurtBellew: I could go either way. I kind of like how the list opens up, especially how you described it
Matt_King: From an accessibility standpoint: when it comes to making click targets as easy as possible for users with less control over the mouse, it's nice to have big hit areas
Matt_King: So clicking the chevron--it seems like it could be helpful to users. Just like you can click the label in radio buttons or checkboxes
Matt_King: It's less work for people who want to see the list. If they don't want to see the list, then they can click the chevron... but if you didn't want to see the list, is it a problem that it is there? Is it a problem that it's covering up the content that is below it?
Matt_King: That seems like less of a downside if you are just interested in changing the value. But it seems like a larger upside for the folks that would benefit from a larger interactable area
CurtBellew: Good point!
Adam: I agree with all of that. I also agree with CurtBellew's bias toward following native conventions
Adam: I'm understanding that there is nothing visually about this control that tells the user that it affords typing. It just resembles a dropdown
Adam: It does have a chevron, though, which suggests that it supports choosing an option from a list.
Adam: For this pull request, the new implementation satisfies my main concern: clicking again after the listbox was open previously caused the cursor to vanish. That's gone
Matt_King: Thanks. I'm happy to have others weigh in here!
Issue 3441: Questions about advanced treegrid practices
github: w3c/
Matt_King: There's a list of things that they are thinking about putting into a user interface. There are four different characteristics that they want. And there's an image
Adam: There are two screen captures that include tables with grouped rows
Jem_: [reads the contents of the tables in the image]
Adam: There's no column for currency
Matt_King: But they made groups based on currency?
Adam: Exactly
Matt_King: Normally, if you have row groups in a table, wouldn't they have to be grouped by a table that's expressed in the table?
Matt_King: I'm thinking about other kinds of treegrid examples. When you expand and collapse, that action is based on showing or hiding a group of rows that all fall under a particular node in a hierarchy. They all essentially have a value for that node. But if that node value isn't represented in a column...
Jem_: There's one more table: a "cost center" table. [Describes the contents of that table]
Adam: I think Matt_King was saying that the information by which rows are grouped needs to be expressed somewhere. It is here, in the form of something that resembles a row but that is actually a column header spanning multiple columns.
Matt_King: If the table was expanded and all rows were shown, would it look like a table where you have a column for that attribute? Essentially, where every row in each group would have a value for that column
Adam: I've seen tables like that. In these screen captures, though, no. The pieces of information that act as grouping mechanisms don't have their own columns
Matt_King: From an ARIA standpoint, that sounds really challenging. From a coding perspective, you would have labeled groups. However, a row group is not a focus-able thing. And it's not a thing where when a screen reader reads a table or a grid--you can't, as far as I know, label a row group in a table
Matt_King: THEAD and TBODY, if you labeled them, it doesn't do anything
Matt_King: As presented here, there isn't an ARIA convention for creating this kind of thing. Now, if it is a focus-able row in the table... Our treegrid example is the e-mail inbox. It is the subject of the e-mail that creates threads, and there is a column for subject
Matt_King: Here, there's no equivalent to the subject column, right?
Adam: Correct
<CurtBellew> https://
Adam: There is no column, so it is not comparable to this.
Adam: In our case, the only value for "subject" is "treegrids are awesome"
Matt_King: Yeah, it's a very simple treegrid there. If it were a real inbox, you would have more than one thread
Adam: Their equivalent is that they would have two treegrids nested that happen to have the exact same structure. The same columns, but they would have a group heading
Matt_King: But essentially they would have to be separate treegrids where you would tab from one to the next
Matt_King: That sounds awful but not impossible
Matt_King: You could use the "down arrow" to go from tree grid to tree grid. It would have to be a totally custom thing. Technically in ARIA, you would have to make the separate treegrids. I don't think you can nest treegrids
Matt_King: From an API point of view, if it was a series of treegrids, you could have custom documentation for moving from one grid to the next grid. It might be a little bit complicated, though
Matt_King: I'll re-read the issue and try to summarize our discussion
<Jem_> thanks for the scribe, Mike!
<Jem_> I saw similar table pattern from the state governement medicare data.