Meeting minutes
Setup and Review Agenda
Matt_King: Next meeting: June 25
Matt_King: No meeting July 9
Matt_King: Any requests for change to agenda?
Matt_King: Hearing none, we'll use the agenda as scheduled
Publication planning
Matt_King: Publication milestone: https://
Matt_King: It has four items
Matt_King: The first is related to keyboard markup. It's slipped twice, but I still intend to do it
Matt_King: The second is the coverage and quality report. We're waiting on some updates from John in response to howard-e
Matt_King: Third is adding a practices page for high contrast
Matt_King: Fourth is support for experimental example pages (issue number 2977)
Matt_King: I'm optimistic about at least two of these
Matt_King: issue number 3025 should also be added to this milestone. I'm going to do that, now
Matt_King: It is currently waiting on a review from Jem
siri: I can help reviewing, too
Matt_King: Thank you! I've added you as a reviewer, too
Matt_King: It looks like we're on a pretty solid path for at least three of these things
Matt_King: The other two depend on me
HTML source formatting on combobox example page
github: w3c/
Matt_King: arigilmore has submitted a patch for this, which is awesome: https://
arigilmore: I added a "trim" to remove surrounding white-space just in that example
Matt_King: If you press the "open this in CodePen" button and copy it from CodePen, would it work without this change?
Matt_King: I ask because it almost seems to me like we're adding code to support something we wouldn't normally support
arigilmore: The CodePen works
Matt_King: I'm questioning whether we want to do this at all. This bug could pop up on many example pages, and I don't know if we want to be responsible for supporting this use-case everywhere
Matt_King: The way the HTML is formatted for display on the example page, there is some whitespace around the list items
Matt_King: However, if you look at that exact HTML in CodePen, that whitespace isn't there. That's because that whitespace isn't present in the source
Matt_King: But our intention isn't that you would copy and paste that HTML in order to re-create the example
Matt_King: I think that if we were to try to copy-and-paste the HTML from the other pages, we would probably find many other places where white-space was causing issues
arigilmore: Do we even need the HTML source section?
Matt_King: A few people (including myself but others, as well) have reported that the "source" section is useful. One could review the source through CodePen, but doing so can be difficult for an AT user.
jongund: Have we opened any feature requests in CodePen to make it easier to navigate with an AT?
Matt_King: We have not
Matt_King: I just double-checked, and JAWS is still completely silent on the CodePen page
Matt_King: I can press Ctrl+A to select all the text, copy it, paste it into Nodepad, and then review it from there
Matt_King: It's a kind of workaround that I'm used to doing, but I'm not sure how many other screen reader users would think to do that
Matt_King: I suppose we can remove the HTML source, though. We might want to remove the CSS and JavaScript source, for similar reasons
dmontalvo: I appreciate having the source on the same page
CoryJoseph: CodePen is run by a small company. The accessibility issues were reported years ago, but as far as I know, they haven't committed to a timeline to address those
Matt_King: Even a simple change like adding a landmark region around the code would be a massive help...
CurtBellew: We could put a landmark region around our embedding of CodePen
Matt_King: That's a good idea!
Bryan_Garaventa: If we added the landmark for CodePen, then I'd be comfortable removing the source from the example pages
Matt_King: Doing that would eliminate some scripting (the build script that generates the view of the source code), it would make the pages lighter, it would remove a redundancy, and it would prevent the kind of confusion experienced by the reporter of the issue we're currently discussing
dmontalvo: I still believe there's utility in surfacing the source code on the page. Particularly for screen reader users who are not familiar with CodePen (who may not even realize that they could access the source code through CodePen)
dmontalvo: Is our audience for this limited to developers?
Matt_King: No, I don't think so
Matt_King: I wonder if we put the CodePen button in two places. Where it is, currently, and then also in the "source" section with some instructions like, "if you'd like to copy the source code, you can access it on CodePen"
<jugglinmike> s/in the "source" section"/under the "HTML source" heading/
Bryan_Garaventa: Personally, I find CodePen irritating, but to each his own
Matt_King: arigilmore you can experiment with this change on just the page we're discussing. That will give us something to review and decide if we want to do it generally
arigilmore: Sounds good!
New high contrast practice page
github: w3c/
jongund: In the table, under the "sample color" column, I added colors which are computed based on HTML standard color names
jongund: If it doesn't match a known color, it will tell you which color it is closest to
<siri> can you add link to system colors here?
jongund: This is all computed because the colors are different for each browser
<siri> https://
Matt_King: I think the "sample" column--it might be cool to label that "computed sample" or something like that, just to indicate that this is computed specifically for the current browser
jongund: It also detects grayscale. If all of the RGB values are the same, it will report "light gray", "gray", or "dark gray"
jongund: I also tried to work on testing for high-contrast support
jongund: Mostly what I have there is links to instructions for testing high-contrast settings
jongund: For the Chrome browser, I have a link for how to configure the DOM inspector (where you can add a "render" tab to one of the toolbars and use that to force certain colors)
jongund: I'm still working on this section, so it's not very well-organized, yet
Matt_King: It will be helpful to understand which ways of coding must be used in order to support high-contrast
jongund: I was thinking about using a button that's made from an image, a button that's made with a "<div>" whose "role" is "button", and then a button made from an SVG...
Matt_King: Anyone care to weigh in on what would be useful for them?
CurtBellew: I'd have to think about this a bit; I don't know off-hand
arigilmore: I need to take a closer look
Matt_King: We avoid anti-patterns, but in a case like this, maybe we could have a "do's and don't's" kind of section
jongund: When you're using current color, you can't necessarily set the background color. It's not like the "force colors" media query where you can set whatever you want
jongund: If you're not careful, and the background color changes to the current color, you could end up with black-on-black. Clearly, you won't see anything in that case
jongund: There are also considerations around images
Matt_King: Well those are two cautions right there. We could use different wording, like "recommendations" and "cautions" instead of "do's and don't's"
Matt_King: I'm super-excited about getting all this information together in once place. It feels like it could be extremely valuable
Matt_King: It would be great if the other folks in attendance could give jongund feedback about what's good and/or what's missing
Matt_King: If anyone knows someone who might have advice, you can share a link to the preview https://
And they can add comments to jongund's pull request
CurtBellew: I think high-contrast testing is under-served with accessibility testing. I agree that there's potentially a lot of value here
jongund: I'll try to work on this more today and tomorrow. I may not be present on the call next Tuesday; I'll be camping
Matt_King: Thank you for all the really awesome hard work on this, jongund