W3C

– DRAFT –
ARIA Authoring Practices Task Force

15 October 2024

Attendees

Present
Adam_Page, arigilmore, dmontalvo, howard-e, Jem, Jon, jugglinmike, lola, Matt_King
Regrets
-
Chair
-
Scribe
jugglinmike1, jugglinmike

Meeting minutes

Setup and Review Agenda

<jugglinmike> Matt_King: Any requests for change to agenda?

<jugglinmike> Matt_King: hearing none, we'll stick with what's planned

<jugglinmike> Matt_King: Next meeting: October 22

<jugglinmike> Matt_King: I may be out of office on November 5 because it's election day in the US, but we can talk about that as it approaches

Publication planning

<jugglinmike> Matt_King: We talked about possibly pulling this forward sooner than the 29th

<jugglinmike> Matt_King: I'm not sure we'll be ready, though

Matt_King: I gave input from howard-e on his open pull request

howard-e: I incorporated that feedback, and it's ready for another look

Matt_King: Wow! That was fast!

Matt_King: That should be ready this week, then

<Jem> presenet+

howard-e: The redirects should continue working through the 29th. If they stop working, I think it will occur in the middle of November

Jem: Did GitHub fix the problem, or was it automatically fixed?

Matt_King: GitHub fixed it, but they are redirecting. We're making it so we don't rely on the redirects

howard-e: We interacted directly with GitHub support--the handle of the person was "dash"

Feedback sent to mailing list

Matt_King: We have received feedback on the public mailing list in the last month or so.

Matt_King: Although we encourage people to share feedback on that channel, we don't have a process for handling such e-mail. Let's fix this.

Jem: Why don't I volunteer for now to transfer those e-mails to GitHub issues?

Matt_King: And can you copy the replies back to the mail list threads?

Jem: Yes

Matt_King: And can you go back into the history over the past few months?

ask dmontalvo

dmontalvo: We should also immediately reply to the people when we open the issue so they know we are discussing there

Matt_King: So at least two e-mails to the reporter--one when we open the issue and another when we close it

Jem: Sounds good!

Lola: I was going to say the same thing

Lola: Where do people learn about that e-mail list?

Matt_King: It's on the bottom of every WAI page. It's a different address for different pages. Every APG page references our list

Lola: Is there some way to make things clearer for folks? Moving discussions between mailing lists and GitHub issues is fine, but maybe we can communicate GitHub to folks

Matt_King: The footer also includes a link to opening issues, and we express our preference for GitHub on the home page

Lola: Great!

Lola: Also, I'm available to help triage e-mails

Jem: I think we should automate it in the future

howard-e: Should the issue triage also be updated?

howard-e: It may be helpful if there's a section in the issue triage wiki describing what will happen

Matt_King: That wiki is for us (so most people who raise issues likely will not see it), but you're right that we should update it

Matt_King: I can take that as an action item because I was the one working on the wiki

Skipto Update

github: w3c/aria-practices#3141

Matt_King: Jon made some changes to skipto and submitted them as a pull request

Jon: I've been testing here at the University of Illinois. The feedback I received means that none of the changes will be perceptible to end users

Jon: I added a new "scrollTo" feature which is off by default. I could enable that feature if you would like, but consensus here at the University of Illinois was to disable it

Jon: besides that, there are changes under-the-hood related to web components

Matt_King: The motion is in direct response to pressing a key, so don't we always expect some kind of change in that case?

Matt_King: I always thought the motion thing was... Well, maybe the problem is the smooth-scrolling specifically

Jon: I can enable the "instant scroll" variant of the feature and people can take a look at that

Jon: I can also open a separate pull request with the "smooth scroll" variant of the feature. With two pull requests, people would be better-equipped to compare

Matt_King: I think we should evaluate it within this group. There's even the possibility that you could add something to feature--somehow making it easy for people to update their setting directly

Jon: Let's let people try the two kinds of scrolling and test to make sure that it gets disabled when people turn off the feature on their OS

Matt_King: Sounds good

Lola: Is there a place for the user to control scrolling in the place where the scrolling is?

Jon: there is not right now

