Meeting minutes
[New Issue Triage](https://bit.ly/3lmotzt)
jn: two new issues, both need James Craig, I believe
jn: is my understanding correct in that we would not expect this to do what the filer is stating that it should?
https://
cs: I guess I"m not understanding what the problem is here
jn: the filer seems to be implying that certain things are returning things that are different from what they are
jn: essentially we only expect role to return the role if we have explicitly assigned the role via the attribute or assigning it to the object
cs: he's expecting the role for an html element that has an implicit mapping
cs: what he's expecting is not expected
cs: I understand why it's confusing, we should have documentation
jn: can someone take up a task to document it better?
cs: yeah, if you make it for 1.3 or 1.4, I can take it
jn: I think we should try to do it in 1.3, can you and James discuss it?
jn: the other one is https://
jn: James filed this, Scott put a comment in
cs: is Michael Cooper here, I recall this being written for political rather than technical reasons
mc: I recall writing some text for those reasons
jn: so essentially what this is saying is if something does not have a native attribute, but only has a way of programmatically using an API, that could still create a conflict but we do not state that that conflict needs to be resolved in any specific way
cs: I don't know that we need to make it apply to non-content attributes unless there's a really good reason for it
jn: the reason is that there's a conflict, but that's an author error at that point -- which one wins if there's a conflict
so: the one I can think of at the moment is indeterminate for a checkbox. We have aria-checked=mixed, but we only have the IDL attribute for the checkbox attribute
so: I agree with what James is proposing here, which is that the native feature should win out, because we don't want to have aria-checked=not mixed on something that is actually mixed
jn: so you would be responsible for documenting those in html-aria
jn: we would need to make a change that states that you are responsible for documenting where those are, and what wins
so: I'm OK with that
jn: let's put it on 1.3, but we need an assignee
so: I agree, and I have my own work to do there too
cs: I guess I can live with that.
[New PR Triage](https://bit.ly/3yOFg2I)
jn: one new PR we'll take up later
[Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates)
jn: next week we don't have a deep dive planned, the following week we have...
jn: tree grids rowindex posinset conundrum
jn: we have none for next week, is that ok? And do we want to plan anything for the week following that?
gk: how about data viz?
jn: I think that's a great idea, when we get to the next topic, we could do this during TPAC potentially and invite a wider community to them
cs: when is TPAC again?
<WTennisNFCU> sounds good
jn: it'll be in the next agenda topic ;)
Charter Updates - Have agreement from SVG WG to add SVG-AAM - cyns to edit?
jn: we have agreement from the SVG WG to add SVG AAM to our charter, which I feel makes sense. Anyone want to speak up and say we shouldn't do that?
jn: ok, so we now have DPUB AAM, SVG AAM, HTML AAM in our charter
jn: we'll be moving to living standards, so they won't have releases
jn: Cynthia, (someone) said you'd be willing to be an editor?
cs: Greta, would you be interested in being a co-editor?
gk: sure
jn: also would be nice having a co-editor on ARIA
jn: if that's agreed, Michael do you have any charter updates for us?
mc: so, the charter has been in formal review both horizontal and I don't even remember. We've been asked to clarify from the privacy reviewer to address needs reported by authors to achieve parity with native host language
mc: I think those are things he didn't read well, or we need minor clarifications
mc: he says there are things in the ARIA WG that are not named "ARIA", and I'm planning to write a polite note back
jn: maybe we need to write something about what the ARIA WG is actually chartered to do
mc: possibly, I thought we did, but I'm looking from outside
jn: if you're not an a11y person, it may not be as clear as we think it is
<MichaelC_> https://
jn: anything that comes from our side is fair, right?
mc: yes it's fair, we don't have to accept the input, we can argue things the same as we do in working groups. I think it's fine to make some editorial clarifications, and hopefully that'll be satisfactory
jn: I think we could say "for every thing, we have a corresponding API mapping"
jn: mappings for ARIA spec and its mapping
jn: once we have that, it would be great to get it soon, and then we can work on getting this through the formal process
mc: I think it's still on track for becoming live when the current one expires
mk: does it make sense to say what ARIA specs do is defining what semantics that are used across all web host languages? And so an ARIA spec is more about a11y semantics as opposed to something called "ARIA". ARIA was just the name of the first spec
jn: maybe we should change the WG name
mk: it's not a crazy idea to call us the a11y semantics WG
mc: that's a big change to make this late in the chartering process. If we feel like we need to, but I don't think we need to
mc: it's certainly worth keeping in mind for next rechartering
cs: does APA still exist?
jn: yup
cs: maybe clarifying the difference
cs: defining those lines, might help
jn: realistically everything but core aam could, but it doesn't make much sense
mk: I wonder if when we're describing the purpose of the group, the outside feedback could be addressed by saying what we do is a11y semantics
jn: do we have an issue to make comments on our charter?
mc: yes, the one I pasted a while back (https://
mc: yes, things can go in that issue
jn: if there are other comments not based on the ones in that issue, should we put them somewhere else?
mc: comments we're dealing with on this charter round?
jn: yes
mc: I guess this is as good a place as any
jn: it says feel free to raise issues pointing to our ARIA WG issues -- should we put them there?
mc: if they're for our tracking, I'd say put them in the ARIA repo. If they're for something related to our charter, put them in this issue
jn: the strategy issue?
mc: yes
<jamesn> https://
jn: anything else on charter?
[TPAC 2021 - breakout sessions](https://www.w3.org/wiki/TPAC/2021/SessionIdeas)
jn: so, TPAC is coming up, this is breakout week, we're asked to ask our WG to come up with breakout sessions
jn: if you've been at TPAC before in person, Wednesday is the plenary day where you can propose topics and form an impromptu group of people to talk about any topic whatsoever
jn: we're doing it virtually, october (missed date), we're asked to run them twice in two different time slots. Oh, there's also single time slots
jn: if anyone has sessions to propose we can do so, we can also take deep dive topics and do one of those
jn: people have come up with ideas already (lists some), we could maybe have a data viz a11y topic, maybe any of the other topics that we have potential deep dives would be awesome things to come up with for this kind of stuff
jn: we might get broader participation. If anyone wants to propose one, that'd be awesome, or send a message on the mailing lists to find others
cs: we'd talked about an idea for a breakout a few weeks ago
cs: I asked Michael the action to propose one
mc: at the time I didn't know, I do know now. Let me dig it up
jn: what was it? was I here?
<MichaelC_> https://
mc: there's a wiki page to propose wiki sessions (linked)
jn: Cynthia, can you trawl back through the minutes and find what topic you proposed?
cs: yes
jn: also if anyone else has topics to propose, it doesn't have to come out of the WG
cs: I think it was AOM
mk: what makes a good topic is the kind of thing where we want to draw people in from other WGs that will either not have time to participate in ARIA b/c they're doing other a11y stuff, or they're working on tech that has a dependency on ARIA or us on them.
mk: our normal deepdive stuff is us making up our own minds
jn: sometimes not right, data viz is an example of where there are some proposals that are fundamentally different from how we do things today. I know Aaron has one, and I think that would be good to discuss with a wider group fo people
cs: I know accessible text editing needs a lot of work
jn: yeah. If folks want to think about that, or want help or to work with other people, bring it to their attention
jn: if you want to run things by me or anyone in this group, please feel free to do so
jn: the other thing we can do around TPAC is do our normal deep dive meetings, and have intros around and run some of those during TPAC time
cs: October 8th is the deadline for submitting these
cs: looks like you can submit after, but ones submitted by the 8th get scheduled first
jn: anything else on TPAC? Hopefully in 2022 we'll be in person again
sh: so hopeful
cs: where would it be?
jn: Vancouver
[Updating ARIA 1.2 due to IDL implementations (exit and re-enter CR?)](https://github.com/w3c/aria/issues/1598) - is this ready?
jn: this is the issue, there's the PR too
<jamesn> https://
https://
jn: I'm gonna need some reviewers for this PR
cs: I approved it
jn: you essentially wrote it, so I don't think you or I are valid reviewers for this PR
jn: there are a few minor changes, which I don't know if you noticed
cs: I think you had a MUST where I wasn't sure if there should be a must or should
jn: could you check on that? It wasn't deliberate
jn: the main change was linking to the def of nullable and domstring in the IDL docs, which weren't linked from yours
jn: did that change the meaning or intention?
cs: I don't think so
jn: or actually domstring should be linking to the nullable domstring, but we don't have it yet so it's linking to our def currently
jn: our definition of domstring will go away, and it will end up linking to the IDL one
cs: that's fine
jn: can I get some reviewers who at least have a basic understanding of IDL
so: I'll take a look
jg: I'll take a look at it
jg: do we have any test suites for this?
cs: we should
jn: the testing for IDL was somewhere else, I think web platform?
cs: Joanie knows, we should wait for her to get back
jn: we didn't run the tests for it, someone else did. But that's a Joanie question
jn: bah, I made some mistakes, thank you Scott for being an HTML validator for me
jg: I have a question about IDL. If in Safari, if I set .role, I can use querySelector to find that role, that should work, right?
jg: just like if I set with a role attribute, right?
jg: for example, using querySelector I can find all elements with role=switch for example. So if I set the role using IDL, I should get the switch too, right?
cs: that will work for role and string-type attributes, but not other attributes
cs: because there were multiple choices, and that was the least bad
jg: is that discussed here?
cs: the background is not discussed here, querySelectors are not discussed here. It will work for the simple string ones.
cs: .... is that in here?
jn: it says all ARIA attributes reflect in HTML, so it says they reflect
cs: what doesn't reflect is arrays of idrefs. and that isn't here yet actually. Arrays of idrefs don't reflect
jn: we don't have that in 1.2 yet, so everything in 1.2 reflects
cs: there we go, this may be a problem or a thing to document in 1.3
jn: everything is a nullable dom string in 1.2
jn: OK, so we have now three reviewers for this
jn: James reviewing it would be awesome because it wasn't involved in writing it
jn: is there anyone else from the AOM group who should review it, or have they all verbally signed off on it?
cs: I posted a link to it to that group on tuesday
jn: would it be worth getting someone who knows IDL who isn't necessarily versed in ARIA to take a look at it?
jn: I can ask Westbrook
jn: so he knows a bit of background
cs: yeah
cs: the other part of that issue is do we exit and re-enter CR
jn: yes, it was decided we have to if we want this to be in 1.2
jn: this is enough of a change that we have to do a new CR
jn: the process is slightly different, it's not a formal withdrawing
jn: it used to be you had to do a new working draft and things before you went back in
cs: a lot of process has lightened up
jn: as soon as this is merged, I can get the spec back in order and get the changed in this version stuff redone, and we can re-enter
jn: the editor's draft, I'm going to have to create a separate PR against -- I don't think I can cherry-pick this, I think it'll be a difficult merge
jn: Cynthia, can I ask you to read the new version of the CR carefully to make sure I haven't messed something up
cs: yup
[When is hidden content taken into calculation of name and description?](https://github.com/w3c/accname/issues/57) - please review current draft
<jongund> have to leave a little early
jn: I just want some updates and to update everyone on where this is and work out next steps
jn: there is a draft PR, 137
<jamesn> https://
jn: which James did some work on, got some approvals, so I would like to ask some more people to take a look at this and see if they want to comment on it
jn: who else would like to take a look at this?
cs: I can
cs: though we worked pretty closely together, you might want someone further away
jn: Sarah, can you?
sh: sure
jn: you've probably seen use cases where this could break, can you take a look?
so: we can tag team that together if you want
so: two reviewers for the price of one
sh: 👍
cs: do you want me to be a reviewer?
jn: if you'd like to be, yes, if you don't know, no. If by mean make you a reviewer it makes you get to it, then yes
cs: I probably won't get to it quickly
jn: if you want to, awesome
jn: is this something we should get someone from Mozilla to look it?
cs: that might be a good idea
jn: James Teh?
cs: yeah, that sounds like the right person
jn: I never know how to get him on it, he's not in the ARIA group is he
jn: a housekeeping thing, if anyone wants to flag something for the agenda, just put the agenda label on it