<scribe> scribe: harris
https://github.com/w3c/aria/issues/1318
jamesn: jcraig can you clarify this one?
<jamesn> https://github.com/w3c/aria/pull/984
jamesn: when I last looked, we had a work in progress label on it. but now it seems like its being waited on
jcraig: I've got a couple similar
ones in 1.3 assigned to me but I haven't looked in a
while
... are we blocked for 1.2 on this?
jamesn: is this something that can go to 1.3 (984 PR)?
jcraig: I can't imagine that an editors note is a blocker. carol do you think this is a blocker?
jamesn: to me it depends on if 984 is a 1.2 or 1.3 milestone ticket
https://github.com/w3c/accname/issues/91
Scott_O: technology is rad!
<Scott_O> so glad that made it in
jamesn: we were going to put all accName things as 1.2 is that ok?
https://github.com/w3c/aria/issues/1316
jamesn: I dont know what to do
with this but I think this a 1.3 thing
... I'd still like some comments on this one
jcraig: translatable is effectively "its ok to auto translate" which doesn't seem realistic for either of the braille attributes
jamesn: we should put a note and separate some of these out
jcraig: maybe we should change it to "auto translatable"
jamesn: we're following html on this though
https://github.com/w3c/aria/pull/1315
jamesn: we talked about this last week and we're still waiting on review
bryan: I'd like to discuss the trim one
Matt_King: do we need a full deep
dive for https://github.com/w3c/aria/issues/559?
... I wonder if we should 'frame' this as a group. Decide what
areas need to be explored etc
jamesn: I agree, its not ready
for deep dive quite yet
... bryan do you think the whitespace one is ready for deep
dive next week?
Bryan: yea sounds good
jamesn: whitespace it is!
joanie: I am starting to write
tests...basically just getting everything ready for CR
... anything that maybe we're not going to get an
implementation for, we should mark @risk
jamesn: we can come to the group next week (or earlier) for a call for consensus
joanie: getting everyone on the same page on spin button is something we've got to figure out
Matt_King: something like that,
moving to 1.3 doesn't seem like a big deal
... I think APG guidance assumed that this (spin button) was a
done deal
jamesn: is this something we want to consider? or is aria-busy sufficient?
Scott_O: I don't think this is needed
Matt_King: I agree, a role does not help here
sarah_higly: I agree
Scott_O: I can reply on the ticket
jamesn: is there anything we need
to do about this? change core-aam?
... is this 1.3? or 1.2?
joanie: if we have implementations, I don't see why we can't do it now
jcraig: I don't think any change would be necessary for webkit
Matt_King: they are currently
getting exposed as buttons
... I looked at all the menu examples in APG and it is not just
in the menubar that they are showing up as buttons
... Regardless of context, if the menuitem has the haspopup
attribute, they are getting exposed as a button
<jamesn> https://github.com/w3c/core-aam/issues/80#issuecomment-677856849
Matt_King: it is just inconsistent with the way the OS menus are
jamesn: this is just going to be dealt with in the 1.3 timeframe if anything else is needed
jcraig: if we have to test this in 1.2 it might make sense to move it there
jamesn: it seems like the chrome
implementation has been pushed
... Im taking the agenda off of this
jamesn: carolyn isn't here so let's punt this to next week
jamesn: this is the PR that
jcraig has agreed to look at
... we're going to take a look at decide if it is a 1.2 or
1.3
jcraig: I will assign the 1.3
milestone to it
... I will make a single idl branch to put this stuff
together
... unless anyone wants it to be more granular
https://github.com/w3c/aria/issues/689
jamesn: is this something we're going to get in the 1.3 timeframe
jcraig: if we're ok with tokens before the text field, then this is effectively a button. It's definitely confusing to do this on the web
jamesn: I don't see how we can do this in 1.3
Matt_King: we have that pill thing in APG and it can be done properly on the web. But if it shows up in the text field that is different
jcraig: it is challenging because historically inputs have limited the content to text only. It can't have child nodes
Matt_King: if you do content editable, and the content has a link, in some implementations I can hear with my screen reader that I'm going in and out of a link
jcraig: on mac, we'll have an "attributed string", string ranges with properties (link, bold, etc)
Matt_King: but core-aam doesn't have anything to do with that though, right?
jcraig: yes
Scott_O: is this an issue that would benefit from working with the open ui folks?
jamesn: that is a good suggestion
sarah_higley: is this at all related to aria annotations?
jcraig: this is more like an
object inside of text field and the other one is a range that
is pointed at outside the text field
... annotations is about associating the 2
... this is a more granular finite control in the UI
Matt_King: I'm concerned about adding a role here. When you have a token its not always going to be the same role. If you have a token role, how does that provide any useful information to the assistive technology user. It seems it should always be a button, or a link, or if its selectable thing maybe represented as a checkbox. Are tokens never not interactable
jcraig: The benefit is that role
descriptions will tell the AT user "this is what to
expect"
... for tokens, you can't do a subedit so you interact with the
range as a whole
... sometimes these mean "delete". If you press it, you'll
remove it from the list
jamesn: I've moved this to 1.4
and a open ui flag on it
... it'd be nice to have an APG example for this
<jcraig> /me I have to drop. thanks all.
https://github.com/w3c/aria/issues/704
jamesn: we changed this, right?
what does the scrollbar spec say in editors draft?
... aria-valuenow is required
Matt_King: we changed it to required
jamesn: Since its required now, do we need to worry about this? I say no
https://github.com/w3c/aria/issues/721
Matt_King: we might want to close
this. This was related to collapsable listboxes (before we
changed comboboxes)
... I think this is overcome by events now that we have the
revised combobox in 1.2
https://github.com/w3c/aria/issues/723
https://github.com/w3c/aria/issues/730
jamesn: are we ever going to do this?
Matt_King: does anybody make a web-based keyboard
Sina: it is impossible on the web
right now
... do we agree that an aria passthrough shouldn't exist?
Scott_O: this seems like something that is currently blocked by AOM
jamesn: is there an issue for that somewhere?
Sina: this is not 1.3, right?
jamesn: yes, not 1.3
Matt_King: we don't think we want a "key" role. If we are going to solve this problem we would solve it in another way
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) Succeeded: s/which doesn't seem realistic/which doesn't seem realistic for either of the braille attributes/ Default Present: StefanS_, harris, Joanmarie_Diggs, jamesn, CurtBellew, sarah_higley, Matt_King, Scott_O Present: StefanS_ harris Joanmarie_Diggs jamesn CurtBellew sarah_higley Matt_King Scott_O Found Scribe: harris Inferring ScribeNick: harris WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth 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]