Meeting minutes
<Jem> https://
<Jem> https://
APG Issue Triage
https://
MarkMcCarthy: This example
https://
Matt_King: oh we're deprecating this one
Matt_King: i'll add a link to the new example
Matt_King: oh this is the 1.1 listbox, that'll affect my comment
https://
MarkMcCarthy: same issue, closed with comment
https://
Matt_King: I know it doesn't require its own label, and it's a controlled listbox... Bryan, should the listbox have a label? since it's controlled, not owned
Bryan: I don't ever label them, when I tried that it's really spammy
Bryan: In some cases it annouces the label for every option
Matt_King: not sure if we're labelling it in our current combobox as is...
siri_: i think the name of the combobox conveys what the listbox will do
Bryan: +1
CurtBellew: we point back to the main label (of the combobox)
jongunderson: listbox has a required label, right?
Matt_King: good question
siri_: in ARIA roles states properties, it says it needs it if it's NOT part of another widget
jongunderson: this might complicate things for validators though
siri: From spec - If the element with role listbox is not part of another widget, such as a combobox, then it has either a visible label referenced by aria-labelledby or a value specified for aria-label.
jongunderson: then the ARIA spec should change. til its updated, I don't know that we can comment on this
Matt_King: the thing about a listbox, if there isn't anything about the listbox that tells a validator that it's part of the combobox, then it might indeed be confusing
MarkMcCarthy: issue filer originally opened ticket in axe-core, says: For a combobox pattern, the listbox is part of a composite widget and isn’t independently focusable nor navigable. Focus remains on the associated textfield (which has role combobox), which does require a label. So to me it seems duplicative at best and confusing/misleading at worst to also require a label for the listbox.
Matt_King: that helps! so there is a spec issue I think
Matt_King: the only clue is that the listbox itself is not focusable. could use roving tabindex... hmm
Bryan: I worry about using a touchscreen on iOS for instance, then the focusable thing doesn't apply
Matt_King: but iOS doesn't require that to be focusable from a DOM perspective
Bryan: but the logic for not requiring a name...
Matt_King: ah true, it is technically "focusable" on its own
jongunderson: the example for the 1.2 combobox, the <ul> for the combobox doesn't have a label. so either the example is invalid or spec is invalid
Matt_King: i think the spec is clear except the table part you mentioned jongunderson - could you raise an issue against ARIA?
siri_: what I had read was part of APG documentation
Matt_King: OHH so we're in conflict with ARIA spec
jongunderson: as written. the example is in conflict then too!
Matt_King: if you could reference this issue and the axe-core issue, that'll help resolve
siri_: so based on this issue, what should we decide? that listbox has a label?
bryan: I'm not clear on that
Matt_King: i'm not sure either
siri_: thinking about <select>, we tried to use ARIA roles to give other options if HTML isn't usable. it replicates <select>, and select-only-combobox doesn't have a label.
Matt_King: right... but there's only one element
Matt_King: if size is 1 anyway, 2 or greater becomes a listbox
CurtBellew: our combobox example with a listbox has aria-labelledby that points to the combobox label
Matt_King: i'm not sure which way is the bestd way to go
Matt_King: if Jon makes an ARIA issue, we should have a discussion there about this and move forwar from there
<CurtBellew> and with that I need to drop off. See you all next time.
MarkMcCarthy: we are agenda+ing this for a later day
https://
Matt_King: if anyone has ideas of resources to share, please do!
Matt_King: no need to be an expert
jongunderson: sounds like webcomponents, i'll try to respond
https://
Matt_King: i can take a look at this one, seems more related to screen reader issues
https://
Matt_King: does this need discussion? or is it immediately obviously one way or the other
Matt_King: i wouldn't say i'm an expert in reflow
jongunderson: are we going to get into responsive design in APG? that'd complicate them. if the examples are about **explaining ARIA**, it's going to obfuscate things to add more code
jongunderson: maybe we have a separate example that shows reflow, to show what's different
jongunderson: i want to avoid people thinking that this is a component library
Matt_King: as far as I know WCAG doesn't require full responsive design... do we want to explictly state we're not trying to satisfy this particular success criterion?
Matt_King: somewhere int he scope of our practices stuff, it does seem like we should have a statement/position on what we're achieving and why we mgiht not meet certain WCAG requirements
Matt_King: i want to agenda+ this
jongunderson: even in WCAG it says "Except for parts of the content which require two-dimensional layout for usage or meaning." and the tabs have meaning
Matt_King: that doesn't help much with the response we're coming up with
Matt_King: i think as a group, we need a positional statement about wcag compliance
jongunderson: there's a ton of exceptions to reflow. i'm not sure if you think we're out of compliance with reflow or not...
Matt_King: we'll spend some time on this in the future
Radio Group Focus Behavior
Matt_King: we'll move on to radio groups, as file directory requires Sarah
https://
Matt_King: our radio example is a bit different than native browser behavior
Matt_King: ARIA example is nice because, if going backwards, it's _exactly_ the same as how it was going forward
Matt_King: i've suggested raising a bug against browsers re: how native ones behave
Matt_King: if you're going quick, you won't get to the same place with a native group, which could be confusing
jongunderson: i can already hear them saying "how important is this?" *chuckle*
Matt_King: Well, we all reviewed and approved our radiogroup examples, and we have a note in there about this.
MarkMcCarthy: I'm in favor of raising issues with the browsers, it's slightly jarring even as a sighted user
siri: +1, I think it should be the same order
Matt_King: well, that all said, I could mention Jory specifically and ask if he'd be willing to raise issues against browsers
Matt_King: or if we could just get one to change, like Google *chuckle*
Matt_King: well it is the most popular browser!
Matt_King: i could make that comment and close as wontfix, or we could get some followthrough
Matt_King: i don't think i'd be misrepresneting the group if i made a comment that the TF won't be changing the example, or something like that
MarkMcCarthy: i can't think of any major objections
Matt_King: certainly not a hill worth dying on either way
Matt_King: it seems like OpenUI would be a good forum for this discussion, that deep dive is...
MarkMcCarthy: next week -- https://
siri_: I'll ask my manager and see what he thinks
Matt_King: oh right you're at Google now!
siri_: LOL
Matt_King: i think this is a good place to stop. i don't want to close this so others can respond, but i'll leave a comment
jongunderson: i've been looking at the radiobutton components - they make every radio button a tabstop *laughs*