W3C

– DRAFT –
ARIA Authoring Practices Task Force

08 October 2024

Attendees

Present
Adam_Page, CurtBellew, Daniel, howard-e, jongund, jugglinmike, Matt_King
Regrets
-
Chair
-
Scribe
jugglinmike

Meeting minutes

Setup and Review Agenda

https://github.com/w3c/aria-practices/wiki/October-8%2C-2024-Agenda

Matt_King: Any requests for change to agenda?

Matt_King: Hearing none, we'll stick with the agenda as scheduled

Matt_King: Next meeting: October 15

Matt_King: Then we should be on a regular cadence until the American holiday of Thanksgiving

Publication planning

Daniel: No issues with the target date of October 29

Matt_King: Only one thing could end up being time-sensitive--the one about updating links to related issues

Matt_King: If GitHub stops doing redirects in November, we'll want to get this out to prevent those links from being broken

Matt_King: There are two things that are already done

Matt_King: Adam_Page's pull request is also on the agenda today. That's pretty lightweight, so it ought to make it in

Matt_King: Then there's jongund's patch for high-contrast. He had to leave this meeting early, so hopefully we can talk about it next week

OliverH: I would like to give an update on the code guide changes

Matt_King: Sure. That's going into the repository content which doesn't get published, so it can be handled on its own timeline

OliverH: w3c/aria-practices#3060

OliverH: There hasn't been much progress only because I've been sick. Rest assured that I'm working on it, now!

Daniel: Maybe we want to advance the publication of howard-e's pull request about the updated links. That way if the publication for the 29th slips, we aren't risking a state of broken links

Matt_King: Yeah. Or we could potentially move the whole milestone forward by a week

Matt_King: I think we could potentially publish that patch sooner to give ourselves some breathing room

Matt_King: That's next on the agenda, actually...

Where did our pattern-based GitHub projects go?

github: w3c/aria-practices#3113

Matt_King: I want to celebrate

Matt_King: When we figured out what was going on here, we had a whole bunch of projects (over 20) that GitHub had essentially deprecated (or "sunset")

Matt_King: They were essentially gone

Matt_King: Everything for combobox, tree grid, tabs, and so on

Matt_King: Every page has a link to "related issues" and that is a specific project which contains all the issues that are related to that example and similar examples

Matt_King: That was quite a shocker

Matt_King: Those projects were supposed to be manually migrated by us if we wanted to keep them. I missed that, despite a prominent banner from GitHub

Matt_King: howard-e opened an issue with GitHub support and worked with them very diligently. They migrated all of those projects for us

Matt_King: The projects continue to remain public

Matt_King: For some reason, projects in the W3C GitHub organization are not public by default (that might be something that the W3C can and should change, by the way Daniel)

Daniel: I can double check with our systems team

Matt_King: If its possible for us to make the default "public" on a repository-by-repository basis, it would be very helpful for the ARIA-APG and ARIA-AT repositories

Matt_King: Anyway, we got them all back, which is awesome!

<jongund> I am back

Matt_King: It's just that the links we have on the website are old links. Those links automatically redirect to the new projects for now, but the redirection will end in November

Matt_King: I will take on reviewing that patch

Matt_King: I plan to get it merged as quickly as we can; hopefully before next week's meeting

jongund: I can help review, too

Matt_King: Sure. The patch is at w3c/aria-practices#3123

Matt_King: If you find any problems, please comment there

Tooltip pattern revision to clarify mouse out behavior

github: w3c/aria-practices#3140

Adam_Page: An issue had been filed to point out that our language for the tooltip pattern (about when the content is automatically dismissed on mouseout or hover out) was vague

Adam_Page: It didn't account for a WCAG requirement

Adam_Page: I wrote a clarification on that topic

Adam_Page: preview here: https://deploy-preview-363--aria-practices.netlify.app/aria/apg/patterns/tooltip/#keyboardinteraction

Adam_Page: It's in the "keyboard" section

Adam_Page: I went ahead and split the details on "hover out" into its own list item and added the clarification there

Matt_King: That seems really clear to me

Matt_King: I'll paste the wording into the minutes...

<Matt_King> 3. If the tooltip is invoked when a pointing cursor moves over the trigger element, then it is dismissed when the cursor is neither over the trigger nor

