Meeting minutes
<Jem> https://
Setup and Review Agenda
Matt_King: Any requests for change to agenda?
howard-e: I have a tiny infrastructure comment, but it's not pressing, and it's something we can continue in the issue. It's related to macOS testing
howard-e: We have our regression tests that have been running with Ubuntu for a long time. Recently, persons have made comments about issues with running in macOS. So I'm wondering if we want to expand the set of operating systems we are using in the continuous integration environment so that we maintain awareness of issues like this
howard-e: w3c/
howard-e: We don't need a discussion item for this; I just request that people review that issue and chime in
Matt_King: Next meeting: February 25
Publication planning
Matt_King: We're planning a publication for next week, primarily featuring this color-contrast settings page.
Matt_King: Wow did Jon add a lot of content! I think there's room for a lot of editorial revision, though, so I wanted to talk about pushing publication back by one week to accommodate review
Matt_King: We could push back by two weeks, but that would put publication during the week of CSUN. I'm not sure if that would be a problem
howard-e: March 4th would work for me
Matt_King: Okay, any objections?
Matt_King: Hearing none, I'll plan to check with Daniel
Matt_King: Also thanks to Adam_Page for the review
Adam_Page: Absolutely
PR 2991 - Practice Page for Supporting color settings
github: w3c/
Matt_King: Please open the "preview" link which is listed at the top of the pull request
<Jem> https://
<Matt_King> link to preview of practice page:
<Matt_King> https://
howard-e: There was a bug with the Netlify cache which impacted this pull request and a few others from around the same time. I have since logged in to the Netlify account and manually refreshed it
Matt_King: There is a section titled "Contrast themes forced colors"
Matt_King: This is primarily about what Microsoft Windows does
Matt_King: This has turned into a really long section
Matt_King: There's a lot of really good information here, but I'm really kind of worried about the primary messages getting lost or not being clear from the top
Matt_King: I'm kind of wondering what the primary messaging should be--that's the question I put into today's agenda
Matt_King: At a high level, I feel like the structure might not support the messaging
Matt_King: One of the first questions I have is, if somebody is using all native HTML and no ARIA at all, is it the case that these contrast themes will just work well with the way browsers use system colors? In general, is that the simplest way to support the contrast themes?
Adam_Page: When you said, "no ARIA", did you also mean "no custom CSS"
Matt_King: I didn't mean that, but maybe when we talk about CSS, we talk about the changes to hover, etc.
Adam_Page: I heard "no ARIA", and my instant reaction was "how can ARIA even effect this, anyway?"
sarah4: That was also my question
<lola4> ditto
Matt_King: If somebody makes a "div" with a "role" of "button", that button is going to end up looking like text because the browser does nothing with the semantics of that button (e.g. it won't give it the system colors that are related to buttons)
Matt_King: So I'm wondering, is "message number 1". Is it true that if you don't use ARIA, you will automatically get a page that works well with contrast themes?
sarah4: Yes, there are other ways to break it. You can break it with CSS, as well.
Matt_King: Okay, so I guess we don't want to give the primary message of "just use native elements, and you're better off"
Matt_King: I wonder if we even address these issues in this content...
sarah4: There could be meaningful color. Imagine that you have icons with people that are accompanied by a colored dot whose color describes each person's status
sarah4: You could easily design something whose focus outline is not super-visible in high-contrast mode
sarah4: There are a lot of cases where you actively need to design things to be visible in high-contrast mode
Matt_King: Some of those sound like they would be related to customized widgets
sarah4: I don't remember if "select" adopts actual colors from Windows high-contrast themes...
sarah4: If you're building a menu, for instance, you could build it with "button". That would give it slightly different border colors in high-contrast mode
Matt_King: I guess what I feel like we're missing here in terms of high-level messaging is, we don't even have a recipe for people to follow. This is for a "practice" page, after all.
Matt_King: It feels like what we don't have anywhere in this section is like a recipe. "Add this many cups of flour and this many cups of sugar, and you'll get there"
Matt_King: Is a simple five-step recipe a way to support forced-colors--surely that has to be a feasible idea. We can do that, right?
lola: Why are we not relying on the current accessibility advice when it comes to color?
lola: Is there something in that advice which doesn't apply here?
Matt_King: We are relying on the standard color advice; it's linked here like ten times
Matt_King: The list of things you need to do or consider in order for a contrast theme to work well with your page
Matt_King: When I read this section, now, it reads to me like a ton of confusing information
sarah4: Another way to screw up is using the wrong background color or a box-shadow to differentiate the boundaries, and when you enable high-contrast mode, that becomes imperceptible
sarah4: I think the problem is the way to design for high-contrast mode is similar to designing for everything else--you really need to turn it on and audit everything to make sure it all looks good
<lola4> Sarah got to what I was trying to say lol
CurtBellew: The question is, "do I see everything the way that I should?"
Matt_King: Yeah. If you could share a link to your tips in the minutes, sarah4, along with a link to Melanie's article...
Matt_King: One of the things that jon had been talking a lot about were the advantages of using system color over current color, but this copy right now addresses current color, first
sarah4: I think I threw something in about svg's for icons with current-color
Matt_King: Adam_Page raised a point (and made a couple suggestions that got committed) that were related to "current color" camel-casing
<sarah4> Dropping the zoom comment on article links here too:
<sarah4> Melanie’s Edge blog: https://
<sarah4> My tips: https://
<sarah4> Adrian has a post too: https://
Adam_Page: It was pretty editorial, but I found different instances of capitalization, and I lost track of what Jon was communicating
Matt_King: Is there a difference between "current color" as a concept and using "current-color" keyword as a technique
Adam_Page: It's really a technical writing question. I don't think there is a concept which is distinct from the keyword
Matt_King: Right now, just getting it consistent on this page would be good
Matt_King: I looked at the MDN article, and I don't remember seeing it camel-cased there
sarah4: Functionally, you can type either, and it will work. I use camel-case because it's what's in the CSS spec and it seems more pedantically correct
Matt_King: If there's no such thing as a clear concept where I would use "current color", then I'm going to adjust the phrasings so we're consistently talking about the "currentColor" keyword, and I will camel-case it
Matt_King: Adam_Page also made a suggestion related to nested CSS which was beyond me
Matt_King: Jon said that it was an editorial decision which he would leave to me
Adam_Page: That was a super-soft suggestion and also not specifically related to high-contrast (the content of this effort)
Adam_Page: It's only because I'm still new to the APG that I find myself having these ideas during code reviews
Adam_Page: Where I am seeing opportunities to modernize the language and make it easier for folks to understand
Adam_Page: I've had similar suggestions in other PRs
Adam_Page: This is one where, to me eyes, using native nested CSS would make it cleaner and more readable, as a reference
Adam_Page: There are five or so code blocks. I picked on just one knowing that this would be a much bigger conversation
Matt_King: Well, just because we make THIS page more readable... In the pages of the APG itself, you don't see any CSS. This is a very exceptional page
Matt_King: Of course, if you go to the examples, you see CSS. But that would be a separate conversation--one that would involve the code guide
Matt_King: We don't have to get into the code guide if we're only discussing the code samples that are present on this page
Matt_King: Anybody think it would be a problem if we accepted Adam_Page's suggestion?
howard-e: No problems, here. I'm also in support. For what it's worth, I've been using styled components in post-processors in Motion et. al for some time. I'll always support the approach that Adam_Page suggested here
Matt_King: If we accept the one commit that you made there, would you be up for making similar suggestions for the other examples on the page
Adam_Page: I'm up for that
Adam_Page: I'm glad you mentioned the code guide. I was aware that it existed, but I haven't reviewed it very thoroughly. I've had an itch in the back of my head about what APG supports in terms of browser versions
Adam_Page: I feel like we should conform to that code guide throughout the APG
Matt_King: With a large project like this, it can be had to evolve all the code at once
Matt_King: Right now, we make the code guide be our aspirational bar--it's what we use for anything new that comes in.
Matt_King: If you think we need some changes to the CSS part of the code guide, Adam_Page, we'd gladly take a look at those, as well
Adam_Page: Great! One other thought I had along those lines was that now that Baseline is a thing, maybe we can start to reference it.
Matt_King: Could you raise an issue about this? And include an intro to Baseline?
Adam_Page: Absolutely
Matt_King: I feel like the best use of people's time right now might be to go off and read the two resources that sarah4 has shared. That might help shape this content better. It also might add to the timeline, but I think it's probably worth it
Matt_King: Any further questions or comments on this topic before we move on?
Matt_King: Hearing none, we'll move on. I really appreciate all the input!
Matt_King: Our goal is to deliver something that's really practical and really useful to the community. I want to avoid falling into any rabbit holes, but at least give readers pointers to the rabbit holes
Issue 3232 - rowgroup for table body
Matt_King: We'll skip this topic for time
Issue 3238 - Hover moving focus in menus
github: w3c/
sarah4: Application menus on Windows (and maybe macOS) have focus follow hover when they're open
sarah4: The editor menu example in the APG does that same thing. When you have an open dropdown menu, focus follows hover
sarah4: That happens in the script, and there's a line in the guidance that describes that behavior
sarah4: Because of this, we did the same behavior in my library that I work on. We've had a number of problems since making that decision (especially when there's scroll overflow)
sarah4: I'm not sure what the benefit is of focus following hover--other than that Windows and macOS do it
sarah4: I'm wondering if there's a benefit beyond matching native OS
Matt_King: One thing that happens to me is, when I'm using Google Docs, and I press alt+shift+A to open the accessibility menu--if my mouse happens to be sitting in the area that that menu pops open to (so that the mouse ends up being somewhere in the middle of the menu), then the comments item automatically gets activated, and I end up in a sub-menu of the accessibility menu.
sarah4: Yeah, that's another example of what I'm talking about
Matt_King: If weird stuff like that is happening, I go through an exercise to park my mouse in a corner of the screen, and the problem goes away
Matt_King: Freedom Scientific was talking about making that behavior happen automatically--they just have to do so without disrupting mouse users
sarah4: It makes me sad that the workaround is "move the mouse"
Matt_King: I thought we made it so that you had to click, so that we weren't ever moving focus unless you clicked
sarah4: I went back and read all the discussions. On the editor menu bar (not in the dropdown menus), focus doesn't follow the mouse before you've opened anything. As soon as you open something, it will follow
Matt_King: Ah, so that's why it applies to my case. If you open with the keyboard, and the mouse is in place, then boom
sarah4: Right
Matt_King: Let's say someone clicks on the first drop down, and that opens the first dropdown, but then they move their mouse to hover over the second item in the top menu bar. They are expecting to see the items in that menu to be automatically displayed...
Matt_King: If focus moved when they did that first click, but then wasn't moving as they hovered over the second, third, fourth items in the menu bar--does that have any negative side-effects? If the focus doesn't move?
sarah4: I think we could still handle focus if, with your mouse, you close
<Jem> editor menu bar example link https://
sarah4: I think we could do a focus-recovery thing with more nuanced heuristics (without having focus always follow hover)
Matt_King: Do all the negative side-effects of this occur when somebody isn't actually moving the mouse?
sarah4: Yes. I can reproduce this in the example right now: I put my mouse underneath the dropdown, then use the keyboard to open the dropdown, and focus jumps to the location of my mouse
Matt_King: If someone is driving their magnifier with their mouse, and they also use the keyboard--that is a case where you also want focus to move, right?
sarah4: I don't think so. I believe with something like zoom text, it will follow focus of the keyboard
sarah4: I don't think Zoom Text needs our help
Matt_King: If it's always related to side-effects of the mouse being static, I wonder if there's a really simple approach.
Matt_King: If there's no mouse movement...
sarah4: We did that--we switched to using "mousemove". The side effect of that, is that if your mouse is just resting, then focus won't immediately jump, but if you just brush your touchpad or bump your mouse...
Matt_King: Oooh, right. I disable the touchpad for this reason
Matt_King: We recently landed a pull request that addressed this, partially at least, on one example. I think it was on one of the "action menu button" examples, but I'm not sure
Matt_King: What you're talking about here is more like the guidance. I feel like we should update the guidance and then use that to raise bugs against the examples
Matt_King: Is there anybody that has any objection to removing automatically having focus follow hover?
Jem: It sounds like removing that would be a straightforward solution for now
Matt_King: We don't have any accessibility for keeping this capability of having focus follow hover, right?
Matt_King: Hearing none, I think that answer's sarah4's most fundamental question
sarah4: Excellent. I can even open the pull request to make this change
Matt_King: Awesome