Meeting minutes
Setup and Review Agenda
https://
Matt_King: I'm canceling the meeting for next Tuesday (the day after Memorial Day in the US)
Matt_King: Next meeting: June 3
Matt_King: Any requests for change to agenda?
Matt_King: Hearing none, we'll stick with the agenda as scheduled
Publication planning
Matt_King: Even though we're not meeting next week, I'm hoping we can still go forward with the publication
Matt_King: Right now, there is only one thing showing as totally ready for publication
Matt_King: I'm hoping we can bump that up to two by the end of the meeting and then up to three by the end of this week
Matt_King: I know I won't be working as much this week because I will be off traveling
Matt_King: I think Daniel said that Thursday of next week will be okay for the W3C
howard-e: That works for me
Matt_King: I don't think we should bother if we don't get more things landed, but it seems unlikely that we won't
PR 3249 - Add HTML search to landmark practice
github: w3c/
Matt_King: jongund pushed a whole bunch of commits to resolve a lint error
Matt_King: The changes to the VNU file look correct to me, but they don't appear to be having any effect
jongund: I don't understand, either
howard-e: I replied to the thread. jongund did everything right. There is a message toward the end, though, that says "suppressing further errors from this subtree". That implies that there are additional errors which are not reflected. I'm suggesting that you add a "wildcard" pattern to address those
howard-e: I reviewed the linter's documentation, but I can't find a way to surface those suppressed errors
Matt_King: It's important to get it to work because as soon as we merge, we don't want the main branch or the other pull requests to begin reporting this error
jongund: I'll give it a try!
PR 3258 - Fix slider to remove redundant announcement of value by screen readers
github: w3c/
Matt_King: For the link checker fix, it looked like it was reviewed and approved, but I didn't merge it.
howard-e: I merged it this morning
Matt_King: It sounded like maybe that solution is a little brittle
howard-e: Yes
Matt_King: I still don't understand why the user-agent matters
howard-e: Some websites reject traffic from browsers that present themselves as a certain version--often due to compatibility concerns
Matt_King: If we re-run these tests, should it pass, now?
howard-e: Yes, it should
Matt_King: I tested this with two screen readers
howard-e: We need to merge from the "main" branch, first
Matt_King: Oh, yes! I will do that
PR 3251 - New expandable region pattern
github: w3c/
Matt_King: This is Adam_Page's awesome pull request
Matt_King: Before Adam_Page left, we were discussing where to place this example
Adam_Page: Yes. As I recall, we decided to move it into the existing "disclosure" pattern
Adam_Page: I made that change. It is now a "disclosure" example. I updated the "patterns" page to link to it
Matt_King: Do we have an open issue related to our pinning of the version of the linter?
Matt_King: We had something pinned, if I recall correctly
howard-e: We do not have an issue, but I created a pull request two weeks ago
Matt_King: So you have a pull request to un-pin it. I wonder if we should land that before Adam_Page makes any more changes to the linting specific to his pull request
howard-e: It's pull request 3262 w3c/
Matt_King: That says "all checks have passed" right now on this one
Matt_King: With this new validator--are the old exceptions still needed?
howard-e: I didn't confirm, but I can do so pretty quickly
Matt_King: You can decide and go ahead and merge this as appropriate
Matt_King: And then after this one is merged, Adam_Page, let's see if your errors still pop up
Adam_Page: Sounds great!
howard-e: thank you!
Adam_Page: I'll stay tuned
Adam_Page: I'll also check in on NVDA
Matt_King: Maybe we should finish the documentation before we seek additional feedback
Adam_Page: For what it's worth, before I pushed up my initial Pull request months ago, I chatted with Scott, and he endorsed my work
Matt_King: So you called it "disclosure card"?
Adam_Page: Yeah, I did, but it's not a strong opinion
Matt_King: Do you think that we should give it an alternative name in parenthesis, as we do in other places? E.g.. "(expandable region)"
Adam_Page: Maybe, "Disclosure (show card)" ?
<Adam_Page> Disclosure (Show/Hide) Card
Matt_King: I'm looking at the list of disclosure examples on the patterns page
Matt_King: In these, the HTML element that is the region--what is the element? Is it a "div" with the "role" region?
Adam_Page: The HTML element I'm using is "section" and I give it an accname with aria-labeledby
Adam_Page: That wasn't a strong opinion, either. I just did that because this was an expandable region from the get-go
Adam_Page: I may have complicated this because I chose to make multiple cards and to place them in a semantic ordered list
Adam_Page: That seems like a valid use-case, but it may be a distraction for this example
Matt_King: I guess that if we thought it was really important to show it as a collection of cards, then maybe. But maybe it would be better as an individual
Adam_Page: Yeah. And cards are often presented as a collection. That's why they're cards. From that perspective, it does feel appropriate to present them as a collection. And if it is a collection, it seems appropriate to present it as a semantic list
Matt_King: We have two levels of lists here
Adam_Page: That's because the fiction of the example is a conference with talks spanning multiple days
Adam_Page: The content is silly--it's tongue-in-cheek that I added hastily. I will swap in more straightforward content
Matt_King: From the perspective of testing in the ARIA-AT context, it would be good to bring it down to a single list. That would simplify the semantics
Adam_Page: And I don't think it would limit the example's utility in the APG. I can make that simplification
Matt_King: This is unlike accordion where you normally have one region exposed. If someone took this and ran with it, they could end up with many regions exposed.
Matt_King: I think "article" would be a better use. Articles are great for regions--they don't clutter the navigation
Issue 3269 - Request to change FAQ disclosure list semantics
github: w3c/
Matt_King: In the "disclosure" FAQ, the current markup includes a definition list with a dt for each question and a dd for each answer
Matt_King: This has a bunch of side-effects that we discussed in the ARIA-AT Community Group
Matt_King: The first is that we didn't know what to do with the semantics of the description list
Matt_King: No screen readers handle these semantics really, at all
Matt_King: So the description list semantics are kind of complicated from a screen reader's point of view
Matt_King: That's what caused us to ask if these are the best semantics to recommend for an FAQ
Matt_King: The first thing that screen readers get wrong is making it clear how many items are in the definition list. The second thing they get wrong is making the list navigable
Matt_King: We didn't see any value in having these in a dd and dt versus just a button and a paragraph
Matt_King: So that's a summary of the discussion that took place in the ARIA-AT community group
Matt_King: So this is a request that we change the semantics of the example
jongund: I can do that if you want
Matt_King: Awesome!
Matt_King: Does anyone here have any thoughts on this semantic change? Are there any objections?
Siri: Why can't we go with what we have?
Matt_King: We're changing the semantics to NOT use the description list
Siri: Ah, I see
jongund: It sounds like we should be telling people to avoid using description lists. If there's problems with using them in general...
Matt_King: Well, personally, I find them problematic
Matt_King: The whole group in ARIA-AT finds them problematic
Matt_King: Those problems probably should be solved
Matt_King: But literally no one in the group could think of what they would like the solution to be
Matt_King: Other than general agreement that the definition list should work more like a table than a list. With a dl column and a dt column
Matt_King: From a screen reader user's point of view, there's this idea that tables are way better than description lists, and that tables ought to be preferred
Matt_King: I don't know where and how to get that across
jongund: For the immediate future, it sounds like definition lists should be avoided. Especially because they've been around for 25 years
Siri: My thought's exactly
Matt_King: The real deal is that they aren't used very much, so no one really cares very much
Adam_Page: It breaks my heart to know that it has never had a great accessibility user experience because the semantics are so strong
Matt_King: I think it could be made to work if screen readers were convinced to care
Matt_King: We've pushed that way out on the ARIA-AT timeline. We have more important semantics to get to, first
Matt_King: Anyway, I'll assign this to jongund
Siri: When we change it, can we include a note about our motivation so that people know?
Matt_King: We can definitely include an explanation in the change log. I'm cautious about including such text in the APG itself. I wouldn't want to upset the Adam_Page's of the world by saying something not positive about DL
Pull request 3213 - Update skipTo
github: w3c/
Matt_King: I added some comments to the pull request
Matt_King: Before we dive in: in general, jongund made changes to the menu that is included at the top of each page
Matt_King: This skipTo includes both landmark regions and headings, but only headings in the main content. I didn't realize that until yesterday. I'm wondering where that decision came from--that we would exclude headings from any other part of the page
jongund: That is configurable in skipTo. We can reconfigure it to show all headings
jongund: There's now browser extension versions of skipTo where users have access to a lot of configuration
Matt_King: That configuration appears on every single page--we don't have it centrally.
jongund: I could change the default to be all headings