Bug 158394 - Add accessible relations
Summary: Add accessible relations
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.3   Edit
Hardware: PC Linux-GTK
: P3 enhancement (vote)
Target Milestone: 4.2   Edit
Assignee: Carolyn MacLeod CLA
QA Contact:
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks: 158836
  Show dependency tree
 
Reported: 2006-09-22 18:39 EDT by Larry Weiss CLA
Modified: 2011-10-20 11:28 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Larry Weiss CLA 2006-09-22 18:39:38 EDT
As applications have evolved beyond combinations of standard controls, the sematic relationships between controls has changed. For example, modeling applications that build on the rich frameworks of GEF and GMF, can display unique controls that often have rich semantic relations to other widgets. To allow these applications to expose these rich semantics, the eclipse accessibility package needs to include the support from the native accessibility support.

Linux (RHEL 5 or FC5) ATK defines accessible relations that have no equivalent in the org.eclipse.swt.accessibility.ACC class. (See http://developer.gnome.org/doc/API/2.0/atk/AtkRelation.html#AtkRelationType.) Custom widget authors (including Draw2d and GMF authors) need the ability to expose these existing relations as well as an ability to define custom relations. (See http://developer.gnome.org/doc/API/2.0/atk/AtkRelation.html#atk-relation-type-register.)

The mechanism to implement this functionality on Windows will be added soon.
Comment 1 Carolyn MacLeod CLA 2007-01-02 15:35:57 EST
*** Bug 167397 has been marked as a duplicate of this bug. ***
Comment 2 Connie Martin-Wilson CLA 2007-01-11 12:41:27 EST
We have implemented all APIs in current AccessibleControlListener. But it still 
did not work. 

In MSAA, there are 2 important APIs: accNavigate and get_accParent. The 
AccessibleControlListener does not expose those APIs, so we can not implement 
them. Some screen readers depend those APIs to navigate the tree. Without those 
APIs, some screen readers(like WindowEyes) won't read the tree item. I think 
those APIs are what wasleski said "the enhancement for the additional 
navigation capability". That is what we need. 
Comment 3 Carolyn MacLeod CLA 2011-10-20 11:28:56 EDT
Accessible.addRelation and removeRelation were added in eclipse 3.6, and they include all relation types:
RELATION_CONTROLLED_BY/RELATION_CONTROLLER_FOR
RELATION_DESCRIBED_BY/RELATION_DESCRIPTION_FOR
RELATION_EMBEDDED_BY/RELATION_EMBEDS
RELATION_FLOWS_FROM/RELATION_FLOWS_TO
RELATION_LABEL_FOR/RELATION_LABELLED_BY
RELATION_MEMBER_OF
RELATION_NODE_CHILD_OF
RELATION_PARENT_WINDOW_OF
RELATION_POPUP_FOR
RELATION_SUBWINDOW_OF

We will not be supporting custom relations. Widget authors may be able to use custom attributes if they get together with screen reader authors to support them.

(In reply to comment #2)
We will not be supporting accNavigate. In the documentation for accNavigate, Microsoft says: "Note: The accNavigate method is deprecated and should not be used."

get_accParent is not exposed as api, however the concept of parent/child accessibles was introduced in eclipse 3.6, and creating a parent/child hierarchy of accessibles will correctly report the get_accParent and getChildren to AT without custom widget authors needing to explicitly state them.