Java Accessibility allows extending programs by interfacing application components with assistive technologies -such as speech recognition and audio output- for users having special needs and/or permissions. Accessibility could be featured as a two-sided conversation between an assistive technology and accessibility-friendly components of the application. Java grants access to assistive technologies for all components in VM and brings the ability to relate –direct and quickly- assistive technologies with GUI applications without interfering. Java Accessibility is mainly converted to .NET Framework through classes AccessibleObject, AccessibleRole, AccessibleSelection, AccessibleStates and Control on System.Windows.Forms API.
Principally, JLCA 3.0 helps to convert the following features of Java Accessibility: Accessible Classes, Accessible Contexts (partially) and Accessible Components.
Table 25 and Table 26 contains relevant details about Accessibility conversion. In a summarized manner, they enunciate the Accessibility features preserved in converted applications. On the other hand, they suggest the issues that the user should take care while converting applications using Accessibility.
Class / Interface in Package javax.accessibility
JLCA 3.0 Coverage
Accessible is the main interface that should be implemented by all supporting this package.
Converted to System.Windows.Forms.Control.AccessibilityObject.
This interface provides assistive technology to determine object’s action or to ask objects to perform some action.
This could be performed through AccessibilityObject members like: DefaultAction and DoDefaultAction.
These classes are used to maintain a strongly typed enumeration.
In .NET Framework, the Accessibility model has no common abstraction to display locale-based strings for roles and states.
This interface should be supported by any object that is rendered on the screen.
Converted to System.Windows.Forms.Control. It provides access to component’s properties.
AccessibleContext represents the minimum information that all accessible objects return.
Converted to AccessibleObject as it provides information about any accessible component. This information is based on the role of the visual class being used.
These are used to represent hypertext information on screen.
Some behavior to navigate accessible hypertext can be performed through methods of AccessibleObject.
This interface should be supported by any object that has an associated icon.
In .NET Framework icons-related information is not exposed through .NET Framework’s accessibility mechanism.
These are used to support relations for accessible objects.
.NET Framework does not have equivalent.
AccessibleRole determines the role of a component.
Converted to System.Windows.Forms.AccessibleRole that allows describing the generic function of components.
AccessibleSelection provides the standard mechanism for an assistive technology to determine what the current selected children are, as well as modify the selection set.
In .NET Framework, it is handled differently. A workaround could require a check on AccessibleSelection and AccessibilityObject.State.
These are used to determine component’s particular state or component’s state set.
Converted to System.Windows.Forms.AccessibleStates which allows describing the common states of components. State sets are converted through the enum’s functionality.
AccessibleTable describes a user-interface component that presents data in a two-dimensional table format.
In .NET Framework, form tables can be accessed as simple lists within instances of AccessibleObject.
This interface describes a change to the table model.
.NET Framework does not provide such functionality.
This interface provides the standard mechanism for an assistive technology to access text via its content, attributes, and spatial location.
In .NET Framework, there is no direct equivalent. Some behavior to navigate text in a character-based way could be achieved through property AccessibilityObject.Value.
This interface provides the standard mechanism for an assistive technology to determine and set the numerical value as well as get the minimum and maximum values.
Reduced behavior to provide a current state for a data type with a range of values could be performed through property AccessibilityObject.Value.
Table 25: Accessibility Conversion Coverage
Accessible Icons, Tables And Relations
These Java Accessibility features are not natively supported by .NET Framework’s accessibility model.
Accessible Texts, HyperTexts And HyperLinks
Java’s Accessibility Functionality to display text components and web content (through relations between hypertext and hyperlinks) is not converted to .NET Framework.
A workaround could require the use of components to display web content in an accessibility-like manner.
In Java, most visual classes implementing interface Accessible also inherit from java.awt.Component. Conversion of Accessible classes is carried-out to System.Windows.Forms.Control.
Java classes inheriting from Component are converted to .NET Framework classes which are not derived from System.Windows.Forms.Control. As Control is the base class for .NET Framework’s Accessibility, these kinds of Java classes could not be converted to .NET Framework accessibility-compliant classes.
Broken Inheritance happens with the conversion of classes such as: javax.swing.JMenuItem, javax.swing.JMenuBar, javax.swing.JMenu, java.awt.MenuItem, java.awt.MenuBar and java.awt.Menu. In case of these classes, the accessibility methods are not converted.
General Issues And Accessibility Context Conversion
Conversion of Java’s Accessibility to .NET Framework’s Accessibility is very limited because both models are very different and .NET Framework has no support to advanced-key features of Java accessibility.
Accessibility conversion is based on class AccessibleContext since it manages the base information for all accessible components such as: name, description, role and state.
Conversion for Accessible.getAccessibleContext, AccessibleContext.getAccessibleComponent and AccessibleContext.setAccessibleDescription is based on source code patterns.
In .NET Framework accessibility descriptions are assigned directly to the controls (in Java are managed by a context), the conversion tool then should track which context belongs to the control. This support is based on source code patterns.
User-Defined Accessible Components
In Java, implementing own Accessible components is done through interfaces Accessible and AccessibleContext (to manage user-defined accessibility information).
In .NET Framework, classes implementing the Java’s interface Accessible will inherit from System.Windows.Forms.Control as in .NET accessibility support is built-in in Windows Forms. Since there is no multiple-inheritance in C# .NET, this could lead to compilation problems if the user-defined accessible component is extending from class which is not converted to a child of the Control.
A workaround could require redesigning the target hierarchy of user-defined accessible components. Consider to derive from classes like AccessibleObject or Control.ControlAccessibleObject (to provide the necessary accessibility information).
Table 26: Accessibility Conversion Issues