Rick Berger | 29 Sep 01:27 2015

a way to log all my mouse events?


Can anybody give me a quick and dirty way to log all my mouse events? I 
want to see what the pattern of movement is when I go to select or click 
on something. With my hand control I'll often have trouble positioning 
mouse's pointer and it would be interesting to see what precisely is 
going on.

Alejandro Piñeiro | 21 Sep 17:18 2015

ATK 2.18.0 released

A new major version of the stable version of ATK has just been released.

About ATK

GNOME provides support for accessibility devices using the ATK
framework. This framework defines a set of interfaces to which
graphical interface components adhere. This allows, for instance,
screen readers to read the text of an interface and interact with its
controls. ATK support is built into GTK+ and the rest of the GNOME
platform, so any application using GTK+ will have reasonable
accessibility support for free.

Nonetheless, you should be aware of accessibility issues when when
developing your applications. Although GTK+ interfaces provide
reasonable accessibility by default, you can often improve how well
your program behaves with accessibility tools by providing additional
information to ATK. If you develop custom widgets, you should ensure
that they expose their properties to ATK.

News (compared with 2.16.0)

* Documentation:
  * Replace mentions of 'state-changed' with 'state-change'.
  * Fixed some tiny typos
* Build/win32 improvements:
  * Use Pattern Rules on build/Makefile-newvs.am
  * Tidying and cleaning .vcxproj.filters generation
    * Fixes Bug 748176: out-of-tree distcheck fails in build/win32
(Continue reading)

Sean Workman | 29 Jun 21:15 2015

Getting Started

I would like to start contributing to gnome accessibility code, I am
using gnome on CentOS 7 and I tried following the "Quick Start page"
but there is no System menu so that attempt was short lived. Could I
get some help on how to get started?
Daiki Ueno | 23 Mar 09:37 2015

caribou 0.4.18

Caribou is a text entry and UI navigation application.
This is a new stable release for GNOME 3.16.

