Meeting minutes
Setup and Review Agenda
https://
<Jem> https://
Matt_King: We might re-arrange the agenda depending on whether Jon joins us today
Matt_King: Any requests for change to agenda?
Adam_Page: If we have a few minutes to spare, I can give a quick update to issue 3215 (the expandable region)
Matt_King: Sounds good--that's already on the agenda under "publication planning"
Jem: We'd love to hear about CSUN, Matt_King!
Matt_King: Sure, we can tack that on to the end of the agenda
Matt_King: Next meeting: March 25
Matt_King: The following week, I am in some all-day meetings for work in London. I'll be in the wrong time zone and I won't be able to attend
Matt_King: I cancelled the meeting for April 1
Matt_King: So the following meeting will be April 8
Publication planning
Matt_King: Last time, before we changed the publication target to March 25
Matt_King: Right now, there are three things in the milestone. Two of them are merged, and they're very small changes (strictly editorial stuff)
Matt_King: The other thing in the milestone is PR 2991 which is on the agenda for today. It seems unlikely that we will wrap that up in time for the next publication
Matt_King: Should we just push out these two little changes?
Matt_King: Or should we push it out to some time in April? (There's no harm in letting these little changes sit there)
Matt_King: I don't have an opinion either way
Daniel: These days, we're more flexible in terms of publication. As soon as something is ready, you can submit a pull request, and I can publish (perhaps within the same day)
Matt_King: That sounds good! I like to set goals and have dates that we're working towards as much as we can. But if the overhead of doing a publication is straightforward, then delivering two which are done--that's good
Matt_King: So let's stick to the plan. Or I suppose, we could publish even sooner than planned for the two things in this milestone
howard-e: I can make a publication branch for those two things today
Daniel: And I could have it published by Thursday
Consider adding an expandable "region"
github: w3c/
Adam_Page: I finished an initial prototype
Adam_Page: I used Scott O'Hara's prototype as a starting point
Adam_Page: I built on it, using hypothetical real-world content instead of lorem ipsum
Adam_Page: I reviewed the minutes of the ARIA Working Group and found an example from Aaron Leventhal (sp?)
Adam_Page: I built on that concept
Adam_Page: I wanted to cover nested focusables, as well
Adam_Page: In Scott's example, everything that is expanded is static content. I wanted to support if there was more content in there
Adam_Page: Also, when you click expand, I put programmatic focus on the "expand" button
Adam_Page: And I added cursor support for selecting text within the interactive area
Adam_Page: I haven't committed anything to the repository, yet, but I do have a CodePen link that I can share
Adam_Page: I wanted to check in with you folks about the timeline
Adam_Page: Like Matt_King, I am also headed overseas next week. I don't know if that factors into the timing, but at the very least, I can have this up for review before I go
Matt_King: Sure. If you want to make a "draft" pull request, that will give us something to look at
Matt_King: There's also the table for roles, states, and interactions. Could you add that?
Adam_Page: I can do a draft pull request for the pattern itself, but I've been intentionally holding off on pattern documentation because I expect there to be some churn while we play with the example and discuss how it ought to behave
Matt_King: Yeah, that makes sense. Maybe you can just include an empty table in your "draft" pull request
Adam_Page: Sure
Matt_King: As I think about how we test these things in the ARIA-AT project, sometimes it's a really good idea to have a super-basic example that has as few interactions as possible but still covers the most basic stuff required for interoperability. And then, separately, something fancier
Matt_King: Specifically, I'm thinking about the nested focusables. I'm wondering if we want one example with those and one without because they may have different levels of support...
Adam_Page: That seems plausible. The nested focusables certainly felt like the most complicated aspect, initially
Adam_Page: But where I landed, it doesn't seem like the removal of those nested focusables will lead to a change that needs to be documented
Matt_King: Well, lets start with what you have then, and we can have a discussion about simplification as part of our review
Adam_Page: It took a little extra finesse to ensure that when a user uses a keydown, it doesn't interfere with text selection
Adam_Page: That the user should be allowed to click and drag with a pointing device without triggering the "collapse" behavior
Adam_Page: If it's collapsed, they should be able to select text (and copy it to their clipboard), and the same goes for the "expanded" state
Matt_King: I don't know if that would show up in the accessibility features or not, but commenting about it in your code would be helpful
Matt_King: You might want to mention it in the accessibility features, though. I don't know
Adam_Page: Yeah, I don't know if that ties back to anything normative. It could just be a case where we took special care
Matt_King: Selection is important for things like "select to speak"
Adam_Page: You mean, like, voice control?
Matt_King: Mac and Windows both have a feature where you can select text to have it spoken
Matt_King: So if you can't select text, you can't have it spoken. That's one way selection ties directly to accessibility
Adam_Page: Got it
<Adam_Page> https://
Matt_King: So let's create a "draft" pull request with a skeleton table. That will generate a preview, and we can play around with it
Matt_King: Then we can discuss timeline when you return
Adam_Page: I shared a link to the example as hosted by Codepen
PR 2991 - Next steps on color settings practice
Matt_King: In Jon's absence, we'll skip this topic for now
github: w3c/
PR 3249 - Add HTML search to landmark practice
github: w3c/
Matt_King: I created a new pull request and merged an old pull request into that branch
Matt_King: that's where this pull request originated
Matt_King: The changes are for the "practices" page for landmarks
Matt_King: We have information about landmarks in two places onAPG
Matt_King: In the "featured practices" section and in the "landmarks" pattern
Matt_King: The "landmarks" pattern is pretty straightforward. It lists all the landmarks that we have (which need to be rewritten because they don't follow the APG template--they are the one aberration we have left... but that's a separate piece of work)
Matt_King: My question is: do we want to make a change to the practice without updating the corresponding "search" example page?
Matt_King: In the first comment on this pull request, I added a link to the preview that goes to the right place
Matt_King: The first change is under the heading "HTML Sectioning Elements"
Matt_King: The very last row of that table is new. It's saying that there is now an html "search" element and it corresponds to the role
Matt_King: The other change is under the section simply titled "Search" (a level-three heading)
Matt_King: Under that, there is a change under "HTML technique". There is also an "ARIA technique"
Matt_King: That's essentially all that this PR changes--those two places
Matt_King: A little further down, you'll find a link to two examples. It says "search landmark examples." If you follow that link, the page has a tab called "HTML techniques". It says that there is no "search" element. This pull request did not change that.
Matt_King: Should we push this pull request without updating that part?
Matt_King: Because this landmark example page needs to be rewritten (like all landmark example pages)
Matt_King: But if we pushed this pull request as-is, people would get conflicting information
Matt_King: So I'm reluctant to do that
Jem: I would support to push changes for search and then include a note on this example page that references your new text
Matt_King: I don't know about a note... I think we would just want to change the content of what's under the "HTML Techniques" tab
Matt_King: It's just a content update to this page. I didn't have time to make that change to that page
Matt_King: We do have the option to push this pull request out without changing it, but then the APG would have conflicted information
Matt_King: Ideally, we want an HTML version of the example under the "ARIA Techniques" tab
Matt_King: It's pretty straightforward. I'm recommending that it be done before we push this out
Matt_King: But that means someone needs to add a commit to pull request 3249 which does that
CurtBellew: This may be something that I actually have time to do
CurtBellew: It would look almost exactly the same as the ARIA Technique
Matt_King: Right, I think all you have to do is change the "div" to the "search" element and take away the "role=search". Oh, and also modify the text that's above it
CurtBellew: Got it
Matt_King: That would be really helpful!
Jem: I assigned the pull request to CurtBellew
<Daniel> Issue on respec links
Daniel: Unrelatedly, there are ReSpec links in the first part of this example, and those no longer work. We should probably audit all the examples for this and fix it throughout with a separate patch
Matt_King: I didn't recognize that as being ReSpec. It looks like Wiki markup. I will fix that in this pull request
Daniel: I'll take a pass on the rest of the pages and see if it shows up elsewhere
Matt_King: Thank you for that observation, Daniel!
Issue 3244 next step - relaxing some naming requirements
github: w3c/
Matt_King: I've been going through issues trying to understand the next steps and document them
Matt_King: There are a lot of issues which seem to be stuck
Matt_King: I want the status of these issues to be more clear
Matt_King: We previously discussed this issue. There is clear alignment that this is high-priority
Matt_King: We have multiple patterns plus the naming practice that needs to be updated. I don't know if it needs to be all done at once
Lola: Is this just editorial changes, then?
Matt_King: Well, it's all documentation work. It's not editorial in the sense that we're changing the meeting... But it is writing
Lola: Is there a hard deadline?
Matt_King: No
Lola: You can assign it to me
Jem: Yay!
Matt_King: I recommend that you go through them one at a time. That will make it easier for us to review. Also, doing that first one will make it much more clear for how to do the rest
Matt_King: In the "ARIA Roles, States, and Properties" section
Jem: [reads the section]
Matt_King: The change would be for the label to the group
Matt_King: There are two elements here: buttons and groups
Matt_King: The bullet on the "radiogroup" element needs to change. Honestly, I'm not sure how we want to word it
Matt_King: The current wording describes what we want most of the time
Matt_King: Somehow, we have to come up with a wording that says... "Optionally if it doesn't have a visible label, it is labelled by aria-label, unless a label isn't necessary because the label on each button is sufficient for the user to fully comprehend the purpose of the radio"
Matt_King: That is definitely too wordy, but that's the general idea
Lola: That makes sense
Matt_King: We don't want to change the existing guidance. It should be perfect almost all the time, it's just that there are rare and exceptional circumstances (where there is no visible group and the labels on the buttons are sufficient)
Lola: Adam_Page, the examples that you mentioned in the beginning of the issue--are those just examples, or are those the three affected patterns
Adam_Page: Those are just examples. I didn't do a thorough dive through all of the APG pages
Matt_King: I think if you start with radio, we can do "word smithing" there. Then, whatever format we come up with for radio, it will probably be relatively easy to extend it to all these others. It's the same general problem, after all
Jem: Why are we trying to relax the requirement?
Matt_King: The argument in the ARIA working group was that forcing people to come up with an aria-label in circumstances where such a label isn't necessary, it can make accessibility work (and it creates work that doesn't need to be done)
Jem: got it
Matt_King: It's not super common, in my experience
Matt_King: Thanks to everyone for being here and supporting the APG!