[g-a-devel]Re: [ui-dev] Text in transient objects.

[Peter Korn <peter korn sun com>]

Hi gang,

Because this has implications across other accessibility toolkit
implications, I'm cc-ing several other lists.  To summarize for those other
lists, the issue in this thread is how to deal with text objects that are
inside (and perhaps fairly deeply nested inside) other objects where those
objects are the things getting focus (and not the text objects inside them),
especially transient ones like table cells in a spreadsheet.  Also, this
situation is complicated by situations (e.g. in StarOffice) where there are
multiple distinct text objects within that object-getting-focus.

Everything I'm going to say pretty much boils down to "what he [Bill] said". 

Text is too central to too many apps, which place that text in their own
places within the heirarchy of their widgets (and differently across
different toolkits).

This means that:

 1. getting all apps in all toolkits to behave the same in the heirarchical
    placement of their text is untenable

 2. getting all assistive technology products to share a common algorythm
    for finding the text in the right places within subtrees of widgets
    is likewise untenable

Therefore, our only option is to have conventions for indicating where the
text is.  To date, that convention has been to either:

 1. send focus to the text widget with focus

 2. use the AccessibleActiveDescendent event to indicate the "active"
    descendent (child, grandchild, etc.) that has text and is "active"

It occurs to me that we might be able to use a third mechanism - to introduce
a new AccessibleRelation to indicate that a (potentially distant) child
(potentially children) of an object getting focus is/are the text widget(s)
of importance for that object.  Something like "TextFor" and "TextedBy" (or
some better terminology than what I was able to come up with).  This would
work in cases where the object wasn't transient, and perhaps even in cases
where it was! (when the transient table cell gets focused, we not only create
an instance of it, but of it's children, complete with their relationships).


Thoughts on the relationship approach (vs. approach #2 above)?


Peter Korn
Sun Accessibility team

Bill Haneman wrote:
> 
> On Fri, 2002-05-31 at 19:45, Rich Franzen wrote:
> > Andre,
> >
> > I am new to this list.  I have a fair amount of UI experience but am new at
> > the concept of accessibility.  I assume the goal is to offer useability to
> > people with special needs (blind, mobility or coordination problems, etc).
> > Sorry if I write obvious stuff.
> >
> > IMO, Drawback "1i" (below) is serious.  Consistency is always a goal, and
> > this is even a greater concern to someone trying to use OOo via
> > accessibility methods.
> 
> Hi Rich:
> 
> Thanks for your interest and thoughtful response.  I must say however
> that in my view, as GNOME accessibility architect and in view of the way
> text is currently being treated in the Swing implementation of the Java
> Accessibility API, and the GNOME Accessibility API implementation
> provided for GTK+ and GNOME widgets, Andre's concern about "1i" is
> unfounded.  The accessibility APIs do implement their respective "Text"
> interfaces in different contexts, and though the interfaces themselves
> provide consistency across those contexts, the APIs are in any case
> hierarchical.  That means that sometimes text occurs as multiple
> elements within a container, and sometime as a single element; though of
> course in practice *every* text element is a child of some containing
> instance.
> 
> Andre seems to be suggesting that text cells should also hold their text
> in children (usually single children).  In my view this adds nothing but
> an additional needless indirection which will either complicate the
> user's navigation, or if the assistive technology using this API wishes
> to simpify the user presentation, it complicates the assistive
> technology.  It is reasonable for some cells to be "text cells", some to
> be "image" or "button" or some other kind of cells, and for some cells
> to be compound objects.
> 
> I agree that consistency is important, but I think that consistency
> across toolkits is much more important than trying to make text cells
> structurally like document containers.  GNOME and Java expose table and
> spreadsheet cells as objects which, if they contain text only, expose
> that text directly and not as child objects.  Thus it seems to me that a
> consistent presentation of accessibility APIs from OOo with the other
> toolkits on the user's desktop would be obstructed by Andre's
> suggestion.
> 
> best regards,
> 
> Bill
> 
> You want to give all users full access.  Ideally
> > this can be achieved without reducing overall flexibility to some
> > least-common-denominator design.
> >
> > The hierarchal storage of data is pretty-much transparant to most users.
> > They probably know that a Calc cell can contain text, formulas, or
> > calculated numeric values.  Once in a while they might attach a note, lock
> > the cell, or give it special formatting instructions -- something beyond the
> > norm.  Most users know how to view or change the particular part of the data
> > they are interested in.
> >
> > So the general question seems to boil down to this.  How do you offer full
> > OOo capabilities to someone who cannot control it with his mouse?  One
> > answer is generalization.  Provide an accessibility interface which maps
> > closely to the hierarchal nature of the information.  The data is stored in
> > layers; allow it to be accessed via those same layers.
> >
> > I am ignorant of what you have accomplished to date.  For the sake of
> > discussion let us say that "accessibility" involves the use of a numeric
> > keypad in control mode (Left, Right, PgUp, etc).  How can it be generalized
> > to present sometimes hierarchal data?  Here would be one approach for a
> > spreadsheet.
> >
> >     <5>    (Re)Display information in current layer.
> >            This would be top layer upon cell entry,
> >            probably what the cell normally shows to a
> >            sighted user.
> >
> >     <Up,Down,Left,Right>
> >            Move to the appropriate ajacent cell.
> >            Resets layer to top.
> >
> >     <PgUp> Move to data in the next higher layer.
> >
> >     <PgDn> Move to data in the next lower layer.
> >
> >     <Home> Toggles auto-display of information.
> >            On:  moving layer or cell displays contents.
> >            Off: <5> must be pressed to display contents.
> >
> >     <End>  Toggle data-entry mode.
> >            On:  new values entered.
> >                 <Left,Right> move within string.
> >                 <Up> move to beginning of string.
> >                 <Down> move to end of string.
> >            Off: string accepted, current values displayed
> >
> >     <+>    Display extra information, if any
> >
> >     <Enter> Completes cell transaction, move to next cell.
> >             If data entry-mode is On, <Enter> first accepts
> >             the string before moving to next cell.  Data-
> >             entry mode is then turned Off.
> >
> > Example (auto-display On):
> >
> >     <Down> "Cell C5, normal content, dollars 24.87"
> >     <PgUp> "already at top"
> >     <PgDn> "formula, equals C4 plus B5"
> >     <PgDn> "format, US dollars, 2 decimal places"
> >     <PgDn> "note, none specified"
> >     <End>  "begin data entry"
> >   types:   March total<End>
> >     <5>    "note, March total"
> >     <PgDn> "foreground color, defaulted to black"
> >     <PgDn> "background color, pale white"
> >     <+>    "background color, #f1f1f1"
> >     <Right> "Cell D5, normal content, empty"
> >     <Right> "Cell E5, normal content, 12"
> >     <PgDn>  "formula, literal 12"
> >     <PgUp>  "normal content, 12"
> >
> > Having easy control of the Auto-Display mode would be especially important
> > to blind users.  The quoted strings above represent what the interface would
> > actually speak.  For those hearing the data, manuevering would be quite
> > tedious if every keypress started talking.  But when he is at the desired
> > cell, it might become tedious to keep pressing <PgDn><5> to "view" all the
> > information.
> >
> > For accessibility to a sighted person, the interface would not need to
> > prefix the values.  The information can be viewed normally and in context.
> >
> > I know not all keyboards have numeric pads.  Please interpret the above as
> > simply one way of presenting hierarchal information in a generalized and
> > consistent, yet complete, fashion.
> >
> > -- Rich
> > --- http://rocq.home.att.net
> >
> >
> > --- Andre Fischer <Andre W Fischer Sun Com> wrote:
> > > Hi all,
> > >
> > > I would like to ask all of you for your opinion and advice about the
> > > following:
> > >
> > > Problem:
> > > While testing our accessibility implementation with the AT tool ZoomText
> > > we became aware of a problem with text in transient objects.  When you
> > > travel over the cells of a Calc document only the name but not the (text)
> > > content is not read by ZoomText.
> > >
> > > Analysis:
> > > The problem is of course not restricted to ZoomText or Calc.  The text in
> > > Calc cells is not read because
> > >   a) Text is at the moment represented in a
> > >      hierarchical structure where the text paragraphs are children of the
> > >      cells.
> > >   b) AT tools (in this case ZoomText) only read information of
> > >      accessible objects that have the focus.
> > >   c) When travelling to a cell this cell is focused but its children are
> > >      not.  They are, therefore, ignored.
> > > Moreover, cells are transient objects which would lead to problems with
> > > non-transient children that wanted to send focus events.
> > >
> > > Possible Solutions:
> > > In several discussions about this problem we have so far identified the
> > > following possible solutions/workarrounds:
> > >    1) Merge all paragraphs of the children of a cell and make the text
> > >       accessible directly via the cell (and the XAccessibleText interface
> > >       supported by  the cell).  When the cell gets the focus an AT tool
> > >       will use the XAccessibleText interface to extract and read the text.
> > >
> > >       This, however, has two drawbacks:
> > >       i)  Inconsistency with text representation at other places (e.g. the
> > >           Writer) where text is still represented hierarchically.
> > >       ii) Certain elements of text like graphical bullets or tables or
> > >           images can not be represented without the use of children.
> > >
> > >    2) Use the first n characters or words or sentences as name or
> > >       description of the cell.  This should be enough information for
> > >       navigation.  If you want more detailed information rely on special
> > >       key sequences supported by AT tools that read the whole content of
> > >       all children.
> > >
> > > Are there other solutions?
> > >
> > > Which one do you prefer?
> > >
> > >
> > > Andre
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! - Official partner of 2002 FIFA World Cup
> > http://fifaworldcup.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe ui openoffice org
> > For additional commands, e-mail: dev-help ui openoffice org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe ui openoffice org
> For additional commands, e-mail: dev-help ui openoffice org