- Translation updates (Turkish, Danish, Italian, Aragonese, Bosnian,
  Latvian, Bulgarian, Korean, Vietnamese, Ukrainian, Brazilian
  Portuguese, Greek, Swedish, Catalan, Slovak, Galician, Chinese

https://download.gnome.org/sources/caribou/0.4/caribou-0.4.18.tar.xz (413K)
  sha256sum: 8d94977f3364926600b5f711406e765a9a61aa444609f87a1d435b301e147226

Daiki Ueno
Magdalen Berns | 3 Mar 23:23 2015

Marketing: talk on Thursday for EdLUG

Hi all,

Apologies for the cross post. I am doing a talk at EdLUG on Thursday about hacking accessibility in GNOME. I plan to publish the presentation audio and slides afterwards on planet.gnome.org (after it is done) but in the meantime, since it's a "marketing" thing, I figure I should ask for some feedback in advance from my fellow comrades on the slides to make sure I don't inadvertently misrepresent the project or a11y team.[1] Let me know if you have any questions/comments/concerns/suggestions. It may not seem like it but the talk works out to be around 20 minutes long as it stands.

Lastly, assuming all seems good, I also want to give a huge nod to Mario who's fantastic blog I have lifted some comprehensive ideas from for this talk.[2] Also Marina, who has more or less provided the awesome LibreOffice template which was (also lifted) from wiki.gnome.org.[3] 



gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org
Magdalen Berns | 20 Feb 23:27 2015

Privacy campaign funds

Hi all,

If you read the foundation list recently you might have noticed that the privacy campaign fund of $20,000 is going to be spent on placing bounties privacy bugs.

Apparently the ideas get proposed on https://wiki.gnome.org/Foundation/PrivacyCampaign2013 and assessed by a team of unnamed individuals, before being approved by the board. Perhaps it is worth thinking about whether there are any accessibility bugs which affect privacy that could be proposed.


gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org
Mike Gorse | 16 Feb 22:45 2015

ANNOUNCE: AT-SPI 2.15.90 released

AT-SPI 2.15.90 is now available for download at:


What is AT-SPI2

AT-SPI2 is a D-Bus based accessibility framework. It defines a D-Bus
protocol for providing and accessing application accessibility
information. The project includes a library for bridging the D-Bus
protocol to the ATK API, allowing Gtk based applications to be made
accessible. It also contains a client (AT) side library in C and a wrapper
for Python.

What's changed in AT-SPI 2.15.90

* Added new roles for fractions, roots, subscripts, and superscripts.

* Deprecate atspi_text_get_text_(before|after)-offset (bgo#697969).

* Added tests for action interface (bgo#743418).

Where can I get more information about AT-SPI2

The project wiki is available at:


How can I contribute to AT-SPI2?

We need help testing with Gnome accessibility technologies, improving
performance, and generally tying up loose ends.  The above-referenced page
contains a list of known issues that should be fixed.

IRC   : #a11y on Gimpnet
E-Mail: accessibility-atspi <at> lists.linux-foundation.org

Development repositories can be found at:

Daiki Ueno | 16 Feb 09:17 2015

caribou 0.4.17

Caribou is a text entry and UI navigation application.
This is an unstable release towards GNOME 3.16.

- Bundle tools to generate and manipulate keyboard layout files.
  See https://wiki.gnome.org/Projects/Caribou/NewLayout for details.
- Bug 691811 - Add support for azerty layout as seen in french
- Bug 743267 - Caribou does 100-130 syscalls for each keypress
- Bug 743880 - String that is hard to understand
- Translation updates (Turkish, Czech, Polish, German, Lithuanian,
  Hungarian, Spanish, Norwegian bokmål, French, Indonesian, Slovenian)

Daiki Ueno
Nicolas Chauvet

Alexandre Franke (fr)
Andika Triwidada (id)
Aurimas Černius (lt)
Balázs Úr (hu)
Benjamin Steinwender (de)
Daniel Mustieles (es)
Kjartan Maraas (nb)
Marek Černocký (cs)
Matej Urbančič (sl)
Muhammet Kara (tr)
Piotr Drąg (pl)

https://download.gnome.org/sources/caribou/0.4/caribou-0.4.17.tar.xz (412K)
  sha256sum: 31828886b812421dd7217a7aa29043945b8601f3a101507f7e3faa0dc157e516


Daiki Ueno
gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org
Alexander Surkov | 11 Dec 22:35 2014

specialized dialog roles

Hi. ATK as IAccessible2 both have bunch of roles for specialized dialogs like color chooser dialog [1], [2]. I'm curious if there's any application on Linux today for these roles. In case of IAccessible2 we never used those in Firefox following IA2 spec. However Chrome uses those roles for control elements rather than for their associated dialogs, and Jamie from NVDA thinks it's reasonable [3]. I'm curious if it makes sense to follow this example.

gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org
Michael Pozhidaev | 5 Dec 05:43 2014

How to choose the suitable event in AT-SPI

Hello all,

I got a question regarding choosing the most relevant event for the
particular user action. When the user does something (presses the key or
anything else) his/her action usually yields the several events which go
through registryd and are transmitted to AT. The problem is how to
choose among them the most preferable one? We can collect them and do
the selection but for that we should be sure that know them all and for
the last user action there will no events any more. This require a some
sort of transactions or packets and I am wondering is there any way to
ensure that we got everything for the last user action? Maybe my
approach is wrong and I would be thankful if somebody can help me to
understand what I should do with that.

Speaking "the most preferable event" I mean the most relevant event to
construct a user feedback. For example, when the user presses keys in
the editable text, the events reflecting caret move and text changing arrive.
Among them we need the text changing one while caret move is very
confusing because it could be caused just by pressing the arrows.

Thank you in advance! 


Michael Pozhidaev. Tomsk, Russia.
Russian info page: http://www.marigostra.ru/
English info page: http://www.marigostra.com/
Juanjo Marín | 30 Nov 23:23 2014

Some notes about the status of the keyboard navigation in GNOME 3.14

I've been learning how users can interact to GNOME using just the keyboard, after reading Peter Vágner
email to the (a11y) mailing list. Reading the documentation [2], the main shortcuts for keyboard
navigation in applications are: 

1) Tab: Moves keyboard focus between different controls. Shift+Tab does the same in the reverse order. 

2) Ctrl+Tab: moves between groups of controls and can also break out of a control that uses Tab itself, such
as a text area. Shift+Ctrl+Tab does the same in the reverse order. 

3) Arrows keys: Move selection between items in a single control, or among a set of related controls. 

