<jemma> scribe:Jemma
agenda 1
take up item 1
<MarkMcCarthy> scribe: MarkMcCarthy
<jemma> https://github.com/w3c/aria/issues/989
<jemma> aron:"The original intention of aria-invalid="grammar" or "spelling" is unclear from the ARIA spec, although clear from CORE-AAM. So the two are not really in sync."
<jemma> jamesn:it can be part of 1.3
<jemma> take up item 2
<jemma> https://github.com/w3c/aria/issues/988
<jemma> https://github.com/w3c/aria/issues/987
jamesn: 988, part of 1.3
<jemma> carmacleod:"Tooltip role should allow referencing by aria-labelledby"
carmacleod: thoughts on agreeing? happy to take it on
Jesse: it'd override any label on the button itself...
jamesn: yes
... so if you have an iconic button and you want the tooltip to
be the label, this would take care of that
Jesse: Right, okay
carmacleod: but you're right, the gudiance should mention something like "if there's a visible label, your tooltip should be aria-describedby" etc.
jamesn: to me it makes sense, any objections?
joanie: quick question, not an objection; if the author chooses to wait until the tooltip is displayed, it may not have a name
carmacleod: you're right, that needs wordsmithing
Jesse: some clarifying
questions...
... we're confused on what it means for a screen reader user...
what other way could we launch a tooltip?
carmacleod: I did open an issue
with APG, like toggletip (i'll find a link in a minute), and I
think this is what you're getting at
... i'll paste it in and please add comments!
jamesn: right, this is a little more of guidance rather than spec
<DorothyBass> specific to ____, if you use this_____, there is NO need to use this or use this.???
jamesn: assigned 1.2, to
carmacleod
... issue 986, i'd love some implementor feedback
<jemma> https://github.com/w3c/aria/issues/986
jamesn: we have some text in spec that states authors shouldn't change role of something
<carmacleod> APG Toggletip pattern feature request: https://github.com/w3c/aria-practices/issues/1014
jamesn: we don't know if this is
a problem with webkit etc., we probably need more
investigation
... if you set a role on something at page start, when is it ok
to change it later, if so?
... joanie, i'd be interested in your feedback
joanie: all sorts ofthings cause
gecko and chromium to recreate objects, can happen to focused
elements too
... screen readers already having to sort out how to find
replacement objects etc.
... that said, if this another case of that, screen readers can
probably deal with that
jamesn: leave this open for investigation, discuss next week? put on 1.2?
joanie: that's fair
jamesn: moving on
jamesn: not worrying about this PR, already on agenda
jamesn: another reminder for
TPAC, we have 3 weeks til early bird registration closes
... EB saves 250 euros on the week, hotel now bookable
Jesse: are there speaking discounts/passes etc?
jamesn: this is WG meetings,
everyone is speaking since we're working in meetings
... technically requirements to attend, if you need
justification to attend. look in the charter
Jesse: thanks!
MichaelC: there are breakout sessions on wednesday of the week
jamesn: you can't sign up for that in advance, done day of, similar to lightning talks
MichaelC: fairly good chance if you propose it, it'll be on the agenda. not a guarantee
Jesse: good info, thanks all!
<DorothyBass> links to this info?
jamesn: let me know if you need help
<jemma> https://www.w3.org/2019/09/TPAC/
DorothyBass: links for meetings etc.
jamesn: check above, at jemma's
link
... we have ARIA WG meetings on Mon and Tues, lots of other
groups too
<DorothyBass> thank you
jamesn: anything else?
jamesn: joanie, have anything you'd like?
<joanie> https://github.com/w3c/core-aam/issues/46
joanie: all the auth practices for new rules
melanierichards: i've been discussing internally, should have soon
<joanie> https://github.com/w3c/html-aam/issues/141
melanierichards: started a big discussion
joanie: need info for these
issues, core aam mappings are what we'd have for html aam
... i need everyone's input really, on issue 46. meaning
accessibility api platform owners
... and auth practices, but really just need the above
jamesn: for auth practices, i
haven't been able to get to it yet, working on it with
apologies
... meter is almost ready, rest should be fairly simple
jemma: i need to work on google examples, get that to james and APG
jamesn: mostly ready! just need to get in the right sections
jemma: okay, good!
jamesn: anything else?
jamesn: let me get the links
<jamesn> https://github.com/w3c/aria/pull/946
jamesn: melanierichards' PR, melanierichards are you updated?
melanierichards: what we
discussed last call were supported but not req attributes;
there are separate issues that some people felt should be
removed
... change i made is to remove supported attrs from auth error
handling
<jamesn> https://pr-preview.s3.amazonaws.com/w3c/aria/946/78b9178...melanierichards:484e344.html
jamesn: this is the diff link for
that change
... anyone need more time, or ready to go?
<melanierichards> there were some attributes that were supported but their implicit values were still in the fallback table for handling author errors. There was a separate issue about whether the name of the table should change or not to reflect that fact. People felt that actually the supported attributes should be removed from that table, so I made that removal
carmacleod: could do "we'll merge by monday if no comments"
jamesn: I agree
... we'll merge monday if no significant comments
... we'll do this for all three pending PRs
... (also for 945 and 944) since melanierichards believes we're
all set
<jemma> https://github.com/w3c/aria/pull/945
<jamesn> https://github.com/w3c/aria/pull/984
jamesn: next PR to review is
984
... we said we'd discuss this week, have people had a chance to
look?
carmacleod: yes, but complicated! use cases will be interesting
jamesn: i agree, indeed complicated.
<jamesn> https://pr-preview.s3.amazonaws.com/w3c/aria/984/aeb62bb...domenic:0cec33b.html
jamesn: only looking at main
changes since prev. approval; if this where browsers are
headed, no problem merging as is. we know no better
... joanie, there are some musts. we'll need some tests i
think
joanie: if they could provide the tests, that'd be helpful
carmacleod: that's a good idea
jamesn: we'll need to ask them
then, and change to RfC
... they're changing polyfills, updating other semantics.
joanie: the tests would only block putting in the working draft
jamesn: right. we could merge after RfC and make it editorial for now
carmacleod: dominic said "might not be worth reviewing in depth..." in PR, so maybe he doesn't need/want it merged yet?
jamesn: good question
<DorothyBass> agree with your reading
carmacleod: is there a way to label that?
jamesn: needs to be in spec
somewhere before changes can be made
... but yes, worth clarifying. i'll talk to dominic about
tests, if it should be, and clearing up normative language
MichaelC: for the record, there's a draft PR; maybe that's an option
jamesn: can't be retroactively applied
<jamesn> https://lists.w3.org/Archives/Public/public-aria/2019May/0002.html
jamesn: this is the first, accname logic tree doc for refactoring
bgaraventa1979 put this together, hoping to simplify some things. feedback?
bgaraventa1979: basically, during
f2f, we had a long discussion about accname and refactoring. a
couple goals were to simply what acname is and also to make it
simple to implement
... essentially, this helps identify the structure of accname
and achieve agreement on fundamental basic features
... so this outline should help make all this clear
... as far as i'm aware, there hasn't been much discussion
carmacleod: so, this correlates to your test feature, right?
bgaraventa1979: yes, and to what
we've discussed for 1.2 changes. it's missing a couple
things,like newer roles
... this represents 1.0, 1.1, some things in 1.2 we've
discussed esp. whitespace handling
carmacleod: it doesn't touch on aria-label or -labelledby deletions we're proposing?
bgaraventa1979: correct, but we
did discuss that. i don't think there was much time at the
f2f
... determination at that point was to let it be. say that
-label and -labelledby are supported, as long as no
conflicts
... it's complicated to explain
jamesn: can we have combo of "auth must not do X" but still have accname support it -if- they do, produce an author error but, if UA is conformant, it'll still produce something for interpretation even if not necessarily useful?
bgaraventa1979: say you have a
link, a font inside of that styling a span. currently, put
aria-label on it and it works
... if we say something like that is a violation, it'll limit
what people can do; testers will flag violations, devs might
not put anything anymore
jamesn: so we need to find real use cases
bgaraventa1979: gets tricky when spans are split up
jamesn: so do we need role=static
back?
... need to have something that's not a container, but defining
elements somehow
... we need to find a good way of solving use cases we come up
with before prohibiting aria-label
bgaraventa1979: important to note browsers already do things like this, because nothing in spec says otherwise
<DorothyBass> Recommend Native HTML and CSS markup: ??? Not Recommended Alternative option: ???
bgaraventa1979: could widely break things
joanie: i thought i added that support, where spans have aria-label, etc., for the sole purpose of getting some of your test cases for AccName 1.1 passing
bgaraventa1979: accname doesn't
call out specific roles; to do that we'd need to add an index
of dis/allowed roles
... that's fine if necessary, but simply, difficult
jamesn: sounds like a hard place; people saying they won't support generic unelss we prohibit labelling (or paragraph, similar roles)
carmacleod: i've said things like
that, kind of going back and forth in my head
... but there are things where funny fonts might benefit from
aria-label vs being turned into an image
jamesn: what if we have some
"must" statements, but accname takes allowances into
account
... so these are author validation errors
... might solve some of the problems bgaraventa1979 is worried
about.
... so validators could fail a page but browsers still work
carmacleod: maybe. might be able
to add more info for validators
... might be challenging, but maybe some little rules we can
come up with. there are sometimes other workarounds too
... we should try harder to make accname more comprehensive
bgaraventa1979: [laughs] or complicated
jamesn: joanie? as an implementor?
joanie: i'll wait for consensus and then do my best
jamesn: this also got into 2nd
topic of indepth discussions
... all, ideas for resolution?
bgaraventa1979: simplest i can think of is leave these as global
jamesn: right, but with no restrictions on use
<DorothyBass> yuck
carmacleod: we can make it clear in Labeling and Describing document at ARIA APG that things are goofy
bgaraventa1979: that is something
we might be able to do
... if it has no accessible content, it'd fallback to
aria-label if present... that might be something we could
do
... not talking about overriding paragraphs etc.
... difficulty comes in mapping addtl roles
jongund: couldn't we have something like "not allowed"?
jamesn: yeah, that's what my PR has
<jemma> "prohibited"
bgaraventa1979: i'm talking about divs and spans
jamesn: important to consider not overriding expectations, but for generic, we might be
<DorothyBass> to be used as a supplement, NOT a replacement for
jamesn: so we've got a lot out there, please add comments to issues and PRs, as well as bgaraventa1979's email thread
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/eright/right/ Succeeded: s/... we/jamesn: we/ Succeeded: s/hsouldn't/shouldn't/ Succeeded: s/anohter/another/ Succeeded: s/ifthis/if this/ Succeeded: s/all1/all!/ Succeeded: s/could test/could provide the tests/ Succeeded: s/inside a font/a font inside of that/ Succeeded: s/... could/bgaraventa1979: could/ Succeeded: s/some support like that, based on old discussions/that support, where spans have aria-label, etc., for the sole purpose of getting some of your test cases for AccName 1.1 passing/ Succeeded: s/ideas/all, ideas/ Succeeded: s/in APG/in Labeling and Describing document at ARIA APG/ Present: MichaelC jemma melanierichards MarkMcCarthy carmacleod harris Joanmarie_Diggs jongund Bryan_Garaventa Regrets: PeterKrautzberger CurtBellew ScottOHara IrfanAli StefanSchnabel Found Scribe: Jemma Inferring ScribeNick: jemma Found Scribe: MarkMcCarthy Inferring ScribeNick: MarkMcCarthy Scribes: Jemma, MarkMcCarthy ScribeNicks: jemma, MarkMcCarthy Found Date: 30 May 2019 People with action items: 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]