Daiki Ueno | 23 Mar 09:37 2015
Picon

caribou 0.4.18

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

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

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

Regards,
--
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] 

Thanks,

Magdalen

_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
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.

Magdalen




_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
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:

http://download.gnome.org/sources/at-spi2-core/2.15/
http://download.gnome.org/sources/at-spi2-atk/2.15/
http://download.gnome.org/sources/pyatspi/2.15/

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:

http://www.a11y.org/d-bus

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:

git://git.gnome.org/pyatspi2
git://git.gnome.org/at-spi2-core
git://git.gnome.org/at-spi2-atk
Daiki Ueno | 16 Feb 09:17 2015
Picon

caribou 0.4.17

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

News
====
- 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)

Contributors
============
Daiki Ueno
Nicolas Chauvet

Translations
============
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)

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

Regards,
--

-- 
Daiki Ueno
_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
Alexander Surkov | 11 Dec 22:35 2014
Picon

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.

Thanks.
Alexander.
_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
Michael Pozhidaev | 5 Dec 05:43 2014
Picon

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
Picon
Picon

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
IMO. 

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 :-)

Cheers,

-- 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
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
Mike Gorse | 25 Nov 01:18 2014

ANNOUNCE: at-spi2-core 2.15.2 released

At-spi2-core 2.15.2 is now available for download at:

http://download.gnome.org/sources/at-spi2-core/2.15/

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.2
===============

* Make the documentation of ATSPI's STATE_ACTIVE consistent with that of
   ATK's (bgo#740274).

* Add ATSPI_ROLE_STATIC and update documentation for ATSPI_ROLE_TEXT
   (bgo#740340).

* gi-annotations: get_relation_set returns a array of AtspiRelation

Where can I get more information about AT-SPI2
==============================================

The project wiki is available at:

http://www.a11y.org/d-bus

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:

git://git.gnome.org/pyatspi2
git://git.gnome.org/at-spi2-core
git://git.gnome.org/at-spi2-atk
Daiki Ueno | 25 Nov 00:07 2014
Picon

caribou 0.4.16

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

News
====
- Stop using deprecated accessibility events ("focus:*")
- Bug 739837 - Allow label overwrite in keyboard layout
- Bug 739716 - Add more keys to label_map
- Bug 739711 - Escape key does not work in us layout.
- Bug 739526 - Some buttons do not have a label.
- Bug 722634 - [regression] build failure: ImportError: No module named 'caribou_settings'
- Translation updates (Punjabi, Nepali, Slovak)

Contributors
============
Daiki Ueno
Raphael Freudiger

Translations
============
A S Alam (pa)
Dušan Kazik (sk)
Pawan Chitrakar (ne)

Download
========
https://download.gnome.org/sources/caribou/0.4/caribou-0.4.16.tar.xz (398K)
  sha256sum: 8e70090f9cf64e3b42f6995e3228ab1f38a438687d13e2aa9497925a2a6b1d32

Regards,
--

-- 
Daiki Ueno
_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
Magdalen Berns | 22 Nov 20:29 2014

Java ATK Wrapper unimplented methods

Hi list,

Without fully testing each one I went through the java-atk-wrapper code and have been able to identify the following methods and interfaces as being unimplemented or as having an implementation which is incomplete:

Action:
get_localized_name
set_description
Component:
add_focus_handler
get_mdi_zorder
get_alpha
remove_focus_handler
Document Interface (not yet implemented):
get_document_type
get_document
get_attribute_value
get_attribute_value
get_attributes
get_locale
get_current_page_number
get_page_count
EditableText:
set_run_attributes
HyperlinkImpl:
TODO Currently Not fully documented by ATK
Image:
get_image_locale
set_image_description
StreamableContent (not yet implemented and may not have java equivalent):
get_n_mime_types
content_get_mime_type
content_get_stream
content_get_uri
Table:
set_caption
set_row_description
set_column_description
set_row_header
set_column_header
set_summary
add_column_selection
add_row_selection
TableCell (not yet implemented):
get_column_span
get_column_header_cells
get_position
get_row_span
get_row_header_cells
get_row_column_span
cell_get_table
Text:
set_free
attribute_register
attribute_get_name
attribute_for_name
attribute_get_value
Value:
get_minimum_increment
get_range
get_sub_ranges
get_value_and_text
set_value

For now it would be useful to get some feedback on what might be a good idea to focus on implementing. Alejandro has indicated the text interface as quite important so I am thinking this might be the best place to start but I am a bit concerned about what I am seeing with the focus stuff too. I am also quite keen to further investigate what's happening with the Windows interface signals in jawobject.c. Generally, I am interested in what the first impressions on this are so far, before going ahead with a strategy on addressing some of these implementations for java-atk-wrapper.

Magdalen

_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel

Gmane