The Free and Open Productivity Suite
Follow us on Twitter: @ApacheOO

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





Overview

1. Action Items

2. Intention of this meeting

3. Inventory

3.1. Design Mode vs. Alive Mode

3.2. Name/Description

3.3. AccessibleParent

3.4. Geometry information

3.5. Integration into the Document's Accessibility Component Tree

3.6. Notifications

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:

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

Page 1 of 1

Apache Software Foundation

Copyright & License | Privacy | Website Feedback | Contact Us | Donate | Thanks

Apache, the Apache feather logo, and OpenOffice are trademarks of The Apache Software Foundation. OpenOffice.org and the seagull logo are registered trademarks of The Apache Software Foundation. Other names appearing on the site may be trademarks of their respective owners.