15:05:16 <API> #startmeeting
15:05:17 <Services> Meeting started Thu Jan 22 15:05:16 2015 UTC.  The chair is API. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:05:17 <Services> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:05:29 <API> #topic Progress towards 3.16
15:05:38 <API> #info This week is 3.15.4 release week
15:06:04 * clown feels like a 5th wheel
15:06:52 <API> #info last additions on ATK are math-related roles. They are going directly as roles, after finding that the role-subrole work became a big chunk. Hopefully role-subroles would be a 3.18 thing, but having math roles now, would give us more info on that work while implementing them
15:07:26 <API> #info I personally toyed a little with the gnome-shell selected event order emission, but not enough to get something ready, will try again this week
15:08:03 <API> #info that gdm patch is not reviewed yet, so I guess that next action would be IRC ping (and as agreed, asking about the grey screen of crash on gnome-shell)
15:08:03 <API> done
15:08:14 <clown> what is the "gnome-shell selected event order emission"?
15:08:20 * API looking for bug
15:08:48 <API> bug 738701
15:08:48 <Services> 04Bug http://bugzilla.gnome.org/show_bug.cgi?id=738701 normal, Normal, ---, gnome-shell-maint, UNCONFIRMED, Please emit accessible object:state-changed:selected events after window:activate for switchers
15:09:17 <API> basically, the current event emission order is push-button:selected window:activated switcher:focused
15:09:37 <API> and joanie mentioned that for orca it would be better the more sensible
15:09:50 <API> window:activated switcher:focused push-button:selected
15:09:51 <clown> what window is involved in the switcher?  (Perhaps I should read the bug more closely).
15:10:05 <API> that window is the gnome-shell clutter stage
15:10:12 <API> so all the screen
15:10:16 <joanie> the problem is that the current order says "there's this event for something the user is not in"
15:10:37 <joanie> Orca sees bazillions of accessible events for things the user is not in
15:10:38 <clown> oh, okay.  I thought for a moment that the app icons where put in their own window, which struck me as odd.
15:10:42 <joanie> these should be ignored
15:10:55 <clown> sure.
15:10:59 <joanie> Orca needs to know the user is actually in the thing :)
15:11:10 <joanie> failing that, implementing the appropriate interfaces would be nice ;)
15:11:55 <API> clown, no is a window as a top-level window
15:12:05 <API> because if you are, lets say on gedit
15:12:18 <API> the top level window active is gedit's window
15:12:35 <API> if you press alt+tab, the top-level window of gnome-shell became active
15:12:43 <API> as is the one that would manage the key events now
15:12:54 <API> as is a really top-level window
15:13:02 <API> as in the case of gnome-shell it covers all the screen
15:13:11 <clown> i see.  (resisting urge to ask, why is it a window?)
15:13:30 <API> well, top-level windows are also windows after all
15:14:18 <API> and on the atk api, the way to explicitly know that a different application has the key management now
15:14:25 <API> is because a different window became active
15:14:40 <API> right now
15:14:49 <API> the only way to know which app is the active one
15:14:52 <clown> Well, my question is more of a "how does gnome-shell and/or GTK work", than it is an a11y question.  Which isn't really appropriate for this meeting.
15:15:09 <API> is with window:active events
15:15:13 <clown> So, on gnome, an application is a window?
15:15:25 <API> no
15:15:29 <API> there is a role application
15:15:30 <API> but usually
15:15:39 <API> the first child of the application is a window
15:15:49 <API> one could argue that we could have
15:15:52 <API> application:active events
15:15:57 <API> instead of window:active events
15:15:59 <API> but then
15:16:08 <clown> indeed.  I *think* that's how it works on a mac
15:16:15 <API> what would happen with applications that manage several top-level windows?
15:16:24 <API> for example
15:16:28 <API> gedit without tabs
15:16:34 <API> they had several top-level windows
15:16:48 <API> and just one was active at one given moment
15:16:51 <API> and in theory
15:16:59 <API> in clutter you could have several stages
15:17:03 <API> and just one is active
15:17:12 <API> so I think that it is still better to have window:active
15:17:32 <clown> my recollection about clutter was that you could only ever have one stage.  But, my memory might be wrong.
15:17:42 <API> well, at beginning yes
15:18:04 <API> but then it was not the case
15:18:16 <API> so it supported several stages
15:18:20 <API> and in the practice
15:18:26 <API> and "in the practice" means gnome-shell
15:18:36 <API> most clutter applications just need one stage
15:18:44 <API> but as I said, clutter supports more than one
15:19:19 <API> so, as Im saying
15:19:20 <clown> is there multiple magnifier per stage, then?  (Aren't we getting waaaay off topic?)
15:19:45 <API> I don't get that question, but I agree that is too off-topic ;)
15:19:59 <API> so unless you have a strong argument for the application:active event
15:20:16 <API> I think that I will give the opportunity to others to add #infos on current topic
15:20:31 <joanie> i have a bunch of pre-typed evo #infos
15:20:34 <clown> back when there was one stage, there was a magnifier for that stage, so to speak. If there are now multiple stages, are there multiple magnifiers?  But, enough.
15:20:37 <joanie> it's a BUNCH
15:20:48 <joanie> so does anyone have small items, or should I go next?
15:20:52 <API> clown, if we have time, lets retake that on misc
15:20:57 <API> meanwhile
15:21:02 <API> yes joanie, you are next
15:21:06 <joanie> k
15:21:08 <API> next as now
15:21:14 <joanie> #info Joanie has been adding support in Orca for the newly-accessible Evolution GUI.
15:21:23 <joanie> #info In doing so, she's found some things which can be improved ("status" cell/column needs a better accessible name), along with some bugs (dead accessibles, missing states, etc.). She has not yet filed these as she's still working through identifying them as she implements support in Orca.
15:21:44 <joanie> #info There's also the problem of the body of a received message not being something you can arrow into, which the Evo developers closed as NOTGNOME. (https://bugzilla.gnome.org/show_bug.cgi?id=711350)
15:21:44 <Services> 04Bug 711350: normal, Normal, ---, evolution-mail-maintainers, RESOLVED NOTGNOME, Cannot position caret in received message body without using the mouse
15:21:44 <joanie> #info Joanie tried to hack around this by setting the caret position via the accessible text interface, but there's one or two bugs preventing that.
15:21:53 <joanie> #info One is a WebKit bug (WebKit1? -- who's maintaining that anyway?).
15:22:04 <joanie> #info The other is something Joanie is not (yet) sure about, namely: Even when setting the caret officially works (according to the accessible text interface implemented by WebKitGtk), the caret won't actually move there unless the parent container is focused. And you cannot focus the parent container without clicking on it.
15:22:17 <joanie> #info That issue needs further investigation. In the meantime, in order to continue making progress, Joanie is attempting to hack around that by synthesizing mouse clicks via AT-SPI2. Even if that works (it's hit or miss),there's that whole Wayland, mouse clicks, security issue stuff. So the sad hack might not ultimately be an option. :( And if it's a WebKit1 thing....
15:22:29 <joanie> #info Joanie hopes we can do some sort of accessibility-based work around and add it to Evolution. Maybe a grab focus via the component interface could do the same thing as a click does (currently that doesn't work). Joanie would be interested in knowing what Mike and others think about that.
15:22:43 <joanie> #info Lastly, Joanie would like to know how much time Mike realistically can devote to this. If not much, she might actually try to fix some of the things in Evo herself in her CopiousSpareTime (tm). ;) But if Mike can do that, Joanie can keep focusing on the Orca half of the problem and we might be able to achieve Evolution accessibility as the big accomplishment for GNOME 3.16.
15:22:49 <joanie> (done)
15:23:48 <mgorse> I'd say to prioritize fixing things in Orca. Evolution really should be accessible in SLED, so I figure I can consider it day job work
15:24:00 * joanie cheers
15:24:17 <joanie> #action Joanie will start filing bugs against Evo for Mike.
15:24:27 <API> just a question
15:24:32 <API> "accessible in SLED"
15:24:33 <joanie> Any thoughts from the group on a component iface work-around?
15:24:34 <API> SLED?
15:24:41 <mgorse> SUSE Linux Enterprise Desktop
15:24:55 <API> ah ok
15:24:55 <jjmarin> mgorse and joanie +1+1
15:24:55 <API> mgorse, thanks
15:24:55 <joanie> aka the DayJob
15:25:03 <joanie> SUSE++
15:25:04 <mgorse> Is the accessible in question a webkit accessible?
15:25:16 <joanie> mgorse: yes
15:25:24 <joanie> but it's embedded
15:25:26 <mgorse> so there may or may not be a webkit 1 bug there
15:25:42 <joanie> right
15:26:01 <joanie> basically, what I'm saying is that I'm ok to hack around this by setting the caret there via at-spi2
15:26:01 <jjmarin> Do Evo maintainers have plans to move to WebKit2 ?
15:26:17 <joanie> but in order to do that hack (which is reasonable), the parent container must have focus
15:26:21 <joanie> I think it's an iframe
15:26:22 <joanie> anyhoo
15:26:32 <joanie> the only way to focus it is by clicking
15:26:46 <joanie> so my proposed possible-hack is:
15:27:17 <joanie> in evo, have a grab focus on the accessible do the equivalent of a click
15:27:41 <joanie> is that crazy? (she says having not actually looked at the evo code)
15:27:57 <joanie> and what is the situation with WK1?
15:28:10 <mgorse> oh, not sure, if you're asking if it would be hard to implement
15:28:30 <joanie> 1 is: Is it hard to implement in Evo (rather than webkit1 where it may belong)
15:28:47 <joanie> 2 is: Will the evo devs (the one who NOTGNOMEd my bug) accept it
15:28:58 <joanie> i.e. in the spirit of being accessible
15:28:58 <API> about that wk1 question, and in relation with jjmarin question
15:29:07 * joanie shuts up :)
15:29:09 <API> probably you should ask cgarcia
15:29:16 <API> and I think that evo tried wk2
15:29:20 <API> but eventually they gave up
15:29:46 <API> not sure if they would retake that, now that igalia did some work to document how to do the switch from wk1 to wk2
15:29:52 <API> again probably we could ask cgarcia
15:30:02 <API> and about 1 and 2 from joanie
15:30:20 <jjmarin> ok, thanks
15:30:27 <API> as joanie said, seems a hacky solution
15:30:37 <API> but as joanie, I didn't look at the code
15:30:43 <API> so I can't give a better solution
15:31:02 <joanie> so you think start with WK1? (figure out the maintainence situation)
15:31:59 <API> yes, makes sense
15:32:01 <joanie> k
15:32:12 <API> I think that all the effort now is on wk2
15:32:22 <joanie> #action Joanie will investigate the current situation with respect to WK1 maintainence.
15:32:25 * joanie nods
15:32:25 <API> or at least most
15:32:34 <API> but don't know if they do wk1 work now and then
15:32:43 <joanie> I thought all the WK1 stuff was physically removed from upstream
15:32:52 <joanie> s/thought/think/
15:33:21 <joanie> anyhoo, I'll ask my/our colleagues
15:33:35 <joanie> ok, thanks for the floor and deep dive
15:33:39 <joanie> I have actions and a plan
15:35:01 <API> well, I can't say the opposite
15:35:05 <API> as you , Im not sure
15:35:28 <API> "I cant say the opposite", Im talkinb about this: "<joanie> I thought all the WK1 stuff was physically removed from upstream"
15:35:33 <API> having said so
15:35:37 <API> anyone else on this topic?
15:35:50 <jjmarin> yes
15:35:53 <jjmarin> #info It's still pending some discussion about GNOME keyboard navigation https://mail.gnome.org/archives/gnome-accessibility-devel/2014-November/msg00017.html
15:36:30 <API> yes,
15:36:32 <jjmarin> just a reminder :-)
15:36:34 <API> thanks for the ping
15:36:45 <API> it is always on my todo thing to resume it
15:37:22 <jjmarin> no problem, your todo thing is huge
15:37:26 <API> on my next community moment, I will try to take a look, and not just suck myself on the event order emission
15:37:47 <API> and again, thanks for your effort recollecting that information
15:37:52 * clown worries that API will turn into an event...
15:38:24 <API> a event hurricane
15:38:25 <joanie> object:state-changed:fearless ?
15:38:30 <API> somewhere over the rainbow
15:38:39 <API> so, after this small misc time moment
15:38:41 <API> something else?
15:38:45 <API> moving to next topic?
15:39:08 <joanie> ATK_STATE_DOESNT_APPRECIATE_MY_JOKE?
15:39:15 * joanie hides
15:39:50 <clown> no, API_STATE_DOESNT_APPRECIATE_MY_JOKE
15:39:58 <joanie> heh
15:40:03 <API> I will take those two bad jokes as a "yes, moving please"
15:40:09 <API> #topic w3c updates
15:40:10 <clown> good call.
15:40:11 <API> clown, ?
15:40:33 <clown> I can think of two things, one fairly short, and the other a little more meaty.
15:41:02 <clown> #info Rich, Joanie, and I are having a discussion about how to map the ARIA group role.
15:41:03 * joanie prepares to refrain from ranting
15:41:44 <clown> #info, For reference, here is the spec:  http://w3c.github.io/aria/aria/aria.html#group
15:41:57 <clown> #info we currently map it so ROLE_PANEL.
15:42:18 <clown> I meant *to ROLE_PANEL.
15:42:58 <clown> #info But, Rich thinks that wrong, saying:  "A panel does not apply a group. It is just a space to draw in. The panel could have just text in it."
15:43:23 <clown> #info  I think Rich is actually describing ROLE_CANVAS when he says it's someting to draw into.
15:43:52 <clown> Done on the first topic, any questions before I move on to the next?
15:44:15 <joanie> should we include the definition of ATK_ROLE_PANEL?
15:44:20 <joanie> for the minutes
15:44:29 <clown> sure.  I have it in another window...
15:44:40 <joanie> and for that matter the aria one
15:44:55 <jjmarin> it sounds good even for an aria ignorant like me :-)
15:44:59 <clown> #info ROLE_PANEL is defined as "A generic container that is often used to group objects."
15:45:28 <clown> joanei, what do you mean by the aria "one"?
15:45:34 <joanie> the def
15:45:37 <joanie> from the spec
15:45:41 <clown> of group?
15:45:46 <joanie> yes
15:45:52 <clown> gotcha
15:46:34 <clown> #info The definition of the aria role group is "A set of user interface object which are not intended to be included in a page summary or table of contents by assistive technologies."
15:46:40 <joanie> thanks
15:46:43 <clown> np
15:46:43 <joanie> now, seriously, guys
15:46:58 <joanie> isn't an aria role "group" an ATK/ATSPI_ROLE_PANEL?
15:47:20 <clown> #info for completeness, ROLE_CANVAS is defined as "Object that can be drawn into and is used to trap events."
15:47:28 <joanie> to me, the definitions are practically identical
15:47:32 <API> joanie, yes
15:47:40 <joanie> good point clown re canvas
15:47:46 <API> I think that the mapping is correct
15:47:47 * clown I thought it would be quick.
15:47:59 <API> ATK_ROLE_PANEL definition was at it is for more that 10 years
15:48:11 <joanie> I just want to make sure it's not just joanie and joseph telling rich he's incorrect
15:48:35 <clown> yeah, that's why I brought it up.
15:48:38 <API> well, what I mean is that PANEL could have been defined as Rich is saying
15:48:45 <API> but the thing is that it was not
15:48:48 <joanie> i.e. does GNOME Accessibility think Rich is incorrect and that ROLE_PANEL is the correct (and only) mapping approriate for the ARIA role="group"?
15:48:55 <API> and he seems to want to change the meaning
15:49:12 <API> just because of how he interprets the meaning of panel
15:49:18 <API> imho, that is not reason enough
15:49:31 <API> <joanie> i.e. does GNOME Accessibility think Rich is incorrect and that ROLE_PANEL is the correct (and only) mapping approriate for the ARIA role="group"?
15:49:31 <API> ye
15:49:34 <joanie> which would break everything else for us, since on our platform others treat panel as is defined by ATK.
15:49:35 <API> *yes
15:49:52 <clown> btw, I checked GTK code, and the base container widget (aka GtkContainer) has ROLE_PANEL.
15:50:09 <joanie> ditto for clutter/gnome-shell
15:50:22 <joanie> and I think in Qt too, though I'd have to check
15:50:22 <clown> my, we have a lot of ammunition.
15:50:44 <joanie> and in the GAILish support for ... what's that swing alternative?
15:51:07 <joanie> anyhoo
15:51:11 <clown> it's been while, but I think it's JPanel.
15:51:20 <joanie> clown: no, I mean
15:51:30 <joanie> there's a product that's java
15:51:33 <joanie> but it's not the swing java
15:51:38 <joanie> Eclipse uses it
15:51:49 <clown> swt?
15:51:53 <joanie> yes
15:51:53 <joanie> thanks
15:52:02 <joanie> pretty sure we see panels there too
15:52:09 <joanie> as they do wht Gtk+ does
15:52:15 <joanie> s/wht/what/
15:52:20 <joanie> anyhoo, lemme #agreed this
15:52:38 <clown> sure.
15:52:48 <joanie> #agreed The GNOME Accessibility Team believes that the correct mapping for ARIA role="group" is ATK/ATSPI_ROLE_PANEL.
15:52:55 <joanie> i'll do one re canvas too
15:53:18 <jjmarin> My vote is against Eclipse :-)
15:53:26 <API> ?
15:53:32 <API> against eclipse in relation to what?
15:53:38 <jjmarin> joke, sorry
15:53:38 <clown> the Sun?
15:53:40 <joanie> #agreed The GNOME Accessibility Team believes that ATK/ATSPI_ROLE_CANVAS may be an appropriate option for mapping things you can "draw into"
15:53:48 <joanie> I'm done
15:53:54 <API> joanie, ok thanks
15:53:59 <API> jjmarin, ok, got it
15:54:09 <API> so, clown anything else on this topic?
15:54:10 <clown> shall I move on to the more meatier issue?  There's not much time left.
15:54:18 <joanie> what's the topic?
15:54:22 <joanie> issue I mean?
15:54:24 <clown> W3C updates?
15:54:32 <joanie> is meatier?
15:54:42 <API> hmm, well, if it is meatier
15:54:52 <API> you only have time for a preview
15:54:57 <API> if you want a discussion
15:54:59 <clown> the issue is aria-rowindex, aria-colindex, and aria-setsize for those (not sure it's called aria-setsize)
15:55:03 <API> you can give us the preview here
15:55:08 <API> and the discussion on  next meeteing
15:55:12 <clown> okay.
15:55:52 <clown> #info There exists a aria-setsize and aria-posinset to declare the size of, say, a listbox and the index of each item in the list.
15:56:25 <clown> #info There is an example of these in the spec for aria-setsize:  http://w3c.github.io/aria/aria/aria.html#aria-setsize
15:56:35 <clown> #info It's "example 20".
15:57:28 <clown> #info  Note that the aria-setsize is on the individual items in the listbox, not on the listbox itself.
15:58:01 <clown> #info There is a proposal to add aria-colindex and aria-rowindex specifically for tabular kinds of objects, such as grids and tables.
15:58:54 <clown> #info  Alex prefers to put those on the column/row object, not on the cells themselves.
15:59:16 * joanie notes that whatever he does (and authors do) won't impact the mapping
15:59:32 <joanie> as the exposure would be through the table and tablecell interfaces
15:59:33 * API notes that a lot of people call me "Alex", so just in case, clown is talking about a different "Alex"
15:59:34 <clown> #info I have argued that it's easier for ATs if those properties are on the cells themselves, since they do not have to look up the parent to find the information.
15:59:36 <joanie> which provide the API for that
15:59:53 <joanie> clown: we won't look at the object attributes
15:59:54 <clown> #info Note:  Alex is Alex Surkhov in this case.
16:00:14 <joanie> we'll use the table and tablecell (new) interfaces
16:00:23 <joanie> which Surkov will implement
16:00:33 <API> joanie, does this discussion would affect the bug you opened about having support on ATK for all that?
16:00:49 <joanie> no
16:00:53 <joanie> this is about tables
16:01:02 <joanie> and tables we already have interfaces for
16:01:14 <joanie> the posinset and setsize are related, but different
16:01:20 <joanie> and we do need API in ATK for that
16:01:25 <joanie> I have another meeting btw
16:01:27 <joanie> now
16:01:29 * joanie dials in
16:01:35 <clown> #info See this email (part of a larger thread):  https://lists.w3.org/Archives/Public/public-pfwg/2015Jan/0065.html
16:01:39 * jjmarin wonders which Rich was in the previous aria issue ?
16:02:22 <joanie> but seriously, clown I don't think it matters for us
16:02:47 <clown> #info Finally, joanie added the following in a response:  "If the latter, wouldn't aria-colindex be a property of the cell and not the row?"
16:02:59 <clown> #info Joanie's email is here: https://lists.w3.org/Archives/Public/public-pfwg/2015Jan/0118.html
16:03:08 <joanie> clown: that's about aria and authors
16:03:13 <joanie> it's not about mapping
16:03:39 <joanie> wherever it goes in aria's spec, won't change the correct platform mapping for ATK/ATSPI
16:03:40 <API> hmm
16:03:56 <clown> well … my point was where to put the aria-* attributes.  I was advocating the list options for a list box, a cell for tabulare constructs, etc.
16:04:13 <joanie> the colspan, rowspan, rowindex, colindex, etc are not attributes we'll look at
16:04:27 <joanie> given a cell, we will do cell.queryTableCell()
16:04:33 <joanie> or get its table (old style)
16:04:41 * joanie pulls up doc
16:04:50 <clown> I suppose my justifcation may have been off, but we were heading towards the same conclusion.
16:05:11 <clown> Also, I was considering an AT that is entirelly web-based.  For example, ChromeVox.
16:05:18 <joanie> https://developer.gnome.org/atk/unstable/AtkTableCell.html
16:05:23 <clown> That doesn't use AT-SPI to access the information.
16:05:26 <joanie> clown: that's fine
16:05:34 <joanie> but ask those platforms
16:05:37 <joanie> :)
16:05:45 <joanie> i.e. gnome accessibility cares about gnome a11y
16:05:48 <clown> Wait a second, the method is on the table cell?
16:05:49 <joanie> and for gnome a11y, it doesn't matter
16:06:09 <joanie> clown: what that means is Surkov will expose it to use via the table cell
16:06:25 <joanie> where AUTHORS put aria-colindex, etc doesn't matter
16:06:30 <clown> But, I though he was arguing to expose it via the table row/column.
16:06:42 <joanie> He's arguing for authors to put it there
16:06:57 <joanie> as I understand it
16:07:15 <clown> Okay, I guess I should re-read it.
16:08:12 <API> ok
16:08:16 <API> so as we are already over time
16:08:34 <API> #action clown will re-read it, and we will discuss (or not) again next week
16:08:45 <API> so, if you don't mind
16:08:50 <API> I will close the meeting now
16:09:03 <clown> okay.
16:09:06 <API> #endmeeting