HOME > Community > Projects > ui

Accessibility Proposal

Autor: Dusan Pavlica
Wednesday, January 10, 2001

Analysis:

ABC of disability and accessibility:

What does it mean accessible application, for who is destined and why is so needed ?

Types of disability:

Color Blindness
Poor Vision
Lack of Vision
Poor Hearing
Lack of Hearing
Poor Mouse and Keyboard Use
Lack of Mouse and Keyboard Use

Types of Accessibility

Direct accessibility: Type I
Users choose the display format of and way they interact with information
Braille-n-Speak
Augmented accessibility: Type II
Electronic services support interaction with assistive technologies
Screen Readers, Screen Maginifiers, AccessX
Partial or no accessibility: Type III
Electronic services and products didn't factor accessibilty into their design
Optacon, A friend needs to read or translate information

Assistive Technology for Computers and how does it work ?

Assistive access means that system infrastructure allows add-on assistive software to transparently provide specialized input and output capabilities.
Assistive technology, also called accessibility aids, are added to computers by people who use them to make computers more accessible. Some common aids include:

Screen magnifiers help people with low vision.
Screen readers are for people who are blind.
On-screen keyboards are used by people who are unable to use a standard keyboard.
Keyboard enhancement utilities are used by people who have trouble typing and controlling a mouse.
Speech recognition programs are primarily used by people with mobility impairments.

Basic Description of Interaction Between AT and Application/Platform:

The AT asks the Application for information about its components.
The Application provides the AT with things such as what it is (e.g. a button), what its name is (e.g. Open), what it contains (e.g. its editable text), what its state is and when it
changes (e.g. button pressed), and much more.
The AT interacts with the Platform to generate and obtain lower level system events (e.g. a key press or mouse button click), to generate audio, and more

Examples why is accessibility needed:

For instance, say that a blind user has used the tab key to move to an address entry field. If the application provides no accessibility information, the screen reader may only say "Editable Text," which does not provide enough information for the user to utilize the application. When the developer takes advantage of the component properties supported by the Java[tm] platform, the computer can say something more meaningful, such as "Address, Line 1" (more on these properties in Nuts and Bolts). Clearly, this additional information is indispensable to the user.
For instance, a block font may be much easier to read than a serif font, and custom fonts could be developed that aid an even broader population.
Similarly, the ability to customize colors is a necessity for some people. In the most common case, a selection of colors with high contrast is a great benefit. A less-obvious problem is that some users can see only certain colors and may require what seem strange color combinations to make an application usable.
The accessible name of an object is often the key to making that object usable by a person with disabilities.

What goal is neccessarily achieve ?

The point of complete accessible application is to keep the conditions, which have been set in Section 508 of the Federal Rehabilitation Act. The development effort to build an accessible platform can be divided into three "phases". It should be noted that compliance with Section 508 requires the delivery of all three phases:

Build the hook and platform support
- Define the specification for the hooks then develop an implementation.
- Implement keyboard navigation and control support on all interactive UI components at the same time
- Develop the platform services that support user interaction at the same time
Develop the compatible AT
Develop the applications based on the hooks (Accessibility API)

How to make it for the Netbeans ?

The Java[tm] Accessibility API (JAAPI) is a standard extension in all releases of the Java[tm] 2 platform, and this means that the javax.accessibility package exists on any machine
where Java[tm] 2 is installed. A component can utilize this extension simply by implementing the Accessible interface, which consists of exactly one method call,
getAccessibleContext(). This call returns an instance of AccessibleContext that is specific to the component and provides the information and functionality necessary to
enable its accessibility.

The good news is that all of the standard JFC/Swing! components implement the Accessible interface, and this means that most of the work has been done for applications
developers. What follows are seven relatively simple guidelines that will finish the job.

Provide Accessible Names and Descriptions
Do Not Customize Fonts or Colors Unnecessarily
Implement Necessary Custom Colors and Fonts Via Properties
Use Dynamic GUI Layout
All Interface Components Must Be Keyboard Traversable
Use Mnemonics and Accelerators
Custom Components Must Implement Accessible

An application can work with an assistive technology only if all its GUI components implement the Accessible interface. All standard JComponent subclasses implement this interface and do everything necessary to be accessible, so this implies a corollary to this guideline: All custom components should extend a standard class as far down the JFC/Swing! inheritance hierarchy as possible.

Example: Each JFC/Swing! class contains a protected inner class that actually does the accessibility work, and the root class is JComponent.AccessibleJComponent (in reality, this class derives from an inner class of java.awt.Component, but that is beyond the scope of this discussion). When a subclass needs to extend its accessibility behavior, a protected inner class should be created that extends its superclass' inner class. In addition, the component must override getAccessibleContext(), in order to create an instance of this new accessibility class. For instance, if a programmer creates a new class WarningLight that extends JComponent, the additional code would look something like this:

    public class WarningLight extends JComponent implements Accessible {

        public AccessibleContext getAccessibleContext() {
	    // variable accessibleContext is protected in superclass
            if (accessibleContext == null) {
                accessibleContext = new AccessibleWarningLight();
            }
            return accessibleContext;
        }

        protected class AccessibleWarningLight extends AccessibleJComponent {
	    public AccessibleRole getAccessibleRole() {
	        return AccessibleRole.ALERT;
	    }
        }
	// Implementation of WarningLight omitted...

This is all the code necessary to inherit the accessibility support available in JComponent and specify this object's role as an ALERT. It is very important to understand that the inner class is actually the AccessibleContext used by assistive technologies.

Example of actual state of nonaccessibility Netbeans

JavaTM Accessibility Helper Early Access v.0.2

The JavaTM Accessibility Helper aids JavaTM software developers in making their JFC-based programs accessible to persons with disabilities. The Helper generates a report that includes a prioritized list of problems and potential problems with the application being tested. For example, the Helper verifies that all input fields in an application can be reached using only the keyboard. The Accessibility Helper does not require the source code for the application being tested and will work with any AWT- or Swing-based application.
Next paragraph is demonstrating some main windows of Accessiblity Helper and report of nonaccessibilty at the end.

Main menu of Accessibility Helper

There is options which shows what is able to test

While is application tested, this windows is showed

Report1 of testing main UI of Netbeans: CLICK HERE
Report2 of testing main UI of Netbeans: CLICK HERE

Proposal:

This paragraph is showing general Road map of implementing and testing accessibility in Netbeans. The dates are only estimated, because isn't easy to plan so far future work.
Dates of parts will be more refineing in the progres of implementing.

date	detail of work
22.2.2001	Presentation of elementary knowledge of accessibility for developers (in Prague)
during March	Analysis of all possible Accessibility Helper's error reports and plan next work in details.
April-May	First basic implementations of accessibility and elaborate test plan, write pilot documentation
June	Testing of implementation, which have been done yet
July-August	Second part of implementation and prepare second testing
September	Deeper testing of all implementations and creating documentation for developers
October	Last part of accessibility impplementation
November	Final testing, make up final document about completed work