Meeting minutes
[New Issue Triage](https://bit.ly/3ywacVd)
<jamesn> https://
jamesn: new issue against accname, in relation to proposed changes to inner text
jamesn: bryan, can you put together a comment for james craig and others to look at it? is this a blocking issue?
joanie: if there is an aria label, use it, if there is not, use inner text
garaventa: yeah originally that is what we were doing, essentially we are not checking attributes now for hidden content. the whole point is that he doesn't want to check attributes on hidden text
joanie: if a node is directly referenced by aria-labelled by, just that node is looked at, not the descendants, I think. it wouldn't be hard in webkit to grab that aria-label value instead of innertext
[New PR Triage](https://bit.ly/3t1OaIR)
zakim next item
Group chair update
jamesn: joanie will be stepping down from ARIA chair, after 5 years \o/
jamesn: we will be looking for a new chair!
<cyns> Thank you, Joanie!
<MarkMcCarthy> cheers and hurrahs for Joanie!
<StefanS> big hand clap
jamesn: Joanie has helped transform the group and has been wonderful part of ARIA
joanie: I'll be sticking around as a working bee and help others take over all the work I've been doing
[Upcoming Deep Dive calls](https://www.w3.org/groups/wg/aria/calendar)
jamesn: I added layout grid part two for next week
jamesn: treegrid posinset for the week following
jamesn: wasn't there something else from this morning we wanted to add.....??
joanie: on the posinset and setsize, I'm going to be away that week, and I am not essential for the convo. I'll implement a solution if you figure it out, but if I need to be there then we'd need to move out a week
jamesn: anyone ok with rescheduling? seems like its ok
[Deep Dives for future weeks](https://bit.ly/aria-meaty-topic-candidates)
cyns: accname whitespace?
jamesn: we need bryan for that.. how about the 30th?
melanie: I'll be speaking at a conference on the 30th so I won't be here
jamesn: 16th and 30th is open, email me if you want a topic
[Remaining 1.2 Issues](https://github.com/w3c/aria/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22ARIA+1.2%22)
jamesn: three issues left
<jamesn> https://
jamesn: author must statements -- authors much manage focus
jamesn: can we write a test on this? I think it's not possible
jamesn: lets close it unless anyone has an idea
jamesn: closed
<jamesn> https://
jamesn: test case aria error-msg, jon is not here
<jamesn> https://
jon created a PR for this, and I had a comment and wanted other people's views on this to resolve it
<jamesn> https://
jamesn: jon is testing a failure if aria-errormsg is empty. is that a failure?
stefan: seems like there is a use case to have an empty aria-errormsg
most people seem to agree it's not a failure
melanie: AT won't say anything if it is blank, right?
jamesn: right
garaventa: if you have an invalid field, it definately should have content
<jamesn> Sometimes states and properties are present in the DOM but have a zero-length string ("") as their value. Authors MAY specify a zero-length string ("") for any supported (but not required) state or property. User agents SHOULD treat state and property attributes with a value of "" the same as they treat an absent attribute.
jamesn: specification text ^
melanie: I think we shouldn't put it in until you need it, but it's not wrong according ot the spec
jamesn: let's get jon to fix this then
<cyns> https://
cyns: highlighted stuff is new text
cyns: this is basically changing from dom strings to nullable dom strings, because that is what seems to be implemented. 6.2.4 I have a question, nullable dom string is not a seperate type, but maybe it makes sense to add a def here.
cyns: 6.3 in the first paragraph, I changed from having things defaulting to their default from the ctables to defaulting to not existing when they are not present
cyns: all aria attributes are nullable dom strings, including boolean (this was in non normative section before)
cyns: move some examples to 6.3.1, normative paragraphs, summarizing what the html spec says
cyns: moved the "MUST" from the html
cyns: which is: if the attribute is not there, and you query it, it returns null
jamesn: I wouldn't recommend the block quote, because if that spec is updated, then we have to update the HTML spec
cyns: can we have a scripted link?
jamesn: that would be ok
cyns: we missed this when writing tests before
jamesn: i don't know if there is a way to do that from respec
jcraig: I think we shouldn't move the spec
jcraig: I don't think we should quote the HTML
joanie: I think SOMETHING needs to be here so that people know what user agents should do
jcraig: maybe make an acknowledgement of when the text was copied, and maybe put it in a note, say go check the REAL reference
actually, jamesn said that ^
cyns: I'll get to it next week, if you can do it sooner that'd be great
jamesn: is it ok to put a quote from another spec in our spec, michael cooper?
MichaelC: I have seen it before, seems fine
MichaelC: now I think this needs to be considered more
MichaelC: I would use their latest review draft
cyns: that is were I got this
cyns: how do I say that?
MichaelC: this comes from the HTML5 spec
cyns: this part of the spec is pretty stable
MichaelC: it seems safest for me to do the quote in a non normative way
MichaelC: we can have our OWN requirements that compliment the HTML5
MichaelC: aren't all references to HTML5 "advisory"
jamesn: not necessarially
cyns: the references are either normative or non normative, int his case it is normative
cyns: I can include it by reference or...
MichaelC: it's ok to quote, and say any normative statements in the quote should be reaffirmed somehow.
cyns: what I have right now is: (cyns quotes the document)
6.3.1 ARIA Enumerated Attributes in HTML5
As noted in Mapping WAI-ARIA Value Types to Languages, attributes are included in host languages, and the syntax for representation of enumerated value types is governed by the host language.
When the host language is HTML5, ARIA enumerated attributes MUST follow the HTML5 rules for reflecting nullable DOMString IDL attributes.
cyns: if your aria is in HTML, this is what you should do
jamesn: do we need to version our quote of hte html 5 spec?
cyns: can I say "these are the rules as of <date>"
MichaelC: lets start with date and ask a friendly person in html how to reference?
jamesn: say "html" not "html5"
jamesn: I'll make some edits here in this document
jamesn: there are some examples, are they ok, joanie ?
and jcraig ?
jcraig: seems reasonable ot me
joanie: the value of foo, aria-pressed="foo", I don't think implementations are checking that
cyns: should we document reality or try to get the spec to align with the html5 spec behavior
jamesn: if the browsers are consistent, we should document reality
cyns: I think there isn't a invalid default
joanie: this is invalid, aria-pressed can be true, false or undefined
joanie: but are user agents are doing anything in terms of checking what they expose as aria attributes...?
cyns: I think we did do that for forward compatibility
cyns: I think in spec language, these enumerated values don't have invalid default. if you put an invalid value, it doesn't do what the defaul tis
cyns: in the case where there is no invalid default in html5, I think that is what is uppose to happen
joanie: core-aam is not in CR yet
joanie: can we change the spec in this one place...
cyns: if what we want to do is document reality, I'll find out
joanie: the paragraph about the missing default... should it be removed...?
joanie: I made a comment on it
cyns: we don't have default values when we switch it to nullables
jcraig: I wrote that sentence, based on the fact that it is ennumerated attributes
jcraig: but I think joanie pointed out that doesn't matter any more
jcraig: they are nullable in the dom, but they are NOT nullable in the accessibility APIs
joanie: but does that parapgraph say that?
jcraig: nope
jcraig: either that sentence could be removed or changed to make it clear that it applies to the AAM not the dom
cyns: lets move it to the AAM
joanie: I'm ok with that but is it an AAM thing?
joanie: user agents aren't doing that on a platform by platform basis
joanie: aria-busy by default is false, if it is not in the dom, then UA prentend it is false, treat it likes it's false, that should be in the aria spec, but the platform spec, its not a mapping
joanie: it is how the user agent should interpret the infor
joanie: 5.2.3:
aria 5.2.3
joanie: there is nothing to change in the aam
<joanie> https://
cyns: ok we will update
joanie: not a lot of validation in browsers
joanie: so we should remove that part
jcraig: since this language is similar to the html language, I'd rather have a sentence that says this is the value for the dom, and another sentence that says the accessibility API mapping should be ... it should be back to back sentences for clarity
jcraig: ..... (I didn't catch but cyns seemed to agree)
cyns: I think I know what to do
jamesn: should we meet with anyone during TPCA??
MichaelC: the breakout sessions are not yet being scheduled/suggested
how do I make minutes??