W3C

– DRAFT –
ARIA Authoring Practices Task Force

31 October 2023

Attendees

Present
arigilmore, Daniel, howard-e, jongund, jugglinmike, Matt_King, siri
Regrets
-
Chair
Jemma
Scribe
jugglinmike

Meeting minutes

Setup and Review Agenda

[Jem summarizes the agenda]

Jem: Before we get started, would anyone like to change this in some way?

Jem: Hearing none, we'll keep it as-is

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

Setup and Review Agenda

Jem: We will meet next week, November 7

Jem: We're considering cancellations on November 14 (due to Matt_King's absense) and November 21 (due to the US holiday of Thanksgiving)

Jem: We'll decide about the 14th next week

Status of Site Updates

Jem: w3c/aria-practices#2818 is ready for the next publication

Jem: The agenda lists another five patches which are ready for the next publication

Matt_King: It doesn't seem like we're going to have many of those five complete this week

Matt_King: I guess it depends on how much progress we make

Matt_King: I'd prefer to save the "keyboard" patch for last because it will touch so many pages

Matt_King: Regarding the feed example, we're still waiting on input from Alex on the iframe issue

Matt_King: Alternatively, we could remove the iframe. I don't have a strong point of view on that

arigilmore: I'm happy to wait for the solution for the iframe

Matt_King: Yeah, I was kind of looking at it as an experiment for using iframes for all the examples

howard-e: I can take a look, though I've lost a bit of context

jugglinmike: I can bring you up to speed

Matt_King: I'm skeptical that we can have a substantial update ready by Monday

Matt_King: If we wait two weeks, we might be able to get some other items in

Matt_King: I suggest that we don't push ourselves to publish next week, and that we target November 14, instead

Jem: That sounds good to me

PR 2839 - set aria-expanded false when menus are closed

github: w3c/aria-practices#2839

arigilmore: I worked on this with Andrea

arigilmore: Oh, wait, no. Andrea worked on this alone

Matt_King: This is updating JavaScript, documentation, and tests

Matt_King: I don't see any JavaScript changes here

arigilmore: I'll let Andrea know and see if she needs any help working on it

Matt_King: Probably the more complicated part of this fix will be writing a test

Matt_King: It at least won't be starting from scratch--there is already a test for setting aria-expanded to "true"

Jem: We eventually need a reviewer...

Matt_King: Let's wait until we have the patch closer to ready

Issue 2501 - Rating slider redesign

github: w3c/aria-practices#2831

Matt_King: We assigned reviewers, and the primary thing that came up was related to the design review

arigilmore: I performed a visual review, and I found one issue. On mobile, the UI extends beyond the width of the page and triggers the rendering of a horizontal scroll bar

Jem: Good catch, arigilmore!

Matt_King: do you think you can address that soon, jongund?

jongund: WCAG has target size requirements

Matt_King: The minimum target size for AA is 24-by-24. We have 10 targets on this thing arranged horizontally

Matt_King: That means the slider itself can't be less than 240 pixels

arigilmore: Could it become a vertical slider?

jongund: I would rather see a note explaining how to accommodate mobile devices

Matt_King: It should still be functional on mobile, though...

Matt_King: What if we do make it scrunched down and failed WCAG on mobile, but it still works?

Matt_King: Is that better?

<jamesn> (monitoring online) - the width of each of the targets is 48 - why can't they be made a little narrower and still pass wcag

jugglinmike: We might not have a WCAG concern, here. It is still a slider--you can still drag along the spectrum of values

jugglinmike: ...we just happen to be rendering the value "stops" with vertical lines

jugglinmike: ...so while it appears as a row of ten buttons, it is still fundamentally a slider widget

Matt_King: I think jugglinmike may have a point there

jongund: What's the mobile viewport width that we're targetting, anyway?

Matt_King: We don't have a specification for that

Jem: I typically test with the iPhone width

Matt_King: I'm wondering if there should be something in our code guide on this topic

Matt_King: I bet Carbon has some sort of spec for its responsive design requirements

<jamesn> we should support 1280 at 400% zoom - which equals 320

[arigilmore could not respond to this as she left the meeting]

Issue 2842 - Bug in modal dialog example when accessed on mobile

github: w3c/aria-practices#2842

Matt_King: We received both an issue and a pull request from this contributor--that's great!

Matt_King: But before we look at the patch, we should agree on whether this is truly a bug as raised

siri: It is somewhat subjective

Matt_King: can others reproduce whatever is in the provided screen shot?

[the group works to reproduce the problem, eventually discovering that is occurs in a nested modal dialog]

jongund: There appears to be an unrelated problem--with touch, I can't close the dialog

howard-e: I can reproduce that, jongund

Jem: The patch solves the "obscuring button" problem. I'm using my mouse to confirm this, so I can't confirm touch

howard-e: I can confirm the fix as well. It also fixes "touch" for me (I'm using a simulated version of touch with my browser's developer tools)

howard-e: The best confirmation will be from a true mobile device

Matt_King: I think I can merge this fix because it is so simple. Even if it doesn't address the problem that jongund reported, I think it would still be worth merging

jongund: I can't verify with my phone right now

Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).

Diagnostics

Succeeded: s/Regard/Regarding/

Maybe present: Jem

All speakers: arigilmore, howard-e, Jem, jongund, jugglinmike, Matt_King, siri

Active on IRC: dmontalvo, howard-e, jamesn, Jem, jongund, jugglinmike, Matt_King