Meeting minutes
jamesn dealing with individual issues within the github issue UI
<carmacleod> https://
jamesn will add a "1.3 blocking" topic to future meetings
We triaged issues starting at #1130 and ended by triaging #1202
<MarkMccarthy> [now breaking before regular 10amPST ARIA-WG call]
[New Issue Triage](https://bit.ly/3vTgj64)
Issue 1437 deemed to be editorial, action item added to issue
Issue 1436: Action may be to add name not applicable, notes added to issue
Matthew King: This change in 1435 might suggest the disability community "owns" the term disabled, but disabled is an adjective that covers thnings beyond people
MK: By adopting the "PWD" terminology a goal is remove the negative connotation of the "dis" in disability
MK: Has not seen a groundswell in the disabled community to own "disabled" and remove other uses
Greta: In the teaching community it is often deemed better to speak of ability rahter than disability, also this change is inline with the change away from the terms "Master/Slave"
James Craig: While we all agree with the change away from "master/slave" there is more disagreement around the mechanics of using disability
Greta: Yes, but this is a matter of perception, it is valid to perceive this use of "disabled" as not inclusive
Sarah Higley: There is a potential for causing harm if various groups in W3 don't change it universally
James: It would still live on in legacy cases, even if we deprecated it
MK: "Differently Abled" vs "People w/ Disabilities" is still unsettled in the community but "Differently Abled is often perceived as negative, while "Disability" is embedded with an effort to bring positivity to the term. This contrasts with Master/Slave which is less controversially perceived as negative
StefanS does not advocate for deprecation, but that we should be considering this in future naming
James Craig: agrees with MK that he has not heard the disability community request this category of change.
<pkra> I have to dropp off early, I'm afraid.
JamesNurthen suggests taking it up with chairs group
(missed who said) this should be a public conversation
Above was Sarah Higley
Greta: advocacy groups are sometimes run by sytems with their own bias or beholden to systems of bias, we should speak to people, not just orgs
James N will take to Judy, we need wider buy in.
<jcraig> s/foo bar/foo bop/
jamesn: issue 1433, answer seems to be no
ScottO: yeah we talked about that the other day, agree
jamesn: i think all the major browsers are doing the right things
sarah_higley: i don't think IE11 had great support anyway
jamesn: is anything missing in the spec? Can someone take a look to confirm?
melanie: i'd love to take a look at it
jamesn: should be a minor change if anything
[New PR Triage](https://bit.ly/31b4WrU)
jamesn: issue 91 is somethiing i filed against core-aam, alreeady working on it
[Meaty topic for next week](https://bit.ly/394l1Eb)
jamesn: do we want a deep dive next week? topic suggestions?
jamesn: there were some comments from slack, some new things that should be exposed related to data vis, may be a good route but needs the right people involved
jamesn: if no topic proposals, i propose no deep dive next week
melanie: +1
jamesn: sorted.
Matt_King: a general question, we talked about -owns related stuff last week. when are we coming back to it?
jamesn: myself and sarah_higley are working on some of it, and we've got someone else working on another. once we get some place with those, then we'll have another
sarah_higley: i'm hoping to work on that soon, but might not be finished in time for next week
jamesn: yeah, we'll wait until a PR is ready, no pressure
[Security and Privacy Section](https://raw.githack.com/w3c/aria/jnurthen/issue1371/index.html#privacy-and-security-considerations)
jamesn: we had a meeting with the privacy group earlier in the week and they'd like us to add privacy considerations to 1.2 - which should be fairly simple
jamesn: we worked on drafting up something but needs some language tweaks, grammar and simplification
<jamesn> In accordance with TAG Designs Principles, this specification provides no programatic interface to determine if that information is being used by Assistive Technologies. However, it is possible to present information which is different for users of Assistive Technologies from the information seen by users who do not use Assistive Technologies. This is possible using many features of the ARIA specification, as well as many other parts of the
<jamesn> web technology stack. This content disparity could be used as a fingerprinting method on users of Assistive Technologies.
jamesn: might also want to split into security considerations and privacy considerations [pasted above]
jcraig: i think fingerprinting is the wrong word in this case
Matt_King: does fingerprinting have a proper definition, technically speaking?
melanie: in web dev it does
Matt_King: right, and like in conversation it does, but is there a formal technical definition out there?
<joanie> https://
jcraig: i think the context here is that what this allows on its own is _not_ fingerprinting. _in combination_ with other things we could fingerprint, but not through these methods alone
jcraig: i'm also not even certain our spec does that. the DOM spec does, but is this language going into that too?
jamesn: we've no way of taking care of that with W3C since that's WHAT-WG
jcraig: if this is going into 1.2 as is before the tag issues are address, then this should go in every update henceforth
jamesn: i think CSS is using this liberally now in all new things
jcraig: this particular language?
jamesn: the fingerprinting bit
jcraig: good - but it needs to be more focused on assisitive tech since that's the area it's more likely to be used
joanie: i vaguely remember saying that CSS and other specs are way more problematic about this than our spec, but we've still been asked to do so
joanie: i agree with you 100% jcraig but we still gotta do it.
jcraig: i don't disagree about putting it in, but we should push to put it in with HTML/CSS. if they want to address it, that'd be a better place to start
jamesn: so one example where this might apply is putting a disingenuous aria-label on something, and using that to "Catch" a screen reader user becuase their label is different than a visible one
melanie: i propose "device fingerprinting methods" (can be linked to wikipedia - https://
melanie: we all know the entire web stack can be abused, and i think that this says what we mean to say, but adding the adjective would help
+1
melanie: from wikipedia - "A device fingerprint or machine fingerprint is information collected about the software and hardware of a remote computing device for the purpose of identification."
sarah_higley: software is one major way of fingerprinting a device
Matt_King: agree - the term itself is a little wonky, but this makes sense to me too
jamesn: i'll send to the mailing list and ask folks to look at it
jamesn: i think they're misunderstanding exactly how much of this is in the ARIA spec, but I wanted to make sure to get this in there
Matt_King: as an aside, it might be better to spell out TAG rather than an abbreviation
jcraig: one more suggestion - i think that this, as written, could also be applied to CSS. for HTML it should be much more strict
jamesn: yep
jamesn: i'll make those changes and try moving this forward - thanks all
jcraig: one more thing - it should reference the ongoing issue open with TAG.
jamesn: got it
[Suggested simplification](https://github.com/w3c/accname/issues/96)
jamesn: melanie, i wanted your take on this (accname issue 96).
jamesn: i wonder about your thoughts on getting this in 1.2
melanie: yes, i had the same thought. assign me
Matt_King: so a comment on that... right now a lot of people have anchors that say "reference step 2E" etc. in other places. If we do this, those break. Which might be okay. But it might be helpful to address that possibly happening
jamesn: that's the main complication with this
melanie: isn't TF Silver trying to get away from numbers? that should help with this
jamesn: sorted.
[Add role=image as synonym for role=img](https://github.com/w3c/aria/pull/1370)
jamesn: Scott you took an initial pass, were waiting on some changes. any updates?
ScottO: I'll let Matt_King and jcraig decide, since there was contradictory information
Matt_King: lol - i think we were waiting for this to come up on an agenda. i kind of forgot what the changes were
jcraig: me too, to both
Scott: I just wanted to make sure we had agreement on the changes that Matt suggested, which were the opposite of jcraig's points. If we can sort that out, I'm happy continuing.
Matt_King: was there an issue related to something with Chrome not supporting fallback?
jamesn: that was IE
Matt_King: oh okay, so if someone does provide fallback, then it should work?
jamesn: i think it's reasonable to have fallback specified in 1.3 and remove it in 1.4
jcraig: go for it
Matt_King: in practice, specifying a fallback seems... nonsensical from an authoring standpoint
Matt_King: basically i didn't want to _encourage_ that so as to not waste anyone's time
jamesn: decision time! vote for fallback role:
<jcraig> +0
<joanie> -1
<joanie> yes
jamesn: no votes for fallback roles? joanie votes against it
jamesn: okay, then no fallback roles, there we go!
<jcraig> ±1
[Spec is unclear on aria-invalid="spelling" | "grammar" uses](https://github.com/w3c/aria/issues/989)
jamesn: aaron's issue, let's try and make a decision. it seems like, from consensus, that well have a new attribute. two votes against aria-invalid back to global. no votes against creating a new global attribute.
jamesn: last chance to go against that decision
carmacleod: it's 3-2
Matt_King: i feel uncomfortable calling it the last chance, it feels more like a vote for a proposal
jamesn: of course!
jamesn: if someone makes the proposal, we should go with it
Matt_King: i want to see the full proposal and then be able to discuss that with AT vendors before fully deciding
carmacleod: this would involve so many specs
jamesn: yeah, but at least the AT might not have to