Application Techniques
General Techniques

When designing and developing software applications and Web pages that you want to make accessible to people with disabilities, there are four general types of impairments you need to consider:

Visual impairments

Application users who are blind require text equivalents for all graphic images and videos available to the sighted user. The text needs to convey content that is conceptually equivalent to the information provided in graphical form, so that assistive technologies such as screen and braille readers can make the information fully accessible. All user interface (UI) elements must have text or menu equivalents, and blind users need keyboard equivalents for entering input that a sighted user would enter with a mouse.

To accommodate users who are color blind, you should avoid using color as the sole means of conveying information. Using fill patterns in addition to colors in graphs and other images is one strategy for supplementing information conveyed by color. Auditory cues can serve as an alternative way of presenting warnings or other content signaled by color only.

By enabling high contrast support, you can allow color-blind users and users with low vision to adjust default system colors and fonts to make areas of a window or Web page easier to distinguish. Users with low vision also use hardware or software magnifiers to enlarge the pixels on a display, and they depend on alternate text to get some of the information presented in images.

Hearing impairments

Users who are deaf or hard of hearing require visual representations of auditory information. You might need to provide alternate visual cues in your application for audible warnings, for example. Blinking text is one alternative, though the blink rate must be within a certain range to avoid causing problems for users with seizure disorders. Audio tracks require transcripts, and videos might require closed captioning.

Technology to assist with hearing impairments includes voice recognition products that can convert auditory information to text or sign language. Important also are TTY/TDD modems that connect computers with telephones and convert typed ASCII text output to Baudot code, which is what deaf individuals commonly use to communicate over the telephone.

Limited mobility

Users with limited mobility often have difficulty handling hardware and media, but input is typically their biggest challenge. Depending on the disability, mobility-impaired users might need to use voice recognition or an on-screen keyboard with an electronic switch, tracking ball, or joy stick. They might enter input at a slower pace, which means that timers and response times should be adjustable. Systems with built-in intelligence can provide cues to cut down the amount of input required. For Windows applications, the FilterKeys feature is available to slow the keyboard repeat rate, and the Windows StickyKeys feature allows users to enter multiple keystrokes such as Ctrl/Alt/Delete as key sequences.

Cognitive impairments

Reading difficulties, an inability to process visual or auditory information, problems with text input, and short-term memory problems can all affect a user's access to the content of software and Web applications. Use of clear, simple language, enforcement of consistent design, and presentation of the same information in redundant format, such as both audio and video, can all help users with cognitive impairments to access information. Providing adjustable response times is important to those whose comprehension is slower than normal. Making content available to screen readers to reinforce visual representation is another strategy for aiding comprehension of people with cognitive impairments.

General suggestions

For Web display, it is important to use elements for all markup instead of manipulating text features such as font size directly. Visual appearance should not be the only indicator of function for text elements. Element markup allows assistive technologies such as screen readers to announce text elements such as headings by their function.

Good design for accessibility benefits not only those with disabilities, but users in general. By enforcing a consistent interface design, using simple language, ensuring ease of navigation, and providing the same information in a variety of ways, you can make your applications more usable for everyone.

For more information

For general information about making websites accessible, see the World Wide Web Consortium website at http://www.w3.org/ and the Utah State University WebAim website at http://www.webaim.org.

For information on how your users can adjust various browsers for better legibility, and for ways to accommodate vision impairments in general, see the Lighthouse International website at http://www.lighthouse.org/.

Organizations that want to make their applications accessible to the disabled might have to comply with several sets of slightly different regulations and guidelines, depending on the countries in which their products will be sold or used.

Section 508

Section 508, enacted in 1998, is an extension of the U.S. Government's Rehabilitation Act. Section 508 requires that all electronic and information technology that U.S. Government agencies develop, procure, maintain, and use must be accessible to members of the general public who have disabilities. Many individual states in the U.S. have adopted these requirements as well. Organizations that offer software applications for sale to the U.S. Federal government and many state governments, as well as companies that use or sell accessibility aids, must comply with these regulations to ensure that their products qualify for purchase.

WCAG 1.0

The Section 508 guidelines are based on the accessibility guidelines published in May 1999 by the World Wide Web Consortium. These are known as the Web Content Accessibility Guidelines (WCAG) version 1.0. The WCAG 1.0 is the common basis for most accessibility guidelines and the standard for government enforcement of regulations in many countries today. These guidelines have three priority levels. Priority 1 deals with features essential for access to Web content; Priority 2 defines practices that make websites more usable and comprehensible in general, and especially to those using accessibility tools; Priority 3 describes enhanced usability features that make use of the newest technology.

Section 508 includes most of the Priority 1 WCAG recommendations, several from Priorities 2 and 3, and also a few other requirements that are not in the WCAG. The WCAG recommends that organizations strive to meet the Priority 1 and 2 guidelines.

French legislation

