Meeting minutes
reflections on TPAC
Matt_King: APG was discussed in multiple contexts
Matt_King: The most substantial discussion was around the Tooltip pattern. It got 90 minutes of discussion in the ARIA WG!
<Jem> https://
Matt_King: I need to revisit the minutes to capture the essense of that discussion
<Jem> tooltip: w3c/
Matt_King: I think we made some decisions that enable some forward progress on the Tooltip pattern
jongund: Why did this pattern get consideration at TPAC?
Matt_King: Tooltips are all over the place, APG doesn't have an example, and we have an issue that's been open for 7 years
Matt_King: Separately, we talked about bringing new features into ARIA and making sure we have alignment with screen reader developers
<Jem> Tuesday meeting agenda: Relationship with ATs, and update on ARIA-AT results
Matt_King: I suggested that for the new features we're working on in 2024, we should include early prototype examples in the APG, and then give the ARIA-AT community group an opportunity to consider how they would write tests
Matt_King: That seems to be agreeable to the folks involved in the discussion, though some expressed concerned that it might be too early for that kind of design
<Jem> w3c/
<Jem> 1.4 prioritization
Matt_King: ARIA has four very clear priorities for the 2024 roadmap
<Jem> notification proposal: https://
Matt_King: 1. ARIA actions, 2. AT notifications, 3. changes to ARIA Model to support UI popover, and (my favorite) 4. list view
Matt_King: I'm already working on the ARIA pull requests for modal and list view
Matt_King: ARIA actions, as we know, has already made a lot of progress. The main thing is to get someone (hopefully Sarah) to write an example
Matt_King: The main implication for APG is that we need a way to write content that is LOUDLY labeled as "experimental". That content is included as a way for the community to iterate
Matt_King: I don't know if we can prioritize this by the end of this year, though
Matt_King: I felt really good about the progress we made on all of these things! APG also received some nice call outs; it seems as though the wider community is recognizing our work.
Status of Site Updates
Status of Site Updates
Matt_King: We landed three changes, including the longstanding patch from jongund "Listbox Examples: Update scrolling of listbox item with focus into view when page is magnified"
Matt_King: w3c/
Matt_King: Those patches are listed in the agenda for this meeting
PR 2780: Fix for iOS Safari combobox bug
github: w3c/
Matt_King: I put in a review checklist, and I'm pretty sure we only need people looking at the visual presentation and the code
Matt_King: There's not much code, but the code review is important because we want to make sure the approach is appropriate
Matt_King: The patch uses absolute numbers, and I wonder if that is the best way
jongund: I can do a code review
Matt_King: My second question is about the two examples which are NOT changed by this pull request. Could we have someone look and verify that this problem does not exist in iOS and Safari on those two?
Matt_King: The other two examples are "select only" and "date picker". They do not use the CSS which are modified by this patch (they have their own separate CSS)
jongund: I can look at those, too
Matt_King: Thanks! If those also need changes, I'd like those changes to be included in the scope of this patch
Matt_King: Because I don't actually understand what was wrong (or what "auto" does in that patch), I had trouble choosing a good title for this pull request
[Jem explains the problem]
Matt_King: Okay, thank you. I have the answer that I need for the third question. If jongund and jem submit reviews, then Andrea will have what she needs
PR 2775: Feed example changes
Matt_King: Because neither Andrea nor Ariella is here, I think we should skip this today
github: w3c/
Issue 2798: Question about how typeahead should work in treeviews
github: w3c/
Matt_King: The reporter believes that the description of tree view is not specific enough about scrolling in a specific situation
Matt_King: They offer a solution
Matt_King: As far as I can tell from native implementations of tree view, their suggestion would be more of a search than a typeahead.
<Jem> https://
Matt_King: Scrolling to things in tree view that are inside of a collapsed node seems more like a search behavior to me
Matt_King: in my mind, scrolling into collapsed content would not necessarily be great because the user may have content collapsed on purpose--as a mechanism to limit the number of potential destinations
Matt_King: Imagine trying to use "type ahead" with a huge tree view like the Windows Registry
jugglinmike: there's also the implementation concern of tree views whose "branches" are expensive to retrieve
jugglinmike: e.g. for a file system hierarchy which requires disk I/O
jugglinmike: In those situations, implementations may intentionally defer the population of collapsed items. They can't provide a general search across all the content of the tree view because they haven't retrieved (or otherwise computed) collapsed content
Issue 2800: HTML structure of listbox with grouped options
github: w3c/
Matt_King: Is this just another equally valid way of structuring content? Or is it better in some way? Are there any disadvantages?
jongund: The suggested approach may be semantically more accurate
Matt_King: I have some concerns about indexing, but now that I think about it, I don't know if we have a spec for this case
Matt_King: In Chrome, the way indexes are calculated, is that the entire list has 11 items.
Matt_King: But at one point in time, there were people arguing about how/when numbering restarts in groups and menus
Matt_King: Firefox is different! It says "cat" is "one of five", "reindeer" five of five, and then "dolphin" is one of three
Matt_King: We have a meaningful difference between Firefox and Chrome, and I think it shouldn't exist
Matt_King: I wonder what WebKit does, but I'm not going to try that just now
Matt_King: From my perspective, this is one list that just has some groupings within it
Matt_King: It's kind of funny because HTML doesn't actually have a semantic structure equivalent to "group" which fits within the "UL" element
Matt_King: The "select" element does, though
Matt_King: In a sense, Firefox is justified in its behavior because the HTML semantics describe three separate lists
Matt_King: That would still be the case even in this reporter's example because there are still separate lists (they're just nested)
jugglinmike: I always thought that role="presentation" applied recursively to all of an element's contents
Matt_King: It does, but authors can re-surface specific ancestor nodes by specifying an explicit role on them. This is what the proposed example does
Matt_King: My initial impression was that these were two equivalent way of coding it, that they're both valid, and authors can choose between either. I still feel that way
[all in attendence agreed that this is a matter of personal preference]
updating the version of skipTo
jongund: I found the template for the example. For the other pages (like the simple "about" pages) are there templates? Or are those more hard-coded
Matt_King: To update the version, you update it in aria-practices, and that will automatically apply everywhere
jongund: But I need to add an HTML "data-" attribute to the script tag
Matt_King: Oh! That would require two pull requests that would have to be merged simultaneously. I'm not sure how that would work
Matt_King: I recommend you open an issue in the WAI-ARIA-Practices repository that describes your requirements, and a pull request in the ARIA-Practices repository that implements what you need to do there
howard-e: I will keep a look out for the ARIA-Practices pull request and review it
Matt_King: That ARIA-Practices pull request should only modify content/shared/js