Re: Orca debugging question

Yeah... Sorry--those sockets are for direct peer-to-peer D-Bus 
connections, which send messages faster than they would be sent if they 
were routed through dbus-daemon, but it makes it harder to debug that way. 
Perhaps it could be made to work; I guess at-spi2-atk would need to handle 
some additional method calls that are normally handled by dbus-daemon and 
send copies of messages to additional connections that have a match rule 
asking for them. Anyway, you could build at-spi2-atk with --disable-p2p 
(this is usually what I do temporarily when I want to run dbus-monitor). 
You could then run something like

dbus-monitor --address `xprop -root | grep AT_SPI_BUS | sed -e 's/.*= "//' | sed -e 's/"$//'`

-Mike

On Mon, 31 Oct 2011, Michael Pozhidaev wrote:

> Hello, everybody!
>
> I am trying to prepare orca-3.2.1 for using in ALT Linux
> distribution, but it is not working properly. Please, help me to debug
> it and fix all problems!
>
> Orca can speak, so I hear welcome message at startup and sequence of questions at
> first orca start are spoken with voice properly, but there are no
> notifications on my cursor moving in menus and any dialogs. There is
> total silence after orca speaks its welcome message.
>
> My idea was to connect to dbus with dbus-monitor and check if there are
> any events when I changing cursor position. I found at-spi dbus socket
> in the /tmp/at-spi2, but establishing a connection is impossible. The

Coming to grips with the state of a11y in GNOME

I've been asked to present my thoughts on accessibility in GNOME,
again. After some discussions and some playing with orca in GNOME
3.2.1, here's what I have come up with. Again, this is largely my
opinions, and not meant as an attack.

The current state of accessibility in GNOME
----------------------------------------------------------------

Most of the accessibility features of GNOME 3 can be used without
turning on toolkit accessibility:

- High-contrast and large text are implemented via theming

- Zoom is entirely implemented in the shell

- The screen keyboard is implemented in the shell

- Visual alerts are implemented with a combination of AccessX,
  XKB and the window manager

- The keyboard accessibility features (sticky/slow/bounce/mouse keys)
  are all handled entirely on the X layer

Most of these features work reasonably well, if somewhat limited (zoom
and the screen keyboard could clearly benefit from more widget-level
information, such as focus tracking and entry type hints). The only
accessibility feature that really requires toolkit accessibility is
the screen reader.

The screen reader, orca, clearly is our 'flagship' AT. In my recent

Re: Coming to grips with the state of a11y in GNOME

On Thu, Nov 3, 2011 at 9:13 PM, Matthias Clasen
<matthias.clasen <at> gmail.com> wrote:

> - I couldn't get a word out of firefox - I thought maybe my gtk2 a11y
> stack was misconfigured, but openoffice did speak...

this is due to firefox still looking for the old gconf key for
activating accesibility instead of gsettings.

Running it with GNOME_ACCESSIBILITY=1 env var should fix it. The plan
is to use directly dbus to check if accessibility is enabled:

https://bugzilla.mozilla.org/show_bug.cgi?id=693343

Thanks!

Salu2

Re: Coming to grips with the state of a11y in GNOME

Matthias Clasen <matthias.clasen <at> gmail.com> writes:

> The screen reader, orca, clearly is our 'flagship' AT. In my recent
> experience with orca, it worked surprisingly well and spoke to me for
> hours. The impression I got was much better than I had expected. In
> earlier attempts (sometime during 3.1.x), it randomly stopped speaking
> to me and I was unable to make it speak again.
>
> Problems I've seen today include
>
> - gnome-shell crashes when orca is restarted
>
> - interacting with treeviews while orca is running easily crashes
> (just select a file in the file chooser in any app...)
>
> - people have also seen gnome-terminal crash with orca
>
> - Insufficient labelling in new UIs, e.g gnome-shell is largely just
> 'panel' to orca...
>
> - Lack of a11y support in 3rd party widgets (stock widgetry in
> evolution is read just fine to me, but I don't hear any of the
> 'interesting' things: subjects, senders, email bodies...)
>
> - I couldn't get a word out of firefox - I thought maybe my gtk2 a11y
> stack was misconfigured, but openoffice did speak...
>
> What are the problems ?
> -----------------------------------
>

Re: Coming to grips with the state of a11y in GNOME

On Fri, 4 Nov 2011, Piñeiro wrote:

>> - people have also seen gnome-terminal crash with orca
>
> I don't know the details, but I think that Mike Gorse already detected
> and started to work here.

Fwiw, I haven't fixed any crashes in gmone-terminal, nor have I seen it 
crash or heard of it crashing that I can remember. ALl I did was to make 
some changes needed because of the GTK a11y refactor 
(http://bugzilla.gnome.org/show_bug.cgi?id=654630). I suspect something 
similar is going on with evolution custom widgets--typically third-party 
apps would fetch the gail type via the atk factory and derive from it, and 
that no longer works. Right now a third-party app has to replicate a whole 
bunch of component/focus-handling code from gtk in order for a custom 
widget to be accessible, since GtkWidgetAccessible and its related classes 
are not currently public, so a class cannot derive from them.

(I'm at a conference and can't write more right now, but it's good to have 
some discussion.)

-Mike

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

HTML 5 figure and figcaption elements.

Hi. HTML 5 provides two new elements figure and figcaption that seems
to don't have a good way for ATK mapping.

The proposal is:
1) introduce new ATK role for figure element like ROLE_FIGURE
2) use ROLE_CAPTION for figcaption element
3) make figure and figcaption accessible objects related by label relations

