Meeting minutes
<Jem> https://
Setup and Review Agenda
Jem: No meeting July 9
Jem: Next meeting: July 16
Jem: Any requests for change to agenda?
<Jem> https://
Jem: Hearing none, we'll move on as scheduled
Publication planning
Matt_King: Ari's pull request is missing from the milestone; we'll add it when we get there
<Jem> https://
Matt_King: first, PR 3024 - Coverage and Quality Report: Add reporting on use of forced-colors media query and currentcolor value by jongund
Matt_King: That's pending some action by me and then I can merge it
Matt_King: next, PR 3025 - Ratings Slider: Use buttontext instead of linktext system color in high contrast mode by jongund
Matt_King: We've requested review from Siri, but I don't think that's truly necessary, so I'll merge it
Matt_King: next, PR 2991 - Add Practice Page for Supporting High Contrast
Matt_King: This patch is a sort of public service announcement. We need people to read this new section and provide feedback
Matt_King: We'll discuss this more on the 16th when Jon has returned
Matt_King: In the mean time, if you have feedback, it would be helpful if you added it to the pull request
Matt_King: and finally, there's Feature: Search for patterns, toggle grid/list view by stalgiag · Pull Request #3043 · w3c/aria-practices
Jem: I've added myself as a reviewer for pull request #2991
Matt_King: Thanks! I'm sure we'll have to go through a few rounds of review with that one. It's a big change
Change to HTML source section on example pages
github: w3c/
Matt_King: I would love to merge this very soon because it changes 59 pages, and I want to avoid conflicts with other pull requests
Matt_King: I think we need some people to look at some of these pages and just look for possible anomalies
Matt_King: Basically, right now, I think we need two reviewers in addition to myself
Matt_King: It's the same change on every page, but as we know, there are some variations in the example pages, e.g. the list box page and the button page
Matt_King: But we also want to pay attention to the more normal pages which only have one example per page
Matt_King: We also want to be sure that it works when you zoom in, and that it all looks acceptable on mobile
CurtBellew: I can help out
Jem: Me, too
Matt_King: Okay, could we maybe split the pages alphabetically? Jem, you could look at pages belonging the first half of the alphabet, and CurtBellew, you would look at pages in the second half...?
Matt_King: To be clear, you wouldn't have to look at every single page assigned to you; just use that constraint to inform your sampling
Jem: I can take a look by the end of this week
CurtBellew: Same for me
Matt_King: Okay. I'm going to look at the coverage to make sure we didn't skip any examples
Matt_King: Don't worry about the "Feed" example--we don't have an "Open in CodePen" button there due to a technical shortcoming
Matt_King: This was a cool change. It was a tiny issue that someone raised, and I'm happy we made this decision
Three or more levels in disclosure nav menus
github: w3c/
Matt_King: Last week, we recognized that there's a difference in content between the "navigation menu bar" and the "disclosure menu bar"
Matt_King: The former has three levels, but the latter does not
Jem: So the idea was that we should provide a consistent example, like a two-level menu for both patterns
Matt_King: Well, the reporter is just asking how it would be done
CurtBellew: Doesn't it have more than two levels?
Matt_King: If you compare the two... I don't see "history" in the "disclosure menu bar"
Matt_King: There is not a page called "Facts" in one, but there is such a page in the other
Matt_King: In the disclosure menu bar, I assume that the way it would work is that you would replace the links with a button that expands and shows the ones below it
Matt_King: The thing that would be strange from a screen reader user's point of view, at least with a disclosure, they would not expect "campus tours" (for example) to disappear
Matt_King: Visually, do you still see the parent when you expand the child?
CurtBellew: Yes, it sits next to it
Matt_King: Okay, I think we could do the same. That seems like a good thing to demonstrate in this example
Matt_King: I don't know why it was originally built any other way. Maybe we should ask Sarah, the original author
Matt_King: I think the answer here is to replace the "Facts" link with another disclosure and it would behave he same way as the flyout in the "navigation menu bar" does
Jem: If we build another layer of menu, there's going to be another nested UL and LI element with an A link
Matt_King: Correct
Jem: Seems to be simple
Matt_King: It's too bad that we're working on the test plan in ARIA-AT right now. If we update this, we'll have to re-do all the ARIA-AT work.
Matt_King: It'd be really interesting to see if we could do this in the other "navigation disclosure" menu, instead
Matt_King: Because we have two of them--one that has top-level links, and one that does not have top-level links
Matt_King: If we instead update the other one--the one with top-level links--then it would avoid disrupting the ARIA-AT work. That also seems better for APG, since the one with top-level links is the more complicated one
Matt_King: This would allow us to preserve the simplicity of the one without top-level links
Jem: This would be a good warm-up for Adam, the new contributor who will be joining us soon
Matt_King: I'm going to add a link to the new example page that we want to modify
Should the current location on a breadcrumb trail be an anchor element?
github: w3c/
Matt_King: I remember discussing this concern when we made this example
Matt_King: There have been a variety of opinions, and I don't know if there is a right or wrong answer
Matt_King: It kind of feels as though the answer may be more of a design decision that is based on the structure of the current site
Matt_King: I've seen some that don't include the current page at all
Matt_King: WCAG has a document that may be relevant, "G65: Providing a breadcrumb trail"
<Jem> https://
Jem: 2.4.8 seems relevant
Jem: My vote is to not add the anchor tag. What do other folks?
CurtBellew: I'd like to put aria-current on it
Matt_King: I like that, too, though aria-current works better on a link. aria-current on a word doesn't have any meaning to it
Matt_King: The second example on WCAG includes the current page as a link, but it doesn't say *not* to do that
Mark_McCarthy: there isn't anything that says *not* to use links. It seems like a design decision that authors are expected to make
Matt_King: So perhaps APG doesn't need to make a recommendation about this
howard-e: For what it's worth, at the bottom of the WCAG page, there's a note that reads "failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance."
Matt_King: That's an interesting wording
Matt_King: That statement applies to the entire list which precedes it
Matt_King: Does the Task Force actually agree that WCAG should be so prescriptive about bread crumbs? Maybe we should raise an issue here...
Matt_King: The first words are a little weird: "If this is a sufficient technique for a success criterion"
Matt_King: I don't know what that condition means
Matt_King: Apparently, they must include insufficient techniques
Matt_King: It's essentially saying, "if you fail these checks, this technique has not been successfully implemented"
Matt_King: "...and cannot be used to claim conformance"
Matt_King: That would mean that if someone built breadcrumbs like the APG's, their implementation would be invalid
Matt_King: I do think that statement on the WCAG is authoritative
<Jem> https://
Matt_King: With that understanding, do we think that the APG bread crumb that this Task Force has previously reviewed and approved--do we think that decision needs to be revisited based on this reading of WCAG?
Jem: They have versions of this technique in 2.0 and 2.2
Matt_King: For my part, I don't think we should revisit the validity of the APG bread crumb example. If people implement bread crumbs the way they are implemented in APG, they should be considered valid by WCAG
Jem: I'm fine with that
Mark_McCarthy: I agree that we don't need to re-assess. I think the current implementation is fine
CurtBellew: I concur. In fact, I prefer the APG implementation
Matt_King: Okay, then I may use this Task Force's agreement in an issue raised with WCAG
<Jem> https://
<Jem> https://