Meeting minutes
<spectranaut_> scribe:
[New Issue Triage](https://tinyurl.com/55pwk6w5)
sarah: selection for multiple cells within a row or cells within a grid, you have mix state on the row or column
sarah: or you have a checkbox within the cell, and you arrow within the row
sarah: or table commands to move through cells, to expose the current checked state
sarah: its a small change if it is not controversal
jamesn: why are we looking to add more stuff to something that doesn't work very well
sarah_h: I have abandoned hope that aria-select would be useful for multiple selection
sarah_h: selected isn't exposed by some, not selected is not working for others -- mostly it works when selection is following focus
sarah_h: but if you are trying to expose a permanent selected/unselected state
jamesn: lets agenda+
jamesn: seems like there is more to discuss. I'm hesitant to add more features when what we currently have doesn't work
??: selected is the correct semantic
issue for tracking status
Doug: scott helped me set this up, the goal is to set up discussions in the background discussion groups
Doug: some of this is low hanging fruit
jamesn: I'll put this in the notification project
jamesn: should we agenda this for next week
[New PR Triage](https://tinyurl.com/erndjtaw)
[Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates) - [Considerations for focusgroup](https://github.com/w3c/aria/issues/1947)
jamesn: should we discuss next week?
mcking: yes please
jamesn: let me know if I should invite anyone from outside the group
jamesn: btw we have cancelled the july 6th meeting
[`aria-controls` with late-mounted elements](https://github.com/w3c/aria/issues/1956)
jamesn: my reply to this involved taking pieces out of the spec... adding aria-controls with an invalid value should be ignored
jamesn: but I think it looks like an author error, it looks like validators should flag
jamesn: because it is in a section called "handling author errors"
jamesn: it seems like it shouldn't be an author error and that we should maybe move it
jamesn: do people agree with me on this?
jamesn: or should people work around this another way
mcking: clarification question, as I understand, there are two choices, one is that it is an author error to specify an invalid control on anything that takes an id reference, two is user agents are responsible for not exposing the attribute if it has an invalid reference
jamesn: yes, currently, user agents are responsible, (2)
jamesn: (reads the handling authors error section)
jamesn: the dom will still show, in the accessibility apis they are not exposed
jamesn: therefor html validators show this as an error
mario: do validators validate static state
jamesn: validators don't have access to the accessibility tree
mario: oh I see
mario: its a problem they validate the DOM
curtis: that is a problem we have, no way to validate the accessiblity tree
jamesn: the problem is this might be an error, but also there are cases where the thing that aria-controls points to might not be in the page all the time
sarah_h: there are some wrangling things we could do, for example, only an error on an expandable widget when expanded
sarah_h: I think this came up in an axe core issue at some point
sarah_h: I think we could spec that
jamesn: is that fixing the problem, or only a version of the problem?
jamesn: what about aria-describedby on something, and it references 3 id references, and one is only present in certain error conditions and not at other times. more commonly it is empty. a tool tip for example
sarah_h: we ran into that, the tooltip only appears on focus, and you navigate to something without focus then you don't get the description
sarah_h: the cases where it is not an error are pretty scoped
jamesn: I
jamesn: I've seen cases of error text which point to an error text that is only there sometimes
CurtBellew: I heard someone say that this could be a warning. full disclosure, we use axe but silence this error
CurtBellew: the id references don't exist until they are rendered
CurtBellew: active descendent, all kinds
mario: maybe the author should put the attribute at the same time that the element with the id is dynamically put into the page. but when the author has to think about it, to put the attribute at the same time, we should say the attribute that links to the element with ids are not required
mario: if they are not required, then it is possible to put them on the element at a later time
<pkra> I have to drop off early -- sorry! Talk to you all next week.
cyns: it still feels like a warning to me
cyns: maybe it would be better if authors added at the create the thing, but it doesn't actually cause a problem, so
cyns: seems to me we should let it be
jamesn: I guess if we move this out of authoring error... there is a previous section called id reference error processing.. not is not it
cyns: do we ever do notes to validators
jamesn: I think we should move from handling authors error to "state and property attribute processing" section
jamesn: we could add user agents must in there
jamesn: we could add a note to validators that this is just a warning in validators
jamesn: what do people thing of that
cyns: +1
mario: +1
<CurtBellew> +1
<sarah_h> +1
<Adam_Page> +1
jamesn: the whole "state and property attribute processing" is a whole wall of text and could use a rewrite
mcking: the must statements must be clear and stand alone
james: and it's weird there are authors must....
mcking: those should be notes that point to where they are actually listed, if it is replicated
<Marcelo> I could pair with someone, so I can learn the process
mcking: I can help you some with that
<Marcelo> thanks
mcking: on this issue, you suggested a PR that would have a scope bigger than this issue
mcking: is that what you are looking for?
jamesn: it feels like just moving this to that section would lead to a very difficult to read section. It becomes less useful.
mcking: I see, you see it has necessary scope
mcking: it doesn't have to be a separate issue
[Consider ignoring pseudo element content for accname if it has empty alt text](https://github.com/w3c/accname/issues/194)
jamesn: this is about css generate content, where alt text is specified in it
jamesn: I was hoping we could have some folks commenting about how this should be resolved
bryan: in the accessibility tree, is that represented as a node the same way an image would be
bryan: if role="none"
james: after and before content, where you specify text or a presentation semantics, or empty text
jamesn: as the content
bryan: if you specify empty text... it should be hidden?
jamesn: that is the question
bryan: I'm just not sure what happens in the accesisbility tree right now
jamesn: maybe the best thing is to write tests and then we can know what the issue is
jamesn: and james craig did make a placeholder issue for this
jamesn: on a philosphical case, are people comfortable with different text being presented to screenreader that is different than is on the screen?
<Marcelo> I feel this is a design decision, not an implementation decision.
bryan: from my own perspective, I feel the same way as an image that has something different than the image displayed
jamesn: it's a button with an aria-label that puts something totally different than the button text
adam: more descriptive text for example
cyns: yeah there are valid scenarios
cyns: and opportunity for it to be used in bad ways
jamesn: like all of aria
jamesn: but is there any higher risk from this than any other aria feature?
cyns: I don't think so
sarah_h: I think the common valid usecase I've come acrossed is like an element that you want in the accessibility tree but you insert a unicode character and you don't want that included in the accessible name
sarah_h: there aren't great ways to work around that
sarah_h: you have to create a new dom node instead of using the pseudo element
sarah_h: on the flip side, I don't see it as fundmentally different than aria-label... pseudo elements add a whole nother layer to finding where the accname comes from by looking at the dom
jamesn: there are work arounds?
jamesn: should this be in the fabled css-aam
sarah_h: should this be in processing the text content of a node?
sarah_h: and then the accname spec doesn't need to deal with it
jamesn: well there is a step here....
sarah_h: but if css-aam changes the way textual content is exposed then we won't have to change the algorithm
marcelo: isn't this a content design decision
Marcelo: doesn't it combine with aria-description/aria-label
cyns: that is all part of name calculation so it is definately related
jamesn: it fits in, it's one of the nuances of the calculation
jamesn: the only place we have it is where name from generated content..... should we even be defining this... maybe it should be somewhere else
<sarah_h> +1 to somewhere else :D
jamesn: I'd love to hear from aaron, who probably knows this in more detail, I'd like to know his view point on this
jamesn: here in the accname algorithm we are only specifying css before and after pseudo elements, but what about the other pseudo elements that exist, like list, where unicode characters shouw up
jamesn: maybe this is a good tpac discussion for getting css-aam off the ground again!
jamesn: what can we do about this issue
jamesn: the first thing to do is write the tests
mcking: we don't know how pressing this is
mcking: even if it isn't speced, maybe everyone agrees
cyns: I'll take this issue, if there is no time pressure
mcking: done sometime before TPAC would be useful
<Marcelo> thanks everyone
#topic TPAC
james: there are some funds for diverse members