Re: [orca-list] More granularity of voice selection and user (was Re: Priorities...)



Hi Benjamin:

Somewhat tangentially to this discussion, I'm a web developer
interesting in accessibility, not a regular Orca user. I would like to 
help with this:

Distinguish Q and BLOCKQUOTE in (X)HTML content

http://bugzilla.gnome.org/show_bug.cgi?id=405759

and

Refactor speech generators to provide ACSS per string

http://bugzilla.gnome.org/show_bug.cgi?id=412656

This would be great.  As I hope you know, we're not ignoring these
things.  We don't see a lot of user outcry for these, however, and we
also don't have a good understanding of the real user requirements.  

As a result, they're on the radar screen, but not active targets right
now.  A fun thing about open source, however, is that while there might
be some set of general prioritization of tasks, there's really no
stopping someone from working on something lower on the priority list.
Thus, if someone like you wanted to take these on, I'd have no objection
and would be willing to answer questions you may have.

I can't work out whether this is something so architecturally sensitive 
that it will really need to be done by the core developers. 

It will touch quite a few modules since calls to getSpeech() and
getSpeechContext() are peppered throughout the code.  As such, changing
the underpinnings might be something that one needs to spend a full
weekend hacking on rather than doing over a longer period of time.  The
GUI for allowing people to define different voices, however, could be
done over time.

If not, I'd 
be happy to work on this gradually in my spare time, but would like
a bit more certainty on whether the proposed solution is the one we want
to go for. 

I think the first thing to do is discuss what the end user experience is
supposed to be like.  What do users (who want this functionality) want
to hear?  For example, should the voice use be based primarily on object
role?  Should all of the label/role/state/etc strings of a single object
be presented using the same voice?  Should the granularity be finer than
that?  Once we learn answers for stuff like this, it should lead to even
more questions/answers and ultimately a design that will address what
users want.

Thanks!

Will





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]