It seems to me there some inconsistencies, or at least the definition of control, group of controls and
items are fuzzy in practice. Some cases to explain this: 

gnome-control-center: What I expect is three groups of controls: find, Personal, Hardware and System.
However, the Ctrl+Tab doesn't work as I expected. In this application, Tab behaves as I expected Ctrl+Tab
should do. This means that find, Personal, Hardware and System are controls instead of groups and there
are only two groups controls: find and everything else. The arrow keys allow me to move between all the the options.

Online accounts: This is tricky. The item selected from the list on the left determines the content of the
right panel. The current keyboard navigation layout doesn't convey this relationship IMHO. The user
starts in the first item of the list, pressing Tab moves the focus to the add button and pressing Tab again
moves the focus to the controls on the right related to the item selected on the list. IMHO this behaviour is
confusing. To convey this relationship, I guess that pressing Tab should move the focus to the controls
related to the item selected on the list. However, this fix is not totally perfect, because the minus
button for removing this account (and related of the selected item on the list), it is not the following
button focused by pressing Tab, though it can be reached by pressing the left arrow. 

gnome-calculator: It works ok, except that there aren't any group of controls. I think it makes sense to
have the following groups: calculator selector, calculator display and the keys. I like the fact I can
navigate the keys with tab or using the arrows keys, but also you can use Ctrl+Tab, and this is not as good

Region and Language: I focus in the language menu here. You can navigate the items of the list using Tab or the
arrows keys. I find strange the fact the enter key doesn't work to activate the "more language" option and
you have to press the space key instead. The language menu after pressing the "more languages" options is
pretty similar to the previos menu. It has much more language-items and a search control. The navigation
in the items is pretty similar, using Tabs or arrows keys. It is weird that the scroll of the list don't
follow the item selected in the list, so the selected item can be out of view easily. 

In general terms, I think that the keyboard navigation will benefit of a better definition of control
groups. This is something that it has to be done along with the design of the interface, so I think it
deserves a section in the HIG and mentioned in other sections. I take as granted that this can be done with
the current version of GTK+. I think that the user should be able to reach linearly all the controls shown in
the interface by pressing Tab (except when it is necessary to use Ctrl+Tab to  break out of a control that
uses Tab itself). You can also navigate controls using the arrows, it becomes very handy when the group of
controls have grid (or sort-of) layout. And finally, items in lists and similar can me reached by using the
arrows, and unless the items can be considered a control itself, Tab shouldn't work here IMO. 

Another issue I think it deserves some attention is that accelerators are not shown in the menus of in
certain redesigned applications like gedit. And, in general, accelerators are not shown in the
Application Menus. Also, the use of buttons in the new design usually means as well that accelerators for
those options are not shown. In previous/old designs, buttons usually were a way to help mouse oriented
users to easy access to frequently used options, and those options were also in the menus with their
accelerators. In the new designs, the buttons are usually the only way that those options are shown in the
interface. They only way I can think of to show accelerators in buttons is by adding this info in the
tooltips, but currently they only shown briefly desc of the action assigned to the button. My opinion is
that accelerators must be shown because they really encourage users to learn how to use the applications
using only the keyboard. I think it is good idea not to shown accelerators if not keyboard is detected, but,
if detected, they must be shown by default. And related to this, GTK+ deprecated the support for changing
accelerators since 3.10. This maybe is not a great lost, because it is supposed that most common
accelerators are standarised by the HIG [4]. However it could be useful in certain situations, for
example, when an option doesn't have any accelerator, adapt applications to other envs or personal
needs, etc. 

I hope this message can help to get some debate and eventually take some actions to improve the situation :-)


-- Juanjo Marín 

[1] https://mail.gnome.org/archives/gnome-accessibility-list/2014-October/msg00001.html 
[2] https://help.gnome.org/users/gnome-help/stable/keyboard-nav.html.en 
[3] https://git.gnome.org/browse/gtk+/commit/?id=2d79334bb069224966b3dcd8456967c9800e8fd0 
[4] https://developer.gnome.org/hig/stable/keyboard-input.html.en
gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org