16:17:16 <API> #startmeeting
16:17:16 <tota11y> Meeting started Thu Jan  3 16:17:16 2013 CET.  The chair is API. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:17:16 <tota11y> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:17:25 <API> #topic W3c update
16:17:41 <API> clown, your turn
16:18:16 <clown> #info the first public working draft of the IndieUI spec will be published sometime in January.
16:18:53 <clown> #info there is a chance it will be published by end of next week, but various people want to read the latest editor's draft before giving consent.
16:19:03 <clown> #info editor's draft is here:  http://dvcs.w3.org/hg/IndieUI/raw-file/tip/src/indie-ui-events.html
16:19:19 <clown> any questions about that?
16:20:03 * joanie pulls it up
16:20:16 <API> well, probably in order to make questions we should read all that stuff
16:20:26 * joanie nods
16:20:31 * clown has yet to read it, himself...
16:20:31 <joanie> so a meta question
16:20:32 <API> and probably here and now is not the place and moment
16:20:47 <joanie> if, having read it, we have questions or feedback
16:20:49 <clown> well, my "questions" was any questions about those info's?
16:20:58 <joanie> should we send them to the indie ui list?
16:21:04 <joanie> or is this more or less an fyi
16:21:16 <joanie> and pending final review of the work committee, this is getting published
16:21:17 <joanie> period
16:21:18 <joanie> ?
16:21:31 <clown> you could send them to the indie ui list, since it is a public list.
16:21:55 <clown> hmmm…  might be worthwhile describing the W3C process.
16:22:25 <clown> first, there are editor's drafts — changes due to meetings of the working group.
16:23:08 <clown> then there are public drafts, which are more "fixed", but still open to lots of modifications.  They are intended to get feedback from the larger community.
16:23:17 <clown> there can be a sequence of public drafts.
16:23:52 <clown> The next step is the "last call draft", where active solicitation of comments from the world at large is sought.
16:24:35 <joanie> about how long (in terms of drafts or months) is it between the first public draft and the last call draft?
16:24:36 <clown> after all comments on the LCD have been addressed, the spec moves to CR track (Candidate Recommendation).
16:25:01 <clown> joanie, I'll try to answer that in a bit.
16:25:24 <clown> During CR, one must show that at least two browsers implement the spec as stated.
16:25:43 <clown> If so, the CR is moved to Recommendation, and become release 1.0
16:26:19 <clown> in terms of first public draft and last call draft, the only spec I have personal experience with is the aria spec.
16:27:26 <clown> the first public draft was circa 2006.  The first LC draft was early 2009.  The second LC draft  was fall 2009, and we began the CR track in early 2010 (and are still there).
16:27:31 <clown> (done).
16:27:42 <joanie> thanks
16:27:49 <joanie> I have additional questions
16:28:07 <joanie> does two browsers mean two browsers or two web rendering engines?
16:28:25 <joanie> i.e. if there's firefox and another gecko-based browser, is that 2?
16:28:31 <clown> yes, it's better to say two web rendering engines.
16:28:36 <joanie> k
16:28:47 <joanie> and two per platform or .... ?
16:28:51 <clown> so, webkit and gecko.  or webkit and IE
16:29:22 <clown> not sure what you mean by platform.
16:29:32 <joanie> windows, mac, linux
16:29:42 <joanie> i.e. if it's in gecko and ie for windows
16:29:49 <joanie> and nowhere on the mac or linux
16:29:56 <joanie> do you have your two?
16:30:55 <clown> this partially answers your question:  I've been testing aria in FF (gecko) on linux/at-spi.  IBM has been testing FF on windows/IA2.  Some have complained that doesn't count as two separate implemenations.  More like 1.5 implementations.
16:31:30 <clown> but, yes, it it's in gecko and ie for windows, that would suffice for the W3C.
16:31:39 <joanie> ok
16:31:40 <joanie> thanks
16:31:44 <clown> welcome
16:32:22 <API> ok, so anything else in this point ?
16:32:42 <clown> only other thing I have is more of a question about toggle buttons.
16:32:49 <clown> and aria question.
16:32:55 <clown> "an" aria question.
16:33:38 <API> clown, shot
16:33:43 <clown> currently you specifiy that an html element is a toggle button using the aria-pressed attribute.
16:34:17 <clown> e.g.  <span role="button" aria-pressed='false'>  is mapped to a toggle button in the a11y api (e.g., AT-SPI).
16:34:36 <clown> that particular toggle button is not pressed (or not toggled).
16:35:37 <clown> the user agent implementation guide says (1) that this should be exposed with ROLE_TOGGLE_BUTTON, (2) with STATE_TOGGLED (if it is toggled), and (3) object attribute checkable:true.
16:35:54 <clown> It's the (3) that some people are complaining about.
16:36:09 <joanie> API recently did this implementation in WebKit
16:36:19 <clown> pardon me, "STATE_PRESSED".
16:36:32 <clown> with respect to (2)
16:36:43 <clown> API?
16:36:53 <API> clown, well about 3
16:37:17 <API> on atk/at-spi we don't have the state checkable
16:37:32 <joanie> and a toggle button is not checkable
16:37:36 <API> people complaining are sying that we should have that state?
16:37:45 <joanie> API that's probably why it's an object attribute
16:37:52 <API> and joanie comment is also true
16:37:53 <clown> right, which is why the UAIG says to put it in as an *object attribute*
16:37:59 <joanie> but it's a silly object attribute
16:38:14 <clown> yes, API, some nvda people are complaining that it's tripping them up.
16:38:25 * API also wonders about that "people" complaining, which people?
16:38:34 <joanie> btw, piling stuff into object attributes rather than creating the appropriate API is (imho) not good
16:38:38 <clown> James Teh, actually
16:38:46 * clown doesn't really know who Jame Teh is.
16:39:00 <API> but you know what James Teh do?
16:39:04 <API> webkit develper?
16:39:10 * clown looks.
16:39:12 <API> w3c guy?
16:39:15 <joanie> James is one of the two NVDA project leads
16:39:26 <joanie> he is the one who does the web support in NVDA
16:39:49 <joanie> and he tends to be right on most things in my experience
16:39:53 <clown> here is the bugzilla he filed against FF:  https://bugzilla.mozilla.org/show_bug.cgi?id=825114
16:39:53 <tota11y> 04Bug 825114: normal, --, ---, nobody, NEW , Checkable state should not be exposed for ARIA buttons with aria-pressed
16:40:09 <joanie> and checkable state is for checkbuttons and radio buttons
16:40:13 <joanie> a toggle button is not checked
16:40:20 <clown> note that he has it slightly wrong in that it's not a checkable *state*, but an object property.
16:40:39 <joanie> checkable anything is for checkbuttons and radio buttons
16:41:05 <clown> or is it for any two-state widget?  (just wondering).
16:41:09 <API> ok, so now I have all the information, but I'm somewhat lost
16:41:17 <API> clown, you raised this discussion because ...
16:41:18 <joanie> checkbuttons can actually have three states
16:41:18 <clown> actually, pressed can be on, off and mixed.
16:41:26 <API> you want the opinion from atk/at-spi developers?
16:41:33 <API> or it is just a fyi
16:41:33 <clown> sure.
16:41:46 <API> well as joanie said
16:41:53 <API> (3) is somewhat weird
16:41:54 <joanie> my opinion is that checkable should not be exposed for toggle buttons
16:41:55 <joanie> not as a state
16:41:59 <joanie> not as an attribute
16:42:01 <API> because a toggle button is not a checkable thing
16:42:05 <joanie> toggle buttons are not checked
16:42:06 <joanie> period
16:42:08 <joanie> :)
16:42:20 <joanie> or to put it another way, James is right
16:42:44 <clown> I suspect (gut feeling), it's there because there is no "toggle-able" state or object property, and they didn't want to create a new one.
16:42:58 <joanie> clown: which gets back to what I was saying earlier
16:43:02 <joanie> way the heck back
16:43:04 <API> that sounds like a lazy answer :P
16:43:14 <joanie> when this aria-pressed thing first came up
16:43:20 <clown> oh, it's not answer, just a stab in the dark.
16:43:24 <joanie> the thing to do was ask James and Me
16:43:28 <API> I'm not calling you lazy, but the ones wanted to reuse checkable insted of define toggle-able
16:43:29 <joanie> and other such developers
16:43:42 <joanie> and we could have said back then
16:43:45 <joanie> what we are now
16:43:46 <joanie> namely
16:43:52 <joanie> 1. Checked doesn't apply
16:43:57 <joanie> 2. We need some API for pressed
16:44:13 <joanie> and we could have then implemented that API addition in IA2 and ATK/AT-SPI2
16:44:31 <joanie> but that didn't happen
16:44:38 <joanie> so now we have these silly object attributes
16:44:54 <joanie> and have to try to bring implementors into alignment
16:44:59 <joanie> so that they use the same attributes
16:45:00 <clown> okay, I'm not sure about 2 (I'm really completely on the fence about this whole thing) — why do we even need checkable for checkboxes?
16:45:26 <joanie> the way orca uses it is:
16:45:27 <clown> isn't the fact that it's a checkbox entail it's checkable?
16:45:32 <joanie> if an object has state checkable
16:45:48 <joanie> then it is worth presenting "checked" or "not checked" when it gets focus
16:46:04 <joanie> so the user knows whether or not he/she wants to toggle it with the space bar
16:46:15 <clown> if an object is a checkbox, then it will have state checked, unchecked, or mixed, no?
16:46:17 <joanie> or in the case of radio buttons by arrowing to it
16:46:32 <joanie> we don't have state unchecked
16:46:37 <joanie> if we had a state unchecked, sure
16:46:47 <clown> right, it's bit flag sort of.
16:47:00 <clown> either STATE_CHECKED is set of cleared.
16:47:05 <clown> "or" cleared.
16:47:10 <joanie> and if state checked is cleared
16:47:25 <joanie> then we can only look to the role
16:47:37 <joanie> if someone creates a new widget called a foo
16:47:38 <API> clown, the fact is that without checkable we don't know if an object can be checked or not
16:47:48 <API> except for the role, and sometimes its not clear
16:47:58 <clown> right, and role is there is it not?
16:48:06 <joanie> for instance
16:48:08 <joanie> check menu items
16:48:19 <joanie> often those lack the check menu item role
16:48:22 <joanie> and just have menu item
16:48:27 <clown> why?
16:48:29 <API> clown, but as I said sometimes it is not clear just from the role all the states he can get
16:48:32 <joanie> but the fact that it has state checkable
16:48:43 <joanie> tells us that the menu item is something we can toggle
16:49:06 <joanie> and the fact that state checked is absent in a menu item
16:49:13 <clown> not toggle — only toggle buttons are toggle-able (according to you).
16:49:13 <joanie> is noteworthy
16:49:15 <API> in that sense mac a11y has the advantage that for any role, it explicitly specifies which states can be set
16:49:29 <API> although not sure if this is a code thing (so forced) or just a documentationthing
16:49:30 <joanie> clown I am typing quickly without proofreading
16:50:02 <clown> still, it's kind of telling:  what is the difference between toggled and checked?
16:50:35 * clown apologizes for arguing both sides of the issue, but I really don't have an opinon yet.
16:51:08 <joanie> ok
16:51:11 <joanie> there is toggled
16:51:14 <joanie> there is pressed
16:51:16 <joanie> there is checked
16:51:24 <clown> there is expanded
16:51:24 <joanie> toggle buttons can be pressed or not pressed
16:51:31 <joanie> checkboxes can be checked or not checked
16:51:43 <joanie> expanded does not apply to buttons that are not menus
16:51:53 <clown> it applies to tabs.
16:51:57 <joanie> so as I was saying
16:52:04 * joanie backs up
16:52:15 * clown shuts up.
16:52:16 <joanie> Assumption one: The widgets under consideration are
16:52:19 <joanie> 1. checkbuttons
16:52:22 <joanie> 2. radio buttons
16:52:26 <joanie> 3. push buttons
16:52:30 <joanie> 4. toggle buttons
16:53:17 <joanie> Assumption two: The states under consideration -- where states here means expression of condition and not an API official exposure
16:53:22 <joanie> are
16:53:25 <joanie> 1. toggled
16:53:27 <joanie> 2. pressed
16:53:30 <joanie> 3. checked
16:53:36 <joanie> Given the above two assumptions
16:53:44 <joanie> I would suggest for your consideration
16:53:45 <joanie> that
16:53:54 <joanie> toggle buttons can be pressed or not pressed
16:54:07 <joanie> checkboxes and radio buttons can be checked or not checked
16:54:20 <joanie> and that toggle is an action
16:54:24 <joanie> that describes
16:54:33 <joanie> changing the state from pressed to not pressed and vice versa
16:54:43 <joanie> and changing the state from pressed to not pressed and vice versa
16:54:50 <joanie> under these conditions
16:54:55 <joanie> James is right
16:55:07 <joanie> and the toggle button should not claim in any fashion
16:55:16 <joanie> be that a state or an object attribute or a catchy tune
16:55:19 <joanie> that it is checkec
16:55:22 <joanie> or checked
16:55:26 * joanie is finished
16:55:43 <clown> a question:
16:56:40 <clown> based on the above, I infer that checked (or checkable) applies only ever to checkboxes and radio buttons (and also check box menuitems and radio button menuitems).  Correct?
16:57:16 <joanie> I would say that of the list of roles you specify
16:57:27 <joanie> that checked/checkable applies to them
16:57:35 <joanie> but given some hypothetical role foo
16:57:40 <joanie> that we have not conceived of
16:57:52 <joanie> foo might also be a candidate for checked/checkable
16:58:00 <joanie> as long as foo ain't a toggle button
16:58:11 <joanie> or a widget behaving like a toggle button
16:59:01 * API realizes that it is about end-meeting time
16:59:05 <clown> well, there is a relatively new kid on the block, the "switch", which visually slides on/off, and show "on" or "off" depending on its state.
16:59:14 <API> well guys, this became too long for the meeting (imho)
16:59:23 <clown> yeah, you're right.
16:59:31 <API> and during the process I remembered some points that it would be good to talk about
16:59:32 <API> soo
16:59:38 <clown> is that switch checkable?  or toggle-able?  or somthing else-able?
16:59:47 <joanie> the switch is checkable
17:00:02 <joanie> and that's what we've done in gnome-shell, right API?
17:00:04 <clown> and yet it's called a toggle switch on Mac.
17:00:06 <API> the compromise could be discuss this on the IRC/mailing list and resume the meeting on a different point
17:00:20 <clown> sure.
17:00:24 <API> joanie, yes I think so
17:00:36 <API> although I would need to see the code to confirm that
17:00:39 <API> can do that later
17:00:54 <joanie> in gnome, the switch basically took the role of checkbox when the item under consideration is a service
17:00:59 <joanie> I think that's even documented somewhere
17:01:09 <API> yes I think so
17:01:24 <API> I remind some designers document that I used as base
17:01:27 <joanie> anyhhhhhoooo getting back to the original/non-deep dive
17:01:37 <clown> sorry...
17:01:45 <joanie> this is why I think we need more input early on from more parties
17:01:54 <joanie> so we can get more stuff right
17:02:02 <joanie> rather than have to later file bugs asking for changes
17:02:03 <clown> this spec has been around since 2009 or earlier…  (just sayin')
17:02:19 <joanie> clown: and were James and I asked about it?
17:02:31 <clown> specifically?  dunno.
17:02:37 <joanie> because if we were asked about it, I bet you would have gotten the same opinion back then
17:02:39 <clown> but it wasn't hidden.
17:02:50 <joanie> but when you have a billion other things to do
17:02:56 <clown> yeah, I know.
17:03:06 <joanie> looking around for things you might -- just might -- need to weigh in on
17:03:10 <joanie> is kinda tough
17:03:16 <clown> and the spec is "big -ish"
17:04:10 <joanie> so only people who can afford to invest staff time weigh in
17:04:30 <joanie> and some of those people might represent companies (say 1200 screen reader companies) who have an agenda
17:05:05 <joanie> I won't call the system fully broken, but I do think it could be tweaked a tad
17:05:35 <clown> perhaps what we are doing now is the beginning of such a tweak.
17:06:01 <joanie> indeed
17:06:03 <joanie> :)
17:06:06 <joanie> we should do more of it
17:06:09 <clown> thanks for all the input.
17:06:10 <joanie> but not at meetings
17:06:20 <API> and using that last sentence
17:06:21 <joanie> otherwise API will kill me
17:06:25 <joanie> :)
17:06:30 <API> could we move to next point and assume
17:06:48 <API> that we will find other moment to resume the prevoius conversation if it is worth?
17:07:18 <clown> sure, API
17:07:29 <API> ok lets do that
17:07:33 <API> #topic JAW update
17:08:02 <API> #info API sent that jaw asking mail, and we have a brief (but not public) chat with Peter Korn
17:08:30 <API> #info we don't have new information since then, but Peter told us that he would contact the proper people
17:08:45 <API> #info meanwhile, an oracle worker sent a email to orca-list
17:08:48 * API looking
17:09:09 <API> https://mail.gnome.org/archives/orca-list/2012-December/msg00180.html
17:09:39 <joanie> s/an oracle worker/the former orca project manager from the Sun APO who knows what Orca is and that linux ain't windows/
17:10:11 <API> #info talking about Window Java bridge on a orca list, so that seems to suggest that right now Linux is not at their priority list
17:10:22 <API> yes joanie comment adds more information here
17:10:26 <joanie> ;)
17:10:30 <API> sooo
17:10:51 <API> #info seems really unlikely to get some kind of actions from oracle with respect to jaw
17:11:14 <jjmarin> :(
17:11:18 <API> #info some of the more popular java based programs are "accessible enough"
17:11:23 <API> #info like eclipse
17:11:31 <API> #info in spite of not having jaw
17:11:33 <joanie> #info Joanie yesterday discovered that not only does JAW not build, but it's still expecting GNOME 2 stuff
17:11:56 <API> #info so next question is: should we just assume that JAW is dead or do something with JAW?
17:12:02 <joanie> #info Eclipse and its widgets are accessible because they have their own a11y implementation that mirrors GAIL
17:12:10 <API> #info do we have people resources to do something with Jaw?
17:12:27 <API> we are not a lot of people today
17:12:33 <API> so not sure if we are in the position to answer that
17:12:42 <joanie> but I think we should be mulling it over
17:12:53 <API> so probably it is better to do the fyi here, and think about it
17:12:56 <joanie> because it's a tough question
17:12:59 * joanie nods
17:13:00 <joanie> exactly
17:13:04 * API looking if mulling is what API is saying
17:13:10 <joanie> API yup
17:13:23 * API have a friend on wordreference
17:13:24 <API> ok
17:13:29 <API> so, questions doubts comments?
17:13:44 * jjmarin wonders if IBM eclipse people can help on this
17:13:51 <joanie> no
17:14:09 <joanie> I mean, why would they want to improve a competing java implementation
17:14:13 <joanie> when theirs is accessible
17:14:27 <clown> right eclipse uses SWT, which is a "native" widget in the long run.
17:15:19 <joanie> I would think the IBM folks would love to see the Oracle Java Swing toolkit die
17:15:29 <jjmarin> ok
17:15:39 <joanie> doesn't mean it's not a good idea in spirit
17:15:44 <clown> yes, there is a reason it's called "eclipse".
17:15:53 <joanie> just that in this particular case it ain't gonna happen
17:17:16 <API> not a lot of discussion
17:17:19 <API> here
17:17:24 <API> (something that was not the prupose)
17:17:32 <API> but as we need to think about it
17:17:50 <API> #action API will send a mail answering his own mail about the same conclusions shared on the meeting
17:17:54 <API> so, moving?
17:18:01 <API> (to next topic)
17:18:42 <jjmarin> Does SWT use gtk+2 ?
17:19:18 * clown doesn't know enough about the nitty gritty details...
17:19:49 <jjmarin> sorry for the collateral question
17:19:51 * API neither
17:20:00 <API> jjmarin, congratulations, you have a new action!
17:20:06 <API> investigate your own question!
17:20:07 <API> :P
17:20:09 <joanie> jjmarin: it doesn't
17:20:13 <joanie> to my knowledge
17:20:17 <API> or not
17:20:20 <joanie> as I mentioned earlier
17:20:22 <jjmarin> I can do that :)
17:20:29 <joanie> they have their own accessibility implementation
17:20:37 <joanie> that parallels what Gtk+ does
17:20:43 <joanie> it claims to be GAIL
17:20:53 <joanie> where as Gtk+ now claims to be Gtk+
17:21:06 <joanie> it looks like Gtk+ 2
17:21:11 <joanie> and how that happens I dunno
17:21:26 <joanie> but my understanding is the a11y stuff (i.e. what we care about) is pure them
17:21:29 <joanie> and not gtk
17:22:29 <API> soo
17:22:36 <API> as nobody is talking now, I will move
17:22:50 <API> (what at the begining was a short meeting became a long one, impressive)
17:23:18 <API> #topic Q3
17:23:25 <API> this was whispered by joanie
17:23:48 <joanie> #info The talk on either the Foundation and/or Marketing lists suggests that there will not be a Q3
17:23:50 <API> seems that we are not going to have q3 reports
17:24:00 * API "shut upping"
17:24:08 <jjmarin> #info Juanjo has posted to the Foundation list about having reports for each release instead of quarterly reports. It seems it gets harder and harder to get the quarterly reports in time (the a11y is always on of the most responsive, even when we are late). I think that part of the problem is that the quarterly reports doen't feet very well into the release cycles. Let's see what is going on.
17:24:09 <joanie> #info There has been recent suggestions that the Quarterlies become more tied to release cycles
17:24:17 * joanie shuts up too
17:24:44 <jjmarin> shutting down here :)
17:25:41 <jjmarin> next thing ?
17:26:10 <API> unless someone has questions or doubts (I don't), my plan is move to next topic....
17:27:17 <clown> regarding the previous topic, I couln't help but google — according to wikipedia, SWT uses GTK+ on Linux.  Take that with a grain of salt, I suppose.
17:27:24 <clown> http://en.wikipedia.org/wiki/Standard_Widget_Toolkit
17:27:28 <API> it seems that there are not about this
17:27:38 <API> clown, thanks for the information (will take a look later)
17:27:45 <clown> no problem.
17:27:54 <API> #topic webkit2 and 3.8
17:28:03 <joanie> if they use Gtk+ on linux
17:28:15 <joanie> shouldn't the widgets act like Gtk+ a11y wize
17:28:16 <joanie> ?
17:28:25 <clown> indeed.
17:28:30 <joanie> s/like/exactly like/
17:28:36 <API> #info for 3.8 webkitgtk developers are planning to move to webkit2
17:28:59 <API> #info this is a major change, and although we should also be aware/vigilant about regressions
17:29:35 <API> #info it is also important to note that they implied that they are going to stick to specific library versions, or more specifically, APIs
17:29:51 <API> #info in that sense if would be somewhat difficult to add new APIs after that release
17:30:39 <API> #info ATK developers (me and Joanie as Orca is main user) is taking that into account for APIs like AtkCollection, an old would-like-to-have, that probably should be speeded up now
17:30:48 <API> (done)
17:31:00 <API> this is basically a FYI, in relation to new API to be added
17:31:16 <API> as seems that 3.8 would be a harder deadline with respect to what we thought
17:31:22 <API> doubts, comments, questions=
17:31:24 <API> ?
17:31:31 <jjmarin> It sounds this change will be for better :)
17:32:48 <API> every change are supposed to be for better :P
17:32:54 <API> lets see what happens
17:33:30 <joanie> some changes are not
17:34:17 <API> well, it seems that are not a lot of questions
17:34:21 <API> anyway,
17:34:42 <API> #action API, for the same quorum-reason that before, will send a mail to igalia-accessibility-devel about this
17:34:50 <API> and as there are no questions
17:34:58 <API> #topic Miscellaneous time
17:35:21 <API> anything not scheduled and short to talk about?
17:37:28 * clown crickets.
17:37:32 <API> well, today we spoke a lot
17:37:55 <API> lets finish the meeting and lets catch crickets as when we were kids
17:38:01 <API> so thanks everybody
17:38:05 <API> #endmeeting