headers
Samuel Thibault | 1 Mar 2012 02:27
Gravatar

Health & Accessibility topic of LSM 2012

LSM/RMLL 2012
                 13th Libre Software Meeting
                      July 7-12, 2012
                     Geneva, SWITZERLAND
                   http://2012.rmll.info/
              Call For Papers and Participation
           limited on health & accessibility topic
     [we apologize for duplicate receipt of this message]
         Last call before deadline : march *31* 2012

Dear Colleague,

The 13th Libre Software Meeting (LSM) takes place in Geneva,
Switzerland, July 7-12 2012 (http://2012.rmll.info/).

LSM is an annual non-commercial conference on Libre Softwares that
includes round tables and practical workshops. The objective is
to provide a place where users, developers and promoters of Libre
Software can exchange ideas and information. Attendance is free and
open to everyone. 

Each year the health & accessibility workshop is held as part of
this broader meeting.  This year, it will be organized around 3
major fields:

- Accessibility, autonomy and dependency management (mobile/web
accessibility, accessible desktop applications, usability, ...)

- Hospital information system & Tele-health (EHR, telemedicine systems,
workflow solutions, PACS, HL7, ...)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Piñeiro | 6 Mar 2012 01:32
Favicon

ATK 2.3.91 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. You should also avoid using
sound, graphics, or color as the sole means of conveying information
to the user.

The GNOME desktop ships with a number of accessibility tools which
enable users with disabilities to take full advantage of their desktop
and applications. Applications that fully implement ATK will be able
to work with the accessibility tools. GNOME's accessibility tools
include a screen reader, a screen magnifier, an on-screen keyboard,
and Dasher, an predictive text entry tool.

News
====
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Gorse | 6 Mar 2012 01:44
Favicon

ANNOUNCE: AT-SPI 2.3.91 released

AT-SPI 2.3.91 is now available for download at:

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

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

* [core] Fix for BGO#668334: Set correct end offset in
   atspi_text_get_attributes.

* [core] Add some type checking on method replies; this should prevent crashes
   if an application-side AT-SPI implementor returns something unexpected.

* [core] Call g_settings_sync after updating toolkit-accessibility.

* [core] Add ScreenReaderEnabled D-Bus property as a proxy for the GSettings
   key.

* [core] Fix for BGO#669344: Don't use "restrict" as a variable name, since it
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander Surkov | 7 Mar 2012 07:45
Picon

ATK STATE_EDITABLE

Hi. There's interesting discussion about editable vs unavailable state
happening at Mozilla bug -
https://bugzilla.mozilla.org/show_bug.cgi?id=733382. I put here some
summary of it.

The ATK spec says: "Indicates the user can change the contents of this
object" - http://www.pygtk.org/docs/pygtk/atk-constants.html#atk-state-type-constants.
That means readonly and disabled text controls shouldn't be exposed as
editable. ATs might be interested to know whether the object is
potentially editable to put it into navigation order. Also that makes
it similar to other 'able' states like expandable or multiselectable
except focusable state which is sort of opposite to absent enabled
state. So let's consider an exampe:

<p contentEditable="true" aria-disabled="true">

Currently: no enabled state, no editable state. This paragraph exposed
absolutely identically to plain <p>.
Proposed: no enabled state, editable state is presented. AT understand
this paragraph is sort of control and can be used for typing when
enabled.

Please let me know what you think.

Thank you.
Alex
Permalink | Reply | 2 comments |
headers
Piñeiro | 7 Mar 2012 13:40
Favicon

ATK 2.3.93 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. You should also avoid using
sound, graphics, or color as the sole means of conveying information
to the user.

The GNOME desktop ships with a number of accessibility tools which
enable users with disabilities to take full advantage of their desktop
and applications. Applications that fully implement ATK will be able
to work with the accessibility tools. GNOME's accessibility tools
include a screen reader, a screen magnifier, an on-screen keyboard,
and Dasher, an predictive text entry tool.

News
====
(Continue reading)

Permalink | Reply | 0 comments |
headers
Piñeiro | 7 Mar 2012 15:40
Favicon

Re: ATK STATE_EDITABLE

On 03/07/2012 07:45 AM, Alexander Surkov wrote:
> Hi. There's interesting discussion about editable vs unavailable state
> happening at Mozilla bug -
> https://bugzilla.mozilla.org/show_bug.cgi?id=733382. I put here some
> summary of it.
>
> The ATK spec says: "Indicates the user can change the contents of this
> object" - http://www.pygtk.org/docs/pygtk/atk-constants.html#atk-state-type-constants.
> That means readonly and disabled text controls shouldn't be exposed as
> editable. ATs might be interested to know whether the object is
> potentially editable to put it into navigation order. Also that makes
> it similar to other 'able' states like expandable or multiselectable
> except focusable state which is sort of opposite to absent enabled
> state. So let's consider an exampe:
>
> <p contentEditable="true" aria-disabled="true">
>
> Currently: no enabled state, no editable state. This paragraph exposed
> absolutely identically to plain <p>.
> Proposed: no enabled state, editable state is presented. AT understand
> this paragraph is sort of control and can be used for typing when
> enabled.
>
> Please let me know what you think.

I think that make sense maintaining that state to expose that "would
be", as mentioned on the bug. ATK_STATE_EDITABLE + ATK_STATE_DISABLED
would mean that you can't edit it now (as is disabled) but that
potentially this is editable.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexander Surkov | 7 Mar 2012 17:23
Picon

Re: ATK STATE_EDITABLE

> I think that make sense maintaining that state to expose that "would
> be", as mentioned on the bug. ATK_STATE_EDITABLE + ATK_STATE_DISABLED
> would mean that you can't edit it now (as is disabled) but that
> potentially this is editable.

Cool. What's the usual process that's needed to be done before the the
idea gets into the spec? (Btw, latest IA2 spec allows editable state
on readonly textboxes).

The idea to keep states as methods looks appeal. Other great win is
this is performant way since the server doesn't need to calculate
states all together when AT doesn't need them. I assume the cost of
the server's method call is quite low on ATK so if AT needs to get
several states then it can call several methods unlike the case of out
of process calls on Windows.

Anyway it sounds interesting. I'd like to follow this progress.

Thank you.
Alex.

On Wed, Mar 7, 2012 at 11:40 PM, Piñeiro <apinheiro <at> igalia.com> wrote:
> On 03/07/2012 07:45 AM, Alexander Surkov wrote:
>> Hi. There's interesting discussion about editable vs unavailable state
>> happening at Mozilla bug -
>> https://bugzilla.mozilla.org/show_bug.cgi?id=733382. I put here some
>> summary of it.
>>
>> The ATK spec says: "Indicates the user can change the contents of this
>> object" - http://www.pygtk.org/docs/pygtk/atk-constants.html#atk-state-type-constants.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Piñeiro | 20 Mar 2012 00:36
Favicon

ATK 2.3.95 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. You should also avoid using
sound, graphics, or color as the sole means of conveying information
to the user.

The GNOME desktop ships with a number of accessibility tools which
enable users with disabilities to take full advantage of their desktop
and applications. Applications that fully implement ATK will be able
to work with the accessibility tools. GNOME's accessibility tools
include a screen reader, a screen magnifier, an on-screen keyboard,
and Dasher, an predictive text entry tool.

News
====
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Gorse | 20 Mar 2012 22:00
Favicon

ANNOUNCE: AT-SPI 2.3.92 released

AT-SPI 2.3.92 is now available for download at:

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

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

* [core] Some changes to try to prevent at-spi2-registryd from incorrectly
   thinking that an AT is hung and passing keys meant for it to the application.

* [core] Fix crash fetching an error from a reply when retrieving a property.

* [atk] Add Khmer and Malayalam translations.

* [pyatspi] Another fix for --enable-tests.

Where can I get more information about AT-SPI2
==============================================
(Continue reading)

Permalink | Reply | 0 comments |
headers
Piñeiro | 26 Mar 2012 20:59
Favicon

ATK 2.4.0 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. You should also avoid using
sound, graphics, or color as the sole means of conveying information
to the user.

The GNOME desktop ships with a number of accessibility tools which
enable users with disabilities to take full advantage of their desktop
and applications. Applications that fully implement ATK will be able
to work with the accessibility tools. GNOME's accessibility tools
include a screen reader, a screen magnifier, an on-screen keyboard,
and Dasher, an predictive text entry tool.

News
====
(Continue reading)

Permalink | Reply | 0 comments |

Gmane