<jamesn> https://www.irccloud.com/pastebin/8sUwKSwo/
<pkra> jamesn can we put https://github.com/w3c/aria/pull/1097 on the agenda? Just to let people know it's ready?
<pkra> :)
<scribe> scribe: MarkMccarthy
jamesn: the above link isn't
correct, let me get a new one
... here is a better one (below)
jamesn: seven issues on there,
let's start from the top
... 1139; straw poll, do we think error messages should be
assertive or polite?
jongund: polite, because they might interrupt someone going through a form field for instance
aaronlev: it makes sense when there's an error to speak it like description, so if you move away you should be on to something new
jamesn: but sometimes they only appear when you tab away
aaronlev: true
jamesn: there's a use case here, but something to think about it. let's tack it on to a future agenda, 1.3 milestone
aaronlev: one of the things on that agenda might be working w/ AT vendors on this
jamesn: true
aaronlev: on assertive vs. polite
jamesn: 1138, aria-rowindex; it does seem a bit imprecise. anyone volunteer to look at it, pref. someone who knows -rowindex and -colindex. ...aaronlev...?
aaronlev: preferably not [laughs]
jamesn: don't need a PR on it, just some comments, thoughts on a resolution
aaronlev: yeah, i can do that.
jamesn: 58, -hidden=false issues;
seems like it's something that's unclear. aaronlev has been
putting in comments (with which i generally agree). spec should
be crystal clear on intention and its not
... i don't have the right answer right now, adding 1.3
milestone. if anyone can take a look go ahead
carmacleod: what use case do you have aaronlev? a different way to do skip links maybe? can't think of one
jamesn: can't think of any now
either, might be something to look at
... ultimately, spec isn't clear
Scott_O: i went down the rabbithole on the bugzilla thread. seemed at the end of it that it didn't do anything, but based on the spec now, i can see some reasons why
jamesn: clearly unclear
[chuckle]
... aaronlev objections to changing it?
aaronlev: now that edge is based
on chrome, one example might be if you have a -describedby,
they do what we'd normally expect with -details (i THINK)
... and there might be hidden descriptions.
... another might be a screenreader hack, text only for screen
readers
jamesn: that might be what they
intended to allow, but it's not a good use today
... don't think it applies on descriptions, ultimately
... scott, sounds like you have some good ideas. would you be
able to give thoughts on a proposal on where to go?
Scott_O: yeah, i can do that
aaronlev: we should see what webkit does.
Scott_O: i'll check into that especially
jamesn: 1132, -roledescription
shouldn't be global; not sure what to do about this. sounds
like folks are misusing something
... open for comments, don't see a concrete proposal from Bryan
or anything. if he wants to come up with something, great! but
no easy way of encompassing this
BGaraventa: i don't see an easy fix either; part of it is problems with the name itself. people see roledescription and think it describes a role...
Stefan: better name is role *alias* or something
aaronlev: propose we disallow it on a generic element/something with no role
mck: we already have that
BGaraventa: i can see people putting it on form fields
Stefan: they describe how to use
the role with roledescription, which should be avoided
... spec seems quite clear, maybe APG can be enhanced w/ better
examples
jamesn: mck, it wasn't allowed on generics in 1.1 - it needed implicit or semantic roles. but now it IS allowed
mck: ohh then yes we should change that. wasn't the intention
jamesn: do like -label and -labelledby and list explicit roles it's not allowed on
mck: if our intention was not to change things, then this was an oversight
jamesn: dunno if we can do 1.2 on that but maybe
mck: i think we have to.
otherwise we're unintentionally changing -roledescription
... and I hate the name
jamesn: can't change that right now in 1.2 [laughs]
mck: maybe longer term make a synonym and deprecate the other
jamesn: yes, but indeed long
term
... and we could check out formal process for that
... MichaelC? for something we need to fix in 1.2 before
finalizing?
MichaelC: we just entered wide review, we can't not make changes, but if it'd change people's understanding we'll want to call it out
jamesn: ok. i'll mark this as 1.2 then. can someone change the title of the issue to better reflect this discussion?
BGaraventa: should be a new
issue
... my question though, if -roledescription is global, why
can't it be used on a form field? and i don't have an answer
for that
jamesn: it can
... but it's screwy because each screen reader announces things
a bit different
<pkra> Do we have data on how wide spread this is? It seems more an communication/educational issue.
mck: BGaraventa would it be helpful for us to prioritize for us to include guidance on -roledescription?
BGaraventa: we probably have to
mck: ok
jamesn: i'd love to put prohibitive things in spec, like authors must not, but we can't
mck: i thought we had some of those
MichaelC: we intended to clean
them out, but i'd have to check
... should be "validators must"
... we don't mean to have "authors must"
... also some that don't mean formal "must"
mck: we do have strong "authors should", and "unless" kind of things
aaronlev: screen readers should speak name-role before the role instead of the -roledescription
<pkra> a replacement.
mck: bbut that's the whole point, and why i hated the name
aaronlev: just brainstorming on it a little
jamesn: my gut feel is that i'm okay with -roledescription being a supplemental name for widgets, replace for non-widgets
mck: if we're gonna have it, it should do what was intended otherwise get rid of it
jamesn: can someone log a new issue for this?
<pkra> would it make sense to ask AT to provide UI to get the original role?
<pkra> instead of spec.
Scott_O: i'm on it right now
jamesn/mck: thanks
<pkra> my mic seems broken.
<pkra> this just came from last meeting.
jamesn: 1131, -roledescription shouldn't duplicate; that's very related to our previous discussion. maybe just some text to put in
<pkra> thanks you :) I'll try to reconnect to webex.
jamesn: okay, let's put this on
1.3, doesn't seem like 1.2
... 1130, non-focusable descendents; is this a 1.3 issue?
... well yeah, this definitely is.
... 1128, unclear -valuemin, etc.;
mck: this is 1.3
jamesn: yep
jamesn: so 1.2 is published! woohoo, thanks MichaelC !
mck: awesome!
<carmacleod> thanks +1
mck: quick question on timelines - what was the wide review length of time and predicted time for CR?
MichaelC: normally a month, not counting holiday time. from a testing perspective, CR should be a minimal length as I think it's all in palce
<Jemma> https://www.w3.org/TR/wai-aria-practices-1.2/
MichaelC: the hold up is that
when we enter CR we trigger a new 60 day window for patent
commitment, and we can't rec until that's over
... basically, looking at end of March is the soonest it can be
published
mck: we can be in PR by March 10 right?
jamesn: yep! which is good
enough
... we've done this
<Jemma> https://www.w3.org/TR/wai-aria-1.2/
jamesn: Scott_O is looking at
this
... we have a PR on this. i'm not thrilled to change all of
these, i'd rather that other spec should do things a bit
differently.
MichaelC: this is a PR to remove "may"?
jamesn: yes, when it's not in a normative sense
MichaelC: this came up in WCAG too. it's hard to avoid common English words. may consider instead a statement in conformance section that, unless emphasized, it's not "normative"
jamesn: it does!
MichaelC: i'd rather say we leave that in and people need to be sure to read the spec and take responsibility for it
Scott_O: having put together the PR, i'm not too concerned. but can't speak for the requestor
mck: this came from Simon?
jamesn: yeah
<Jemma> https://github.com/w3c/aria/pull/1127
jamesn: because WHAT-WG is a bit different
Scott_O: but they don't follow it to a T
MichaelC: i don't think it does much harm, but this'll keep coming up.
mck: most of the time "can" can
be used instead; a caveat of all this is screen reader users
can't discern between all caps and not
... might be possible to make a sound scheme for reading specs,
but that's a lot
MichaelC: we can certainly look
into ways to make it more accessible
... it's not the formatting that's always confusing
though...
jamesn: right - transitioning to something with no formatting for normativity to something that *does*
mck: yeah context switching can be difficult
jamesn: if folks want to do a PR, and we think it's editorial, i'm pretty happy to accept it
carmacleod: everything to me didn't seem too awkward, other than what was already fixed
jamesn: so only if something changing from non-normative do we need to discuss
carmacleod: that's not the case
jamesn: i'll probably accept it,
but put it in 1.3 branch
... these are what aaronlev is here for, lots of things on
annotations
<jamesn> https://github.com/w3c/aria/pull/1137
jamesn: PR is above
... aaronlev? i just want a brief overview so folks can review
them before our next meeting (ideally)
aaronlev: so -description is the
equivalent of -label, as related to -labelledby
... we didn't have it much before because we thought a long
description should be same as what's provided for sighted
users, but had lots of hacky use, so we added this
<jamesn> https://github.com/w3c/aria/pull/1136
aaronlev: aria-details updates - when it points to a description or annotation, it can be more general; it also now allows more IDREFs
<jamesn> https://github.com/w3c/aria/pull/1135
aaronlev: comment role - has a feature that you can have hierarchy and structure
<jamesn> https://github.com/w3c/aria/pull/1134
aaronlev: suggestion role - can pair with insertion and deletion to say it's not yet accepted
<jamesn> https://github.com/w3c/aria/pull/1133
aaronlev: mark role - same as HTML mark element
mck: you were talking about not having a role for revision?
aaronlev: basically it seemed redundant
mck: so is a suggestion ever not an insertion?
aaronlev: if you're adding something and not removing something
mck: is it ever not a revision?
aaronlev: well it's always revising the document
mck: okay, i think it get it. so a suggestion is paired w/ a comment or something usually
<pkra> We can tell people getting role-description wrong that they're looking for aria-description.
aaronlev: right.
<Jemma> https://pr-preview.s3.amazonaws.com/w3c/aria/1134/f519fca...74ddc01.html#suggestion
mck: then is someone accepts a suggestion, author removes that role?
<pkra> "When a suggestion is accepted, the suggestion role should be removed."
aaronlev: PR says what to do in that case [above]
jamesn: thanks aaronlev!
<Jemma> " suggestion (role)
<Jemma> A suggestion contains a proposed change to content that can be approved or rejected. For example, in an editing system that supports multiple authors, one author may suggest a change, and another author would be responsible for accepting or rejecting the suggestion. The suggested change must be present as child content, as an insertion, a deletion, or one of each.
<Jemma> When a suggestion is accepted, the suggestion role should be removed. "
<carmacleod> thanks, aaron!
jamesn: can people take the break to review and hopefully merge to 1.3?
aaronlev: that sounds
great.
... they're pretty manageable, i tried to keep them light
... these are in chrome behind a flag, except for the change to
-details
jamesn: if you have any use cases, that might help reviewing
aaronlev: okay, yeah i can probably provide something
jamesn: if you could, post it to the list
aaronlev: cool. and the google docs team is working on adding this to an experimental build, as is Vispero working on it
jongund: the goal for screen readers is to provide a way to navigate to what they point to?
aaronlev: for aria-details,
yes
... i have an explainer i can point people to
jamesn: half serious, maybe
-details could take over -controls in some circumstances
... might be some overlap depending on how AT vendors implement
-details, which could be really useful
<aaronlev> Here's a link to the explainer, I need to update it to remove revision, but otherwise it's correct:
<aaronlev> https://github.com/aleventhal/aria-annotations
mck: maybe...
aaronlev: maybe you read my mind a little
jamesn: can you add links to the PRs to that explainer?
mck: or the other way around, in the PRs
aaronlev: sure
jamesn: no meetings for the next 2 weeks
MarkMccarthy: scribe note - items 6-10 were discussed under item 6
pkra: braille-roledescription is my topic, i've made two more commits
<jongund> happy holidays, I have to go
<Jemma> "rephrase opening line - #924 (comment)
<Jemma> Braille/braille capitalization - #924 (comment)
<Jemma> suffice => overly verbose - #924 (comment)
<Jemma> two examples show => example shows - #924 (comment)"
pkra: i removed some troubling
sentences, some items that burdened user agents
... jemma provided most of them above
... i think this should be ready to go, if everyone agrees
jamesn: i'm happy to merge, but i'd like to hold off until after holidays
pkra: absolutely
jamesn: so this can probably be
added in 1.3
... -annotations might be closest to ready
pkra: and i'll start thinking
about -description
... yay!
mck: i'm not sure about -description, because it seems that it'll be the same for braille users as everyone else
pkra: i agree, just thought i should think about it
jamesn: awesome awesome - if
folks can get that reviewed, we'll merge if no negative
comments
... thanks EVERYONE for the hard work this year. we've got 1.2
almost out, and can hopefully get that wrapped up early in the
new year. 1.3 coming soon!
<pkra> hear hear
Jemma: thank YOU jamesn for all your work as chair!
MarkMccarthy: thanks everyone!
<pkra> happy holidays!
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/apg/APG/ Succeeded: s/sttement/statement/ Succeeded: s/6-11/6-10/ Succeeded: s/6. Add aria-description 📕/agendum 6, Add aria-description 📕/ Succeeded: s/6. Add aria-description 📕/agendum 6. Add aria-description 📕/ Succeeded: s/3. 1.2 Published 🎉/agendum 3. 1.2 Published 🎉/ Present: pkra Jemma MarkMccarthy jamesn jongund Stefan Scott_O carmacleod Bryan_Garaventa Found Scribe: MarkMccarthy Inferring ScribeNick: MarkMccarthy Found Date: 19 Dec 2019 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]