Proposal
by Andre Fischer (andre.w.fischer@sun.com),
last modification on November 11th 2001
This paper describes how documents of the StarOffice/OpenOffice.org Impress and Draw applications can be made accessible by using the UNO Accessibility API (UAA).
It will be shown that making Impress accessible can be (largely) reduced to making Draw accessible. This proposal will therefore first give a short introduction to Impress documents and then show that mainly Draw pages have to be made accessible.
Impress documents consist of one ore more pages. Each page can contain a number of objects like
Every page of an Impress document is made up of two parts: a drawing page and a master page. There is one drawing page per document page. Master pages are used to specify material that is visible on more than one page and therefore can be shared between drawing pages. A master page can be used for example to include the page number, time, date, or author.
There are six display modes for visualizing an Impress document:
This is the only graphical edit mode. At any one time there is one document page visible on the screen. Its initial scale is chosen so that the whole page fits in the document window.
The textual content of all pages including title and outliner objects is displayed and can be edited in a hierarchical list. It gives an overview of the document's structure and offers an easy and non-graphical way to create and modify the document. The outline view is certainly very attractive for users which create an Impress slide show via an AT device.
Display of all pages at once. This view acts as a visual selection tool. You can browse the whole document for a specific page and jump from there into the edit mode.
This introduces a third kind of page, the notes page. Each notes page is associated to one document page. It is divided into two parts. The first contains the document page, the second contains a list of notes describing the document page. In this display mode you can not edit document pages.
At the first glance similar to the slide view, this mode puts several--defaults to four--document pages onto one print page. It is used to create a printed version of the whole document. You can neither edit the pages nor can you jump into the edit mode from here.
The slide show mode displays all document pages full-screen one slide at a time in a consecutive order. Mouse clicks or pressing a key advances to the next page. No editing in this mode.
Only the first mode allows the graphical modification of the document. The second lets you change at least the text information. All but the second contain graphical representations of one or more document pages.
As a result we have two different cases. All modes but the second use draw pages for visualizing the document. This case is handled by making the Draw application accessible. Special handling due to the editing capability of the drawing view is not necessary. The outline view has to be handled separately. The two cases are described in more detail in the next two sections.
The UAA uses a set of interfaces to offer a hierarchical representation of an application window. In the following we will focus on representing one draw page. If there is more than one draw page visible on the screen then each one of them is represented by a separate sub-tree.
According to our document representation guidelines only those objects on a draw page will be represented, that are visible at the time of a query. Both Draw and Impress scale new pages so that the whole page fits on the screen. Therefore, only an active rescaling or placing of objects outside the page boundaries will result in objects not being represented.
However, there is one exception to the rule to represent only fully or
partially visible objects. If a connector links a visible object to one
object that is currently not visible, this target object will be included
into the UAA representation. This is necessary to be able to provide the
connectors as AccessibleRelation objects.
All classes that implement the draw pages and the objects--shapes and OLE
objects--that can be inserted into a draw page have to be extended to
support the Accessible service. Calls to their
getAccessibleContext method will return references to instances
of classes that are implemented independently from the draw page and shape
classes. That means that the only modification of existing code is needed
for the support of the XAccessible interface. All other coding
can be done independently in another place.
All fully and partially visible objects on a draw page are represented by
objects that support the AccessibleContext service. They
support the additional services AccessibleComponent,
AccessibleEditableText, AccessibleRole, and
AccessibleText. Whether or not the
AccessibleAction service will be supported has yet to be
discussed. If a shape is linked to other shapes via connectors then the
AccessibleContext object of the shape from which such a link
originates will return a non empty relation set when the
getRelationSet method is called.
Each draw page will be represented in a shallow hierarchy. The root node corresponds to the view that is responsible for drawing a document window. Its children are the representations of all visible draw pages. The children of each draw page node are the representations of the visible shapes on that draw page.
The order of the children of a draw page node depends on the z-order of the represented shapes, i.e. the order in which they are painted onto the screen: if shape A is painted over by shape B, then shape A comes before shape B in the list of children.
The UAA representations of the different view modes described above differ only in their second layers: There are a different number of draw pages and the draw pages have different geometries.
The task to assign roles, names, and descriptions to draw shapes is not a trivial one. There is a multitude of shapes which leads to the problem of creating meaningful default names and descriptions.
The roles could be taken from a small set like 'View', 'DrawPage', and 'Shape' that would have essentially one role per layer. However, this would render the role quite useless. It is preferable to use a larger set of roles that gives each type of shape its own role and maybe distinguishes even between different kinds of views. With this an AT can perform special actions on certain roles. A shape's role would be quite similar to a shape's default name but because roles are taken from a fixed set (fixed in the environment of a given application) while names are free-form strings. Roles are therefore better suited to be processed automatically than names.
On the first glance naming the objects may seem to be straightforward. Simply use the already existing name attribute of the shapes. The problem lies in finding proper default names. A first and trivial solution is to use the shape's type and append a number.
The same holds true with descriptions. One approach can be to use a shape's type and adorn it with a human readable and, more importantly, understandable representation of the shape's properties like fill color, outline width, or font.
However good the defaults for name and description will be, they will never come close to those supplied by the author of a document. Therefore, the author should be more 'encouraged' to do so. It would be helpful to have a special accessibility mode that would--at appropriate times--pop up a dialog box inquiring names and descriptions of shapes that have not yet been given explicit names or descriptions.
There are a number of objects that can appear on a draw page, that deserve special consideration:
XAccessibleRelationSet object returned by the object from
which the connection originates.
The Impress outline view is a relatively simple document visualization and its UAA representation is straightforward. It consists of a hierarchical view of most of the textual information on all slides. Each slide has a top-level entry. The text on the slides follows properly indented.
The UAA tree will use objects implementing
AccessibleEditableText which are nested according to the
hierarchy of the text in the outline view. It will be only those objects be
available that lie inside the visible area.
Entering the outline view creates a preview window that shows a preview of the slide who's text in the outline view contains the cursor. Its content is a single draw page and can be represented accordingly. Because the preview is not directly editable, there is no need to make the preview window focusable.