The French government has also enacted legislation requiring Web accessibility for those with disabilities and published criteria for conformance called AccessiWeb. AccessiWeb includes three levels, Bronze, Silver, and Gold, that correspond roughly to the three priority levels of the WCAG, but AccessiWeb promotes many level 2 and 3 requirements to higher levels and includes more detail than some of the WCAG recommendations.

U.K. legislation

The United Kingdom has passed legislation called the Disability Discrimination Act that requires websites targeting British residents to be accessible to those with disabilities. Enforcement of the U.K. law currently is based on the WCAG 1.0 Priority 1 and 2 guidelines.

Other countries

Many other countries have enacted legislation requiring government or general-use websites to be accessible to the disabled. Several of these countries explicitly require compliance with Priorities 1 and 2 of the WCAG 1.0, but a few require only Priority 1 compliance. Many other countries without legislated requirements use the WCAG standards in practice.

WCAG 2.0

The WCAG standards are currently being updated with the intention that they will become a universally accepted set of international guidelines for Web accessibility. WCAG 2.0 will focus on general principles that set out the characteristics websites must have to be accessible to users with disabilities. Separate documents will spell out the technical requirements so that these can be updated easily as technology changes without requiring updates to the general principles.

For more information

For information about the accessibility requirements of the U.S. Federal Government for software applications and websites, see the Section 508 Standards for Electronic and Information Technology at https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-section-508-standards/section-508-standards and the Guide to Section 508 Standards at https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-section-508-standards/guide-to-the-section-508-standards.

For the generally accepted international recommendations for Web accessibility, see the WCAG guidelines at http://www.w3.org/TR/WCAG10/. For the new guidelines under development, see the WCAG 2.0 guidelines at http://www.w3.org/TR/WCAG20/.

For the Web accessibility criteria adopted by the French government, see the AccessiWeb criteria at http://www.accessiweb.org.

PowerBuilder supports the following two technologies of Windows accessibility and automation -- Microsoft Active Accessibility (MSAA) and Microsoft UI Automation.

MSAA is a legacy technology introduced in Windows 95; it supports the PowerBuilder standard controls well; but it imposes major limitations on the PowerBuilder custom controls such as DataWindows. Starting from PowerBuilder 2019 R3, PowerBuilder supports a newer and more capable technology which overcomes the limitations of MSAA; this new technology called Microsoft UI Automation offers a richer set of properties and extended interfaces to manipulate not only standard controls but also custom controls (such as PowerBuilder DataWindows and child controls in DataWindows).

The support for Microsoft Active Accessibility (MSAA) and Microsoft UI Automation is enabled by default. You can disable the support using the Accessibility option in the PB.INI file:

For example,

[Data Window]
ACCESSIBILITY=0

It is recommended that you enable (value is 1) or disable (value is 0) both technologies; if you set the value to 2 or 3 (enable only one of them), some testing tools may not work well with only UIA or MSAA, and may cause the application to malfunction or crash.

cb_1.accessiblename = "Delete"
cb_1.accessibledescription = "Deletes selected text"

dw_1.Object.b_1.accessiblename = "Update"

cb_1.accessiblename = "Delete"
cb_1.accessibledescription = "Deletes selected text"
cb_1.accessiblerole = pushbuttonrole!

dw_1.Object.b_1.accessiblename = "Update"

string ls_data
dw_1.Object.b_1.AccessibleRole = 43
ls_data = dw_1.Describe("b_1.AccessibleRole")

A Voluntary Product Accessibility Template (VPAT) is a table designed to help U.S. Federal officials make preliminary assessments of accessibility compliance for products offered to the government for sale. A VPAT lists the criteria for compliance with accessibility requirements for various types of products and provides columns where you can indicate and comment on how your product meets them.

VPATs are available for software applications and operating systems, Web-based Internet information and applications, and other types of products. Even if you do not need to fill out a VPAT, reviewing the template for your type of product can give you a clearer understanding of the requirements of Section 508 for software and Web applications.

To view the various VPATs, see the Information Technology Industry Council website at http://www.itic.org.

You should read PowerBuilder VPATs carefully and assess the applicability of any defects or exceptions listed for your particular application.

The MSAA 2.0 Software Development Kit (SDK) includes several tools for verifying the MSAA compliance of your application. They include AccExplorer, Accessible Event Watcher, and Object Inspector. These tools are available on the Microsoft website at http://www.microsoft.com/en-us/download/default.aspx.

To test the user experience of your application for those with disabilities directly, you can use various methods. For example, try using a text-only browser; enter input using only the keyboard; use the application with a screen reader such as JAWS, Window-Eyes, Hal, or Supernova.

Several commercial applications are also available for testing Web sites for compliance with Section 508 and the WCAG 1.0.

For more information

For a checklist for testing WCAG 1.0 compliance, see the appendix to the WCAG 1.0 on the W3C website at http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/full-checklist. The W3C website also lists and evaluates tools for testing accessibility.