Meeting minutes
Setup and Review Agenda
Matt_King: Next meeting: July 30
Matt_King: Any requests for change to agenda?
Matt_King: Hearing none, we'll stick with the agenda as planned
Publication planning
Matt_King: Next publication will be 2 weeks from today, August 6
Matt_King: Publication planning
Matt_King: https://
Matt_King: Pending final review: Feature: Search for patterns, toggle grid/list view by stalgiag · Pull Request #3043 · w3c/aria-practices w3c/
Matt_King: Pending fix to one review finding: PR 3041: All Example Pages: Add source copy instructions and CodePen button to HTML source section by ariellagilmore w3c/
Matt_King: CurtBellew spotted a problem, and I was able to reproduce it. ariellagilmore commented just 3 hours ago; it sounds like the problem may have been an issue with the preview, specifically.
Matt_King: This may be ready, after all
CurtBellew: I can take another look in light of ariellagilmore's latest comment
Matt_King: The only other item is in regards to high-contrast; we have a separate agenda item dedicated to that
Regression test fix
github: w3c/
howard-e: This is a change related to the viewport with a specific test
howard-e: It aligns the test with others in the suite
howard-e: previously, there was some flakiness--perhaps because the click was happening while scrolling was in progress
howard-e: I could reproduce the flakiness locally with the previous version, but I couldn't reproduce it locally with this version
jongund: I'm looking at the code right now, and it looks good to me
jongund: I'll verify the fix locally and submit a review
Matt_King: Thank you, jongund and howard-e!
Tablist naming guidance
github: w3c/
Matt_King: the "tabs" pattern suggests that a tab list should have an accessible name
Matt_King: Name is not required for tab list by the ARIA specification
Matt_King: ...so the current language is probably not appropriate because it sort of implies that a name is required
Matt_King: We say that the name is recommended for tab list. I actually think that's a good idea
Matt_King: We express the importance of naming with four different levels: required, recommended, discretionary, and "do not name"
Matt_King: This one, for tab list, we currently have as "recommended"
Matt_King: There's some argument here that it should instead be "discretionary" and "do not name"
Matt_King: But if we look at the use-cases we have in the APG, there is no visible name and a accessible name provides clear benefit
Matt_King: So, in my mind, that justifies either "recommended" or "discretionary"
jongund: Do screen readers consider a grouping label, like if you go into a tab list, does it read the name?
Matt_King: Well, they should, and it's something we can test in ARIA-AT
Matt_King: in the carousel JAWS doesn't say "tab list" which isn't great (although it does tell you when you're on a tab)
jongund: I think that's an even stronger reason to recommend it--there's a known user benefit
Matt_King: If there *is* a visual label, then there should be a screen reader label. If there's *not* a visual label, then at least one person in this issue was saying that there shouldn't be a screen reader label
Matt_King: ...though I still think there's benefit to a screen reader label in cases like the carousel
Matt_King: But this shouldn't be about my opinions. Do you use this pattern much in your products, CurtBellew?
CurtBellew: I advise a name
jongund: I think one thing we may want to consider is whether there is a visible label for the tab list. That seems to be a stronger argument
jongund: If there is a visible label, that's an indication that it should be used in this particular case
CurtBellew: As in referencing it via "labeledby"?
jongund: yeah, that would be the preferred way
Matt_King: So if there is no visual label, should it still be recommended to provide an accessible name to the tab list?
jongund: If there are multiple tab lists on the page, then you might not recognize that you've moved between the two unless a name is used
Matt_King: I have a difficult time thinking about a scenario where there's no benefit at all
jongund: I think it would be useful to point out that it's especially useful when there's no visual labels or when there's multiple tab lists on the page
Matt_King: We could add a phrase like, "especially when multiple tab lists are present"; but I think it's always helpful
Matt_King: Maybe we can write a pull request that makes it more clearly "recommended" rather than vaguely suggesting that it's required
Matt_King: I think it appears in multiple places, so we'll have to take care to search the APG for where it needs to be changed
Guidance for other high contrast media queries
github: w3c/
jongund: There are three main ways for users to adjust the colors of rendered content, with two of the ways detectable by the author. Our patterns only demonstrate the use of the "forced-colors” media query which right now is only implemented on the browsers for the Windows 10/11 operating systems. We don't have any examples using the “prefers-contrast" or “prefers-color-theme” CSS media selectors. Let's discuss guidance fo
r “prefers-contrast” and “prefers-color-theme”.
jongund: It was kind of eye-opening for me to look at all these different things in depth
jongund: The operating system features that are available and how they impact what authors can actually detect
jongund: The big thing that all OSes have is "invert colors"; this takes all the RGB values and subtracts them from 255
jongund: On Apple, it's just a visual effect--it doesn't impact the computed color in the browser, for example
jongund: I don't know how it works in Windows
jongund: The next one is contrast. There's dark-screen mode and light-screen mode
jongund: There's a media query for this: prefers-color-scheme with values "dark" or "light"
jongund: It seems to be geared toward people who are working at night or low-visibility settings
Matt_King: If a user prefers dark, then a web page doesn't have to do anything special
jongund: Right. The chrome of the browser changes, but the pages themselves don't change unless the author has defined a media query for it
Matt_King: I don't know for sure, on Facebook for instance, whether the dark mode has to be turned on in Facebook or if it has a media query
jongund: Under "accessibility", there's something called "increased contrast"
jongund: This one's a little more buried
jongund: It's a toggle which, when enabled, sets a media query for "prefers-contrast" with the value "more"
jongund: Again, that changes how the browser chrome appears, but it doesn't impact the rendered content (unless the author has defined a media query)
jongund: Windows has a unique feature called "contrast themes"--at least 3 or 4 themes that users can select
jongund: Those actually change the web content
jongund: First: should we be looking at these other media queries and supporting them?
jongund: Second: what is our definition of support when they are not available across platform?
jongund: We have a lot of information about how to use "force-colors" and it's still useful, but I don't know if we have to be clear about whether its universally useful
Matt_King: So in the examples that we have that are currently supporting high-contrast...
jongund: It really only makes a difference if you're using Windows. There's no setting on a Mac that would change the CSS media query "force-colors"
jongund: I don't think it's considered an accessibility feature; it's usually in "display options" or "appearance", not in the accessibility section
jongund: If we're going to call it out, we might acknowledge that this feature is not necessarily organized alongside accessibility features
Matt_King: At the APG, we want to help web authors support people with disabilities. APG is mostly focused on keyboard and assistive technology, but I think this is an important topic that's not addressed elsewhere
Matt_King: We want to give people guidance on the best way to support people using color
Matt_King: But based on what you're saying jongund, it doesn't appear as if there is a single approach that always works on all platforms
Matt_King: "prefers contrast" is a toggle, right?
jongund: Yes; but that makes me wonder about WCAG conformance
jongund: It's present in all the platforms
Matt_King: What does it mean to support it? If you do the query and you find out that the value is set to "more", what does the author need to do?
jongund: The only thing I could think of on the first level is that any page now needs to meet WCAG "AAA" requirements
jongund: It only signals to authors that, "hey, this person prefers high contrast"
jongund: Maybe it should be taken as "hey, you should do something about that"
CurtBellew: I have not come across this media query. We have thousands of products, but I haven't come across it, personally
Matt_King: arigilmore, do you know if Carbon does anything with this media query, "prefers contrast"?
arigilmore: No, I don't believe so
Matt_King: It's interesting that the setting exists, that there's a media query for it, but I wonder if anyone's actually doing anything with it
Matt_King: It seems like it would be important to include this, but it also seems like we want to suggest what to do with it. But then, it almost seems like the entire website needs to model appropriate behavior
Matt_King: And then I wonder, what's appropriate in this case?
jongund: My guess is that people are just relying on "invert color" because that just means that a light color scheme now becomes a dark color scheme
Matt_King: I don't think that you would want to invert colors if "prefers contrast" is set to "more". That could be pretty shocking
Matt_King: The operating systems don't behave that way, after all
Matt_King: You've raised a good set of questions, jongund, but it doesn't seem that anybody here has any concrete knowledge about what to do
Matt_King: It makes me wonder about how the folks in the CSS working group managed to get this added
jongund: These are features in operating systems that they put into CSS
Matt_King: Maybe we could ask people like James Craig and Scott O'Hara. "So you have these features in the operating system..." Well, I wonder if sites like apple.com or microsoft.com are responsive to those systems. We could ask people at Apple and Microsoft about what their operating system does in response to those settings
Matt_King: jongund, could you raise a specific issue just for the "prefers contrast" media query so that we can get a discussion going with folks from Apple and Microsoft and learn how web authors should use them?
Matt_King: As for "prefers color theme", that seems really straight forward
Matt_King: I guess you need to build infrastructure to support dark mode...
jongund: The apple website does not respond to dark mode or increased contrast, but the macOS operating system does
Matt_King: So maybe the answer is to be silent on these things...
Matt_King: Lets raise an issue for each specific media query and tie it back to this first issue for developing guidance for high-contrast
jongund: Got it. Will do