Lola: I think there would need to be if it were on by default. I believe WCAG requires that users have the ability to adjust animation whenever it is used

Jon: scrolling only occurs when people use skipTo

Matt_King: I don't know if this counts as animation. This is exactly the same kind of scrolling that you get with tabs

Jon: think the next step is for people to try it

Jon: I'll make that second pull request

howard-e: It sounds to me like the scroll is controlled in the script itself. Or is it in an HTML attribute?

Jon: It can be controlled through a data- attribute, yes

Jon: there are three states: none, smooth, and instant

High Contrast guidance update

jon: I'm still working on updates

Jon: I hope to have something ready for next week

github: w3c/aria-practices#2991

Bug: First element in listbox should receive focus

github: w3c/aria-practices#3138

Matt_King: There's a discrepancy between the implementation and the guidance for the scrollable listbox example

Matt_King: The pattern says the first item should receive focus. I think that's probably correct guidance

Matt_King: The problem here is that there isn't an item in the list that says "choose your favorite element" or "choose value" or something like that

Matt_King: If we focus the first item, it would amount to choosing the first item for the user by default

Matt_King: This kind of has more to do with the design of the example. If you focus the first one by default, that means there's a default favorite

Matt_King: So I'm wondering if a better fix is to add an option to the beginning of the list--one labeled something like "Choose an element". That coul get selected by default.

howard-e: For me, it does feel right to support what the bug reporter said. A placeholder or "option zero" could be good here. Provided it was styled appropriately

howard-e: That is--a "disabled look"

arigilmore: The dropdown implementation in my company's UI framework may be relevant...

Adam_Page: In the original bug, the reporter quoted the keyboard interaction instructions, but only partially

<Matt_King_> Preview of proposed fix: https://deploy-preview-362--aria-practices.netlify.app/aria/apg/patterns/listbox/examples/listbox-scrollable/

Adam_Page: They did not include the final statement in the text they referenced. That statement reads, "Optionally, the first option may be automatically selected."

Adam_Page: We could update this so that we don't automatically select it, we just require the press of the "space" key

Matt_King: My concern is that if there is nothing selected, then--JAWS and NVDA would normally announce the label of the list box without speaking a value because no value is selected

Matt_King: If there's an item focused that isn't selected, is it going to be somehow represented as the value of the list box?

Matt_King: I'm unable to test the current behavior using JAWS and Chrome at this moment; I don't understand why that is...

Matt_King: In NVDA, when I navigate to the listbox, it says, "List clickable neptunium". It doesn't tell you whether it's selected, which is interesting

Matt_King: If I select a value, tab out, and then return...

Matt_King: In NVDA, there's no way to read the ones that are not selected in a single-select list box, so there isn't a distinction between focus and selection

Matt_King: I know I've seen other implementations with a placeholder value which represents the empty value

Matt_King: That's why I was wondering if that could be the answer for our implementation, and I even kind of wonder if the pattern should say something about it

Matt_King: Is that common practice in your experience, Adam_Page?

Adam_Page: I think so. This particular use case is probably something I would discourage from a UX perspective because it presents options to the user, but it doesn't give them a user a mechanism for removing their selection

Adam_Page: To get out of that, the UX recommendation is usually to add an option which represents "no selection"

Adam_Page: It seems like a fix for this particular issue, but it kind of kicks down the road the question of whether this is a valid use case (where nothing is selected by default and there is no way to remove a value once one has been selected)

Adam_Page: We could either pattern change this pattern to be more realistic, or we could let this example continue to exist as it does and just update our documentation to explain how it should behave

Matt_King: How would we make it more realistic? Would it be enough to add a placeholder value?

Adam_Page: I think that is enough

Matt_King: It sounds like Adam_Page, arigilmore, and howard-e agree that a placeholder would make this a more realistic example

Matt_King: That could receive focus by default

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

Diagnostics

Succeeded: s/yet/yes/

All speakers: Adam_Page, arigilmore, dmontalvo, howard-e, Jem, Jon, Lola, Matt_King

Active on IRC: dmontalvo, howard-e, Jem, jugglinmike, jugglinmike1, Matt_King_