Meeting Minutes	OpenOffice.org

Form Layer Accessibility

Date & Time	April, 15th, 2002, 15:00 - 16:00 MEST
Attendees	MT - Malte Timmermann
	AF - Andre Fischer
	CL - Christian Lippka
	FS - Frank Schönheit
Minute Taker	FS - Frank Schönheit
Recipients	News group sun.star.minutes

1. Action Items

Task	Owner	Status
New Action Items
create a base class for accessible UNO components which can be UNO-tunneled and re-parented	FS	new
create a fallback implementation for the Accessibility component of an UNO control	FS	new
check how to obtain an XControl from an XControlModel and a drawing layer view	FS	new
integrate the Accessibility components form SdrUnoControls (once finished) into the Accessibility Component Tree of the drawing layer	AF	new

2. Intention of this meeting

The intention of this meeting was to clarify what needs to be done for making form layer controls accessible. More general, the Toolkit controls would have to be made accessible (in terms of supporting the respective UAA (UNO Accessibility API)), which then would imply accessibility of form controls as well as the Basic dialog editor's control design part.

3. Inventory

Currently, only the peers for UNO controls are accessible - they inherit the respective UNO functionality from the VCL controls they're based on.

3.1. Design Mode vs. Alive Mode

There should be a difference in representing UNO controls in the UAA (UNO Accessibility API) between controls in alive and controls in design mode. In design mode, a VCL control (such as a Edit field) is used for painting the control only, but does not expose e.g. the ability to being focused. So it seems necessary to have two different implementations.

For alive mode, it seems quite natural to use the accessibility wrapper of the VCL controls (which can be obtained from the peers), which already are (or are going to be) implemented. For some sub problems then, see below.

For the design mode, we decided to use an own wrapper class (action item: FS), which only provides the most basic functionality such as geometry information and a name. Finally, this is all which the controls in design mode are used for. Everything else can be accessed via for instance the property browser.

3.2. Name/Description

We decided to provide no description (means an empty one) for the moment. The problem is that else we would need an user interface for the creator of a document (or smaller: the creator of a form control) to set such a description. This is consistent with "ordinary" shapes (not carrying an UNO control), which at the moment neither have a AccessibleDescription nor an user interface for the creator of the document to set such a description.

For the name, we decided to provide the name which can be obtained at the model (if any, this is the case for form controls, but not for Basic controls), or a default name (such as "edit field <no>").

3.3. AccessibleParent

A problem which arose is related to the parent objects in the hierarchy of Accessibility objects. No matter if we use the default accessibility object provided by VCL (in alive mode), or a fallback implementation (in design mode), the component never knows it's proper parent. In the VCL case, it would even know a wrong parent.

After quite some discussion we decided to use an UnoTunnel based implementation. For this, a new base class (AccessibleImplementation or so) will be created (action item: FS), which does nothing more than supporting the XUnoTunnel, providing a static method for re-parenting of an existing component, and a (not static) method for retrieving the current AccessibleParent.
Every class which needs re-parenting could then derive from this helper.

With this help, we could rely on the standard implementation for retrieving the AccessibleIndexInParent: ask the parent for all children and check for equivalence with the component itself.

3.4. Geometry information

The accessibility wrapper for an UNO control needs to support the XAccessibleComponent interface for providing geometry information, too. We think that this can be solved in our accessibility implementations (in opposite to an outer, shape-specific implementation which would just aggregate our implementation) by taking into account:

• the screen coordinates of the VCL parent

• the screen coordinates of the Accessibility parent

• the relative coordinates of the component relative to it's VCL parent

These information should be sufficient for calculating the coordinates relative to the Accessibility parent, which is what is needed for UAA.

In general, all geometry information available in the Toolkit (and transported via UNO) is in Pixel, so we should not need to bother with mappings.

3.5. Integration into the Document's Accessibility Component Tree

When integrating the Accessibility components for form controls into the document's tree, we need a method for retrieving a UNO control, given it's model and the view where it resides in (remember that we have one model, but potentially multiple views, and UAA is view-centric).

The code for doing this should be already somewhere in SVX, FS is to look it up and provide the details to AF.

AF is to do the integration once the implementation is finished. It's not yet decided whether the accessibility component for a control should be a child of the accessibility component of the respective shape, or if they should be "merged" to one component.

3.6. Notifications

• As controls in design and alive mode are represented by different implementations, we need to dispose the current implementation of all controls as soon as the design mode is switched.

• Whenever a shape is positioned or sized, the notification for this is in the responsibility of the accessibility component of the control, too.

• state changes: The only state which can change during the lifetime of an control's accessibility component is "selected". This means whenever a shape in the view is marked, the acc-component needs to be notified of this, and it then should notify it's AccessibilityListeners.
  For the first step (notifying the acc-component), we decided to use the base class introduced in chapter 3.4. The alternative would be a wrapper class in the drawing layer, which aggregates the AccessibleContext of the control, just for the reason of overriding state handling.