accessdoor.gif (4798 bytes)duk2.gif (2714 bytes)Accessibility Proposal

Autor: Dusan Pavlica
Wednesday, January 10, 2001



  1. Analysis
  2. ABC of disability and accesssiblity
  3. What goal is neccessarily 508 ?
  4. How to make it for the Netbeans ?
  5. Example of actual state of nonaccessibility
  6. Proposal for future
  7. Links on source information


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
  • 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:

anatomy.gif (3688 bytes)
  1. The AT asks the Application for information about its components.
  2. 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.
  3. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

  1. 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
  2. Develop the compatible AT
  3. 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.

  1. Provide Accessible Names and Descriptions
  2. Do Not Customize Fonts or Colors Unnecessarily
  3. Implement Necessary Custom Colors and Fonts Via Properties
  4. Use Dynamic GUI Layout
  5. All Interface Components Must Be Keyboard Traversable
  6. Use Mnemonics and Accelerators
  7. 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.

hleper1.gif (4916 bytes)
Main menu of Accessibility Helper

hleper2.gif (10620 bytes)
There is options which shows what is able to test
helper4.gif (7326 bytes)
While is application tested, this windows is showed

bullet_sub.gif (63 bytes)Report1 of testing main UI of Netbeans: CLICK HERE
bullet_sub.gif (63 bytes)Report2 of testing main UI of Netbeans: CLICK HERE



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


Links and main information source: ... main information about accessibility from SUN Microsystem
http://javaweb.eng/access/ ... second importand source of information
http://javaweb.eng/access/site.topics/at.html ... about assistive technology ...  JavaTM Accessibility Helper Early Access v.0.2 ... The IBM Self Voicing Kit (SVK) enables automatic speaking of Java applications.




Project Features

About this Project

ui was started in November 2009, is owned by Jiří Kovalský, and has 44 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
Please Confirm