Meeting minutes
<Jem> https://
Setup and Review Agenda
<jongund> Coming, having some issues wuth zoom starting
Jem: No meeting on December 26 or January 2 due to winter holidays
Status of Site Updates
Matt_King: We had a publication at the end of October
Matt_King: I think at this point, it makes sense to try to squeeze as much as we can in before the end of the year
Matt_King: I don't know how late Shawn at the W3C can go, but I think the latest Bocoup should plan for is a pull request on December 18th for publication on December 19
howard-e: That should work for us
dmontalvo: I think that should work on W3C's side, too
Matt_King: That means we need to have everything wrapped up by Friday, December 15. We'll work toward that, then
Matt_King: It will be our cut-off for the pull requests
Jem: It looks like that's almost twenty days
Issue 2842 - Bug in modal dialog example when accessed on mobile
Jem: jongund reviewed; we need one additional reviewer
Matt_King: This is a CSS change. I don't feel comfortable reviewing it myself
The patch is gh-2843
github: w3c/
Andrea_Cardona: I can take a look at this. I should be able to do that by the end of the day
Matt_King: Sweet!
Jem: I'll assign you on the pull request
PR 2839 - set aria-expanded false when menus are closed
github: w3c/
Matt_King: I did a bunch of work on this last night. I found two areas of concern
Matt_King: First, the documentation is changed for toolbar, but not the actual script
Andrea_Cardona: I'll take a look at the example you shared
Matt_King: Second is the tests
Matt_King: The test message is exactly wrong. It's saying that it's testing to make sure the value is "false"
Matt_King: The tests need to be updated, but don't forget to update the test message as well
Jem: We're missing a bunch of keyboard tests
Matt_King: We should address that in a separate pull request. In this pull request, we should focus on the change for aria-expanded
Issue 2501 - Rating slider redesign
patch available here: PR 2831: Rating Slider Example: Redesign as an input for 10-value satisfaction scale by jongund
github: w3c/
jongund: I'm using a media query, now
jongund: To support high-contrast
jongund: I think we should update the other examples to use that, as well.
Matt_King: Not on this pull request, please!
jongund: Agreed. We should do that as a follow-up
jamesn: I can review this one. I've done a lot of work with high-contrast using named colors
Matt_King: Does Spectrum have a guide for this that we can roll into our code guide?
jamesn: The designers have done a lot of designs for the high-contrast UI, but it mostly just exists publicly in code
jamesn: There are some implementation-specific details, so I don't know if you can roll it in directly. But I can definitely take a look
<Jem> Test in Windows High Contrast Mode (HCM):
<Jem> Turn on HCM in Windows Settings - Ease of Access - High Contrast.
<Jem> Open the example in Edge and Firefox (note that Firefox must be started after HCM is on).
<Jem> Test in both High Contast Black and High Contrast White themes.
<Jem> Make sure everything is visible and has suitable contrast in both themes. Pay particular attention to Non-text contrast, i.e. check that UI components and their states (e.g. focus/hover), as well as any graphical objects, have enough contrast with any adjacent colors.
<Jem> You can use Color Contrast Analyzer to test contrast.
<Jem> Update on "Styling for Windows high contrast with new standards for forced colors" on September 2021 by Microsoft Edge Team
jamesn: It would be good to have one overriding issue for high-contrast review, and then to address it in a series of patches as needed
[jamesn shows the group how to simulate high-contrast mode in Chrome using the browser's built-in developer tools]
Jem: I can document that: "How to use Google Developer Tools to check high-contrast mode"
jamesn: You can probably find a link for that and include the link in the documentation
Matt_King: But will this only work if the web page is using the media query?
jamesn: No, it also simulates the native high-contrast mode
Matt_King: I think we're in the clear here regarding the responsive design stuff. I think all the issues are resolved
jongund: I think so. I've made a few changes based on using the CSS media query, so it would probably be worth having someone check it out.
jongund: jamesn will do that when he reviews, so that's one reviewer
Jem: Is there room to use flexbox to handle responsiveness?
Jem: for some viewport sizes, we have a lot of empty space running along the right edge of the page
jongund: That's a problem with the template
howard-e: I wasn't aware of that problem
Matt_King: We should report that issue with the template
Matt_King: It sounds like there is also a non-visible click target which stretches beyond the length of the slider
jongund: That sounds plausible. Is the reporter saying that this is a deficiency in the user experience?
<Jem> w3c/
<Jem> Mike Gower's comment
Matt_King: They are reporting that it is "not elegant"
Matt_King: Should we take this feedback into account in this pull request?
jongund: Instead of changing the visual design or visual affordances, I could just remove the click area
Feed Example Revisions
<Jem> w3c/
github: w3c/
Matt_King: previously, we had problems with the preview related to iframes. That seems to be resolved, though I don't know how it got resolved
howard-e: The pull request that was generated in the build repo wasn't referencing the fix. Essentially, it needed to be rebased
howard-e: this won't be a problem for future pull requests that use an iframe because those future pull requests will naturally be based on top of the fix (that is, the fix which was originally missing from this one)
Matt_King: I see some functional problems with this. I can write the details in a comment
Matt_King: I think we might want to change the example so that if someone is tabbing, they have a way to jump out of the feed. I have an idea for this; I can write that as a comment on the pull request, as well.
Matt_King: JAWS is doing something interesting now (somehow trapping the focus inside the feed), which NVDA is not.
Matt_King: I'm already signed up for editorial review. We need someone to do functional review and visual design review
Matt_King: Also test and code
Jem: I can do visual review
Jem: I can do accessibility review, as well (I think this includes visual contrast)
howard-e: I can perform test review and code review
CurtBellew: I can do functional review
Jem: Thank you!
Issue 2626 - Guidance on focusability of col and row headers in grids
github: w3c/
Matt_King: Our current guidance is that if you make a grid with row and column headers, and those headers don't have any function (e.g. sort), then because they will be read by the AT, they don't need to be focusable
Matt_King: The reporter suggests that the column headers should always be navigable even if they don't offer any particular functionality
Matt_King: They seem to say that when the headers are not navigable, that prevents screen readers from finding the information. That isn't accurate
Jem: What is the advantage of allowing focus to the column header?
Matt_King: The downside of allowing focus is that it introduces another step in navigation to reach the data
Matt_King: If you want to spell out the column header, you can just go into reading mode
Matt_King: If you can't do anything with the column header, I don't see the value in allowing focus to visit there
CurtBellew: Our libraries always have focusable headers, but they mostly have associated functionality.
Jem: There may be a misunderstanding about screen readers requiring focusability to discover or announce the column headers
Matt_King: Our current guidance says that you can make column headers focusable if you want to, but you don't need to make them focusable if they don't have any associated functionality
Matt_King: We don't have a sortable example, and we really should
Jem: We do have that, actually. It's described by a note for the datagrid example