Re: [orca-list] Update on Jokosher accessibility

[Joanmarie Diggs <joanmarie diggs gmail com>]

Hi Mike.

>   Firstly I just want to make sure we're on the same page as far as 
> terminology goes, this diagram shows what I mean when I refer to the 
> timeline: http://mikeasoft.com/~mike/jokosher-labelled.png Is this also 
> your understanding?

Heh. It wasn't. Thanks for the clarification. I was combining your
timeline with your event lane and calling it "timeline". My apologies.

>   It should be possible to tab through events, when an event is focused 
> it should give the event name, the event position (in seconds) and the 
> event length (in seconds) as an accessibility hint for orca to use (and 
> last time I checked this worked).

Yup, that works. (And I was very much impressed when I noticed this had
been done. :-) )

One thing I found confusing (and why I didn't quite get what was going
on), is that Orca presented the audio event as having focus, but then
the arrow keys didn't do anything (other than move focus elsewhere). I
didn't realize that you couldn't interact with the audio event using the
keyboard until Return had been pressed. In retrospect, the event is
behaving just like the buttons around it do in this regard.

Anyhoo....

> It's then possible to select an event 
> by pressing return.

Confirmed. Thanks! :-)

>  Once an event is selected it's then possible to:
>       * Move that event with the left/right arrow keys.

Confirmed. Very cool.

That does raise the question of then how to best present the new start
and end positions to the user. Right now it looks like you're exposing
this information by updating the accessible name, which is great when
the object first gets focus; but if you're trying to non-visually nudge
an event to a new location, you don't want to have to listen through
"Event, Recorded audio, 17.24 seconds long, starting at" just to hear
"10.19 seconds". Arrow again, to hear "Event, Recorded audio, 17.24
seconds long, starting at" <new time>. Etc. The goal is to present the
user with the relevant info as soon as possible.

While we (Orca team) could try to parse the string in the accessible
name, it would be nifty if, say, the start and end times are exposed as
attributes on the AtkObject associated with the event.

>       * Select a point for cutting by holding shift and pressing left/right 
> then pressing space to cut.

Confirmed. :-)

However, as I use shift+left/right, I'm not seeing any way to identify
the new location of the point. Are you exposing that value to ATs? If
not, perhaps an object:property-change:accessible-value emitted by the
focused event....

Once I press space to cut, I'm not seeing any
object:children-changed:add events to (which would be a nice way to
confirm the successful split to the user.

I'll check out the other points you mention.

>   Is this the sort of behaviour that you'd be expecting and merely the 
> undiscoverability of these options is letting us down, or is there 
> something more/different you'd like to see in this area?

I think mostly it's a matter of discoverability. If the audio event had
changed appearance upon gaining focus and didn't require my pressing
Return to make the event I wanted to edit something I could interact
with via the keyboard, I suspect I would've worked out the other
commands. :-) Though, as an aside, Shift+Arrows typically select;
Alt/Ctrl+Arrows are more likely suspects when the desire is to move
something without selecting.

In terms of Orca users and discoverability.... Orca has a tutorial
message option. When enabled, it adds helpful hints about the object
that just got focus. In other words, when an Orca user presses Tab and
lands on an event, I can cause Orca to speak and braille the fact that
you should press Return in order to interact with the event, can use
Shift+Left/Right followed by Space to split the wave etc. That should
make life easier for Orca users who are new to Jokosher.

>   I'm not sure there's a great deal of accessible non-visual feedback on 
> these actions as they're being performed though, do you have any advice 
> on how this might be handled better? What's generally done during 
> changes to scrollbars for example?

I mentioned some events above that I think will help on the non-visual
feedback front.

Scrollbars typically issue an object:property-change:accessible-value
event. (Which Orca typically ignores for actual scrollbars because this
change is irrelevant. That's where Orca's scripts for apps comes into
play.)

In light of the fact that Jokosher is even more accessible than I
realized (D'oh! and thanks!!), what probably makes the most sense is for
me to start on the Orca script for Jokosher, which I'll begin tomorrow.
As things come up for which there seems to be no way to provide feedback
non-visually, I'll ask and/or file a bug in launchpad. And we can go
from there.

>   On the topic of improving our help documentation is there a common 
> section heading recommended for use across all applications for these 
> sorts of areas to help users find the relevant accessibility specific 
> information quicker? Or would a general section such as "Keyboard 
> Shortcuts" be enough?

"Keyboard Shortcuts" should be fine for a dedicated list of commands. In
addition, it might be nice if the main documentation included the
keyboard shortcuts along with the mouse commands. For instance, in "The
Recording Workspace" under "Split" it says

        "...To split, double-click in the instrument lane at the point
        where the audio should be divided."

Then it moves on to "Trim".

>   The other issues should be fairly simple to fix and I'll try to look 
> at them in the next few days.

Awesome.

>   Thanks again for helping us with this, we'd like Jokosher to be as 
> easy to use as possible for everybody :).

Can we clone y'all? ;-)

Take care.
--joanie