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://
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/
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/
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/
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/
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