Meeting minutes
<Matt_King> CAIR: Jemma
<arigilmore> present_
<Jem> https://
Jem: Our next meeting is Tuesday, October 10
Status of Site Updates
Jem: I saw that Shawn published the changes this morning
Matt_King: All 7 of the items in this list on the agenda were published
Matt_King: Some awesome steps forward here
Matt_King: I haven't done anything yet to validate that things are good in production
Matt_King: I'd appreciate if anyone could volunteer to make sure all these things are present, but I will eventually get to it if no one else does
Jem: I'm pretty tied up this week, but I can try on Sunday night
dmontalvo: I'll take a look as well
Matt_King: Thanks! There's one in particular that I'd like you to look at because it's totally visual--the combobox CSS fix
Matt_King: That's it for site updates. Thank you to everyone for all the help!
PR 2775: Feed example changes
github: w3c/
Matt_King: As we've been reviewing this pull request, we've run into some problems with making the iframe work
Matt_King: howard-e merged a change by jugglinmike in WAI-ARIA Practices. I wasn't clear about what that was doing
jugglinmike: My fix addresses the problem on my machine, and howard-e verified it, as well. Unfortunately, it appears to have had no effect on the preview system.
jugglinmike: I haven't been able to identify why this is the case, yet. Alex_Flenniken will likely be taking a look in the coming months
Matt_King: Thanks. Let's assume that technical problem is solvable. There's another aspect I'd like to discuss
Matt_King: Aaron Leventhal has reported that putting examples inside iframes makes it much easier to direct people to them
Matt_King: I began wondering if this is a pattern we could replicate across the APG--placing all examples within the iframe
Jem: Was Aaron's request sent to you via e-mail or on GitHub?
Matt_King: Via GitHub--issue #2386 w3c/
howard-e: I like that proposal
howard-e: There's an opportunity for ARIA-AT to use the more bare-bones versions of the example pages
howard-e: I worry about how tests may have to be changed to account for this, but right now, I do like the thought
Matt_King: If arigilmore was into us turning her project into a big old experiment, we could try it with this PR
James: Couldn't we host the examples as standalone documents and also build them directly into the pages where they are currently rendered?
Matt_King: So in the ARIA-Practices, we would continue to do things just like we do today?
James: I guess you could do it that way, but I was expecting to do define them as standalone documents and then build them in
Matt_King: To solve 2386, we could write some code that extracts and duplicate that content during the build process
jugglinmike: There may be some examples where an iframe is less appropriate. Dialog for instance
jugglinmike: But in general, I like the idea of pursing the iframe route (rather than generating a separate document by extracting the example source) because it increases parity between how people experience the examples in either context
jugglinmike: As those experiences diverge, I worry about differences which result from our build process
Matt_King: If this works, though, then eventually, we might put iframes on every example page
Matt_King: Once we figured out a pattern, it probably wouldn't be that large of a project to move in that direction
[discussion about how such an iframe would work generally for APG examples]
jugglinmike: We also have to consider how we manage the examples' controls. For arigilmore patch, we intentionally placed the controls outside of the iframe, but it's not clear if/how we should include them for folks who access the iframe content directly
Potential combobox value bug?
link: w3c/
Matt_King: I could use some help verifying this because it was reported with a screenshot
Matt_King: I can't tell which example it concerns
Jem: It looks like the Editable Combobox with Both List and Inline Autocomplete Example
<Jem> Editable Combobox With Both List and Inline Autocomplete Example
Matt_King: Thanks; I'll add a link in the issue itself
Matt_King: What is the issue when they put in a number less than 10?
Jem: VoiceOver says the number followed by "s t a t e"
Matt_King: This sounds like it might be a screen reader bug, if it is a bug
Matt_King: I'm going to follow up with the reporter
PR 1611: Markup for keybord chords
PR 1611: Markup for keybord chords
github: PR 1611: Markup for keybord chords
Matt_King: I've put a table in the agenda that shows what Nick had proposed
Matt_King: Currently, when we write our keyboard commands, like in this table, we use the <kbd> element to wrap entire chords
Matt_King: Nick recommends wrapping each key in its own <kbd> element
Jem: Visually, Nick's suggestion looks more coherent
Andrea_Cardona: Is the current markup confusing?
Matt_King: I don't know if it's confusing anyone, but I don't know if it's technically correct
Jem: because, for instance, there is no "Control plus V" button. There is a "Control" button and a "V" button; the markup Nick recommends reflects that
Andrea_Cardona: Yeah, that makes sense to me
Issue 697 about aria-expanded=false on menu buttons
Matt_King: I can write a patch for issue gh-1611. It will modify a lot of files, so the trick for me is to figure out when to submit it
Issue 697 about aria-expanded=false on menu buttons
github: w3c/
Matt_King: People were so confused by this that they were suggesting a new property in gh-697
Matt_King: I have written a pull request which removes the recommendation
Matt_King: If we go that route, we will need to change three menu button examples
Bryan_Garaventa: we originally proposed this because on some devices (E.g. those based on touch), you cannot perceive menu hierarchy
Bryan_Garaventa: That leads me to two questions
Bryan_Garaventa: How do you identify hierarchy if you take it out?
Matt_King: Today, our menu buttons don't have "aria-expanded=false" when they are collapsed
Bryan_Garaventa: Oh, so this isn't about removing the attribute
Matt_King: No, so it's about applying it consistently
<siri> +1
Bryan_Garaventa: Ah! Yes, I would recommend consistency. Especially for those using touch screen devices
Matt_King: The clarity of knowing that it is collapsed is helpful
<dmontalvo> +1 to adding aria-expanded="false" when collapsed for clarity.
siri: I support this, as well
Matt_King: Sounds like we have a lot of votes here, all in favor!
Matt_King: There are three menu button examples that would need to change
Matt_King: I have already submitted a pull request for the pattern
Matt_King: I think this should be two separate pull requests. I think the code changes should be done in a separate pull request