Meeting minutes
<Jem> https://
Setup and Review Agenda
Matt_King: We may skip the topic on Ari's work since she isn't present today
Matt_King: Any requests for change to agenda?
[no requests]
Matt_King: Next meeting: February 4 (Tuesday, as normally scheduled)
Publication planning
Matt_King: The date will be February 25
Matt_King: I haven't added anything new to the publication
Matt_King: Right now, that includes the high-contrast work and a fix which is later on in today's agenda
Matt_King: The primary focus, though is, that high-contrast patch
Matt_King: That's all I have right now. Any questions or comments?
jongund: did you want to try to get this landmark region work on that publication?
Matt_King: I haven't reviewed it, yet, but we can definitely try. It's already on today's agenda
PR 3194 - Grid and table properties practice editorial fix
github: w3c/
Matt_King: The change in this pull request seems good
Matt_King: Adam noted that the problem exists elsewhere
Matt_King: It seems editorial because it's a misplaced ">" in the code example (not in executable code)
Matt_King: Adam said the change here is good. He asked the person who wrote the PR if they could fix it in the other place where the problem occurs
Matt_King: It's been over a week, though, so I'm wondering if anyone here would like to push the fix
howard-e: I can help out, though I notice that this patch is the author's first contribution to the project. It might be nice to give them a little more time
Matt_King: You're right, there's no rush here. Though if we push to their branch, they will still be recognized as a contributor
Matt_King: If the original contributor provides that fix before February 11th, great. If not, we'll have howard-e or someone else lend a hand on their branch
PR 2991 - Practice Page for Supporting High Contrast
github: w3c/
Matt_King: I have been reviewing from the perspective of someone who doesn't know anything about this topic
Matt_King: It feels unclear to me. In some cases, if the author does nothing to support these settings, the content is still rendered fine.
Matt_King: In the case of increased contrast and high contrast modes, isn't it the case that if someone changes those settings, and the author does nothing, that content can disappear?
jongund: I think the current practice lacks an answer to "what should I do?" We can say, "you should at least do this if you want to comply with WCAG". The only thing we've done is try to comply with contrast themes (as implemented in Windows)
jongund: Increased contrast seems to me like, kind of a "why do it?" issue. Unless you are trying to meet "contrast enhanced"...
Matt_King: If the end user goes to their operating system and chooses to increase contrast--if they visit a webpage where the author has done nothing to support that, then the web page will render without problems
jongund: Correct. If you don't support media queries, then the page renders as if the media queries were absent
jongund: I believe in our examples, if we didn't support high-contrast themes, you would just get the colors that the author originally specified
jongund: but it's complicated; it depends on how much your page is inheriting from the operating system and the browser's default settings
Matt_King: Is it the case, if you're using the author-specified colors, and somebody has chosen a Windows contrast theme--are there scenarios where, because of author-specified colors, that theme would cause content to not render in a perceivable way
jongund: that's definitely a possibility
Jem: Are you talking about operating system configuration changes?
Matt_King: If the user changes the OS scheme, and the author has specified colors without referencing the force-colors media query, the page may render in a way where the content is not perceivable
Jem: Are you talking about the case where the operating system overrides the color settings?
jongund: the browser changes its default stylesheet to a configuration that complies with the Windows theme
jongund: I wouldn't talk about overriding, exactly, because it is changing the default of the browser
Jem: When I studied the trusted [??], there was a role that could override the system settings
jongund: A lot of developers insert a "reset" stylesheet. They're saying, "I don't want the browser to tell me anything; I want to start with this base" So I don't think you can say the default stylesheet of the browser is an accessibility setting
jongund: In some of the ARIA meetings I attended a few years ago, we met with the CSS working group, and they stated that over half of the pages on the web (at that time) use reset stylesheet
jongund: None of this is specified, though, so I think the best recommendation we can make is that "you need to test"
jongund: What Microsoft, Google, Apple--whatever--decides to do with that information is I suppose their best guess at what their users want
jongund: Could there be problems with rendering if people enable them on the page? Yes
Matt_King: Should there be guidance on this page that says, "here are some really common problems which cause content to become imperceivable"
jongund: for "current color", that is an issue because you only get the color of the rendered text. If that color changes from black to white, and you have a white background, that content will disappear
jongund: "current color" to me is kind of a risky way to inherit these system colors
Matt_King: Should the recommendation to be not to do it that way?
jongund: Well then what should we do with all of our examples?
Matt_King: I'm thinking in terms of, "there's a lot of stuff you could do; what happens if you don't do it?" If the answer is "nothing, really", then that's fine
jongund: I think we should say to avoid using "current color" for that particular reason. I would be willing to say that
Matt_King: I think making it really concrete... In so many places, you've done an answer job creating functional examples. I wonder if you'd like to just show the problem with "current color" in a concrete way
jongund: That could work
Matt_King: I have another question on the level-2 heading for the contrast themes. In the table above, we say "contrast themes aka high contrast mode". I wonder if we should do that in the heading as well
Matt_King: That's a common term, so I'm wondering if we should use the same wording in the heading
Matt_King: That's the heading for the section on "Contrast themes"
<Jem> https://
Jem: If it makes the content clearer, then why not?
<Jem> https://
Matt_King: This is the second-to-last section on the page
jongund: As I recall, the Microsoft system settings talk about "high contrast themes"
Matt_King: I would like to be more friendly to a wider audience. The programmers can read the details
Matt_King: I'm also thinking that in the one where we say "color screen light or dark", we could instead say "light or dark modes"
Matt_King: I hear everyday people use those terms
jongund: Yeah, I think that's a good idea
Jem: We use the word "themes", not the word "mode". It doesn't matter much to me, though
siri: Whenever I hear "high contrast mode", that is the setting I see in Windows
siri: Slowly, we are moving away from that. We're moving towards "forced colors", etc.
siri: If we put "high contrast", some readers may get confused
Matt_King: When I was looking at this in Windows, I thought it used the term "high contrast". Is that still the case today?
siri: This morning, my system was updated, and it no longer uses that term
Matt_King: Windows is saying "contrast themes", and if I go to "contrast themes"... Hm.
siri: Only the older versions of Windows used the term "high contrast". Now, it is different
Matt_King: Reviewing these, the names are "night sky", "dust", "desert", "aquatic", and "none". None of them even use the term "high contrast" in the name of the theme!
Matt_King: Well then, maybe we should completely remove "high contrast mode"
siri: That's what I was thinking
jongund: I don't think we should talk so much about "high contrast", either. I don't think it's accurate about what these settings do. They can be used to achieve high-contrast, but in and of themselves, they don't necessarily do that
Matt_King: Should we just change the section title to "Supporting color contrast settings"?
<siri> +1
jongund: That would be more appropriate
Matt_King: Okay! Any objections from anybody to changing the name of the practice?
Jem: no objection
Matt_King: Great! (This is going in a direction I didn't expect. I'm glad I asked!)
Matt_King: Now, there are a couple places on this page where I think the way the page is displayed depends on the browser you are using. I don't think that's explicitly stated, though
Matt_King: Isn't it the case that what you see depends on what browser you use?
jongund: The only one I'm aware of is system colors
Matt_King: Okay, just system colors. So not "increased contrast examples? That one doesn't change?
jongund: We don't do anything to support increased contrast on our pages (other than tiny examples)
jongund: Maybe on the "systems color" page. The only red flag is on Chrome, for accent color and accent color test, their default color is transparent. I could put a warning to say "use with caution because some browsers such as Chrome render this as transparent which may effect color contrast"
Matt_King: Yes, please add that
Matt_King: I still feel like there are some aspects of system colors where I feel like we're not quite bringing people up to speed on what's happen
Matt_King: But following today's discussion, I think I can make comments on specific lines in your page
Matt_King: Okay, that was a lot for this section. Any other questions or comments?
jongund: Just to be clear: you want me to add an example of where "current color" could cause problems?
Matt_King: Yeah, explain exactly how things can disappear, and show an example
Matt_King: Thank you jongund. I will be making the other editorial changes that we discussed
PR 3214 - Multi-thumb slider fix
Matt_King: We'll skip this since Ari isn't here
github: w3c/
Issue 3215 - Expandable region example
github: w3c/
Matt_King: This came up in the ARIA working group meeting
Matt_King: There is possibly the need for an example that is like a disclosure but which is distinct due to: a larger click target, a different example/collapse icon, and the mouse behavior.
Matt_King: I hope I'm representing this well. We might want to have Scott give more input
Matt_King: The description of this issue is, I believe, fairly complete
Matt_King: This originally came up because people are nesting content inside of a button. You click the button, and the content appears. That of course is a problem, and it was suggested that the APG give a better alternative
Matt_King: One of the requirements (which Scott does address) is that there is something visible which means "expand" and which would also be focusable
Jem: I like Scott's idea
Jem: Do you see any concerns about this proposal?
<jongund> https://
siri: My only concern is that the entire "card", if you made it focusable, wouldn't that be too much for the screen reader?
Matt_King: Scott said the "plus/minus" would be used by screen readers
Matt_King: I think they're talking about a larger chunk of content being clickable
jongund: In his example, he's showing partial text (the first paragraph of an article), and if you click, it expands to show all of the text
jongund: That's a pretty common patter that you see in a lot of websites
jongund: One of his examples has an "expand/collapse" button, and that's what becomes focusable
Matt_King: Is the actual focus only on the "plus/minus" but it's only drawn around the entire card?
Jem: It's on the entire card
Matt_King: The screen reader would describe the entire card, then, and that's a bad user experience
jongund: does the screen reader need to know anything? They have access to this regardless
Matt_King: We don't want screen reader users to think that something is visible when it isn't (or vice-versa)
<Jem> https://
jongund: Okay, well, what if when you have a little box that's scrollable--does the screen reader know that there is scrollable content on the page?
Matt_King: They don't have to know that, necessarily
Matt_King: I'm always hoping that the part that I'm reading is visible to other people
siri: I just ran NVDA on this example. It is not reading the text when it isn't visible. When I get to the card, it reads the title of the card. It tells me the content is collapsed.
Matt_King: Is the resolution as simple as turning Scott's example into an APG example?
jongund: I think it could be that straightforward
Matt_King: That's good, I think. I'll get this back on the agenda for next week so we can talk about next steps. It does seem like there's a practical path forward based on what's Scott's saying
<siri> also heading is narrated as clickable by NVDA
Matt_King: I hear what you're saying, though, siri. I don't like the fact that you have to go backward, either
Matt_King: Okay, we're at time. We'll get to the landmarks issue next week