Meeting minutes
Setup and Review Agenda
Jem_: Any requests for changes to the agenda?
Daniel: I have a couple things--an issue and a pull request
Daniel: We can review those offline; I just wanted to bring them to everyone's attention
Matt_King: We can add it to the agenda. We should probably sequence it after the discussion of issue 3372
Daniel: That's issue 3395
Daniel: There's another pull request, WAI-aria-practices number 445, that removes some JavaScript in favor of a Jekyll directive
<jugglinmike> Next meeting: February 18
Publication planning
Matt_King: I've updated the milestone to be for February 18
Matt_King: There are two pull requests that have been merged, and there's at least one other one that's ready for my review
Matt_King: Essentially, we'll merge whatever is ready in two weeks
Matt_King: I'll move to anything that's still in progress at that time to a new milestone
Matt_King: Does February 18 work for your timeline, Daniel?
Daniel: That works. the 18th is a Wednesday, which should give Remy a few days to process the request
Matt_King: I was thinking of having the pull request ready before this meeting and using the meeting to discuss any potential concerns
Daniel: Great!
PR 3372: listbox example with aria-actions
github: w3c/
Matt_King: I just made changes today
Matt_King: The first and most important thing is that I opened a new pull request, w3c/
Matt_King: 3400 is a branch off of 3372
Matt_King: Because 3372 is being referenced by an active discussion in the ARIA working group, but we had also talked about making a whole bunch of changes to 3372, I wanted to keep 3372 stable but allow us to simultaneously progress the discussion we've been having. Hence, the branch
Matt_King: Just this morning, I pushed some changes
Matt_King: An older version of Claude wrote most of the changes, and I was in a little bit of a hurry this morning, so I corrected most of the mistakes, but I don't know if I got them all
Matt_King: The preview in 3400 has the basic content of the proposal I made in the top comment of 3400
Matt_King: In December, we talked about
Matt_King: ...the difference between selection and "flagging" or "favoriting"
Matt_King: We talked about different design content ideas. I put a list of four characteristics that I extracted from that discussion into the top of 3400 under the heading, "New Content Design"
Matt_King: 1: Names of items are short and easily understood.
Matt_King: 2: Supporting "selection" to display a related details panel is relevant.
Matt_King: 3: Ordering, flagging, an deleting are appropriate functions.
Matt_King: 4: Very minimal content would be sufficient, e.g., 5 or 6 options with no need to draft significant content for the details panel.
Matt_King: That's what I wrote there. I'm just throwing it out as a suggestion (or a kind of "bucket list" if you will) to inspire discussion
Adam_Page: I love it
CurtBellew: I'm glad to see that the "favorite" is kind of gone
Matt_King: Well we still have that option because someone said it was important to be able to show a "toggling thing" that doesn't move the focus. James Craig, in particular
CurtBellew: I like the idea of having something that changes state--the only problem was visually representing it. That part, for me, got a little bit weird
CurtBellew: I'd hoped to share it today, to describe it and gather impressions
CurtBellew: [shares screen to demonstrate]
CurtBellew: I added a list where every item initially includes both an empty checkbox and an outline of a star
CurtBellew: The star gets filled in when it is "favorited"
Adam_Page: I do think the hollow star invites a click
Matt_King: What's the reason for having the hollow star in the default state?
CurtBellew: To limit ambiguity
Matt_King: You could have a hover for "flag" that would make the flag appear
CurtBellew: For me, it felt a little jarring to have the star suddenly appear. I don't know why
CurtBellew: But I do agree with Adam_Page about how the hollow star invites the click
CurtBellew: Gmail reveals the button on focus, and it also reveals the indicator on focus
Adam_Page: I think Gmail displays a persistent filled-in star after favoriting
Adam_Page: Gmail's star icon is persistent, actually--even if not "favorited", it is rendered--just as an outline (or "hollow" as we've been saying)
Matt_King: Should we make it so that the text box is empty unless you press enter or click the actual item? And then it stays the same until you enter or click on a different one? So that selection is not following focus?
Matt_King: Or should we make it so that selection DOES follow focus?
Adam_Page: In Gmail, it doesn't do anything except show that you are focused on the item to do things. But it doesn't perform any operation
Matt_King: So selection does NOT follow focus in Gmail
Matt_King: I don't know if we want that or not. I could go either way.
Adam_Page: What does selection achieve in our example?
Matt_King: We don't have this feature, yet, but there would be a read-only textbox that would just have some text that would be relevant to the current option. A details panel placeholder
Adam_Page: So now, I'm wondering... The revealing of that details IS an indication that the item has been "selected", so I wonder if the checkbox is redundant or confusion. We still need aria-selected state, but I wonder if visually, it is sufficient to have the panel open
CurtBellew: There was a checkmark that showed up. I added the checkbox because I added the star. It felt strange without it.
CurtBellew: I'll say that I'm not married to it.
Adam_Page: The checkbox, as a visual, so strongly suggests that you are checking the item to do something later
Matt_King: It would be nice if people looked at this and automatically made the connection to something like Gmail. So they would see, "ah, this is how you use aria-actions to do that kind of thing."
CurtBellew: The big difference, visually, between these checkboxes and stars with what's in Gmail is that the elements are somewhat diminished until you interact with them
Adam_Page: They appear kind of halfway between active and disabled
CurtBellew: Would it be helpful for me to update the example in the way that you suggested, Matt? We still have the "favorite" flag...
Adam_Page: I think it would help to get the "details" mechanism in there--to kind of see the big picture of the interactions
Matt_King: I was thinking that it would be generated content in there--just a placeholder.
Matt_King: I put a suggestion in the comment of my pull request, under the heading "Suggestion to riff on ..."
Matt_King: I just think that "Lorem ipsum" text is disorienting for screen reader users
Adam_Page: I like the "bucket list" idea. The transuranium elements are cute, but they're also kind of intimidating
Matt_King: Ah, it seems that the preview is out-of-date. It doesn't reflect my latest changes
<Jem_> above is supposed to show the preview and it does not.
[the group attempts to troubleshoot an apparent issue with the automated process that generates pull request previews]
Matt_King: We may have to merge the main development branch into this pull request... Perhaps you can pull it down and preview it locally, CurtBellew
CurtBellew: Sure--I'm just not equipped to do that live on this call. I should be able to do it tomorrow or Friday
Matt_King: Okay, it's sounds like we're mostly aligned here. We just need to figure out what to do with the checkbox and whether selection should follow focus
Matt_King: This is about finding something that people will relate to
github: w3c/
Add ‘has-sidebar’ class using Jekyll frontmatter instead of client-side Javascript #445
<Jem_> w3c/
github: w3c/
Daniel: The CSS was previously added via JavaScript, for the pages that needed it. There's now a Jekyll directive that can handle that
Daniel: This touches the "about" page, the example pages... There are some pages that have the CSS class added
Daniel: I just want to flag that this is something we would like to proceed with. We don't necessarily have to review it here during the meeting
Matt_King: Got it. I'll need to make some changes to my development environment before I can review the impact locally
Matt_King: My primary concern is that it doesn't have the intended effect on APG
Matt_King: I suppose one way I could do this is by reviewing the list of changed files, and then I can view those files in the preview...
Daniel: I don't think there are going to be any changes to content. It's just about the way we're adding a CSS class
Matt_King: I'm just concerned about whether content might be omitted because it didn't work as expected for whatever reason.
Jem_: I can do QA as well
Daniel: I already reviewed it, and I would appreciate participation from a sighted reviewer as well.
Matt_King: Basically, we need to make sure that the CSS class is present when it needs to be present
Jem_: Got it. I'll have a look
Modal Dialog Example: Table of contents includes headings from example div that should not be included in TOC #3395
github: w3c/
Matt_King: I think this is happening on many pages, though the reporter observed it on the dialog example page
Matt_King: There's a little navigation table of contents thing. It's automatically generated, pulling content out of the examples. In the case of the dialog, there is content in the HTML that is hidden by CSS. The table-of-contents-generation logic doesn't recognize that the content is being hidden
Matt_King: Can we add some configuration to signal to the examples building--something like, "hey, please ignore this content"
Daniel: That would require changes to the template. I'd have to ask for input on the feasibility of that
Daniel: In reviewing this earlier this morning, I noticed that we have a bunch of H2 elements that may not be semantically correct
Daniel: Is it okay for all those elements to be H2's, or should they be H3's?
Matt_King: There was actually discussion about whether they should be H1's.
Matt_King: I don't think that there's any rationale that we could cite to make them H3's. I did think of doing that, but then we'd have to explain how that if this was a real dialog, you wouldn't make it an H3--that you would make it an H1 or an H2.
Matt_King: Does the table-of-contents logic ignore H1's? If so, maybe we could make them H1's.
Daniel: I will have to double-check on that. If it is the case, that would be a much more straightforward fix.
Matt_King: Though it would likely require some CSS tweaking as well, just to make sure the H1's were visually sized appropriately. That's definitely something we could do
Matt_King: That's a good thing for us to investigate as a next step!
Daniel: I'm not sure if we have standard prose that says that the dialog heading needs to be any particular level. If there is any such prose, I would need to review this, again. But I can't remember any such prose in HTML or ARIA...
Matt_King: I remember a discussion about that when we created the example, but I don't remember if we're explaining that or not.