Resources:
w3c: http://dev.w3.org/html5/spec/grouping-content.html#the-figure-element
example: http://www.w3schools.com/html5/tryit.asp?filename=tryhtml5_figure
TPG blog: http://www.paciellogroup.com/blog/2011/08/html5-accessibility-chops-the-figure-and-figcaption-elements/
Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=658272
IA2 thread: http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2011-November/001550.html

I would love to hear your feedback.

Thank you.
Alex.

Re: HTML 5 figure and figcaption elements.

On 11/09/2011 11:07 AM, Alexander Surkov wrote:
> Hi. HTML 5 provides two new elements figure and figcaption that seems
> to don't have a good way for ATK mapping.
>
> The proposal is:
> 1) introduce new ATK role for figure element like ROLE_FIGURE
> 2) use ROLE_CAPTION for figcaption element
> 3) make figure and figcaption accessible objects related by label relations

This proposal seems sensible, but I have a question.

From the resources, on the figure description I can read this:

"The element can thus be used to annotate illustrations, diagrams,
photos, code listings, etc,"

In that sense, it seems that most of the elements that will be assigned
this new ATK_ROLE_FIGURE role, has right now a ATK_ROLE_IMAGE. So, my
question:

  * Is there any case of a FIGURE not being a IMAGE?
  * And the opposite, is there any case of a IMAGE not being a FIGURE?

My main concern here is the usual of someone having problems to figure
out which one should be used. I guess that this is not a issue on IA2,
as I didn't find a ATK_ROLE_IMAGE equivalent here:

https://developer.mozilla.org/en/Accessibility/AT-APIs/IA2/Roles

>

Re: HTML 5 figure and figcaption elements.

Hi. Figure element is supposed to contain or group illustrations,
diagrams and etc so role_image is inside a figure accessible.
Originally I tempted to say we don't need an accessible for a figure
and we should expose the underlying image labelled by figcaption
element but that seems doesn't work well when figure is used to group
a set of images or diagrams.

I think when AT sees a figure accessible then it should announce this
is a figure and the figure name obtained from figcaption accessible
and then allow user to go into the figure to pick up underlying
elements. It's used to introduce a sort of new level of abstraction so
that the user goes into it when he's interested in details. For
example:

<figure>
  <figcaption>Alhambra</figcaption>
  <img src="alhambra.jpg" alt="A room of the palace and a view of the
Court of the Lions.">
</figure>

Thanks.
Alex.

On Wed, Nov 9, 2011 at 11:43 PM, Piñeiro <apinheiro <at> igalia.com> wrote:
> On 11/09/2011 11:07 AM, Alexander Surkov wrote:
>> Hi. HTML 5 provides two new elements figure and figcaption that seems
>> to don't have a good way for ATK mapping.
>>
>> The proposal is:
>> 1) introduce new ATK role for figure element like ROLE_FIGURE

Re: HTML 5 figure and figcaption elements.

On 11/10/2011 05:25 AM, Alexander Surkov wrote:
> Hi. Figure element is supposed to contain or group illustrations,
> diagrams and etc so role_image is inside a figure accessible.
> Originally I tempted to say we don't need an accessible for a figure
> and we should expose the underlying image labelled by figcaption
> element but that seems doesn't work well when figure is used to group
> a set of images or diagrams.
>
> I think when AT sees a figure accessible then it should announce this
> is a figure and the figure name obtained from figcaption accessible
> and then allow user to go into the figure to pick up underlying
> elements. It's used to introduce a sort of new level of abstraction so
> that the user goes into it when he's interested in details. For
> example:
>
> <figure>
>   <figcaption>Alhambra</figcaption>
>   <img src="alhambra.jpg" alt="A room of the palace and a view of the
> Court of the Lions.">
> </figure>

New questions, sorry ;).

Taking into account previous mail, saying that you want to expose an
object with ATK_ROLE_CAPTION, one can think in this accessible object
hierarchy:

      AtkObject (ATK_ROLE_FIGURE, num_children=2) name=Alhambra
         AtkObject(ATK_ROLE_CAPTION, num_children=0), name=Alhambra
         AtkObject (ATK_ROLE_IMAGE, num_children=0) description="A room ..."

Re: HTML 5 figure and figcaption elements.

Hey.

That's usual practice when we expose label accessible for label
element associated with control. For example:
<label for="input">label</label>
<input id="input">
or
<table>
  <caption>caption</caption>
</table>
AT is free to ignore the label accessible since they can use
accessible name on associated element or use labelled_by relation to
obtain label accessible if it has styles or underneath hierarchy.

I think we shouldn't process figure and figcaption differently. So the
idea is let AT decide.

I don't see a reason why your example wouldn't be possible. w3c
provides similar example (a figure containing several images) at
http://dev.w3.org/html5/spec/grouping-content.html#the-figure-element.

Thank you.
Alex.

On Fri, Nov 11, 2011 at 3:53 AM, Piñeiro <apinheiro <at> igalia.com> wrote:
> On 11/10/2011 05:25 AM, Alexander Surkov wrote:
>> Hi. Figure element is supposed to contain or group illustrations,
>> diagrams and etc so role_image is inside a figure accessible.
>> Originally I tempted to say we don't need an accessible for a figure
>> and we should expose the underlying image labelled by figcaption