Meeting minutes
Setup and Review Agenda
https://
jem: Next meeting: October 14
jem: Any requests for change to agenda?
Daniel: Can we discuss issue 3373, as well?
Jem: Yes, I saw that. We can add it to the agenda, directly after the discussion of publication planning
Publication planning
Matt_King: As Daniel mentioned, the September publication went out
<Daniel> September milestone publisshed
Matt_King: We have seven things to check following that publication
Matt_King: Adam_Page could you go to the production site and make sure the spin button is all good?
Adam_Page: Sure
Matt_King: I'll take a look at the editorial changes for keyboard in grid
Matt_King: We have one related to the editor menubar example. This is a tab index management issue.
Matt_King: Fix so that only the most recent item is in the tab sequence
Matt_King: arigilmore I believe you worked on this; would you mind verifying it on the production website?
arigilmore: Sure
Matt_King: I can take the "read this first" item, and I'm not worried about the JavaScript item
Matt_King: If you folks find any problems, please raise a new issue. I don't expect any problems, but we always want to double-check
Matt_King: So that covers the past publication milesone
Matt_King: For the next publication milestone, we have three items so far
Matt_King: That includes the experimental example which we talked about last week
Matt_King: The date on this milestone is flexible
Matt_King: The one place we are seeking additional review is jongund's pull request, number 3213
Matt_King: This is the skipTo link and menu
Matt_King: jongund pushed a commit and asked if someone could test it on iOS
Matt_King: Adam_Page and arigilmore were reproducing this problem earlier. Would either of you be willing to take a look at jongund's pull request?
Adam_Page: Yes, we both did this already, just today. Unfortunately, we can both still reproduce the problem
Matt_King: Okay, that's it for the publication status update!
"Read this first" code upate
github: w3c/
Daniel: I think it would be more elegant if we could use static HTML for this
Daniel: We're more open to Jekyll "include" directives than we used to be
howard-e: I think the Jekyll "include" (or any frontmatter approach) would be going back to what wasn't wanted. There was an ask that the content in "read this first" could be controlled from this repository. We use a JavaScript approach to simplify maintenance for contributors
howard-e: if it was done in pure HTML, that would involve duplicating the template content across over 30 patterns
Matt_King: So we have client-side JavaScript not just for "read this first" but also for the disclosure on the example pages.
Matt_King: We have it in a couple places
Matt_King: What is the problem with the client-side JavaScript, Daniel?
Daniel: If you've disabled JavaScript, then the content is not available to you
Matt_King: But if you've disabled JavaScript, then most of the APG is not useful to you
Matt_King: Is there a way for the build process to perform the injection into every page as it's built? Is that somehow preferable?
Matt_King: I don't think that we want content repeated across many pages in the source repository. If we want to change content in that scenario, we have to update multiple pages. That makes the content-management more difficult, from an editorial perspective
Jem: What is the downside of using "include"?
Jem: What I'm hearing from Daniel is, "why don't we just use a simpler approach?"
howard-e: All that content was controlled in that repository. There are some assumptions which could be broken
howard-e: If we go back to the approach where the "builder" repository injects it, perhaps with a configuration file, then there may be a happy medium, here
Matt_King: The builder is just supposed to be an automated thing that transforms the content
Matt_King: The build should not be making editorial decisions
Matt_King: Is "include" a Jekyll feature?
Daniel: Yes
Matt_King: Then we'll end up mixing Jekyll directive into our HTML
Matt_King: Our content repository doesn't have any Jekyll in it. That was part of the beauty of the separation--that we don't require anybody to know anything about Jekyll in order to contribute to APG
Matt_King: Is there a "pure HTML" way of including content?
Daniel: I'll have to look into that
Daniel: you could argue that this is not exactly content per se...
Daniel: I'll reflect on this further and share my thoughts as a comment on the issue
Matt_King: In today's world, I wonder if we should be at all concerned about users who disable JavaScript
Daniel: They can read about the examples, they just can't interact with them
Matt_King: I wonder what that kind of person is even doing. And whether they're even part of the target audience
Daniel: This is motivated by discussions around the WAI website
Jem: Is this a build process issue?
Matt_King: Yes
Jem: I used to know people who disable JavaScript, they were mainly security experts
Issue 3193: listbox example with aria-actions
github: w3c/
Matt_King: I created a draft pull request
Matt_King: w3c/
Matt_King: The HTML page is basically complete, including proposed keyboard documentation and roles, states, and properties
Matt_King: I don't know if we can have a useful discussion of the keyboard proposal. We could wait for code from cbellew. I do have a proposal here, though.
Matt_King: This came out of TPAC discussions last year, where we're talking about "aria-actions" being set to null (or '") in certain circumstances
Matt_King: The screen reader would know that it has actions but wouldn't be able to figure out what the actions are until the element receives focus
Matt_King: This is specifically what Aaron was hoping to do
Matt_King: In the aria-actions specification, the empty string is supposed to have meaning
Matt_King: That allows you to use "display: none" for the buttons
cbellew: Ah, so you aren't referencing IDs which don't exist
Matt_King: Exactly. Or so we don't have to use some weird mechanism of making them not visible
cbellew: are there standard icons or icon libraries? Or should I just choose my own?
Matt_King: We don't have a standard set. We have some other examples which have icons which might be similar
Matt_King: Here we want move up, move down, favorite, and delete...
Matt_King: We probably have SVGs already in the repository that might represent most of those things...
cbellew: I've been looking but haven't seen anything. I'll keep searching
siri: Can you add a pattern that has disabled actions?
Matt_King: Well, in this case, you would not show disabled actions
Matt_King: But if the item is the first in the list, you can't move it up. Likewise, if it's the last item in the list, you can't move it down. But I'm assuming we wouldn't display those actions as disabled--that we would simply not display them at all
Issue 3371: Potential bug or editorial issue in navigation tree example related to aria-selected
github: w3c/
Matt_King: In the navigation tree view, we aren't using "Selected" at all. We're using aria-current = page
Matt_King: I re-read the spec, and aria-selected is supported for tree items. It's not required. There is spec language around whether or not the browser should do automatic selection, and I think in this case, some browsers might choose to do automatic selection
Matt_King: ...because that meets the requirements for single-select which are in the spec
Matt_King: And then I read our language in the pattern. There, when we talk about "aria-selected" and "checked", we say how to mark it up if it is selected. But there isn't any language in the pattern that says whether there needs to be a selection
Matt_King: But then when you look at this navigation tree view example, we don't say very much about this choice
Matt_King: There is some language--under "Accessibility Features" we have a section named "Focus Movement after content load" and that's where we talk about the use of "aria-current"
Matt_King: But we don't talk about "aria-selected" anywhere. I don't know if that's a miss, here, but it clearly tripped up this person
Matt_King: So we could add some language.
Matt_King: I don't think it's a bug--I don't think we need to specify aria-selected, but I wonder whether we should say why we are not doing so
<Siri> https://
Jem: So would you like to update the pattern regarding aria-selected?
Matt_King: We could just explain how aria-selected is not required, just as a comment on this issue, and then close this issue
Matt_King: We could say something about not using aria-selected here on this example page. I'm not sure about that.
Matt_King: I don't think we want to update the pattern, though. We use this in aria-breadcrumb, but everywhere else, it's not part of the pattern--its just something you can
Jem: I think this person is just looking for guidance on aria-selected. I think there will be others who will ask the same question
Jem: So I vote for adding some language about aria-selected here in the example
Matt_King: Maybe what we're really doing is using aria-current in lieu of aria-selected
Jem: Maybe we add it to the table. We could add a note to the row for aria-current
Matt_King: We could add a note in the "Accessibility features", too, where we talk about aria-current. Maybe the same note could go in both places
Jem: I remember when I first started learning about ARIA, I was always looking for all the "aria-selected" attributes
Matt_King: I guess a note would say something like, "aria-current is used in lieu of aria-selected because it more clearly conveys the state of the tree, and the pattern and specification do not require that there be a selected element"
Jem: Great!
<Adam_Page> https://
Adam_Page: For what it's worth, I just reviewed the spec for aria-current and found some prose to this effect
Matt_King: I didn't think to check that!
Matt_King: I may have written that
Adam_Page: I think maybe you did. It sounds a lot like the text you just proposed
Matt_King: Maybe we can re-use that language
Matt_King: Having some clear messaging that helps illuminate the spec (especially the spec for aria-current) makes this a more positive change
Matt_King: Okay. We can mark this issue as an editorial enhancement. I will do that, now.
Adam_Page: This also feels like a "good first issue" for folks who might be new to the APG or who are looking for an easy win
Matt_King: Yes, especially if we propose a draft wording in the issue
<Jem> https://
Siri: In the note for aria-current, why does it say "aria-selected=true indicates [...]"
Matt_King: Does that note suggest that we should be using aria-selected?
[Jem reads the note]
"In some use cases for widgets that support aria-selected, current and selected can have different meanings and can both be used within the same set of elements. For example, aria-current="page" can be used in a navigation tree to indicate which page is currently displayed, while aria-selected="true" indicates which page will be displayed if the user activates the treeitem. Furthermore, the same tree can support operating on one or mo
re selected pages (treeitems) by way of a context menu containing options such as "delete" and "move."
Matt_King: In a single-select tree, often the item that is focused is true. It's not necessary for the author to specify aria-selected=true because the browser will do that automatically
Matt_King: You sometimes will see aria-selected set even though it wasn't set by the code
Matt_King: That's the page which will become current when the item is activated
Matt_King: It could also be the case that that navigation tree allows you to do things (like moving things up and down), aria-selected tells you which you will be operating on, while aria-current tells you which is displayed. You may be operating on a tree which is not displayed
Siri: aria-selected=true might confuse me because I would only use aria-selected or aria-current, not both
Adam_Page: I had no idea about this browser behavior!
Matt_King: Sarah and I worked on the user-agent language for this (for tree item, grid cell, option, and maybe more). We had the same language in different parts of the spec so that browsers know what they can do and when they're allowed to do it
Matt_King: The browser cannot do this if it's a multiple selection or if the author used aria-checked
Matt_King: Anyway, there's a little bit of user-agent code that's in there that allows you to do some things automatically
Matt_King: Okay, I've labeled the issue, so we're done with this
Issue 3370: How to manage focus for disable tabs
github:
github: w3c/
Matt_King: Let's save this for next week
Issue 2735: Should APG CI include running regression on macOS?
github: w3c/
Matt_King: howard-e points out that if we proceed with the open pull request for this, there would be other failures
Matt_King: If people are going to run this locally, it should match CI. If they don't match, then that defeats the purpose of running locally
howard-e: That's the value-add. That, and increased robustness
Matt_King: Ah, I see--you said that if you ran it with macOS in CI, it created issues that you didn't observe locally
howard-e: It looks like my final question here was whether we wanted to commit the time to figure out what's happening there
howard-e: I also wonder if we've seen other folks running into issues on their Macs
Matt_King: I think it would be more robust if the CI also ran Mac, but that adds more complexity
Matt_King: If this could turn into a rabbit hole, I don't mind leaving this open for another day (and perhaps another contributor with more experience)
howard-e: I could take the next step--I could at least check in on the updates that have happened since we last discussed this, and I could share the result of that research
Matt_King: That sounds good
Matt_King: Do the folks here develop on Mac?
Adam_Page: I do
arigilmore: I do
cbellew: I mostly develop on macOS, but I also develop in Windows
Adam_Page: I test in Windows, but I develop in macOS exclusively
Jem: I just assigned howard-e to this issue and added Adam_Page and arigilmore as reviewers
Jem: I think we're done. We'll see you all next Tuesday!