Meeting minutes
New Issue Triage
valerie: 1.4 milestone?
jnurthen: different names - also pills, tags etc.
… close as duplicate?
valerieyoung: other one has lots of comments.
… let's close as duplicate.
New PR Triage
valerieyoung: no new PRs
Deep Dive planning
valerieyoung: currently no deep dives planned.
… any interest?
dakahn: notification deep dive still planned?
jnurthen: did we want to?
dakahn: thought so.
jnurthen: I'll double check
… did you mean pop ups?
dakahn: yes.
valerieyoung: waiting for Aaron to be back.
jnurthen: there's a google doc somewhere with significantly different proposal
cyns: sounds about right.
<aaronlev> I can't make it today, but I'll listen in on IRC in case anyone needs anything
jnurthen: aaron waiting for more feedback first.
OpenUI is asking the TAG for the review of focus groups
valerieyoung: just an announcement. early design review for focusgroup
Does aria-hidden obey DOM or AX tree ancestors?
valerieyoung: continuing the discussion from last meeting
… first we decided that hidden should obey AX tree. But James Teh disagreed, Aaron thinks it's worth discussing.
… what is the intution for authors.
<aaronlev> James Teh's POV makes sense to me
<aaronlev> on aria-hidden + aria-owns
mattking: also practicality. Are there some real use cases to think about where someone would put aria-hidden on an element that owns something - and what do they expect.
cyns: I raised this. Probalby good to check what's being used / what we might break.
mattking: so what does the current world look like? Not propagating down AX tree - but descendants?
cyns: descendants yes, owns no.
mattking: aria-owns is meant to affect AX tree structure so what is the expectation that aria-hidden.
valerieyoung: no browsers hide owned elements.
cyns: is there content out there? how much? does it rely on that?
mattking: how did this start?
<aaronlev> There wasn't a real known example
<aaronlev> It was theoretical
valerieyoung: aaron asked, trying to decide what's meant.
cyns: spec is unclear.
valerieyoung: let's look at the spec
… element considered hidden if it or its ancestors are not rendered or aria-hidden=true
cyns: unclear which kinds of ancestor.
mattking: we had similar issues around descendant
cyns: implementors tend to assume 'dom'
mattking: we tend to not limit ARIA to DOM
cyns: we could use "host language tree" vs "accessibility tree"
mattking: feels like we need to give ourselves the language to talk about this clearly
… feels to me we should do no change until then
<aaronlev> How about:
<aaronlev> We could say ancestor/descendant always means AX tree
<aaronlev> except in case of aria-hidden
<aaronlev> Because the aria-hidden property could say "Use of aria-hidden combined with aria-owns is undefined"
<aaronlev> to scare ppl away
<aaronlev> undefined or invalid
mattking: since this didn't come from practices but implementors it might not be too urgent
cyns: if we don't find use cases, we can just go ahead and clarify
jnurthen: I think it's possible there are uses cases and they might just have propagated aria-hidden to aria-owned elements
… aria-owns is already complex, so that seems likely.
mattking: makes sense.
jnurthen: not just element, but also walking down the tree etc.
cyns: might shadow boundaries get in the way?
jnurthen: certainly
mattking: you don't always know how to walk the tree. you might have a container and you don't know what's inside.
jnurthen: seems odd for a container to aria-own something outside the parent
mattking: fair point. I don't want to make up use cases.
cyns: we could make a PR to clarify and share it with people writing component libraries
valerieyoung: sounds great. any volunteers?
cyns: can help sharing them.
mattking: we should sort out the vocabulary
valerieyoung: good point. we should double check.
cyns: accessibility tree appears in spec. but still
pkra: there's at least one issue to go through spec to sort out language for owned/descendant
… https://
jnurthen: element now references concept in DOM
… hidden we still reference ARIA hidden since it's not anywhere else
cyns: sounds like editorial work
1.3 triage
valerieyoung: Name from author on column header & structural relationships #1219
pkra: scott comments points to html-aam
valerieyoung: great. closing.
… May a treeitem contain interactive elements? #1251
pkra: more editorial, "good first issue" tag
valerieyoung: good first issue should probably have a template.
pkra: I'll do it.
valerieyoung: aria-busy language update in Required Owned Element section #1300
jnurthen: this probably goes away if Sarah's PR is merged.
mattking: allowed owned is less restrictive than required owned?
jnurthen: is it though? There seems to be a dual intent, mish mash / different sets of expected
mattking: I remember now. We've used it but inconsistently.
… do we list everything that could be allowed? Not sure.
jnurthen: I think so but should double check
… we really only use it on composite widgets
… so it's limited in scope
mattking: there's a PR?
jnurthen: not sure. Sarah was working on something.
valerieyoung: james, can you ask Sarah?
jnurthen: will look.
valerieyoung: update owned element definition #1301
… I'll take that.
valerieyoung: Reword banner, contentinfo, main to use "on a page" instead of "within any document or application" #1320
ari: I can do it.
valeriyoung: next: aria-haspopup with value treegrid? #1333
mattking: aaron and I had discussed hasPopUp. I should probably do this alongside the other hasPopUp
valeriyoung: next: Extend support for aria-expanded to the radio role #1404
mattking: did we not discuss this already?
jnurthen: we have but it keeps coming up.
… from people with UX research.
… here, gov UK
stephan: a lot of good questions in there.
mattking: I don't know if I comment but there's a risk for overload for AT users.
stephan: these patterns appear all over
… I think there's some reasoning for this
<MarkMcCarthy> +1 Stefan
mattking: would this be an easy change (from the spec)?
jnurthen: is there a benefit for users?
mattking: I'm imagining arrowing through a radio group. I'd assume the name of the radio would give some indication.
… if you hear "selected" and "expanded", how often would you have a case where they don't mean the same thing?
… if the expected behavior is expansion, then it's noise. Compare haspopup on combobox.
stephan: problem that radio button groups that don't have it and some have it. how do we differentiate.
mattking: I don't think it helps to add "expanded". You learn by selecting it and hitting tab, finding new content.
… feels to me the content designer, writing copy for radios, should be responsible to ensure the context is understood; then it won't be surprising.
stephan: because there's a visual change in the UI.
… isn't it beneficial that a blind user gets informed?
mattking: the assumption would be that a blind user understands that
jnurthen: reading through it, they did user testing.
… positive case of checkbox. For radio button, unclear.
… maybe ask for follow up study.
valerieyoung: sounds like we should ask about user research
jnurthen: later on "we don't have the resources to do extra research' :(
… we have something from the last discussion.
valerieyoung: do we want to say that we move it to 1.4 but if use cases / research comes in we'll reconsidered.
jnurthen: feels to me something wants to satisify an interpretation of wcag rather than user benefits.
mattking: +1. You don't need to explain everything. You drown people in instructions.
stephan: last comment: checkbox is reversible, radio button is not. this makes it more complicated.
mattking: expanded is normally on something that you can expand and collapse. here you can't.
jnurthen: reading through this, example of "email / phone / text message". Email would be expanded, the others would not say "collapsed". Is that potentially useful if using a virtual cursor.
mattking: what are the clues that any user has about how it works.
… if they were doing something different to these radio buttons that would be an interesting question.
… is it from looking at UI or interacting with UI.
jnurthen: might this be more useful
cyns: there's also a vertical line to associate it.
jnurthen: but doesn't show it will go away
mattking: feels to me selected has same meaning as expanded here.
cyns: here yes, but not always.
valerieyoung: there's also the case "other" with a text field. like matt said, that's a sign.
mattking: right. that's very common.
valerieyoung: ok. let's move to 1.4