Meeting minutes
<Jem> https://
Setup and Review Agenda
Jem: Any requests for change to agenda?
jongund: I could speak to an issue that was assigned to me a few weeks ago, issue 3289 w3c/
jongund: I don't think it's a bug. Rather, it's a feature
Matt_King: We can resolve that asynchronously, jongund. I'll participate
Jem: Hearing no other requests for changes to the agenda, we'll keep the agenda as planned
Jem: Next meeting: July 8
Jem: No meeting July 15
Publication planning
Matt_King: I changed this to next Wednesday so we can use next Tuesday's meeting to land some things
Matt_King: that includes the "expandable region" work
howard-e: I can help with the publication on Wednesday the ninth. I'll prepare it on Tuesday so it's ready for the W3C on Wednesday
Matt_King: Hopefully there are no problems with them about that change
jongund: Has the skipTo.js change been merged?
Matt_King: No, that's still in a pull request. I didn't add it to the milestone, but I can revisit it
Matt_King: It might be too late to add it to today's agenda, though
jongund: Alright
Matt_King: I need to add 3251 to the milestone
PR 3251 - New example demonstrating expandable cards/regions
github: w3c/
Matt_King: This is what we've been calling the "expandable region" or the "disclosure card"
Matt_King: I'm going to finish my review of the editorial content this afternoon
Matt_King: I know jongund did a code review
Adam_Page: I've pushed changes for all the feedback I've received so far
Matt_King: jongund, do you have the time to review again?
jongund: Sure
Matt_King: Awesome. I'll request another review from you
howard-e: I reviewed the tests and some of the code changes. I had no issues
Matt_King: we had siri and CurtBellew on this one, as well
Jem: siri isn't here today, but CurtBellew is here
Matt_King: as I recall, CurtBellew was going to review the design and functionality
CurtBellew: Yes, I'll do that today
Matt_King: great, that will help today
Adam_Page: I made some minor tweaks to the CSS and to the documentation
Jem: Usually, when we have an example with links, we have a blank page as a placeholder
Matt_King: The link should do something
Matt_King: We decided that we weren't going to create a bunch of "dummy" pages
Matt_King: What do the links in the Tree Grid do?
Jem: They are "mailto:" links
Matt_King: There are some links in some of the dialogs. Those might open up a JavaScript alert
Adam_Page: What does the print button do?
Jem: It opens a modal dialog
Matt_King: The probably doesn't impact the tests because we're not testing the keyboard functionality of buttons or links. Only the "expand/collapse" functionality
Matt_King: We should have a regression test for each keyboard command that's documented
Adam_Page: Yes, we have that
Adam_Page: In the CSS, I'm using an experimental feature called "interpolate size". It's purely cosmetic. It is supported by Chrome and Edge, and Firefox may support it behind a flag.
Matt_King: Does it have a bad side effect if it's not supported?
Adam_Page: No. It is still functional without it
<Jem> https://
Jem: If it doesn't have any bad impact when unsupported, I think we can keep it
Adam_Page: That sounds fine to me
Matt_King: I'm aligned with it as well
howard-e: I'm also fine with it (and I think I said as much in my review)
<Jem> https://
howard-e: I wonder if the "read this first" statement covers things like this. In the future, it could enhance the experience if an experimental feature is used, but it could be detrimental if absent
Jem: I'm sharing the "read this first" page. There, we have a section about "browser and assistive technology support"
Matt_King: as a code guide practice, I don't know if this is really experimental because it is already spec'd and being implemented. If we had doubt about the feature being broadly supported or if it could have a negative impact on the accessible experience
Adam_Page: For what it's worth, I gated this behind a "prefers reduced motion" media query
Matt_King: Great
PR 3302: simple editorial PR needs review
github: w3c/
Matt_King: I only removed a colon. This should be fast. I assigned Jem
Jem: Okay, I'll do it!
Issue 2855: Select only combobox not working on Android
github: w3c/
Matt_King: A long time ago, when we put the select-only combobox out there, people noticed that it wasn't working well on Android
Matt_King: Jem validated the bug
Matt_King: We didn't know if it was an APG problem or a TalkBack problem or a Chrome problem
Matt_King: People recently reminded us that it doesn't work on Android
Matt_King: If we can make it work, I think we should. But if we can't make it work, I think we should start bugging the people who maintain the software whic is at fault
Matt_King: We know the bug is reproducible. We don't know if the open issues being mentioned here are the root cause
Jem: There is a comment from April of this year on one of these external reports. They write about how this may be a delay problem
<Jem> https://
Jem: They included a screen recording of the bug being expressed in Chrome
Matt_King: I want to get to the bottom of whether or not this is something caused by our code
Jem: They're saying that Google Maps has a significant delay. They're actually talking about two different examples: Google Maps and APG
Matt_King: Are these problems present only when TalkBack is running, or do they happen without TalkBack running?
Jem: I think it's when TalkBack is running...
jongund: If it's a bug, it probably has something to do with aria-activedescendent. Is it possible that this would work if we didn't use aria-activedescendent?
<Jem> This is the content from the chrome bug report, filed by Adrian Roselli.
<Jem> "Using the APG listbox with states at https://
Matt_King: I don't know if we would want to make another example just for that purpose. If someone wanted to test it out to verify whether that is the root cause, that would at least be helpful to the Android and/or TalkBack developers
Matt_King: I could be helpful to make a code pen to test out that theory that you could attach to the Google bug
Matt_King: but that's just your hypothesis right now, correct?
jongund: Correct
Matt_King: I don't think we would want to re-write the APG example for that reason
jongund: Agreed
Jem: This sounds like a TalkBack problem. There's another comment (this one from 2023) that suggests this
Matt_King: so the next step? It seems like a problem to have this really important pattern not to work on mobile
jongund: I can build a codepen, but I can't test it because I don't have any Android devices
Jem: I have an Android device for testing
Matt_King: It sounds like we're getting a plan of action. We have one hypothesis to test which will require two people: jongund will make the test, and another person with an Android device (perhaps Jem) can verify
Issue 3275 - Question about color contrast
github: w3c/
Matt_King: someone is asking for advice. It's a bit out-of-scope for the APG because it's not about an APG example
Matt_King: does anyone want to direct this person to the right place for their question?
Jem: Yes, and I can transfer the issue to the WGAG group, as well
Matt_King: That would be great, thank you!
Issue 3261: Spinbuttons, Target Size, and equivalent exception
github: w3c/
Matt_King: The ARIA-AT group also has concerns about our spin buttons
Matt_King: There are some concerns here about the target size for the spinners. Also, how would having an "edit" box effect this?
Matt_King: In ARIA-AT, we are wondering why we have a spinner that doesn't have an "edit" box? Is that realistic?
Matt_King: it seems like we would never want to recommend that anyone use this spinner. If they were going to build something that behaves this way, they should use the slider. If you were going to use the spinner, then you should have an "edit" box?
Jem: Should we retire this example, then? Or modify it?
Matt_King: This is a good question for jongund because I think he worked on this example
Matt_King: Or really, for anyone: Can anyone think of a case where you would want to use a spinner without an "Edit" button?
Jem: I see the use case for mobile
Matt_King: where they don't have "edit" buttons?
<jongund_> I need to leave a little early
Jem: Yes, they just act like a spinner. For creating an event on a calendar, you just click the arrow button to select the year, month, and day.
Matt_King: so there's no place for you to type in the number?
Jem: No. This is on iOS
Adam_Page: Yes, iOS certainly uses this pattern for "date" inputs
Adam_Page: An important difference is that iOS accepts scrolling input. I think they would make an argument that it's a significant ease-of-use difference
Adam_Page: They don't have buttons like we do. They don't have explicit up and down buttons to increment and decrement. Instead, the user scrolls through the options
Matt_King: That's what iOS calls its "picker" adjustable value when you use VoiceOver
Adam_Page: A sighted person would use their finger to drag up and down
Matt_King: How is it different from a slider?
Adam_Page: It wraps around, so it's like you are scrolling a wheel that wraps around (unlike a drop-down with a distinct start and end)
Matt_King: So iOS doesn't have up and down buttons. If they had a mobile web implementation of this, how would you make this?
Jem: Scroll. Touch to push up and push down
Adam_Page: I've seen web implementations of this, but not many. I wouldn't say it's a popular approach to date input
Matt_King: We're at time for today's meeting, but there is more to talk about here (do we keep this example? Do we change this example? How do we change it?) I will put it on the agenda for next week
Matt_King: Thanks everyone!