14:06:38 <API> #startmeeting
14:06:39 <Services> Meeting started Thu Jun 26 14:06:38 2014 UTC.  The chair is API. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:06:39 <Services> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:07:02 <API> #topic Progress towards 3.14 (plus a little 3.12)
14:07:29 <API> #info Jasper agreed on getting a provisional (and partial) solution for bug 730118
14:07:29 <Services> 04Bug http://bugzilla.gnome.org/show_bug.cgi?id=730118 normal, Normal, ---, gnome-shell-maint, RESOLVED FIXED, GtkTreeView very slow since 3.12
14:07:50 <API> #info Piñeiro provided an updated patch
14:08:07 <API> #info now the magnifier doesn't call atspi.init until needed
14:08:28 <API> #info this mitigates somehow the problem: non magnifier users doesn't have this problem
14:08:47 <API> #info in general, non-at users doesn't suffer the treeview slow problem
14:09:05 <API> #info next step: try to solve this problem as a whole
14:09:12 <API> #info hopefully as a 3.14 objective
14:09:20 <clown> good.
14:09:26 * joanie nods
14:09:31 <joanie> Thanks for doing all that API
14:09:49 <joanie> We need things not to suck for our users. But if the entire community hates us....
14:09:57 <API> #info additionally Alejandro Piñeiro was trying to resume wayland-related work, in the form of solving the lack of tree accessibility object on gnome-shell under wayland
14:10:17 <API> #info in the form of solving, as "trying to solve"
14:10:27 <API> and I think that that was my report
14:10:30 <API> questions, doubts, next?
14:11:04 <clown> is the new 3.14 objective an at-spi objective?
14:11:29 <clown> quoting:  "to solve this problem as a whole".
14:12:16 <API> as a first step
14:12:17 <API> yes
14:12:27 <API> I mean that right now those events are needed due the cache
14:12:41 <API> we had that task on the TODO about deciding if the cache is needed or not
14:12:53 * joanie hides (Still on my to-do list)
14:12:54 <clown> right.  (thanks for the reminder).
14:12:59 <joanie> I'll bump it up
14:13:13 <API> depending on the conclusion, we could decide what is the next step for the children-changed flood
14:13:20 <API> ok
14:13:25 <API> btw, as nobody is jumping
14:13:30 <API> I just remebered
14:13:32 * clown jumps
14:14:20 <API> sorry Im looking for a specific bug
14:14:25 * API searching
14:14:33 * clown skips
14:15:19 <API> bug 732246
14:15:19 <Services> 04Bug http://bugzilla.gnome.org/show_bug.cgi?id=732246 normal, Normal, ---, at-spi-maint, UNCONFIRMED, Numerous improvements to the build system
14:15:19 * joanie pokes Services
14:15:22 <joanie> heh
14:15:25 <API> I think that bugzilla is down
14:15:27 <API> or at least slow
14:15:31 <API> in any case
14:15:50 <API> mgorse, someone provided some patches to atspi. After a quick check, they seem sane
14:16:06 <API> reviewing them shouldn't be a big task
14:16:11 <clown> yeah, bugzilla is not connecting for me either.
14:16:27 <mgorse> yeah, it's being slow, or something
14:16:56 <mgorse> It seems I'd missed that bug. Adding it to my to-do list
14:17:08 <joanie> seems like the sysadmin team knows about the bugzilla issue already
14:18:05 <API> ok
14:18:09 <API> having said so
14:18:11 <API> anything else?
14:18:12 <API> moving?
14:18:24 <joanie> evince children?
14:18:28 * joanie smiles insanely
14:18:41 <API> but that is your report ;)
14:18:47 <joanie> but it's not moving
14:18:49 <joanie> to a new topic
14:19:11 <joanie> #info Joanie got some long-awaited reviews from her colleague to expose accessible children of PDF pages
14:19:25 <joanie> #info And Joanie had much reworking to do, but those patches are now committed.
14:19:49 <joanie> #info Carlos also reviewed, tweaked, and committed support to add Tab navigation for PDF forms.
14:20:06 <joanie> #info There's still more work overall to do, but this is another milestone.
14:20:10 <joanie> (done)
14:20:23 <joanie> And this is my "excuse" for not doing the cache thing. ;)
14:21:11 <API> and fwiw
14:21:20 <API> #info Carlos, as Carlos Garcia, evince maintainer
14:21:29 <API> not sure if everybody knows who he is
14:21:36 <joanie> mea culpa
14:21:37 <jjmarin> KaL !!! :-)
14:21:42 <joanie> yup :)
14:22:10 <API> ok, so moving now?
14:22:33 * joanie is done for realz
14:22:52 <API> #topic W3C updates
14:22:54 <API> clown?
14:23:13 * clown checking minutes to see if there is anything worth mentioning.
14:24:47 <clown> #info There was a discussion of adding a new "aria-inert" attribute.  Some history...
14:25:18 <clown> #info There was a previsou proposal within HTML to have an "inert" attribute to use with a container element.
14:25:58 <clown> #info It would be useful in cases where the web app puts up a modal dialog, and the page becomes "background" temporarily, and non-interactive.
14:26:46 <clown> #info The is would be useful to ATs to indicate and stop users from TAB navigating the background material while the modal dialog was up.
14:27:12 <clown> #info when the dialog is dismissed, the page becomes "non-inert", and returns to its former interactive state.
14:27:33 <clown> #info That proprosal appears to have vanished from the latest HTML editor drafts.
14:28:05 <clown> #info The ARIA working group is considering adding an aria-inert attribute to compensate, and, for use with other markup languages such as SVG.
14:28:19 <clown> #info but, this is at the beginning of the discussion.
14:28:23 <clown> done, questions?
14:28:39 <API> hmm yes
14:28:43 <API> <clown> #info The is would be useful to ATs to indicate and stop users from TAB navigating the background material while the modal dialog was up.
14:28:51 <API> if it is a modal dialog
14:28:55 <joanie> yeah, I was going to point out that
14:29:00 <API> users cant tab navigate to the background
14:29:01 <API> right?
14:29:04 <API> or do you mean
14:29:16 <API> "indicate and stop users from trying to tab navigating"
14:29:18 <API> ?
14:29:24 <joanie> and Orca doesn't control what happens when a user Tabs
14:29:37 <clown> API, the scenario under consideration is a dialog made up of html markup (and controlled via JavaScript).
14:30:27 <clown> There is nothing currently to automatically stop users from navigation outside of such a DHTML dialog (NOTE:  it's not a system dialog).
14:31:14 <clown> The author can make some effort to capture all of the keystrokes and "stop" them from moving out of the dialog, but,...
14:31:51 <clown> It would be better (?) easier (?) if that coudl be accomplished just be setting "inert=true" on some other container  element.
14:32:08 <joanie> I have a slightly different perspective
14:32:25 <clown> I could go look for a dojo example, where dojo has done the required "capture keystrokes" technique.
14:32:33 <joanie> What I think this would handle is screen readers that implement their own keyboard navigation for content
14:32:40 <joanie> which, sadly, Orca has to do for Firefox
14:32:50 <joanie> and windows screen readers to do everything
14:33:12 <joanie> in those cases, the screen reader should not allow the user to arrow out of a dialog and into the content behind the dialog
14:33:20 <joanie> and this proposal can help there
14:33:30 <joanie> but for screen readers where that is not the case
14:33:34 <joanie> orca + WebKitGtk
14:33:43 <joanie> or it's not the case for the keystroke
14:33:50 <joanie> Orca doesn't override Tab
14:33:59 <joanie> or in the case there is no screen reader at all
14:34:19 <joanie> and the user presses an arrow key with the browser's native caret nav enabled
14:34:22 <joanie> or Tab
14:34:30 <joanie> the app developer is going to have to handle that
14:34:32 <joanie> imho
14:34:36 <joanie> make sense?
14:35:11 <API> for me yes
14:35:13 <API> and in any case
14:35:17 <API> from what clown explained
14:35:20 <clown> yes, but the previous HTML proposal to add an inert attribute was meant to make it easier for the app developer to do just that.
14:35:23 <API> those dialogs are in fact "fake modal"
14:36:25 <clown> setting "inert=true" is a message to the *browser* to effectively disable all keystrokes outside of the bounds of the "modal" dialog.
14:36:48 <joanie> aha. right. I was thinking of the ARIA possible addition/parallel support
14:36:50 <joanie> sorry!
14:37:21 <clown> right.  the aria attribute would not do that since aria is just for a11y apis, not browser behaviour.
14:37:54 <API> just out of curiosity
14:37:55 * clown is leaning towards the inert proposal, and *not* adding anything to aria.
14:38:04 <API> and can't the aria team just ping "someone"
14:38:08 <joanie> clown: but.... I think we might need it
14:38:22 <joanie> for the reason I stated when I was confused
14:38:23 <API> to check why inert was vanished ?
14:38:29 <clown> well, I did say "leaning".  My opininon may change by tomorrow :-)
14:38:45 <joanie> if it's a fake dialog and the screen reader is presenting/controlling the user interaction
14:39:20 <joanie> then the screen reader needs to know
14:39:40 <clown> API, there was talk of taking the discussion back to the HTML a11y task force to see what the status of inert is, and whether it can be put back.
14:40:17 <API> ok
14:40:22 <API> not sure
14:40:42 <API> but I have the feeling that the best solution would be have inert on html, and not an aria-inert
14:40:59 <clown> right joanie.  In that context, there was also discussion of added an aria-modal boolean.  Would that help?
14:41:05 <clown> *adding
14:41:29 <clown> sort of the flip side of aria-inert.
14:41:29 <joanie> I am very much pro aria-modal :)
14:41:48 <joanie> but James Craig I think had examples where modal didn't apply and inert did
14:41:55 <joanie> and *if* that is indeed true...
14:42:00 <joanie> we need something else
14:42:06 <clown> API if it matters  https://www.w3.org/WAI/PF/Group/track/actions/1461
14:42:13 <joanie> aria-stay-the-frick-out-of-this-really
14:42:43 <API> ok
14:42:44 <API> in any case
14:42:49 <API> all of this is enough for me
14:42:51 <API> thanks clown
14:42:53 <joanie> clown: remind me about a scenario I just thought of
14:42:59 <joanie> remind me later
14:42:59 <clown> your welcome
14:43:10 <joanie> it's coming back to a page with a modal already showing
14:43:11 <clown> okay…
14:43:14 <joanie> thanks
14:43:27 <API> ok, for any deep dive
14:43:32 <API> I guess that the place is #a11y
14:43:35 <API> so
14:43:39 <joanie> deep dive. waves. breakers!
14:43:40 <joanie> (sorry)
14:43:40 <API> #topic Marketing
14:43:46 <clown> that was deep dive, IMHO...
14:43:52 <clown> ;-)
14:44:05 <jjmarin> #info Juanjo has done some refining to the new Orca, ATK and AT-SPI entries in the Spanish Wikipedia. Not finished yet :/
14:44:08 * clown cannon-ball!
14:44:08 <jjmarin> done !
14:44:39 <jjmarin> surf the waves :-)
14:45:11 <API> questions, comments, doubts?
14:45:26 <jjmarin> exactly :)
14:45:40 <API> ok, so thanks
14:45:42 <API> moving then
14:45:45 <API> #topic Misc time
14:46:04 <API> #info Just today, someone sent a email asking questions related to ibus-orca integration
14:46:06 <API> https://mail.gnome.org/archives/gnome-accessibility-devel/2014-June/msg00001.html
14:46:23 <joanie> I saw that
14:46:25 <API> #info A piñeiro replied, but mostly making questions
14:46:37 <API> #info as unfourtunately, he is not really used to ibus
14:46:51 <API> #info having said so, all the solutions proposed looked like hacks
14:47:22 <API> #info in summary, in theory a non-orca user is already being notified of those events
14:47:32 <API> #info so the solution would be about expose the same user interaction
14:47:36 <mgorse> yeah, I saw that but don't know anything about ibus, either
14:47:54 <API> #info not creating invisible accessible objects emitting accessible events
14:48:10 <API> #info having said so, due our lack of knowledge on ibus, we would need to wait to her answers
14:48:33 <API> #info any other feedback on the list would be welcome, as support for languages that needs ibus module would be a good thing
14:48:50 <API> and next
14:48:57 <API> #info about bug 730505
14:48:57 <Services> 04Bug http://bugzilla.gnome.org/show_bug.cgi?id=730505 normal, Normal, ---, at-spi-maint, UNCONFIRMED, Draft for atspi tests
14:49:20 <API> #info both check and glib test suite are similar on features. And although it is true that check has been around longer
14:49:45 <API> #info just for integration, I really think that the atspi tests should be using the glib test suite
14:50:05 <API> #info for example, this means one less dependency on at-spi2
14:50:12 <API> mgorse, btw, I asked them
14:50:21 <API> them== patryk btw
14:50:29 <API> to change the test suite for all those reasons
14:50:34 <API> but it is true that I didnt' ask you
14:50:38 <API> so opinions?
14:51:01 <mgorse> Yeah, I think that makes sense in the long term (although it's annoying for patryk I guess)
14:51:52 <API> but it is better to do it now, with just some tests
14:52:01 <mgorse> Thanks for the review, anyhow
14:52:13 <API> I guess that the glib projects that uses check is just because they started with it
14:52:19 <API> although, fwiw, they are the less
14:52:32 <API> gstreamer and two or three more
14:52:45 <API> most glib modules uses glib testing suite
14:52:53 <API> (making another reasons: coherene)
14:52:55 <API> *coherence
14:52:59 <API> having said so, that was my misc
14:53:02 <API> any other?
14:53:36 <jjmarin> #info A GSoC, Lasse Schuirmann working in Boxes, has written a wiki page about  keyboard nav in GNOME https://wiki.gnome.org/Accessibility/KeyboardNavigation. I read on planet gnome where his blog is syndicated http://wordpress.schuirmann.eu/2014/06/gsoc-halftime/
14:54:38 <jjmarin> Just informative info
14:55:41 <API> interesting
14:55:46 <API> will take a look to that later
14:55:58 <jjmarin> ok, thanks :-)
14:56:02 <clown> "I tried using gnome blindly using Orca and keyboard navigation. I think it is suffice to say that there is space for improvement at least concerning intuitivity there but we mainly need more applications tested for blind user operability."
14:57:10 <clown> I'm remembering emails from a prospective GSOC student a while back where joanie and I advised her to just start testing keyboard support on an app-by-app bases and file bugs.
14:57:26 <clown> I don't think she did.
14:58:19 <joanie> this might be her
14:58:25 <joanie> dunno
14:58:52 <clown> I don't think, since this is a he, no?
14:59:04 <joanie> oh
14:59:06 <joanie> maybe
14:59:24 <jjmarin> hehe
14:59:57 <clown> The picture near the bottom of the blog entry look male-ish.
15:00:07 <joanie> didn't see that
15:00:20 <joanie> ah
15:00:23 <jjmarin> in planet.gnome.org there is a picture
15:00:25 <joanie> I'll shut up now
15:01:05 <clown> s/he says that s/he is lurking in a11y under 'sils'.
15:01:09 <API> so, after this picture-profile search
15:01:15 <API> and as is meeting over time
15:01:17 <API> anything else?
15:01:56 <jjmarin> nop
15:02:09 <clown> i'm good.
15:02:20 <jjmarin> very good :-)
15:02:33 <clown> :-)
15:02:44 <API> #endmeeting