<joanie> agenda: this
<joanie> agenda: be done
zakim scribe: pkra
<scribe> scribe: pkra
joanie: too many conflicts. June
4 no meeting.
... and no deep dive meeting.
<joanie> https://github.com/w3c/core-aam/issues/73
jcraig: we had talked about it
recently.
... e.g., if it's a direct parent but not with more
nesting.
mcking: we were looking at group
of checkboxes in the aria-at work.
... tests were saying that AT would act as if it were a
fieldset.
... jcraig pointed out that it's unclear
joanie: is it really a core-aam issue?
mcking: would have to be contextual, so not just core-aam.
aaron: lot of things "group" on
Mac as generic container. But there's a subrole fieldset.
... then it was pointed out that trees etc wouldn't be a good
case.
... came from early days, Windows APIs.
mcking: I don't think it works
that way on Windows now.
... in any case, doesn't seem just core-aam.
aaron: maybe if it has a name comes in.
<joanie> https://github.com/w3c/aria/issues/1279
joanie: is this 1.3?
carmacleod: can wait for 1.3
<joanie> https://github.com/w3c/aria/issues/1277
joanie: is on the agenda for later.
<joanie> https://github.com/w3c/aria/issues/1275
scott: PR is ready.
joanie: is it 1.2?
scott: it's mostly
editorial.
... came from a11y slack. someone being confused about mixing
may and should, sounding like both are needed.
carmacleod: PR is already reviewed.
mcking: does it change formal language?
scott: not really, it clarifies
the wording.
... brought over from 1.1.
... alongside radio group
... there was a note to keep it consistent with other
guidance.
mcking: did we support groups in
menu item radios before 1.2?
... wondering why separator is there at all.
... it's not a grouping, is it?
carmacleod: it is visually.
joanie: we can squeeze it into 1.2
michaelc: respec maintainers made
some PRs to clean up some issues.
... most issues in the common repo
... or not just applicable to aria but all of them.
... so I converted them for us way.
... but they need to be merged in a synchronized manner so that
things don't break, esp. aria-commons.
mcking: is there one for practices?
michaelc: I think so.
mcking: how well timed does it need to be.
michaelc: not too close but within a few minutes.
<joanie> https://github.com/w3c/aria/pull/1280
carmacleod: it's actually pretty
harmless.
... pkra reviewed it.
pkra: it's at one location, pulled into many places.
joanie: can we split it?
carmacleod: not worth the trouble for 1.2 then.
joanie: cherry picking for
stable.
... might be hard.
<joanie> https://github.com/w3c/aria/pull/1276
joanie: mcking can I add you as
reviewer?
... then we're good.
joanie: for June 11.
<joanie> https://github.com/w3c/aria/issues?q=is%3Aopen+is%3Aissue+label%3Adeep-dive
joanie: which one do we pick for
next deep dive?
... should we combine replaced-text + notification ?
... aaron lead on this?
aaron: yes, first part should be
no-brainer.
... for notifications, maybe someone else has a stronger
opinions.
joanie: ==> June 11, deep dive: replaced text + notifications api
mcking: aria-at goals: create a
working definition of what "good" rendering of ARIA by AT
is.
... we build user interfaces with it. But we cannot count on it
(enough).
... as we know, there's a lot of subjectivity here.
... working to tie down some of it.
... we have created a first version of test runner,
harness
... working out gaps
... to get to v1
... goal is six patterns.
... in 2020, we want to cover a significant portion of APG
patterns and six browser/AT combinations.
joanie: is there a link?
mcking: yes - on w3.org
... not much to do yet if you're not signed in
... public version coming soon.
<joanie> https://w3c.github.io/aria-at/
<carmacleod> http://aria-at.w3.org/
mcking: http://aria-at.w3.org/
everyone: congrats!!!
mcking: this started way back
around 2011/12 at CSUN with discussions around "specs" for
screenreaders.
... it sounded crazy at the time but we are here now.
michaelc: can we do a screenshare with the group some time?
<Jemma> I can help with demo since I am one of testers
mcking: maybe middle of June? Then the tests are done and the runner will be cleaner.
<joanie> https://github.com/w3c/aria/issues/1277
carmacleod: colleague asked me
for help with a highly stylized menuitemradio
... special handling, spin buttons, open textfield to add more
info.
... after some back and forth, we wanted to make it work
... expanded seemed like a good idea.
... but radio doesn't support it. And it mostly makes
sense.
... but then AT sort of works, even nicely.
... then found that menuitemradio does support it.
... looking through old issues/PRs which removed it from a
bunch of roles.
... wasn't clear if it came up back then. Unclear if it's a
good idea or not.
... since some of it works in the wild and is helpful, it might
be worth it.
... gov.uk has a few examples.
... jnurthen responded on the PR
... I addressed them.
... it seems to work ok.
... but aria-expanded still ends up supported, inheriting from
menu item
... but no longer inheriting from input (which is good,
too)
... current status: https://github.com/w3c/aria/pull/1278#issuecomment-633794798
... what now?
jcraig: I've seen examples like that.
sina: do we talk about partially checked?
carmacleod: yes.
bryan: I've not seen a menu item radio with that.
jcraig: I've seen expansion like that, e.g., "how have you've heard about us" => other => text field
mcking: expanded was due to
inheritance and we didn't clean it up because we would need to
fix the hierarchy
... now you did :)
<jcraig> s/I've seen examples like that.I've seen examples like that. Not great usability, but I'm certain some exist. I also recall that example in ARIA editor discussions years ago. Not great usability, but I'm certain some exist. I also recall that example in ARIA editor discussions years ago. Not great usability, but I'm certain some exist. I also recall that example in ARIA editor discussions years ago./
mcking: this sounds like a good idea. getting rid of multiple inheritance is great.
thanks, james.
scribe: I've seen this pattern a
lot, too. It can add noise.
... the reveal example is understandable. But if you're
arrowing it will be always expanded and you will never hear
collapse.
sina: virtual cursor but is not enough
mcking: makes sense!
aaron: it could skip over. screenreader user might not need to know?
sina: but that can be dangerous.
aaron: I've seen them embedded in radio buttons
sina: just don't...
mcking: in the label of the radio?
aaron: yes.
... checkbox "keep email on server for (blank) days". They
would hear the whole thing
stop distracting me ;-)
joanie: maybe there's a use
case?
... radio button carnivore vs vegetarian as a general
preference, menu pops up. horrible but legitimate?
sina: but why expanded here? Why in partially checked context?
jcraig: represents the state of a submenu
sina: I get that. But we're not relating the two.
bryan: I can see this working but you'd have to allow submenus on menu item radio. Does it?
mcking: when you press enter, it would check and expand. you'd never see the checked state unless you come back later.
joanie: right. I don't
necessarily go back to see if I checked vegetarian.
... let's say an author does that, is there a screenreader that
won't say that it's submenu? Does it hurt us to continue to
support it?
jcraig: +1
<Zakim> joanie, you wanted to ask about menuitemradio
sina: harm seems minimal.
... not that it's a good ui...
jcraig: we can say "there's no good example for this, yet"
carmacleod: supported on menu item radio but not radio.
<jcraig> I'm not suggesting we add that as a spec or apg edit
mcking: that's good, it no longer inherits.
<jcraig> I meant we could say that amongst ourselves
carmacleod: double check: only radio is out.
mcking: +1
<jcraig> omnivore and vegetarian?
sina: there doesn't seem a need for it but ok.
mcking: overloading a single UI element with states the purpose becomes ambiguous to AT user.
carmacleod: it's down to the hierarchy stuff.
This is scribe.perl Revision of Date Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) FAILED: s/I've seen examples like that.I've seen examples like that. Not great usability, but I'm certain some exist. I also recall that example in ARIA editor discussions years ago.// Succeeded: s/I've seen examples like that./I've seen examples like that. Not great usability, but I'm certain some exist. I also recall that example in ARIA editor discussions years ago./ Succeeded: s/seen examples like that./seen examples like that. Not great usability, but I'm certain some exist. I also recall that example in ARIA editor discussions years ago./ Succeeded: s/reagent, make minutes// Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** FAILED: s/I've seen examples like that.I've seen examples like that. Not great usability, but I'm certain some exist. I also recall that example in ARIA editor discussions years ago. Not great usability, but I'm certain some exist. I also recall that example in ARIA editor discussions years ago. Not great usability, but I'm certain some exist. I also recall that example in ARIA editor discussions years ago.// Present: StefanS Joanmarie_Diggs Scott_O Greta Irfan pkra harris MarkMccarthy carmacleod Matt_King Jemma jcraig Found Scribe: pkra Inferring ScribeNick: pkra WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 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]