<Matt_King> the tooltip.

Matt_King: It is clear. I can see how there's a lot of different potential options here

Matt_King: Is a tool tip ever not invoked by hover? I'm wondering about the "if" part at the beginning...

Matt_King: The previous item says "if it's invoked on focus" so it's always been there

Matt_King: Now, when I read it, I'm wondering... Is it sometimes the case that you must click to open the tool tip? I guess that still counts as a tool tip

Adam_Page: Yeah. At least at Hilton, we definitely use it. We call it a "toggle tip"

Matt_King: I think Sarah popularized that term

jongund: Is there anything screen readers do with the role "tooltip"?

Matt_King: Not with the actual role, though there's a lot of discussion about that in the related issue.

Matt_King: That's a completely separate discussion from this mouse pull request, though

Matt_King: Okay, so I understand the "if" part

Matt_King: Sometimes when I see "neither [...] nor" I wonder if we can change it to an "either [...] or"

Matt_King: We're talking about when it's dismissed, so I guess it wouldn't make sense to say that it remains visible until until the mouse [...]

jongund: Maybe "remains open as long as the pointer is over the trigger or the tooltip"

Adam_Page: That sounds good. I used the "dismiss" language because I was trying to maintain parity with an earlier item. But jongund's suggestion sounds clearer to me, too

Adam_Page: I'll make that revision and push it up to the pull request

Matt_King: Cool. Thanks for this!

Live regions practice

Matt_King: We have had a pull request open for multiple years, originally drafted by Simon Pieters

Matt_King: I refactored it earlier this year

Matt_King: And jongund recently fixed a bunch of linting errors there

Matt_King: Thank you for that, jongund

Matt_King: We need someone to work on the editorial work of finishing up what this section should say, what it shouldn't say, and any potential revisions

Matt_King: I'm looking for a champion to take this on and get more "live region" information out to the world

ARIA 1.3

Matt_King: Along the same lines, we have a set of issues open related to ARIA 1.3

Matt_King: ARIA 1.3 wasn't even on the TPAC agenda at all

Matt_King: I don't know the status of ARIA 1.3 or the timeline

Daniel: It's still in first public working draft

Daniel: There is an issue which needs some attention before we can move forward

Daniel: Even though some people may consider the spec to be done, there's still quite a bunch of W3C Process work that needs to happen

jongund: There was once some discussion about deprecating some live region markup and just focusing on some roles. Has there been any discussion about that?

Matt_King: No action in that space. I proposed deprecating some of the roles, and Aaron proposed deprecating "aria relevant"

Matt_King: Some of the role deprecation proposals have definitely be rejected. They might have been one deprecation that people were willing to reconsider (I can't remember which)

Matt_King: But no one is working on making changes to that

jongund: I'm still working on the high contrast stuff, but if it's still active when I'm done, then I'd be willing to help

jongund: Otherwise, I've been working on skipTo stuff, and I think that's winding down

Potential WCAG failure in multi-thumb slider

github: w3c/aria-practices#3118

Matt_King: The multi-thumb slider example, according to the reporter, doesn't meet the requirements of 2.5.7, "Dragging movements"

Matt_King: I haven't done any work to understand whether or not this is an accurate assessment, but I'd like to do that here in this meeting

jongund: I built this slider

Adam_Page: I see what the reporter is describing

Adam_Page: The new dragging behavior requires that any control which supports a "dragging" operation also supports a "single click" interaction to perform the same function

Adam_Page: Here, I can drag, but I cannot click on the empty track where I want it to move

OliverH: but there are two sliders--isn't the intention ambiguous in that case?

Adam_Page: I believe it's the nearest slider that's suppose to move

Adam_Page: I'm playing around with Adobe's "double thumb" slider in their React library. For what it's worth, they seem to always choose the nearest thumb (whether you're on the interior of the two or outside of them)

Adam_Page: I'm not arguing that's the solution, but it is a solution

Matt_King: You have to do something, and I suppose that's the most obvious

jongund: The Adobe React example doesn't surprise me

Adam_Page: Yeah, it's definitely anecdotal, but it instinctively felt right

jongund: I think I could fix this pretty quick

