W3C

– DRAFT –
ARIA Authoring Practices Task Force

13 June 2023

Attendees

Present
arigilmore, Daniel, howard-e, Jem, jugglinmike, Matt_King
Regrets
-
Chair
Matt King
Scribe
jugglinmike

Meeting minutes

Review agenda and next meeting

<Matt_King> View agenda at https://github.com/w3c/aria-practices/wiki/June-13%2C-2023-Agenda

<Matt_King> Next meeting date is June 20

<Jem> https://github.com/w3c/aria-practices/wiki/June-13%2C-2023-Agenda

Status of Coming Site Updates

Matt_King: I was hoping we would publish this week, but I'm not sure about the status of that

jugglinmike: Alex_Flenniken is still trying to prepare a branch for publication this week

Matt_King: This list of six items are the things that should be included; they have all been merged to the "main" branch

Pull request reviews

Skipto menu on all pages: Update skipto.js script to version 5.1.6 by jongund · Pull Request #2680 · w3c/aria-practices

github: w3c/aria-practices#2680

Matt_King: I tested this with screen readers to make sure there have been no regressions, but I'm looking for help to verify that there have been no visual regressions

Matt_King: the deadline for review will probably be at least two weeks

arigilmore: I can take a look

Matt_King: Thanks! I'll assign you

Checkbox Example (Mixed-State): Toggle on keyup to prevent continuous toggling by sivakusayan · Pull Request #2722 · w3c/aria-practices

github: w3c/aria-practices#2722

Matt_King: We've already merged a similar pull request for the two-state checkbox

Matt_King: We need volunteers for code review and functional testing

<sirib> can we discuss about https://github.com/w3c/aria-practices/issues/1233, w3c/aria-practices#1947 if you have time

Jem: I can perform the reviews

Listbox Examples: Update scrolling of listbox item with focus into view when page is magnified by jongund · Pull Request #2622 · w3c/aria-practices

Matt_King: Jon isn't here today, so since jugglinmike has provided feedback for Jon on the pull request, we can skip discussing this today

PR 2723: Select-only Combobox Example: Fix scroll event listener bug by ariellalgilmore

<andrea_cardona> w3c/aria-practices#2723

<arigilmore> w3c/aria-practices#2723

arigilmore: The preview is failing

howard-e: I have a theory about what's going wrong; I will take a look

Matt_King: Does this only need to be tested on desktop devices, or should it be tested for mobile, as well?

arigilmore: I don't think it should have an effect on mobile, but I'm not confident about that

Matt_King: It shouldn't change anything for the mobile experience, but I'm concerned about regressions in mobile

Matt_King: We'll have to reach out more for reviewers

Matt_King: I'll add a review checklist, and we can work on finding volunteers over the course of the week and during next week's meeting

PR 2724: Example Pages: Change Javascript to JavaScript in h2 elements by mcking65

github: w3c/aria-practices#2724

Matt_King: This is my pull request. It is super-simple

Jem: I can take a look at that one

Matt_King: Thanks!

andrea_cardona: And it looks like we have one approval on that already

New Issue Action Planning

Add information on joining the group and group communication to "About" page

Matt_King: I agree with this one; I think I'll take it on, myself

Select-Only Combobox Example Tabbing as selection

github: w3c/aria-practices#2703

Matt_King: We discussed this last week, but we only had a few people in attendence

Matt_King: Also, the reporter has not responded to the notes from our discussion

Matt_King: I'll review it for the folks present today to see if anyone here has a different perspective

[Matt_King recaps the issue]

Matt_King: Essentially, does anyone see a problem with the way the APG's selection box currently behaves?

jamesn: I would be annoyed if it didn't behave the way it does today

<jamesn> https://microsoftedge.github.io/Demos/selectmenu/

Matt_King: I'm going to let the person who raised this have an opportunity to respond before closing this as "won't fix." I'll give it some labels so that it doesn't come up in future triage meetings.

How do I know if a menuitem can be activated or only opens a submenu

github: w3c/aria-practices#2720

Matt_King: They're asking whether or not a practice should just be forbidden. I don't know if there's a way to forbid anything in ARIA-Practices. I think we'd have to do that with a "MUST NOT" in ARIA

Matt_King: Is that a direction we should go in?

jamesn: I don't think so. I think authors should avoid doing it, but if you want to add this feature to your application, it's probably learn-able. I don't like it, but it's learn-able

Matt_King: So the guidance we have here is adequate. There's nothing we can do here in ARIA-Practices to help screen readers out

jamesn: I think it should not be forbidden by ARIA.

Matt_King: I don't know if there's a way, editorially, for ARIA-Practices to strengthen our guidance against it. Then again, we don't explain why we recommend against it...

Matt_King: I wonder if we should add another sentence that says why not to do it. We could just add, "because this behavior is not discoverable by assistive technology users."

Jem: That sounds like a good idea to me

Matt_King: I'll put an "editorial" label on it, then

Jem: This reminds me of other cases that we've seen before

tooltips closing with Escape is an irregular UX practice

github: w3c/aria-practices#2538

jamesn: WCAG requires this--there's always a risk that the tooltip will obscure content, so you always need a way to dismiss it

jamesn: If this is irregular behavior that WCAG is requiring, then the issue should be raised with WCAG

Matt_King: I don't take WCAG's recommendation as unquestionable. I'm willing to push back on WCAG, and we have done that in the past. In this case, though, I agree with WCAG

Do non-interactive elements ever properly gain focus?

github: w3c/aria-practices#2698

Matt_King: We leave it up to the author here. I may be too close to the content to see what's unclear about this

Matt_King: Increasingly at Meta, designers are removing disabled and unfocusable items from the page--they're asking, "why are these present on the page at all"

Matt_King: This is a part of WCAG that has always bugged me. Why do some people get to benefit from knowing that something is disabled when other people can't perceive it at all?

Matt_King: When I'm filling out a form and I reach a disabled "submit" button, that's very helpful. When I can't even find a "submit" button, that is very annoying indeed.

jamesn: We see this most often when designers want to put tooltips on disabled items to explain why they're disabled.

jamesn: We have to explain that you can't put tooltips on those things because screen reader users can't perceive them

Matt_King: This person is asking for more clear guidance. I don't think the APG can give more clear guidance, but I'm interested in feedback from other folks on the Task Force

Matt_King: If anyone thinks that we can make it better, then that would be useful

Jem: I like JAWS-test's response

Matt_King: If anyone wants to take up the banner of getting browsers to support focusing on disabled elements, then I'd be all for that!

Minutes manually created (not a transcript), formatted by scribe.perl version 210 (Wed Jan 11 19:21:32 2023 UTC).

Diagnostics

Maybe present: andrea_cardona, jamesn

All speakers: andrea_cardona, arigilmore, howard-e, jamesn, Jem, jugglinmike, Matt_King

Active on IRC: andrea_cardona, arigilmore, dmontalvo, jamesn, Jem, jugglinmike, Matt_King, sirib