Meeting minutes
Should aria-rowindex/colindex really set the position? https://
jamesn: 1.4?
no disagreement.
New ARIA attribute for possible interactions like delete, edit, move https://
StefanS: 2 examples. tokenizer like a tool list from Microsoft and "taps that can be deleted" from personalization
StefanS: I could assemble a list
jcraig: relate to the Actions issue #762...
jamesn: same milestone too
no new PRs
1.2 Status
jamesn: we have a TAG review
we have an issue from the PrivacyWG #1371
working on Sec and i18n reviews
should be able to move forward to CR
one remaining issue #1100, could mark as at-risk
and pull it out before CR if not resolved
<carmacleod> https://
i18n tracker is #1365
rechartering
jamesn: prior deep dive meeting: moving ARIA spec to evergreen aka "ever-teal" (scribe: 🙄)
jamesn: need aria 1.2 in CR first, before starting the recharter that would be needed for ever-tealing
Matt_King: I don't see a need to rush the recharter... to what benefit?
jamesn: process could allow CR to snapshot versions. or you could have a permanent PR that has versions pushed to it...
I want this for the 1.3 timeline, hence the earlier recharter
Matt_King: possible to complete recharter ahead of 1.3 timeline?
jamesn: maybe, but realistically by Oct
any restriction of switching 1.3 to ever-teal with a recharter?
MichaelC: should switch when WG charter switches, so nothing to worry about re: precendent
Matt_King: jamesn your proposal seems reasonable
jamesn: we only push to stable when stable with 2 implementations anyway
discussion of green / teal / blue
pkra: WebAIM discussion about trees?
summary of WebAIM thread re: frustration with trees (not being native controls?)
msumner: any process on starting on 1.3 issues?
jamesn: just start on it... and thank you
carmacleod_: take assignment to avoid risk of duplicated effort
Reminder: Accname feedback needed<https://lists.w3.org/Archives/Public/public-aria/2021Jan/0052.html >
jamesn: no responses to Bryan's thread re AccName... please everyone look again?
or would people prefer a GitHub issue?
<jamesn> https://
+1 for GH issue
<msumner> another +1 for GitHub issue
Action: jamesn to post ACCNAME discussion thread as a github issue
Updated aria-setsize and aria-posinset to clarify usage for authors<https://github.com/w3c/aria/pull/1332 >
msumner: I will follow up
Spec is unclear on aria-invalid="spelling" | "grammar" uses<https://github.com/w3c/aria/issues/989 >
<Jemma> nick/jemma
jamesn: newest change conflicts with use of spelling/grammar
Matt_King:
Matt_King: maybe, or is aria-invalid the incorrect choice for those
carmacleod_: aria-proofing?
Matt_King: need to review our research on document annotations
added comment role
jamesn: is a spelling error an "annotation"?
jcraig: it's a substring associated with (call it "attribution", "annotation" whatever) some indicator, whether comment, warning, error, etc.
Matt_King: haven't seen any uses in the wild
<Jemma> https://
jamesn: aaron implemented in chrome and its supported in JAWS 2020
<jamesn> sounds like folks agree with jaws-test https://
joanie: web engines have built-in spell-check, they expose that platform API attribute in the way that the SRs expect.
has a start/end substring marker
the aria spelling indicator could be exposed as a text attr, or as an object attribute
<jamesn> https://
joanie: considering giant text aria... only a substring is invalid or misspelled, not the whole element (object)
jamesn: to move forward… we've deprecated in 1.2. we need to replace this usage or allow it again. how to proceed?
Matt_King: did we deprecate the other values, like grammar?
jamesn: No
Matt_King: should this be about text instead of invalid, which is specific to elements?
msumner: was aria-invalid specific to give feedback on form input?
If so, we should come up with something different
Matt_King: it was originally a global
msumner: could resolve with AAM instruction to implementors
<jamesn> old issue - https://
<jamesn> https://
Matt_King: could have only some values as global...
jcraig: that might be a complicated spec change.
jamesn: is the consensus to make this global again?
msumner: I may have been convinced of the opposite
(discussion of example edge cases)
Matt_King: user never has to know that spelling and grammar are communicated through aria-invalid... They will just perceive it as they would with native AT usage
so they wouldn't hear "invalid" for example
<msumner> I think we should get implementor feedback
jamesn: will someone take ownership and make a proposal?
carmacleod_: I am a hero (scribe embellished)
Follow-up: tree inclusion of focusable elements from #1100<https://github.com/w3c/aria/issues/1381 >
<Jemma> https://
<CurtBellew> I'm having computer issues. I'm dropping off. See you all next time
jcraig: if something is focusable but aria-hidden, it doesn't have to be included in the accessibility tree
mck: if it is included in the tree on focus, does it stay in the tree after blur?
<msumner> we need inert to be a real thing and not a polyfill
totally agree msumner
it's really close :)
jcraig: this is more of a stopgap until inert is fully implemented
jcraig: so we can use "while focused" instead of "if focused"
jamesn: we have to fix this before CR
jamesn: we should ping Aaron and James Teh