jongund: I'd also like to update it to use some of our high-contrast support

Matt_King: jongund has a lot of his plate right now; is there anyone else that can help out?

Matt_King: Hearing no other volunteers, we'll take you up on your offer, jongund

jongund: I'd also like to change the graphic from using triangles to using circles. Would there be any objection to my doing that as well?

Adam_Page: Circles feel more conventional to me...

OliverH: I have seen triangles in the wild, for what its worth

Adam_Page: For the double-thumb example in particular, I think the triangles reinforce the concept of "min" and "max"

Matt_King: Okay, then triangles it is!

Data grid keyboard interaction design

github: w3c/aria-practices#3117

Matt_King: We received pretty straight-forward feedback

Matt_King: If you have a lot of rows, and you have sortable columns in the column headers where you can access "sort" functions

Matt_King: If you've navigated far down the grid, and you want to change something in the column...

Matt_King: ...though I'm not sure what you'd want to change anything besides "sort"

Matt_King: ...and if you changed "sort", then the row you were on will be in a different place

Matt_King: So I'm not sure if this is actually a problem, after all

CurtBellew: When you get into a huge grid, I'm not sure there's a good way to do this (beyond a new motion that could allow you to jump to a particular row)

Matt_King: Yeah, and that wouldn't be part of the pattern itself

Matt_King: Like, Microsoft Excel has such a command

Matt_King: That feels like an add-on feature for the application that you're building, and that it would probably be unique to that application (just like the similar functions are unique to Microsoft Excel and Google Sheets, and Visual Studio Code)

OliverH: for what it's worth, I don't think NVDA has a command like that for navigation on tables on the web

CurtBellew: And for this scenario, it wouldn't be so helpful because the row number would be different

Matt_King: One suggestion (for the headers being a separate tab index) feels inconsistent with a composite pattern

Matt_King: I have seen where people put their headers in a separate element (either Schwab or Fidelity). It's really a problem!

CurtBellew: We did that at Oracle for some time, and it caused headaches

CurtBellew: Maybe the question is why home, control, end, "page up" and "page down" don't address this issue

Matt_King: If I sorted by "Name" and then read through a bit, and then resorted by "Date", I wouldn't have any expectation that I would be able to return to the same row

CurtBellew: One of the big issues we have (and which isn't necessarily related to the issue report itself) is discovering the availability of those keystrokes

Daniel: Maybe out of scope for this particular pattern: we have type-ahead now. It could be implemented there. If you're dealing with a great number of rows, then chances are that if you're sorting, you want to focus on a subset of the data. Sorting could be one way to do it, but then again, filtering could be another

Daniel: As I said, it's out-of-scope, but I do think it would improve the user experience for screen reader users and for other keyboard users

Matt_King: I think if we ever showed something like that in APG, it would be in the advance data grid, which we haven't gotten anybody to build, yet

Matt_King: It would probably be like Sheets or Excel. I suppose it could be done with the new "ARIA Actions" to open a menu to allow you to input a filter string

Matt_King: But it does feel like it would have to be the developer's responsibility to design and implement the UI in a way that's appropriate for their specific application

Daniel: Yeah, I like the developer being in charge of communicating this to their users

Matt_King: So, to summarize, it doesn't sound like we want to make a change to make a change to change the number of tab stops in the grid or to make the column headers separate from the grid body or anything like that.

CurtBellew: I'm not completely ambivalent. I lean toward them not being separate tab stops, but I can't make a concrete case

Matt_King: I can build a case for that based on the spec

Matt_King: As a screen reader user, it would be hard to understand if tabbing didn't take you in or out of the grid directly. That would be really surprising

Minutes manually created (not a transcript), formatted by scribe.perl version 237 (Fri Oct 4 02:31:45 2024 UTC).

Diagnostics

Succeeded: s/some process work/quite a bunch of W3C Process work/

Succeeded: s/"max/"max"/

Succeeded 6 times: s/Oliver_Habersetzer/OliverH/g

Maybe present: OliverH

All speakers: Adam_Page, CurtBellew, Daniel, jongund, Matt_King, OliverH

Active on IRC: Adam_Page, CurtBellew, Daniel, howard-e, jongund, jugglinmike, Matt_King