Meeting minutes
Setup and Review Agenda
Matt_King: On the agenda today, we have a few pull requests that are planned for the upcoming publication
Matt_King: We also have pull request 3418 at jongund's request
Matt_King: And we have two very good questions on the date picker
Matt_King: And this may be aspirational for one meeting, but a seventh item for another issue
Matt_King: Any requests for change to agenda?
Matt_King: Hearing none
Matt_King: Next meeting: Wednesday, September 16
Publication planning
Matt_King: Schedule revised to September 17 (previously August 27)
Matt_King: Includes 5 pull requests
Matt_King: 1 is merged and four are in-progress
jongund: I've implemented the changes you requested for my skipTo patch, so I think it's ready for another review
Matt_King: Got it. That's in the current milestone, so I will revisit it
Matt_King: The quantity spinbutton was on the agenda last time. Adam has done all the work and is ready for re-review by Joe_humbert, daniel, and myself. I believe jongund is assigned for review, as well
jongund: Got it. I'll take a look at that one, as well
PR 2991: Add Practice Page for Supporting Color Contrast Settings
github: w3c/
Matt_King: After the previous two meetings, I've made significant changes and requested another review
Matt_King: Aside from some minor editorial changes, the major changes are in the section on "contrast themes"
Matt_King: Regarding the framing: this was previously listed as a Windows-only feature, but Microsoft's latest updates indicate a large effort to make this more of a web-platform feature (rather than a Windows-only feature)
Matt_King: It appears that in a very limited way, Mozilla has implemented this in Firefox
Matt_King: That was the reframing I did in the very beginning--just updating the way we're describing the feature
Matt_King: When I made that change, it affected the structure of the section. I tried to make it mirror the content of other sections more closely
Matt_King: Has anyone had an opportunity to review those changes?
jongund: I have
siri: I have not, but I can review if you would like
Matt_King: Yeah, I would like multiple people to look at it
jongund: My main concern is that, while I agree this is becoming more of a platform feature (and it may get into Chrome with Microsoft's support), I think we should provide more information about the Firefox feature
jongund: We should make it clear that there is a Windows feature that works in all browsers on Windows, and that there's a Firefox feature that is cross-platform
jongund: Right now, I'm actively researching the effect that the Firefox functionality actually has on the platform
jongund: I believe they use shades of colors, and I want to better-understand what Firefox is doing right now so that we can explain that a little bit in the practices so that people understand the differences
jongund: I think we may find somewhat interesting subtle differences
jongund: For instance, visited link text is not affected by the color theme, but it might be with this new feature
jongund: I don't know if those things are important right now, but I'd like to have more information before deciding what we document
Matt_King: In the introductory part of the section, it starts out with "Contrast themes are an accessibility setting available in Windows in Firefox that [...]"
Matt_King: What I tried to do in that "intro" section (especially in the second and third paragraphs) is explain the mapping of colors and theme. (It was difficult because it's kind of hard to understand the mapping of what's going on)
Matt_King: Combined with the table below that shows all 19 colors and how they are mapped--that's where I'm hoping you can help, jongund. To understand which colors are used, which are not used, etc. Maybe some are used but with slight variations
jongund: I'd like to do some more research to figure out how new information might be useful. But yes, it is already very confusing. My initial thought is that we have a section of what the Windows contrast theme does and a separate section for the "Firefox Custom Color Settings"
Matt_King: I'm hoping to avoid breaking it into two sections so that people can see that they're really the same thing. I think the table could help with that, especially if we add a column for Firefox. That would drive hope the interoperable aspects
<siri> https://
Matt_King: We don't need to explain the implementation details because most authors don't need that. I think authors just need to know what to expect when testing with these browsers
siri: I don't see a second and third paragraph
Matt_King: Scroll all the way down to the section on "Contrast Themes (forced colors)" (as a level-two heading). That's the section we're talking about; it's the section that has had the most work
siri: Ah, yes, got it
Matt_King: That's one place where I would really appreciate review. Is it clear? Do you understand the web-platform feature after reading?
Matt_King: And as for the table, it currently does not have a Firefox section. I'm hoping we can expand the table to explain the support across Windows, Chrome, and Firefox
Matt_King: If you look at that table, and you're using Firefox, that table would tell you how specific system tables are mapped
Matt_King: We have a table below that that has the Windows implementation that describes all the themes available in Windows. That's a lot of detail about the Windows implementation
jongund: Do you think maybe that's too much noise?
Matt_King: We can leave it for now, but I would like feedback from others. Is it adding too much weight to the section?
jongund: Maybe. Especially because it sounds like we won't replicate this table for what Firefox does
Matt_King: Yeah. And similiar for Chrome (although it would currently be smaller for Chrome because Chrome only has one theme)
jongund: I guess the key is what authors need to know
jongund: We use current color in many examples, I don't think we're using system colors
Matt_King: We have three: the rating slider, quantity spin button example, feed (I assume you added feed, I haven't verified that one)
Matt_King: So CurtBellew and Joe, please do share your perspective
Joe: It's been a while since I last read this page. I'll focus on that specifically
siri: As jongund was explaining, Firefox has it's own. Is there a way we can use existing research (e.g. WebAIM or similar) to focus on the themes that are common?
jongund: I think the main advice we want to give is which system colors to use and where to apply them
jongund: The specific colors that someone sets their computer to is less important
Matt_King: I think that's right. If you're using ARIA, and you're making a custom widget, the browser isn't automatically going to map to a system color for you. You don't want things to be hard to discern when a user chooses to use one of these browser or system features
Matt_King: So authors should take care in making their choices. We're trying to convey that authors should expect the issue and what to test
jongund: You want to tell force colors to use text like button text
Matt_King: Right, so that it doesn't appear like a non-interactive element
Matt_King: You want to make your widgets look as much like native widgets as possible, I guess
jongund: I'll do some testing. This Firefox feature might make the table smaller, I don't know
Matt_King: I think we need all 19 rows so that we can tell readers which colors don't get mapped at all
Matt_King: So this is a work-in-progress, but I think we're getting closer. The entire rest of the page is, I think, ready to ship, and this specific part is getting very close
jongund: I agree
Matt_King: So we would definitely like feedback on the clarity and usefulness of what's written there
PR 3449: Three Combobox Examples: Expand on click and improve filter behavior
github: w3c/
Matt_King: There has been some activity here between daniel and the contributor. I haven't written test-cases, so we don't have those to review
Matt_King: Is there anything else you'd like to bring up related to moving this forward, Daniel?
Daniel: No, I haven't been able to test the fixes they've pushed. I think that rather than me providing feedback which may confuse the implementation, we should get clear on what we want from this
Matt_King: For use case test cases, I think we want to communicate when you take certain actions, this is what should happen. E.g. when you arrow-down and there is only "AL" in the box, what should happen in the combobox and what should happen when you press escape and where the focus should go
Daniel: It's going to end up being a chicken-and-egg situation. Not only from a screen-reader perspective, having sighted people review is important
Matt_King: I'm going to put some effort into writing up something based on our conversation during our previous meeting. I hope to have that ready before our next meeting
PR 3418: Landmark Practice: Update alignment between HTML aside element and ARIA complementary role
github: w3c/
jongund: This is related to the "aside" element and when it becomes a landmark in browsers
jongund: It sounds like the spec may have changed since we originally wrote this
jongund: Also this ties in to the landmarks example, there has been discussion from taking the example out of the W3C space
Matt_King: I want to keep that separate
jongund: But should we update the example that we have to state what browsers do? Or take this as an opportunity to get rid of this and only tackle this in one place?
jongund: Are we trying to maintain something that we don't want to maintain?
Matt_King: That's a good point
Matt_King: If we want to use this as a catalyst for pulling things together so that we aren't doing some sort of unnecessary maintenance...
Matt_King: I don't know if it would be that much maintenance
jongund: I've already created a new example based on the current landmarks example. It has updated styling and more accurate information. It's just sitting on a github.io webpage--I haven't told anyone about it, but it basically provides the same information and some additional information on landmarks
jongund: If the group wanted to link to that as a resource for people to refer to for landmark guidance, then it would still be available to interested readers
Matt_King: This pull request was matching the current content to the spec, and when we looked at this, we had a discussion where we weren't agreeing with what was in the spec
Matt_King: We took this to the ARIA working group, and there was some push back there to changing what is said in the spec.
jongund: They wanted you to show examples of where the current change in the spec was causing accessibility problems
Matt_King: Right
Daniel: At which point, we should ask if we have bigger fish to fry. Because this is certainly annoying, but there are probably other things that have a bigger impact on accessibiility
Matt_King: That's a very pragmatic approach, Daniel. Given how much work it is to do that kind of research, I'm inclined to bight my tongue and accept it
jongund: Even if we could find examples of problems, it will take some time to address it, so we'd still want to document the current behavior for the interim
Matt_King: So we want to consider whether this is appropriate for the current milestone
Matt_King: This pull request updates the landmark-practices page. I'm okay considering us not updating the example page and entertaining a separate pull request that essentially removes the example page. I don't know if we have to synchronize those, though that would be ideal
siri: For me, I refer to the example page often.
siri: I was surprised to see why they came up with this new change for complimentary. We always thought complimentary was independent from main
jongund: I think we can try to synchronize them. I did some work a few months ago on a new example page that doesn't include the current example. I can dig up that pull request
jongund: I think the main thing we need to do is define what's considered a "sectioning element". I can see if we currently define that
Matt_King: That would be helpful. It feels like somehow this has become one of those balls of twine--when you pull at one thread, there are so many other things that are linked to it, and a small change becomes a big change
Matt_King: So for a plan: if jongund can help us put together a plan, that would be helpful. I don't know if it has to be done in this pull request
jongund: Let's continue with this pull request to fix the practices page and address the example in a separate page
Matt_King: And Siri was saying we should merge those simultaneously
jongund: Yeah
Matt_King: Okay, so you will work on the complimentary pull request, jongund?
jongund: Yes
Matt_King: Awesome. That's a good next step
Two Date Picker Dialog Issues
Issue 3151: Date picker dialog example - Feedback from APG list
github: w3c/
Matt_King: The "net" of this issue is that in the date-picker dialog, we don't have an interactive element inside the cells. We made the cells themselves selectable
Matt_King: That has some interesting consequences that I don't remember us discussing in full
Matt_King: A really good point made in this issue is that it makes it hard to disable dates in the past. You can't tell the difference between a select-able date and an un-select-able date. They're effectively the same, especially to screen-reader users
Matt_King: Our pattern doesn't current support use-cases that involve blocking out certain dates
Matt_King: One path forward would be to place toggle buttons inside the cells because they can be pressed or not pressed (which is like selecting them), and they can also be disabled. I've seen that in the wild
Matt_King: Is that a path that we want to go down with this? What are other people doing with their date pickers? Should we change the one that we have?
jongund: What if you put aria-disabled on a cell? What would that do? Is it allowed?
Matt_King: I don't think it's allowed, but we should check
siri: I saw some examples which are similar to ours, but they use the "button" role
jongund: aria-disabled is supported on grid cells...
jongund: ...at least in ARIA 1.3
Matt_King: I wonder if, from a screen-reader user's point of view, the buttons are more clear
Daniel: I don't have a thought on that, really. But going from Mark's comment, it seems that the absence of aria-selected means the cell is not selectable
Daniel: If we want cells to not be select-able, we don't use aria-selected
Matt_King: I have already tested, and I know the difference for a screen-reader user between "aria-selected=false" and no "aria-selected" at all is imperceptible
Matt_King: But aria-disabled on a cell could communicate "not select-able"
path forward: we are seeking a PR that will make dates before the current date disabled by putting aria-disabled on the gridcell.
Curt: At my company, we have date pickers with interactive gridcells and use aria-disabled